The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
The diameter layer is responsible for maintaining connections to other diameter peers. This includes connecting to the peers, sending watch dogs (keep alive), and disconnecting from the peers.
The SCA BB diameter infrastructure includes several components: the standard diameter stack, the peer table, the routing table, and the forwarding scheme table, which defines the forwarding method for each realm. The supported forwarding methods are high availability (HA) and load balancing (LB).
The main entity in the diameter infrastructure is the peer table. The peer table includes all the peers that the SCE should connect to at the transport level. Each peer is defined by a Uniform Resource Identifier (URI) (usually ip:port).
The routing table and the peer table support online configuration, that is, add and remove commands are supported while the diameter stack is up. The peer table and the routing table configurations are saved to the running configuration.
As shown in Figure A-2, after the establishment of a connection and successful exchange of Capability Exchange Request (CER) and Capability Exchange Answer (CEA) messages, the peers send watch dog messages. Even if a single watch dog message is not answered, the connection is disconnected and is considered down. The SCE tries to reestablish TCP connection once in every Tx timer time interval. When TCP connection is reestablished, the peer connection is still considered to be down until a Watch Dog Request (WDR) and Watch Dog Answer (WDA) messages are exchanged.
The standard diameter stack is used for sending and receiving diameter messages. The diameter stack supports both the Gx and Gy interfaces. There is only one diameter stack instance.
The diameter stack includes the following general configurations:
•Tx timeout
•Logging level
•Port
•Realm
The diameter stack holds general message statistics for non-application-specific messages.
The diameter stack includes start and stop operations. To prevent state loss, you cannot stop the stack while one of the interfaces is up.
The peer table lists all the peers with which the SCE has a direct connection. The information for each entry includes:
•Peer host—The host IP
•Peer port
•State—Nonconfigurable (Reflects the connection state (open or closed)).
Table 2-1 lists the CLI commands used to configure and monitor the Peer table.
Example for adding a peer:
SCE8000(config)#diameter peer test_peer peer-host 1.1.1.1
Note Removing a peer from the peer table removes all the peer-related configuration information from the routing table and from the forwarding scheme table.
Example for executing a show command:
SCE8000> show diameter peer-table
Peer Table:
-------------------------------------------------------------
| Name | Host | Port | State |
-------------------------------------------------------------
| SER_GX | 10.121.64.38 | 3869 | Up |
| SER_GY | 10.121.64.46 | 3870 | Up |
-------------------------------------------------------------
The Peer table lists the peers and their state. The state can be Up, Down, or — (which means the stack is not currently activated).
Note A peer is defined by a URI. Therefore, the same IP cannot be used on different ports to distinguish between two servers except when a domain name server (DNS) is used.
The routing table contains the peer application support and the forwarding scheme priority information. Each entry in the routing table includes the peer name, supported application, realm, and priority.
When SCE sends an application message, it is sent to a realm and not to a specific server. In the Gx interface there is one realm with many peers that supporting that realm. In the Gy interface there can be several realms. Each peer can support both interfaces.
Table 2-2 lists the CLI commands used to configure and monitor the Routing table.
Example for adding a route:
SCE8000(config)# diameter realm test_realm.cisco.com Gy peer test_peer priority 95
Example for showing the route table:
SCE8000> show diameter routing-table
---------------------------------------------------------
| Name | Realm | Application | Priority |
---------------------------------------------------------
| SER_GY | cisco.com | Gy | 0 |
| SER_GX | cisco.com | Gx | 0 |
---------------------------------------------------------
SCE8000>
In the example, the peer named SER_GY supports the Gy application on the cisco.com realm.
Diameter networks support load balancing (LB) and high availability (HA) schemes.
The diameter protocol sends messages to a realm and not to a specific server, letting other nodes in the diameter network take care of HA and LB schemes. Some diameter networks require that LB and HA be handled by a network client. This is achieved by sending messages to a specific server that acts as the network client.
For information about load balancing and failover troubleshooting for the Gx interface, see the "High Availability for the Gx Interface" section. For information about load balancing and failover troubleshooting for the Gy interface, see the "Gy Interface Failover Support" section.
The Forwarding Scheme table defines the HA and LB scheme per each realm and application (one scheme per each combination of realm and application).
The following options are supported:
•LB with default HA
•HA with no LB
Table 2-3 lists the forwarding scheme examples for load balancing and high availability. For information on configuring the diameter forwarding scheme, see the "Diameter Forwarding Mode CLI Commands" section.
Load balancing is completed by round robin, using the available servers. The available servers are round robin cycled per session and not per message, that is, the messages for a specific session are all sent to the same server.
When a server fails, it is removed from the round robin.
If a server is removed from the round robin and a session has already initiated, an alternative server completes the session. The application can either start a new session or continue with the alternate server. For information on configuring the load balancing scheme, see the"Diameter Forwarding Mode CLI Commands" section.
When the high availably scheme is used, there is no load balancing between servers. The high availability scheme is strictly an active/standby scheme.
Each server is assigned a priority. Only the server with the highest priority handles the session. When the active server fails, all the new sessions are started on the next server in the priority list order. This mode supports stickiness, that is, when a failed server is back up, new sessions are forwarded to it, but already existing sessions remain forwarded to the secondary server unless transferred by an application decision. For information on configuring the high availability (failover) scheme, see the "Diameter Forwarding Mode CLI Commands" section.
This section contains the information and instructions to configure and monitor the diameter forwarding, load balancing, and high availability schemes. This section contains the following subsections:
•Diameter Forwarding Mode CLI Commands
Table 2-4 lists the CLI commands used to configure and monitor diameter stack support. All the commands, except origin-realm and diameter port, can be set while the stack is running.
Example for showing the diameter counters:
SCE8000> show diameter counters
WDR Sent : 150
WDR Received : 182
WDA Sent : 182
WDA Received : 150
CER Sent : 3
CER Received : 0
CEA Sent : 0
CEA Received : 3
DPR Sent : 0
PDA Sent : 1
Table 2-5 lists the CLI commands used to configure and monitor the diameter forwarding mode.
Example for configuring load balancing:
SCE8000(config)# diameter realm test_realm.cisco.com Gx forwarding-mode load-balancing
Example for configuring high availability:
SCE8000(config)# diameter realm realm test_realm.cisco.com Gy forwarding-mode
high-availability shared-session-on stickiness-off