Direct Server Return

Use Direct Server Return to have responses from backend servers bypass HAProxy ALOHA and go directly to the client, improving performance.

Direct Server Return, also known as Direct Routing, is a good option when you need to service a high volume of traffic, since it prevents the HAProxy ALOHA from becoming a bottleneck for packets that are returning to the client. While packets flow through the HAProxy ALOHA on their way from the client to the backend servers, they skip the HAProxy ALOHA on their way back to the client. You accomplish this by configuring each backend server’s default gateway to be the network’s external gateway.

In this configuration, which does not use NAT, the destination IP address is not changed. So, the backend server must receive traffic on the same IP address as the one on which the HAProxy ALOHA listens, and that the client originally requested. Doing so is easiest on Linux backend servers because they provide a special loopback interface that can be configured with an IP alias (virtual IP). Windows servers do not define a loopback interface.

The advantages of this mode include the ability to service a high volume of traffic efficiently, such as video and audio streams. The disadvantages of this mode include needing to configure the backend server’s loopback interface in a special way to listen on a virtual IP address (IP alias), the need to manage ARP replies so that the network does not detect an IP conflict, and that the HAProxy ALOHA is unable to log responses from servers. This mode is not well supported on Windows servers due to Windows not defining a loopback interface.

This mode can be used only when load balancing traffic via the LB Layer4 tab, which supports the raw TCP and UDP protocols.

Traffic flow Jump to heading #

1. The client connects to your application at the configured public IP address. The HAProxy ALOHA listens at that address and receives the packets.

2. The HAProxy ALOHA routes unmodified packets to one of your backend servers.

   Although any of the servers in the server farm may be chosen, and each listens on a unique private IP address, the packets themselves are not modified. Therefore, they still contain the ALOHA’s public IP address as the destination. The backend servers must be configured to receive traffic on this IP too. They accomplish this by setting up a virtual IP (IP alias) on a virtual interface (the loopback interface).

3. The backend server accepts the request on its private IP address and then forwards the packets to its loopback interface where the virtual IP matching the packet’s destination IP is configured. The loopback interface is a virtual interface found on Linux servers.

4. The server responds directly to the source IP address it finds in the packet, which is that of the client. Because the client’s IP address is outside of the local network, the response is sent to the network’s external gateway and then out, skipping the HAProxy ALOHA on the return.

Enable Direct Server Return Jump to heading #

1. In the web UI’s LB Layer4 tab, add the mode gateway directive to your existing configuration, and apply your changes.

   haproxy
   director exchange 10.0.0.9:443 TCP
     balance roundrobin                               # load balancing algorithm
     mode gateway                                     # forwarding mode
     check interval 10 timeout 2                      # check parameters
     option tcpcheck                                  # adv check parameters
     server exchange1 10.0.0.13:443 weight 10 check   # server exchange1
     server exchange2 10.0.0.14:443 weight 10 check   # server exchange2

   haproxy
   director exchange 10.0.0.9:443 TCP
     balance roundrobin                               # load balancing algorithm
     mode gateway                                     # forwarding mode
     check interval 10 timeout 2                      # check parameters
     option tcpcheck                                  # adv check parameters
     server exchange1 10.0.0.13:443 weight 10 check   # server exchange1
     server exchange2 10.0.0.14:443 weight 10 check   # server exchange2

2. On each backend server, assign the virtual IP to a loopback interface.

3. To make your changes persistent after a reboot, click the Setup tab. Then click Save under Configuration.

Configure VIPs on Linux Jump to heading #

The VIP must be handled on each server’s loopback interface to accept connections, but can’t be advertised on the network or it will be identified as an IP conflict by some network components. To avoid IP address collisions, disable ARP for IP addresses managed by the loopback interface.

1. Manage the VIP through a loopback interface. Specify a /32 or 255.255.255.255 netmask. For example, below we manage the 10.0.0.9 VIP through the lo:1 loopback interface.

   nix
   sudo ifconfig lo:1 10.0.0.9 netmask 255.255.255.255

   nix
   sudo ifconfig lo:1 10.0.0.9 netmask 255.255.255.255

   To check your changes, run ifconfig:

   nix
   ifconfig lo:1

   nix
   ifconfig lo:1

   output
   text
   lo:1: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
     inet 10.0.0.9  netmask 255.255.255.255
     loop  txqueuelen 1000  (Local Loopback)

   output
   text
   lo:1: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
     inet 10.0.0.9  netmask 255.255.255.255
     loop  txqueuelen 1000  (Local Loopback)

2. Add the following lines to /etc/sysctls.conf.

   text
   net.ipv4.conf.all.arp_ignore=1
   net.ipv4.conf.all.arp_announce=2

   text
   net.ipv4.conf.all.arp_ignore=1
   net.ipv4.conf.all.arp_announce=2

   Info

   To test your configuration without rebooting, use the commands below.

   nix
   sudo sysctl -w net.ipv4.conf.all.arp_ignore=1
   sudo sysctl -w net.ipv4.conf.all.arp_announce=2

   nix
   sudo sysctl -w net.ipv4.conf.all.arp_ignore=1
   sudo sysctl -w net.ipv4.conf.all.arp_announce=2

3. Save the configuration. Click the Setup tab. Then click Save in the Configuration section.

4. Reboot the server.

5. Configure the backend server’s default gateway to be the network’s external gateway.