ARP Issues in LVS/DR and LVS/TUN Clusters
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, 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
- arptables
- The arp_announce/arp_ignore approach
- The hidden patch
- The redirect approach
- The policy routing approach
- The noarp module
