Skip to end of metadata
Go to start of metadata

In this section:

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

Overview

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:

Note

The Routing VMs are not directly connected to the packet network.

Figure : Front-End Load Balancer Configuration


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.

Figure : Pure Load Balancer Network Configuration

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:

Figure : Load Balancer and Routing Network Configuration

Incoming Load Balancer Traffic

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.

Outgoing Load Balancer Traffic

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:

  • forwards the packets for the outgoing connection to the external network to be routed to the remote endpoint if the connection has been configured on the Load Balancer application with the particular Routing VM.
  • drops the packets for the outgoing connection if either the connection has not been configured on the Load Balancer application, or the configuration does not match the Routing VM where the packets have been received.

Note

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 Tunnels

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. 

Note

For every tunnel created between a Routing VM and a Load Balancer Application VM, there is also one tunnel interface.

Figure : Load Balancer GRE Tunnels and Interfaces

IPSec Load Balancer Traffic

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.


Load Balancer Traffic Forwarding

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:

  1. Incoming packet arrives at the Packet network interface of the Load Balancer Application VM for VIP address.

  2. The Load Balancer Application VM checks the configured connections in the Load Balancer application. If the source IP/port, destination IP/port, and protocol match a configured connection go to Step 3, otherwise drop the packet.

  3. The packet is forwarded into the GRE Tunnel of the configured Load Balancer application connection slot (Target Slot, 1 in this example).

  4. Routing VM1 receives the packet at its end of the GRE tunnel and consumes it.

The following are the steps that occur for outgoing Load Balancer connections and are shown in blue on the figure Load Balancer Traffic Forwarding:

  1. 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.

    Tip

    When the slot for the ADN Connection is defined ANY, all Routing VMs initiate an outgoing connection.

  2. Since the source address is 10.91.3.77, the packet is pushed into the GRE tunnel and arrives at the other end of the tunnel at the Load Balancer Application VM where the VIP is configured.

    The Load Balancer Application VM checks the configured connections in the Load Balancer application, if the source IP/port, destination IP/port, and protocol match a configured connection and the packet is received from the GRE tunnel of the configured Target Slot then go to Step 3, otherwise drop the packet.

  3. 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). 


  4. The Routing network forwards the packet to the Routing IP Gateway which routes it to its destination (Remote IP 10.91.3.100, Remote Port 3991).

Figure : Load Balancer Traffic Forwarding

  • No labels