Difference between revisions of "ARP Issues in LVS/DR and LVS/TUN Clusters"

Revision as of 11:38, 28 October 2006

Problems

In the LVS/DR and LVS/TUN clusters, we can see that the VIP address is shared by load balancer and all real servers. In order to make the LVS/DR and LVS/TUN clusters work, load balancer should broadcast the VIP address to accept incoming packets for virtual service, the real servers only use the VIP address to process the packets for VIP locally.

The ARP problem arises when real servers have one of their interfaces connected to the network that LVS/DR and LVS/TUN load balancer receives packets for VIP. For example, a LVS/DR or LVS/TUN cluster of the following topology needs to disable ARP for VIP address at real servers.

If we did not disable ARP for VIP address at real servers, there would be race condition in ARP response, the load balancer and the real servers may give ARP response for VIP simultaneously, then router might send requests for VIP to real servers directly instead of the load balancer. This would break the whole load balancing solution.

In a LVS/DR and LVS/TUN cluster of some special configuration illustrated in the following figure, real servers don't have any interfaces connected to the network that load balancer receives packets for VIP, but have their router to transmit response packets, then there is no need to disable ARP for VIP at real servers, because there is no chances for real servers to receive ARP request for VIP.

Anyway, there is no hurt to disable ARP for VIP at real servers in any LVS/DR and LVS/TUN clusters.

Solutions

Linux

There are many solutions to disable ARP for VIP in real servers running the Linux operating system.

• Using arptables to disable ARP
• Using arp_announce/arp_ignore to disable ARP
• Using the hidden interface to disable ARP
• Using redirect to disable ARP
• Using policy routing to disable ARP
• Using the noarp module to disable ARP

FreeBSD

Solaris

Windows

References

• http://www.linuxvirtualserver.org/docs/arp.html