Using FQDNs to Access CCFs over Diameter

You can configure the SBC with a primary and, if desired, a secondary FQDN to access CCF servers over Diameter. You do this by configuring the diameter account-server with an FQDN. The SBC uses DNS to resolve the FQDN into an IP list and, if provided, route the traffic based on DNS-provided priority and weight. The SBC supports resolution of CCF FQDNs from SRV, and A records.

Upon configuration, the SBC can perform a DNS resolution procedure to resolve a configured FQDN to one or more IP addresses. When the SBC receives the DNS response, it extracts the IP address(es). Each IP address corresponds to one CCF. For each IP address, the SBC next establishes a TCP connection and performs a CER and CEA exchange, which makes that CCF eligible to exchange Rf traffic. Having established a connection with these servers, the SBC performs the same diameter procedures and processes it performs when configured with an IP address.

When you configure an account-server, you can specify the server hostname with an FQDN instead of an IP address. In addition, you specify the realm to use for DNS queries. Upon activation, the SBC uses DNS to:

• Identify one or more IP addresses that correspond to your FQDN.
• Utilize the port provided in the response.

  Note:

  If there is no port or port 0 in the response, the SBC contacts the CCF via the port you configure in your account-server.
• Utilize DNS-provided TTL to start the timer used to determine when to re-send an SRV query.
• Utilize DNS-provided priority and weight to determine the order with which to send ACR traffic.

  Note:

  If there is no priority or weight in the DNS response, the SBC uses round robin to define the order it uses to contact CCFs.
• Provide dynamic updates to CCF servers, and perform CCF addition or deletion.
• Achieve runtime scaling of CCF servers without additional configuration.

Ensuing SBC behavior is dependent on the DNS response:

• Single IP address received—Priority is irrelevant and the SBC simply uses the address provided as the only CCF target.
• Multiple IP addresses received—The receipt of multiple addresses makes multiple CCFs available for operations without configuration changes.

  The SBC creates a table of CCF resolutions, including DNS priority and weightage, and creates a target list. It then creates TCP connections, performs CER/CEA exchanges with all IP addresses, and routes ACRs to CCFs using the established order.

• Error/No Response—If the SBC receives an error response or no response to the SRV-query, it starts an internal DNS retry timer before it attempts to contact the servers. Also, if it finds the primary DNS Server is down, the SBC retries using your configured secondary DNS Server.
• TTL below 30 secs—If the SBC receives a TTL that is less than 30 secs for any IP address, it uses 30 seconds as the TTL. This ensures that the system does not become overloaded by an incorrect configuration.
• Zero weightage—The SBC complies with RFC 2873 by ignoring any resolutions that include a weight of zero.

If the SBC receives 3002, 3004 or 4002 error response codes from the CCF, it retries sending the ACR.

The SBC provides traffic statistics on all the IP addresses resolved against an FQDN for both the primary and secondary pools.

Traps and Alarms

For error responses received against accounting or non-accounting requests from the CCF, including CER and DWR as well as ACR issues, the SBC issues SNMP traps and raises local alarms. Examples of these errors include determining the ACR/AVP format or content is malformed or unsupported. Examples of the applicable alarms are presented below.

ID         Task    Severity        First Occurred          Last Occurred
327708     3029     5            2021-11-16 10:31:18     2021-11-16 10:31:18
Count   Description
1       Diameter Accounting Server lost connection!!! 
327709     3029     5            2021-11-1610:33:24      2021-11-16 10:33:24 
Count   Description 
1       Diameter Accounting Server Returned Error Result Code|10.196.2.7:3869-3002

The applicable Traps, within ap-diameter.mib, include apDiameterSrvrErrorResultTrap (1.3.6.1.4.1.9148.3.13.1.2.2.0.5) and apDiameterSrvrSuccessResultTrap (1.3.6.1.4.1.9148.3.13.1.2.2.0.6).

Configuration that Applies to FQDN CCFs

Key configuration on the account-config includes:

• The dns-realm parameter specifies the realm you use for resolving CCF FQDNs. This realm needs a network-interface with appropriate DNS configuration.
• Enabling the use of affinity for CCF sessions

  The maintain-ccf-affinity parameter enables the SBC to establish CCF affinity for ACR sessions, simplifying the reconciliation of ACRs by keeping associated records on the same CCF. Affinity applies to CCFs that you configure with either FQDN and IP address. For FQDN, the SBC still uses the mechanisms described above to determine the first access to a CCF. For determining traffic targets after the first access, the SBC prioritizes affinity over pool membership and DNS priority/weightage.

  To support affinity, the SBC keeps a mapping between CCF and ACR sessions so that it sends all new ACRs for an existing session to the same CCF. The SBC breaks affinity when a selected CCF goes down or is removed from the DNS response.

• The next-priority-selection-interval parameter, which specifies in minutes how long the system waits after experiencing an overload scenario before it refers to the next priority.
• The send-disconnect-peer-msg parameter, which enables the system to send a DPR to the CCF before disconnecting from the CCF.
• The strategy parameter specifies how to select from a pool's CCF servers to distribute CCF traffic. This configuration applies to FQDN CCFs when the DNS response does not include priority/weight.

Key configuration on the account-sever includes:

• The hostname parameter specifies the FQDN you use to fetch DNS resolution of your pool's CCF servers.
• The fqdn-pool-type parameter specifies whether the pool established by the DNS resolution is the primary or secondary pool of CCF servers.