Download (direct link):
Address Resolution Protocol (ARP) is used in the Ethernet network to discover the host IP addresses and their associated MAC addresses. By definition, loopback interface does not respond to ARP requests. Therefore, no one in the network knows the loopback IP addresses on a host, as it is completely internal to the host. We can assign any IP address to be a loopback address; that is, the IP address does not have to begin with 127. While a host cannot respond to ARP requests with the loopback IP address, it can reply to those who send a request to that address. So no one outside can know what loopback IP addresses are defined on a host, but one can send a request to the loopback IP address on a host if one knows the address is defined on that host. If that address is indeed defined, the host can accept the request, and reply to it. Direct server return uses this premise to avoid the destination NAT on the request traffic, yet get the real server to accept the requests by defining the VIP as a loopback address on the servers.
Figure 2.14 shows how a packet flow looks when using direct server return. First, the load balancer leaves the destination IP as VIP in the request packets, but changes the destination MAC to that of the selected server. Since the switch between the load balancer and the real server is a Layer 2 switch, it simply forwards the packet to the right server based on the destination MAC address. The real server accepts the packet, because the destination IP address of the packet, VIP, is defined as a loopback IP address on the server. When the server replies, the VIP now becomes the source IP, and the client’s IP becomes the destination IP. The packet is forwarded through the Layer 2 switch to the router, and then on to the client, avoiding the need for any NAT in the reply. Thus, we have successfully bypassed the load balancer for the reply traffic.
Figure 2.14 : Packet flow when using direct server return.
Let’s now discuss how a loopback IP address is defined on a couple of major operating systems. On Sun Microsystems Solaris operating system, the following command can be used to configure 188.8.131.52 as a loopback IP address:
ifconfig lo0:1 vip addr 184.108.40.206 up
This command applies to the current running configuration only. To make the address permanent, so that it is reconfigured following a reboot or power cycle, create a file under “/etc/rc3.d/foundryloopbackconfigfile”, then create a link to “/etc/init.d/thefile”.
For Linux operating system, the following can be used to configure 220.127.116.11 as a loopback IP address:
ifconfig lo0:0 18.104.22.168 netmask 255.255.255.0 up
This command applies to the current running configuration only. To make the address permanent so that it is reconfigured following a reboot or power cycle, add a “/etc/hostname.lo0:1” entry.
DSR is a useful feature for throughput-intensive applications such as FTP, streaming media traffic where the reply size is very large compared to the request size. If there are 20 reply packets for each request packet, then we are bypassing the load balancer for 20 packets, significantly decreasing the number of packets processed by the load balancer per each request served. This can help the load balancer process more requests and provide us with higher capacity.
DSR is also useful in load balancing those protocols where the NAT requirements are complicated or not supported by the load balancer because direct server return obviates the need for NAT. For example, if a load balancer does not support enhanced NAT for RTSP protocol, as discussed in section Enhanced NAT earlier in this chapter, then we can use DSR to obviate the need for NAT, since the destination IP address in the request packets remains unchanged when using DSR.
DSR is also useful for network configurations where the reply packets cannot be guaranteed to go back through the same load balancer that processed the request traffic. Figures 2.9, 2.10, and 2.11 show examples in which the reply packets do not go through the load balancer. We can use source NAT to force all the reply traffic to go through load balancer, or use direct server return so that reply traffic does not have to go through the load balancer. In the case of the example shown in Figure 2.11, we can set the load balancer as the default gateway on all real servers, forcing the reply traffic through the load balancer so that we neither have to use source NAT nor DSR. We will discuss this further in Chapter 4, section The Load Balancer as a Layer 2 Switch versus a Router.
It’s important to note that DSR cannot be used when using certain advanced features of load balancers discussed in Chapter 3. Please refer to Chapter 3 for a more detailed study.
Load balancers offer tremendous benefits by improving server farm availability, scalability, manageability, and security. Server load balancing is the most popular application for load balancers. Load balancers can perform a variety of health checks to ensure the server, application, and the content served are in good condition. There are many different load-distribution algorithms to balance the load across different types of servers in order to get the maximum scalability and aggregate processing capacity. While stateless load balancing is simple, stateful load balancing is the most powerful and commonly used load-balancing method.