resposta ARP não está presente na outra porta da ponte linux com base no ubuntu 13.10

Question

Eu recentemente construí uma ponte baseada em Linux para fins de monitoramento de pacotes, mas existe um GRANDE problema.

o ambiente é

1. env geral
   • meta de monitoramento é VMs no vSphere.
   • dois vSwitches são configurados no host do vSphere.
   • O vSwitch 1 está configurado com NIC para comunicação entre pontes.
   • O vSwitch 2 é configurado sem NIC para conexão bridge-vm.
   • ambos estão configurados como "Permitir modo promíscuo".
2. env. de ponte.
   • baseado no Ubuntu 13.10, instalado como uma máquina virtual mínima.
   • br0 foi configurado com eth0 (para vS1) e eth1 (para vS2)

meu problema é, quando o VM ping para GW, a solicitação ARP é feita e há uma resposta do GW. mas o pacote de resposta é mostrado apenas em eth0 e br0.

superhero@vim-firewall:~$ sudo tcpdump -i eth0 -n host 192.168.10.172
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:13:45.809949 ARP, Request who-has 192.168.10.1 tell 192.168.10.172, length 46
12:13:45.810060 ARP, Request who-has 192.168.10.1 tell 192.168.10.172, length 46
12:13:45.810742 ARP, Reply 192.168.10.1 is-at 00:00:aa:aa:aa:d9, length 46
...
superhero@vim-firewall:~$ sudo tcpdump -i br0 -n host 192.168.10.172
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:13:51.810928 ARP, Request who-has 192.168.10.1 tell 192.168.10.172, length 46
12:13:51.811031 ARP, Request who-has 192.168.10.1 tell 192.168.10.172, length 46
12:13:51.811579 ARP, Reply 192.168.10.1 is-at 00:aa:aa:aa:aa:d9, length 46
...
superhero@vim-firewall:~$ sudo tcpdump -i eth1 -n host 192.168.10.172
tcpdump: WARNING: eth1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
12:13:57.812937 ARP, Request who-has 192.168.10.1 tell 192.168.10.172, length 46
12:13:57.813040 ARP, Request who-has 192.168.10.1 tell 192.168.10.172, length 46
...

Preciso de ajuda!

PS. atualmente, apenas ARP é problema. se eu adicionar um MAC do GW manualmente, a conexão de rede é boa, exceto o acesso à sub-rede local de causa.

    

Answer 1

Oops! Eu finalmente encontrei a solução de trabalho!

Eu passei mais de 10 horas espalhadas em três dias por esse problema, mas a solução não está limpa, está mais próxima da solução alternativa. Eu preciso de solução real ou melhor solução para isso. por favor ajude.

de qualquer forma, eu encontrei abaixo informações da Comunidade VMware. (a causa raiz do problema está relacionada ao vmware).

1. link
2. link

URL (1) é um comentário do autor original que tem o mesmo problema, sobre o motivo do problema. o problema é causado pelo comportamento do vSwitch . se houver dois ou mais NIC físicos conectados, eles fizeram uma solicitação ARP duplicada e a ponte linux recebe a solicitação dup.ed da NIC / port externa. por isso cai na confusão do mapa da porta MAC.

Eu testei isso (desmarque o NIC de espera do vSwitch) e a rede funciona bem. (com o único NIC vSwitch)

outro comentário, o número do URL (2) descreve uma solução alternativa. se eu definir o tempo de envelhecimento para 0 a partir da ponte linux, ele funciona como um hub fictício (envia todos os pacotes para todas as portas), portanto, a resposta ARP é atingida para a VM na rede interna.

No meu caso, minha bridge tem apenas duas portas para conexão interna e externa, então não é um grande problema IMHO. mas há algo não claro.

Se houver uma maneira de bloquear o pedido em loop / duplicado do NIC em espera, ou ignorar o pedido duplicado ou outra maneira inteligente de lidar com a tabela de bridge MAC, deixe-me agora.

Obrigado por ler e espero ajudar o mesmo problema!

    

Answer 2

Encontrei outra solução de trabalho desse problema! link

Você pode definir a opção Advanced System do host Esxi: Net.ReversePathFwdCheckPromisc = 1 Esta opção desativa a duplicação de pacotes no vSwitch com vários uplinks e portgroup no modo promíscuo.

Espero que esta informação o ajude.