ARP problem in VS/TUN and VS/DR

In the VS/TUN and VS/DR clusters, the Virtual IP (VIP) addresses are shared by both the load balancer and real servers, because they all configure the VIP address on one of their interfaces. In some configurations that real servers are on the same network that the load balancer accepts request packets, if real servers answers arp request for the VIP, there will be race condition, no winner. Packets for the VIP may be sent to the load balancer at one time, to a real server at another time, to another real server at another time, and so on. Then, connections will be broken, everything will be in a mess, and the whole LVS cluster won't work. Therefore, in the VS/TUN and VS/DR cluster, we must guarantee that only the load balancer answers arp request for the VIP to accept incoming packets for virtual service, and the real servers(in the same network of load balancer) don't answer arp request for the VIP but can process packets destined for the VIP locally.

Linux kernel 2.0.xx doesn't do arp response on loopback alias and tunneling interfaces, it is good for the LVS cluster. However, Linux kernel 2.2.xx does all arp responses of all its IP addresses except the loopback addresses ( and multicast addresses. So, you will probably have problem in VS/TUN or VS/DR cluster of real servers running kernel 2.2.xx with instructions provided in other pages. After kernel 2.2.14, there is the "hidden" flag available to make interfaces hidden from ARP broadcast, thank Julian Anastasov and Alexey Kuznetsov for adding this nice ARP policy in the standard kernel!


标签:Linux, Server, LVS