This solution applies to all Load Balancers with real servers running in DSR (Direct Server Return) mode, all firmware versions.
In the event that a Route-Path deployment is not possible, or in the event that maximum throughput is desired, the Barracuda Load Balancer can support Direct Server Return. This deployment involves changing the MAC address of incoming packets to match the Real Server that was selected to handle the request. For this reason, there are some special requirements that need to be met:
- Direct Server Return requires flat network topology, both at layer 2 (Switching) and at layer 3 (IP). This means that the real servers, the Load Balancer, all of the virtual IPs (services), and the gateway must be able to freely talk to one another, and must all be on the same subnet.
- The LAN port (including any LAN IP configured on the Basic > IP Configuration page of the Barracuda Load Balancer) is not used. If all services use Direct Server Return, the LAN adapter may remain undefined and unplugged.
- Each Real Server must be "1 hop" away from the Barracuda Load Balancer's WAN port. This means their switch must be directly connected into the WAN port of the Barracuda Load Balancer, or connected to a series of switches that eventually reach the WAN port of the Barracuda Load Balancer without going through any other machines.
- On the services page, each Real Server listed under each service must individually be configured for Direct Server Return mode. This means that you will need to click Edit for each Real Server (on the Basic > Services page) and select Enable for the Direct Server Return option. If this option has not been configured in a DSR deployment, the services will not function.
- Each real server must be configured with a non-arping loopback adapter (one per Real Server per relevant Virtual IP address). This loopback adapter must not specify a gateway, and must be bound to the VIP of the service that will be passing it traffic. The loopback adapter must also have a subnet mask of 255.255.255.255 on Linux systems, and a subnet mask matching the Barracuda Load Balancer's WAN IP's subnet mask on Windows systems. This means that Real Servers receiving traffic from multiple VIPs must have multiple loopback adapters enabled.
- The software on each real server must be configured to recognize the VIP as its own IP address. Specifically, on Windows Real Servers, the VIP address(es) must be listed in IIS (Internet Information Services), and they must be listed before (above) the physical IP address of the Real Servers.
To add a non-ARPing adapter in any Linux variants including Red Hat, Mandriva, and Debian based distributions, add an alias to the lo (loopback) adapter in the following manner (verified for kernels 2.4.26+, and 2.6.6+):
1. Edit your rc.local file (usually located at /etc/rc.d/rc.local)
2. Add the following to your rc.local file:
sysctl -w net.ipv4.conf.lo.arp_ignore=1
sysctl -w net.ipv4.conf.lo.arp_announce=2
sysctl -w net.ipv4.conf.all.arp_ignore=1
sysctl -w net.ipv4.conf.all.arp_announce=2
ifconfig <interface_name> <ip_address> netmask 255.255.255.255 -arp up
Where <interface_name> is lo:<number> (i.e. lo:0, lo:1, lo:2, etc.), and <ip_address> is the Virtual IP Address for the Service. For example:
ifconfig lo:1 192.168.4.217 netmask 255.255.255.255 -arp up
For information on adding a non-ARPing adapter in a Windows environment, please refer to the following pages:
Windows Server 2003:
Please check the Microsoft Support Site for your specific operating system.
Link to This Page: