Product Documentation
ADC
14.1 - Current Release 13.1 13.0 12.1
View PDF

Configure diameter load balancing

September 27, 2023
Contributed by: 
C S

The Diameter protocol is a next generation Authentication, Authorization, and Accounting (AAA) signaling protocol used mainly on mobile devices such as laptops and mobile phones. It is a peer-to-peer protocol, as opposed to the traditional client-server model used by most other protocols. However, in most Diameter deployments, the clients originates the request and the server responds to the request.

When Diameter messages are exchanged, the Diameter server usually does much more processing than does the Diameter client. With the increase in control plane signaling volume, the Diameter server becomes a bottleneck. Therefore, Diameter messages must be load balanced to multiple servers. A virtual server performing load balancing of Diameter messages provides the following benefits:

  • Lighter load on Diameter servers, which translates to faster response time to end users.
  • Server health monitoring and better failover capabilities.
  • Better scalability in terms of server addition without changing client configuration.
  • High availability.
  • SSL-Diameter offloading.

The following figure shows a Diameter system in a NetScaler deployment:

diameter-system

A Diameter system has the following components:

  • Diameter client. Supports Diameter client applications in addition to the base protocol. Diameter clients are often implemented in devices at the edge of a network and provide access control services for that network. Typical examples of Diameter clients are a Network Access Server (NAS) and the Mobile IP Foreign Agent (FA).
  • Diameter agent. Provides relay, proxy, redirect, or translation services. The NetScaler appliance (configured with a Diameter load balancing virtual server) plays the role of a Diameter agent.
  • Diameter server. Handles the authentication, authorization, and accounting requests for a particular realm. A Diameter server must support Diameter server applications in addition to the base protocol.

In a typical Diameter topology, when an end-user device (such as a mobile phone) needs a service, it sends a request to a Diameter client. Each Diameter client establishes a single connection (TCP connection—SCTP is not yet supported) with a Diameter server as specified by the Diameter base-protocol RFC 6733. The connection is long-lived and all messages between the two Diameter nodes (client and server) are exchanged over this connection. The NetScaler uses message based load balancing.

Example:

A mobile service provider uses Diameter for its billing system. When a subscriber uses a prepaid number, the Diameter client repeatedly sends requests to the server to check the available balance. The Diameter protocol establishes a connection between the client and the server, and all requests are exchanged over that connection. Connection based load balancing would be pointless, because there is only one connection. However, with the large number of messages on the connection, message based load balancing expedites the process of billing the prepaid mobile subscriber.

How diameter load balancing works

A Diameter client opens a connection to the NetScaler appliance and sends a Diameter Capability Exchange Request (CER) message. The NetScaler selects a diameter server, opens a connection to the server, and forwards the CER message to the server. The server reads the client identity and determines that it is directly connected to the client.

The Diameter server prepares the Diameter handshake reply and sends it to the NetScaler appliance. The appliance modifies the handshake and inserts its own identity. At this point, the Diameter client determines that it is directly connected to the NetScaler (the agent).

Note:

All Diameter request messages from the client are queued on the selected server until the Diameter handshake is complete. The packets are forwarded to the server when the handshake is complete.

Load balancing diameter traffic

When a client sends a request to the NetScaler appliance, the appliance parses the request and contextually load balances it to a Diameter server based on a persist AVP. The appliance has advertised the client identity to the server, so it does not add route entries, because the server is expecting messages directly from client.

Server initiated requests are not as frequent as client requests. Server initiated requests are similar to client initiated requests, except:

  • Since messages are received from multiple servers, the appliance maintains the transaction state by adding a unique Hop by Hop (HbyH) number to each forwarded request message. When the message response arrives (with same HbyH number), the appliance translates this HbyH number to the HbyH number that was received on the server when the request arrived.
  • The NetScaler appliance adds a route entry by putting its identity, because the client sees the appliance as a relay agent.

Note: If a Diameter message spans more than one packet, the appliance accumulates the packets in an incomplete header queue and forwards them to the server when the full message is accumulated. Similarly, if a single packet contains more than one Diameter message, the appliance splits the packet and forwards the messages to servers as determined by the load balancing virtual server.

Disconnect a session

A Disconnect Peer Request (DPR) indicates the peer’s intention of closing the connection, with the reason for closing the connection. The peer replies with a DPA (TCP always provides successful DPA).

  • When the NetScaler appliance receives a DPR from the client, it broadcasts the DPR to all servers and immediately replies with a DPA to the client. The servers reply with DPAs, but the appliance ignores them. The client sends a FIN, which the appliance broadcasts to all servers.
  • When the appliance receives a DPR from the server, it replies with a DPA to that server alone, and does not remove the server from the reuse pool. When the server sends a FIN, the appliance replies with FIN/ACK and removes connections from the reuse pool.
  • If the appliance receives a FIN from the client, it sends the client a FIN/ACK, broadcasts the FIN, and immediately removes the server connection from the reuse pool.
  • If the appliance receives a FIN from the server, it sends a FIN/ACK and removes it from reuse pool. Any new message for this server is sent on a new connection.

Configure load balancing for diameter traffic

To configure the NetScaler appliance to load balance diameter traffic, you must first set the Diameter parameters on the appliance, then add the diameter monitor, add the diameter services, bind the services to the monitor, add the diameter load balancing virtual server, and bind the services to the virtual server.

To configure load balancing for diameter traffic by using the command line interface

Configure the diameter parameters.

set ns diameter -identity <string> -realm <string> -serverClosePropagation <YES|NO>
<!--NeedCopy-->

Example:

set ns diameter -identity mydomain.org -realm org -serverClosePropagation YES
<!--NeedCopy-->

Add a Diameter monitor.

add lb monitor <monitorName> DIAMETER -originHost <string> -originRealm <string>
<!--NeedCopy-->

Example:

add lb monitor diameter_mon DIAMETER -originHost mydomain.org -originRealm org
<!--NeedCopy-->

Create the Diameter services.

add service <name> <IP> DIAMETER <port>
<!--NeedCopy-->

Example:

add service diameter_svc0 10.102.82.86 DIAMETER 3868

add service diameter_svc1 10.102.82.87 DIAMETER 3868

add service diameter_svc2 10.102.82.88 DIAMETER 3868

add service diameter_svc3 10.102.82.89 DIAMETER 3868
<!--NeedCopy-->

Bind the Diameter services to the Diameter monitor.

bind service <name>@ monitorName <monitorName>
<!--NeedCopy-->

Example:

bind service diameter_svc0 -monitorName diameter_mon

bind service diameter_svc1 -monitorName diameter_mon

bind service diameter_svc2 -monitorName diameter_mon

bind service diameter_svc3 -monitorName diameter_mon
<!--NeedCopy-->

Add a Diameter load balancing virtual server with Diameter persistence.

add lb vserver <name> DIAMETER <IPAddress> <port> -persistenceType DIAMETER -persistAVPno <positive_integer>
<!--NeedCopy-->

Example:

add lb vserver diameter_vs DIAMETER 10.102.112.152 3868 -persistenceType DIAMETER -persistAVPno 263
<!--NeedCopy-->

Bind the Diameter services to the Diameter load balancing virtual server.

bind lb vserver <name> <serviceName>
<!--NeedCopy-->

Example:

bind lb vserver diameter_vs diameter_svc0

bind lb vserver diameter_vs diameter_svc1

bind lb vserver diameter_vs diameter_svc2

bind lb vserver diameter_vs diameter_svc3
<!--NeedCopy-->

Save the configuration.

save ns config
<!--NeedCopy-->

Note: You can also configure load balancing of Diameter traffic over SSL by using the SSL_DIAMETER service type.

To configure load balancing for Diameter traffic by using the configuration utility

  1. Navigate to System > Settings > Change Diameter Parameters and set the diameter parameters.
  2. Navigate to Traffic Management > Load Balancing > Virtual Servers, and create a load balancing virtual server of type Diameter.
  3. Create a service of type Diameter.
  4. Create a monitor of type Diameter. In Special parameters, set the origin host and origin realm.
  5. Bind the monitor to the service, and bind the service to the Diameter virtual server.
  6. In Advanced Settings, click Persistence, specify the diameter, and enter a persistence AVP number.
  7. Click Save, and click Done.
Configure diameter load balancing
September 27, 2023
Contributed by: 
C S
September 27, 2023
Contributed by: 
C S

In this article

Site feedback | Your privacy choices footer linkYour Privacy Choices | Privacy and legal terms | Cookie preferences | Consent settings | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.