In this section:


This functionality is currently only available in an OpenStack cloud environment.

In a non-cloud environment, remote policy servers are configured on the SBC SWe to interact with an external policy server using the external policy server IP addresses. The SBC SWe gateway-related configuration is done in policy servers directly, and when the SBC SWe comes up, it establishes the connection with configured policy servers. A cloud environment includes a PSX cluster (consisting of multiple instances of policy servers), an SBC SWe cluster (consisting of multiple instances of SBCs) and a DNS server. These clusters are identified with a logical cluster ID/Name and FQDN.

A PSX cluster acts as a single Diameter+ policy engine for an SBC cluster, and the SBC cluster acts as a single gateway for the PSX cluster. One PSX cluster can act as a policy engine for more than one SBC cluster; thus, the same policy will be applied to all the SBC instances in a cluster. The DNS server will know all policy server instances in a PSX cluster.


You can configure the PSX cluster FQDN in an SBC instance or seed it in the SBC instance during instantiation. The SBC instance learns a list of IP addresses of remote policy server instances in a PSX cluster by resolving the PSX cluster's FQDN with the help of the DNS server. This enables SBC to talk to multiple PSX instances of a PSX cluster by simply providing the FQDN of the PSX cluster.

Functionality

In a cloud environment, the PSX cluster acts as a single Diameter+ policy engine for an SBC SWe cluster. The PSX cluster, which has many instances of policy servers, is identified by a single FQDN and cluster ID/Name. In a cloud SBC instance, the PSX cluster FQDN is configured or seeded during instantiation. The SBC will also include information about the policy server count. This is the count of policy server instances where the SBC establishes a D+ connection on receiving the DNS A/AAAA response. The cloud SBC instance queries the DNS server to resolve the PSX cluster's FQDN. The DNS server returns the list of IP addresses of instances of policy servers belonging to PSX cluster FQDN. On receiving the policy server IP address list, the SBC randomly picks policy servers and establishes the D+ connection with policy server instances by sending a registration request. The SBC clusterID is sent in the policy server registration instead of the gateway name whenever the remote server is configured with the FQDN. The PSX then contains a gateway entry with a clusterID as the gateway name.

PSX cluster FQDN support behavior:

  • From the Remote Server configuration, the user enters the PSX cluster FQDN in the FQDN field and specify the maxPolicyServerCount to indicate the number of PSX clients to configure based on the DNS response.
  • Once configured, the SBC sends a DNS query to the DNS server to resolve the FQDN configured. In response to the DNS A/AAAA query request, the SBC can get a single IP address or a list of IP addresses for different PSX cluster policy server instances. The SBC randomly selects a configurable number of IP addresses from the IP list received in the DNS A/AA response.
  • The SBC creates the policy clients for each randomly selected IP and establishes a D+ connection with these policy server instances using the registration mechanism and the clusterID as the gateway name. All policy clients are created using the specified mode (Active/Standby/Out Of Service/Alternate). 
  • The DNS may give fewer IP addresses than the configured number of PSX clients to create or no IP addresses at all. In this case, the SBC queries the DNS every 10 seconds to find more IP addresses and overcome the shortage of PSX clients.
  • The remote server modification triggers a DNS query to resolve the new FQDN for IP addresses. The existing PSX clients are modified accordingly and reregistered with the new PSX servers. The addition or deletion of PSX clients is done based on the change in maxPolicyServerCount value during the modification operation.
  • If the SBC encounters congested PSX instances that are rendered unreachable or down, it queries the DNS for a fresh set of IP addresses and attempts to replace the defunct PSX clients with unused IP addresses picked from the latest DNS records list to re-register with them. 

Load Balancing

The following load-balancing assumptions are made with respect to configuring the DNS server:  

  • The DNS server may be responsible for load balancing of PSX cluster instances. A PSX cluster will be associated with a PSX cluster FQDN and can have many policy server instances. The DNS server will contain information about all the policy server instances in a PSX cluster. The DNS can achieve load balancing in the following manner:
    • When receiving a resolve request for a PSX FQDN from an SBC instance, the DNS server can respond with a subset of IP addresses it knows.
    • If the DNS server receives a resolve request multiple times for a PSX FQDN, it may return a different set of IPs for each request. 
  • The DNS server configuration will not be via DHCP; instead, it will be configured with DNS group CLI. The default address context and default zone will be used for the DNS server-related configurations. The user can configure multiple DNS servers in the DNS group of default address context and default zone to resolve the PSX cluster FQDN; the DNS server will be selected based on the priority associated with the DNS server. 

 The SBC SWe supports round-robin load balancing among active policy client groups.