[MASOCH-L] Mais ilogismo no ping + tcpdump - incluindo arpwatch flip-flop

[Fernando Ulisses dos Santos]

Oi Márcio,

Isso pode estar relacionado à alguma regra de MASQUERADE ou de SNAT, se 
tiver essas regras, tenta o ping sem elas.

Também, se tiver mais de uma placa de rede ativa no VMware, e a política 
de Load Balancing não tiver suporte do switch, pode ter esses resultados.

No VMware, no Host, em Configuration, Network, Properties (do Switch), 
entra no vSwitch principal e no Network Group (vmNetwork por padrão) da 
máquina virtual, na aba Nic Teaming, em Load Balancing deixa a opção 
"Route based on the originating virtual port ID".

Ou, o kernel está perdido com as interfaces eth1 e eth2 na mesma rede, 
se você precisa do IP 192.168.0.2, levanta ele como IP secundário da 
interface eth1 (usa eth1:0) e acaba com a interface eth2, senão 
simplesmente baixe essa interface. Se a ideia é ter mais banda 
disponível para os usuários, use bonding no servidor físico, ou direto 
no Host do VMware.

Fernando Ulisses dos Santos
Blue Solutions - Soluções em TI
19-3321-9068 / 19-3551-3898


Em 16-04-2012 10:44, Marcio Merlone escreveu:
> Grandes colegas,
>
> Ainda analisando o ilogismo do ping sobre o qual pedi ajuda há alguns 
> dias, fui tcpdumpar a interface de meu servidor pra testar o ping em 
> um momento em que não há problemas. Vejam que situação bizarra:
>
> Servidor 1:
> eth0: 192.168.255.1/24
> eth1: 192.168.0.1/24
> eth2: 192.168.0.2/24
>
> Servidor 2:
> eth0: 192.168.255.3/24
> eth1: 192.168.0.3/24
>
> Objetivo: da interface 192.168.0.3 pingar o 192.168.0.1, mas a 
> interface 192.168.0.2 é quem responde o ping:
>
> No servidor 2, de 192.168.0.3 eu pingo:
> ping -I eth1 192.168.0.1
>
> No servidor 1 eu dumpo:
> tcpdump -ni eth1 icmp -> nhada!
>
> Nada acontece aqui. Mas se eu dumpar a outra interface funciona:
> tcpdump -ni eth2 icmp -> ping? pong!
>
> Em resumo, quem responde o ping é a outra interface e não a que tem o 
> IP que estou pingando. Todas as sub-redes estão no mesmo switch 
> virtual, sem VLAN, e são máquinas virtuais VMware ESX 5.0 (for what is 
> worth). Já havia visto este comportamento em máquinas físicas também, 
> então descarto relação com a virtualização.
>
> Pelo cheiro, as mensagens de flip-flop que o arpwatch reporta sobre 
> este servidor (entre alguns outros equipamentos) parece ter relação, 
> mas como posso determinar isto ao certo, as causas, as soluções? Além 
> de resolver o problema, gostaria de entender o que acontece.
>
> A pergunta parece tão boba que me sinto na linux-br uma década atrás. :)
>
> Agradeço antecipadamente qualquer ajuda.
>