We use cookies on our website to ensure we provide you with the best experience on our website. By using our website, you agree to the use of cookies for analytics and personalized content.This website uses cookies. More Information
It seems like your browser didn't download the required fonts. Please revise your security settings and try again.
Barracuda Load Balancer

Direct Server Return Deployment

  • Last updated on

 

Direct Server Return (DSR) is an option associated with a Real Server which allows for increased outbound traffic throughput when performing sustained uploads, such as streamed audio or visual media. With DSR, connection requests and incoming traffic are passed from the Barracuda Load Balancer to the Real Server, but all outgoing traffic goes directly from the Real Server to the client.

Because the Barracuda Load Balancer does not process the outgoing traffic in DSR mode, Layer 7 Service types (HTTP, FTP, UDP, TCP Proxy and RDP), SSL offloading, and cookie persistence are not supported with DSR.

Using DSR requires enabling a non-ARPing loopback adapter on each Real Server. Additionally, your applications may need to be explicitly bound to the loopback adapter.

You may have DSR servers and non-DSR servers running the same Service. Real Servers that are in DSR mode must be on the same subnet as the WAN of the Barracuda Load Balancer.

The following table summarizes the advantages and disadvantages of deploying your Real Servers in DSR mode:

AdvantagesDisadvantages
Ideal for high-bandwidth requirements such as content delivery networks.Requires flat network topology.
Keeps existing IP addresses of Real Servers.Client IP persistence only.
 Only Layer-4 load balancing is supported.
 HTTP, TCP Proxy, UDP Proxy, FTP and RDP are not supported.
 SSL offloading is not supported.
 No actions can be performed on the response headers and data (e.g., caching compression, URL rewrites).

Figure 1. Sample DSR, one-armed architecture.

dsr.png

As shown in the diagram, this is how DSR works:

  • #1 - The request comes to the switch and is passed to the Virtual IP (VIP) address on Barracuda Load Balancer.
  • #2  -  A Real Server is selected, and the data frame of the packet is modified to be the MAC address of that Real Server.
  • #3 - The packet is then placed back on the network.
  • #4 - Because the VIP address is bound to the Real Server’s loopback interface, the Real Server accepts the packet.
  • #5 - The Real Server responds directly to the client using the VIP address as the source IP address.

DSR in conjunction with Bridge-Path deployment is not supported.

Network Topology

DSR uses a flat network topology at the Layer 2 (Switching) and Layer 3 (IP) levels, which means that the Barracuda Load Balancer, VIP addresses, and Real Servers all must be within the same IP network and connected on the same switch. The figure above shows this topology. Each Real Server must be one hop away from the Barracuda Load Balancer and using the WAN port. The switch of the Real Servers must be directly connected into the WAN port of the Load Balancer, or connected to a series of switches that eventually reach the WAN port of the Load Balancer without going through any other networking devices.

If you specify Route-Path deployment for the Barracuda Load Balancer, but only use Real Servers with DSR enabled, the physical LAN port is used for management or not at all.

On the BASIC > Services page, each Real Server listed under each Service must individually be configured for DSR mode. Edit each Real Server and select Enable for the DSR option.

When deploying Real Servers in DSR mode, note the following:

  • The Barracuda Load Balancer needs to have the WAN adapter plugged into the same switch or VLAN as all of the Real Servers.
  • The WAN IP, all VIPs, and all of the Real Servers that use DSR must be on the same IP subnet.
  • Each Real Server needs to recognize the VIP as a local address. This requires enabling of a non-ARPing virtual adapter such as a loopback adapter and binding it to the VIP address of the load-balanced Service. Because this is not a true adapter, there should be no gateway defined in the TCP/IP settings for this adapter.
  • Real Servers accepting traffic from multiple VIPs must have a loopback adapter enabled for each VIP. Additionally, the applications on each Real Server must be aware of both the Virtual IP address as well as the real IP addresses.

Deployment Options

Last updated on