DSC SWe on this page refers to the DSC SWe on Kernel-based Virtual Machine (KVM), DSC SWe on VMware, and DSC SWe on OpenStack.
The following page describes how a DSC SWe with a Load Balancer inter-connects with a customer network and affects incoming and outgoing traffic. For a general overview of how the DSC SWe integrates with a customer network, refer to Customer Network Requirements for the DSC SWe.
The Load Balancer helps to route and balance network traffic. A single Load Balancer is comprised of two Application VMs and is positioned in front of the Routing VMs to provide connectivity to the external networks and to hide the internal resources (Routing VMs) from the networks by being the only visible entity to external networks.
The Routing VMs are connected to the Load Balancer Application VMs through Generic Routing Encapsulation (GRE) Tunnels (see GRE Tunnels) through the internal HA network. In a pure Load Balancer setup where no packet network IP addresses are configured on the Routing VMs, the user configures the Virtual IP (VIP) addresses at the Load Balancer Application VMs' packet network interfaces. All connections configured at the DSC SWe applications must use the VIP addresses as the local host.
Incoming connection packets arrive at the packet network interface of the configured Load Balancer Application VM. The Load Balancer Application VM, through the Load Balancer application, then determines which Routing VM receives these packets.
Outgoing connection packets also go through the Load Balancer Application VM from the Routing VMs, and based on the Load Balancer application configuration, the Load Balancer Application VM forwards only the packets from the configured Routing VM. Outgoing packets from Routing VMs that are not configured in the Load Balancer application are dropped by the Load Balancer Application VM.
The following figure depicts how the Load Balancer Application VMs appear at the front-end to external networks:
The Routing VMs are not directly connected to the packet network.
The following figure depicts the network configuration of a pure Load Balancer system where the Routing VMs have no packet network IP addresses configured:
In the presence of a Load Balancer system, the Routing VMs still have the ability to reach external networks if the Routing VM's packet network interfaces have a valid IP address.
The following figure depicts the network configuration of a hybrid Load Balancer system where the Routing VMs have packet network IP addresses configured in addition to the Load Balancer Packet network VIP addresses:
The VIP addresses are configured on the Load Balancer Application VM. Any packet that arrives at the packet network destined for a VIP configured on the Load Balancer goes to the appropriate Load Balancer Application VM. This Load Balancer Application VM then forwards the packets to the appropriate Routing VM based on the configured connections for the Load Balancer application. The forwarding is achieved through GRE Tunnels, which are end-to-end tunnels between the Load Balancer Application VM and every Routing VM in the DSC SWe. If the Load Balancer application is not configured for an incoming connection, the packets are dropped.
When an outgoing connection is configured on one of the DSC applications with the local host attribute set to one of the Load Balancer VIPs, the configured Routing VMs send outgoing packets to the Load Balancer Application VM where the VIP is configured. The Load Balancer Application VM then checks the Load Balancer application configuration and performs one of the following actions:
The packets for the outgoing connections are sent through the established GRE Tunnels from the Routing VMs to the Load Balancer where the VIP has been configured.
GRE is a tunneling protocol that encapsulates a wide variety of network layer protocols inside virtual point-to-point links over an IP network. In DSC SWe, there is one GRE Tunnel between every Load Balancer Application VM and Routing VM. The GRE Tunnels use the internal HA network and are created when the first Load Balancer Application VM is commissioned. At the end of each tunnel is a tunnel interface called lbX where X is an integer.
For every tunnel created between a Routing VM and a Load Balancer Application VM, there is also one tunnel interface.
When a Load Balancer connection is configured with the IPSec protocol on the Load Balancer application, the traffic is encrypted end-to-end between the remote end and the configured Routing VM. The Load Balancer Application VM does not decrypt traffic; it simply forwards it to its destination according to the configured connection at the Load Balancer application.
The following are the steps that occur for the incoming Load Balancer connections and are shown in red on the figure Load Balancer Traffic Forwarding:
The following are the steps that occur for outgoing Load Balancer connections and are shown in blue on the figure Load Balancer Traffic Forwarding:
The Routing VMs send an outgoing SCTP packet with destination address 10.91.3.100 and source address 10.91.3.77, local port 4881 and remote port 3991.
When the slot for the ADN Connection is defined ANY, all Routing VMs initiate an outgoing connection.
Since Target Slot 1 is configured for the connection, only the packet received from Routing VM1 is forwarded to the Routing network. The packet received from Routing VM2 is dropped because the Load Balancer only allows a pass-through for the allocated slot for that connection based on its configuration (in this case, slot 1).