DRA Distributor


Note


For configurations, see DRA Distributor Configuration chapter in the CPS vDRA Configuration Guide.

Introduction

The DRA distributor is a load balancer that front ends the diameter connections inbound to the DRA. It then forwards the connections to a selected Director VM. For client facing traffic (for example, PGW, AF), two distributor VMs configured as an HA pair are used. In addition, two distributor VMs are used to support server facing entities (for example, PCRF).

When a new connection arrives at the Distributor, it employs the Weighted Least Connections algorithm to select a Director VM for the new connection. The return traffic is sent from the Director VM directly to the originator of the connection (PGW, PCRF, and so on) bypassing the Distributor VM. This forwarding mechanism is known as Direct Routing. A pair of Distributors synchronizes the connection information to continue with the forwarding traffic if one of the Distributor VMs fails.

Figure 1. DRA Distributor
  • CIP: Client IP

  • DIP: Distributor IP

  • VIP: Virtual IP

  • RIP: Real IP

Direct Routing

The DRA Distributor VM has a Virtual IP (VIP) address and TCP port that is used by a PGW, PCRF and so on for connections that are forwarded to the DRA Director VMs. The DRA Directors have an interface with the same VIP configured as a secondary IP address. The DRA Distributor VM and DRA Director VMs must be configured on the same subnet/layer 2 network.

The DRA Distributor uses the Director VM’s Real IP address (RIP) to resolve the Director’s MAC address. Before forwarding packets to the Director VM, the Distributor VM replaces the source MAC address with its own, and replaces the destination MAC address with the Director VM's IP address. The source and destination IP (PGW, VIP) remain the same.

Figure 2. Direct Routing

ARP and IPv6 Neighbor Discovery

Devices responsible for forwarding PGW/PCRF and so on packets to the Active Distributor VM, such as a router, must discover the MAC address of the Distributor’s interface that is configured with the VIP. Since the Distributor and Director VMs are configured with the same VIP, and the Distributor and Director VMs are on the same subnet/layer-2 network, the Director VMs must not respond to IPv4 ARP or IPv6 neighbor solicitation requests for the VIP.

In addition, the Director VMs must not send unnecessary IPv4 ARPs or IPv6 neighbor advertisements. To prevent Director VMs from advertising their MAC addresses for the VIPs, ARP tables and IPv6 tables are used to filter IPv4 ARP and IPv6 neighbor discovery respectively.

Distributor VIPs are automatically configured on the Director VMs along with the required ARP table and IPv6 table rules.

The DRA Distributor in the DRA VNF is configured using ConfD CLI on the Master VM.

Figure 3. Distributor Direct Routing

Balancing Distributor Connections

DRA distributor rebalances the existing active connections across all available directors through CLI commands. The Rebalancing allows:

  • Equal distribution of connections on all available directors

  • Recommendation of number of peers that are disconnected from each director where there are more active connections.

  • Ensures graceful disconnect of peers on directors with more connections and on rejoin, same peers gets distributed to the right directors, which have less number of connections.

Distributor connection balancing mechanism uses below CLIs::

  • dra-distributor balance connection cluster-name service-name audit : This command checks the total active peer connections on each diameter-endpoint containers and determines whether connections are balanced or unbalanced between the containers. This uses weighted least connections algorithm, to check if connections are balanced or unbalanced.

  • dra-distributor balance connection cluster-name service-name : This command checks the balancing and determines if connections need to be balanced. If the connections are unbalanced, it allows user to balance the connections.


Note


The disconnection of peers is based on a logic, where at a time only one peer from each realm/gateway is disconnected, and if there is a need to move more connections from the same container, peer from different realm is selected and disconnected.

DRA Distributor Failover

If a Distributor VM fails, all VIPs on the failed VM are moved to the Standby Distributor VM. The failover is transparent to devices originating connections through the Distributor and the Director VMs.

Active-Active

VIPs can be configured as pseudo active-active by allowing VIPs to independently configure the priority of the DRA distributor VMs.

For example, a Gx VIP could configure dra-distributor-1 with priority 10 and dra-distributor-2 with priority 5 (the highest priority takes precedence). An Rx VIP could configure dra-distributor-2 with priority 10 and dra-distributor-1 with priority 5. In this scenario, the Gx VIP will start on dra-distributor-1 and the Rx VIP will start on dra-distributor-2.

Connection Synchronization

In order to support failover, connection information is periodically synchronized between a pair of Distributor VMs. Each Distributor advertises its connection information over multicast.

Health Checks

A Distributor virtual service consists of a virtual IP address/port combination and a list of real-server IP addresses used to handle connections to the VIP at the Director VMs.

A real-server IP address exists on a director VM. Health checks are performed for the diameter endpoint VIP/Port for each real-server.

Diameter Endpoint IP and Port

If a Distributor VIP’s real-server fails the health check for the VIP:port (for example, 192.168.10.50:3868), the real-server is removed from the virtual service. In addition, if the Diameter Endpoint is not configured in Policy Builder, the real-server is removed from the virtual service.

Real-server Connections

In order for a Distributor virtual service to process incoming connections, it has to have at least one healthy real-server. If the virtual service does not have at least one healthy real-server, the VIP is removed from the active Distributor VM.