Às vezes, o switch mantém o antigo mapeamento ARP por muito tempo; Eu tive que usar "arping -U" no linux para dizer ao switch upstream para esvaziar o cache.
Eu tenho um balanceador de carga baseado em LVS que tem funcionado muito bem. Ele é executado em dois servidores usando heartbeat para fornecer failover.
Eu adicionei suporte para um segundo intervalo de IPs ao sistema, mas quando ocorre o failover, o servidor que assume o controle não pode ARP nenhum IP nesse segundo intervalo até que eu remova e adicione novamente a rota para esse intervalo. / p>
Veja mais detalhes sobre o que eu vejo no balanceador de carga ativo logo após o failover:
# arp
foo1.example.com ether 00:20:ED:1A:0C:82 C eth0
foo2.example.com ether 00:1E:C9:B0:F6:FE C eth0
bar1.example.com (incomplete) eth0
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
2.2.2.128 * 255.255.255.192 U 0 0 0 eth0
1.1.1.0 * 255.255.255.0 U 0 0 0 eth0
default 1.1.1.1 0.0.0.0 UG 100 0 0 eth0
então eu não posso ARP que bar1.example.com que estará no 2.2.2. * netblock
O que eu descobri é que remover e adicionar a rota para o netblock corrige o problema
ip route del 2.2.2.128/26 dev eth0
ip route add 2.2.2.128/26 dev eth0
Se eu acionar uma pesquisa ARP fazendo ping em bar1.example.com, o cache ARP agora será exibido
bar1.example.com ether 00:22:19:51:71:E4 C eth0
Alguém sabe o que está acontecendo aqui, ou sabe de uma maneira que eu poderia fazer com que o daemon de heartbeat executasse essa exclusão de rota e adicionasse novamente quando ela executasse a transferência?
Como você está especificando um IP como um recurso? Você está usando o script de recurso IPAddr ? Se você não estiver transmitindo novamente o ARP no failover, o equipamento que estiver falando com o VIP terá o endereço físico antigo na tabela ARP.