The Diameter protocol provides message-routing functionality that the BIG-IP® system supports in a load-balancing configuration.
In a message routing configuration, the BIG-IP system manages requests and responses among peers. The following illustration shows a Diameter routing configuration with requests from Client 1 and Client 2 to servers located in different destination realms, Realm-A and Realm-B.
A Diameter message routing configuration
A typical Diameter message routing configuration with two realms involves configuring the following items.
|Pool||A pool for each realm directs Diameter traffic to servers.|
|Session profile||A session profile for each realm configures a session as a set of messages between two Diameter nodes on behalf of a user.|
|Transport configuration||An optional transport configuration for each realm defines how the BIG-IP system connects with the servers on your network when routing messages. You can assign a transport configuration to a virtual server or peer, as needed.|
|Peer||Each BIG-IP message-routing peer routes messages to a destination host. In this example, BIG-IP message-routing peers route messages to 10.10.10.1:3868, 10.10.10.2:3868, and 10.10.10.3:3868.|
|Static Route||Each static route specifies a set of peers in a destination realm to use in forwarding messages. In this example, Realm-A includes Peer 1 , and Realm-B includes Peer 2.|
|Router profile||A router profile configures Diameter message routing parameters and static routes to be used by a virtual server in routing Diameter messages.|
|Virtual server||Manages Diameter traffic to and from each realm and pool members.|
The Diameter session profile includes Diameter protocol parameters that can be used by a virtual server or transport configuration in managing Diameter traffic. The profile enables you to configure the properties of a Diameter session as a set of messages between two diameter nodes on behalf of a user. Note that those same two diameter nodes can also include multiple active user sessions. The session profile provides you with parameters to configure settings for timeout, watchdog failures, and message-size, as well as persistence, rewrite, and capabilities-handshake functionality.
|Settings||Configure timeout functionality, watchdog failures, and message size.|
|Persistence||Configure persistence functionality, including a type, AVP, and timeout.|
|Rewrite||Provide AVP rewriting to conceal clients from servers, as well as to conceal servers from clients.|
|Capabilities Handshake||When the Diameter session profile is configured as a proxy, the BIG-IP system generates capabilities-exchange messages, sending a Capabilities-Exchange-Request (CER) and responding with a Capabilities-Exchange-Answer (CEA), to establish a diameter session with connected nodes.|
You can apply different session profiles to different transport configurations, and then apply the different transport configurations to different message routing peers, which point to different physical pools. You can also apply different session profiles by applying one session profile to the transport configuration, and a different session profile to the virtual server.
A message routing peer defines how the BIG-IP® system routes messages to destination hosts. When you configure a message routing peer, you define a pool of destination hosts, and a connection method for them, an optional transport configuration configured with a Diameter session profile, as needed, the number of connections to a destination host, and a ratio value for selection of a peer. After defining the peers, you can use those peers in configuring static routes.
When an inband monitor is assigned to a Diameter message routing pool, the inband monitor marks a pool member down when the total failures from the pool member exceeds or equals the maximum number of failures configured. When a pool member is marked down, the connection remains alive, but load balancing functions only among the remaining pool members within the same pool. The active Diameter monitor marks the pool member up when service is restored.
If a peer does not specify a pool, the BIG-IP system uses the destination IP address and port of the ingress message's connection. If a peer specifies a pool without pool members, the message is unroutable.
When you configure a message routing peer to use a transport configuration, you can enable that peer to use auto-initialization functionality, which automatically creates outbound connections to active pool members in the peer's specified pool. In order for the auto-initialization functionality to work, you need to specify the peer in a static route, and then specify that static route in a router profile that is assigned to a message routing virtual server, The BIG-IP system automatically initiates a connection for each router profile that contains the peer. You enable auto-initialization functionality for a peer by selecting the Auto-Initialization Enabled check box. Additionally, you can specify an Auto-Initialization Interval value, which compensates for latency, to verify the connection between the BIG-IP system and pool members (ranging from 500ms through 65535ms, with a default value of 5000ms). If a connection does not exist, auto-initialization functionality attempts to reestablish a connection.
If a peer does not specify a transport configuration, the BIG-IP system uses the transport type of the message's originating connection.
When you configure a Diameter static route, the BIG-IP® system provides two modes for peer selection: sequential and ratio.
In sequential mode, the BIG-IP system uses peers in the order specified by the Peers Selected list. If a message is retried, the next peer in the Peers Selected list is used.
In ratio mode, the BIG-IP system uses peers in accordance with the peer's ratio value, which you specify when configuring each peer. The relative ratio value for each peer determines whether a peer is selected from the list. For example, a peer with a ratio value of 1 is typically selected over a peer with a ratio value of 2. The lower the ratio value, the greater the probability for selection.
Before configuring a mode for peer selection, you must first configure each peer, using the Peer tab, to include peers in the Available list.
In the rare instance when a Diameter peer connects to the BIG-IP® system, and the BIG-IP system simultaneously initiates a connection to that peer, the BIG-IP system resolves the connection conflict by means of an election process. The BIG-IP system uses an algorithm that evaluates and resolves which connection to use (whereupon the election winner drops the unused connection), based on the Origin-Host Attribute-Value Pair (AVP).
This election process is enabled only when the Diameter peer Connection Mode is set to Per Peer and the Number of Connections value equals 1.
In an active-standby configuration, the election process runs only on the active device. If mirroring is enabled, the used connection is mirrored on the standby device.
You can examine the election process results in the Diameter log files. The following examples show typical log messages for the election process.
|Election process results||DIAMETER: Election process won | lost between peer peer-host-name and big-ip-host-name.|
|Closing outgoing connection due to winning election||DIAMETER: Closing outgoing connection to ip:port-id closed by election process.|
The message routing functionality Static Routes enables you to configure a route that specifies a set of peers to use in forwarding messages. When you configure a static route, you can specify an application ID, destination realm, origin realm, virtual server, peer selection mode, and peers.
The required static route attributes (each of which must match the respective request parameter) are prioritized in this order:
A static route is a default route when each of these attributes is set to the default (wildcard) value.
With the Diameter router profile, you can configure Diameter routing parameters to be used by a virtual server in routing Diameter messages. When you configure a Diameter router profile, you can specify persistence, rewrite, and capabilities-handshake functionality.
A Diameter proxy and router implementation can mirror client and server connections.
In a high-availability configuration, the active device mirrors connections (including auto-initialization connections) on the standby device, creating and maintaining the same state on each device. The standby device, however, does not route the messages. Instead the standby device stores the messages until the active device notifies the standby device that the message has been routed. This enables the standby device to deliver the message to the equivalent connection for egress processing. A sweeper drops the messages if the standby device stores them longer than the specified value. Enabling this setting ensures a higher level of connection reliability, but it can also affect system performance. As the mirrored messages flow though the client-side connection, normal ingress iRule events and routing occur.
This list specifies supported Diameter Attribute-Value Pair (AVP) names.
Complete these tasks to configure Diameter message routing on a BIG-IP® system.
|AVP||Enables persistence as determined by the AVP within the message.|
|Custom||Enables persistence as determined by a custom key specified within an iRule.|
|SNAT||The system uses the specified SNAT pool for source address translation.|
The system uses the self IP addresses of BIG-IP as the translation addresses.
The system does not translate source addresses.
|Per Blade||The number of connections are distributed and controlled per blade on a VIPRION® system.|
|Per Peer||(Default) The number of connections to a remote host is per peer.|
|Per TMM||The number of connections to a remote host is per TMM on the BIG-IP system.|
|Per Client||The number of connections to a remote host is per client connection. Responses are delivered to the connection initiating the request. This option is typically used when implementing a firewall, because of its restrictive functionality.|
|Ratio||Peer selection is based on the ratio that is set for each peer in the Selected list.|
|Sequential||Peer selection is based on the order of the peers in the Selected list.|
The final task in configuring Diameter message routing for load balancing is to define a virtual server that references the custom Diameter profile and Router profile that you created in previous tasks.
The virtual server that references the Diameter session profile and Router profile appears in the Virtual Server list.
You can configure the BIG-IP® system to monitor pool member health using a Diameter monitor. Use a Diameter monitor to check the health of a host with an active Diameter session. The Diameter monitor also monitors a Diameter connection independently of a specific Diameter session and marks a host that had been marked down, but is online again, as available.
Perform these tasks to configure health monitors and apply the monitors to a pool:
You can view statistics for Diameter sessions and routes.