Parar duplicado icmp echo responde ao fazer uma ponte para uma interface fictícia?

Question

Eu configurei recentemente uma ponte br0 com membros como eth0 (real if ) e dummy0 ( dummy.ko if ).

Quando faço ping nessa máquina, recebo respostas duplicadas como:

  # ping SERVERA
  PING SERVERA.domain.local (192.168.100.115) 56(84) bytes of data.
  64 bytes from SERVERA.domain.local (192.168.100.115): icmp_seq=1 ttl=62 time=113 ms
  64 bytes from SERVERA.domain.local (192.168.100.115): icmp_seq=1 ttl=62 time=114 ms (DUP!)
  64 bytes from SERVERA.domain.local (192.168.100.115): icmp_seq=2 ttl=62 time=113 ms
  64 bytes from SERVERA.domain.local (192.168.100.115): icmp_seq=2 ttl=62 time=113 ms (DUP!)

Usando tcpdump on SERVERA , consegui ver as respostas de eco icmp sendo enviadas de eth0 e br0 como segue (estranhamente dois pacotes de solicitação de eco chegam "de" minha caixa do Windows myhost ) :

  23:19:05.324192 IP myhost.domain.local > SERVERA.domain.local: ICMP echo request, id 512, seq 43781, length 40
  23:19:05.324212 IP SERVERA.domain.local > myhost.domain.local: ICMP echo reply, id 512, seq 43781, length 40
  23:19:05.324217 IP myhost.domain.local > SERVERA.domain.local: ICMP echo request, id 512, seq 43781, length 40
  23:19:05.324221 IP SERVERA.domain.local > myhost.domain.local: ICMP echo reply, id 512, seq 43781, length 40
  23:19:05.324264 IP SERVERA.domain.local > myhost.domain.local: ICMP echo reply, id 512, seq 43781, length 40
  23:19:05.324272 IP SERVERA.domain.local > myhost.domain.local: ICMP echo reply, id 512, seq 43781, length 40

Vale a pena notar que testes revelam que hosts no mesmo switch físico não vêem DUP icmp echo responses (um host na mesma VLAN em outro switch vê um dup icmp echo response ).

Eu li que isso pode ser devido à tabela ARP de um switch, mas não consigo encontrar nenhuma informação diretamente relacionada a bridges , apenas bonds . Tenho a sensação de que meu problema está na pilha no linux, não no switch, mas estou aberto a qualquer sugestão.

O sistema está rodando centos6 / el6 kernel 2.6.32-71.29.1.el6.i686 .

Como faço para impedir que as respostas de eco do ICMP sejam enviadas em duplicado ao lidar com interfaces de ponte / interface em ponte?

Obrigado,

Matt

[editar]

Nota rápida: Foi recomendado em #linux para:

[08:53] == mbrownnyc [gateway/web/freenode/] has joined ##linux
[08:57] <lkeijser> mbrownnyc: what happens if you set arp_ignore to 1 for the dummy interface?
[08:59] <lkeijser> also set arp_announce to 2 for that interface
[09:24] <mbrownnyc> lkeijser: I set arp_annouce to 2, arp_ignore to 2 in /etc/sysctl.conf and rebooted the machine... verifying that the bits are set after boot... the problem is still present

Eu fiz isso e saí vazio. O mesmo problema de dup.

Eu estarei evitando incluir a interface fictícia na bridge como:

[09:31] == mbrownnyc [gateway/web/freenode/] has joined #Netfilter
[09:31] <mbrownnyc> Hello all... I'm wondering, is it correct that even with an interface in PROMISC that the kernel will drop /some/ packets before they reach applications?
[09:31] <whaffle> What would you make think so?
[09:32] <mbrownnyc> I ask because I am receiving ICMP echo replies after configuring a bridge with a dummy interface in order for ipt_netflow to see all packets, only as reported in it's documentation: http://ipt-netflow.git.sourceforge.net/git/gitweb.cgi?p=ipt-netflow/ipt-netflow;a=blob;f=README.promisc
[09:32] <mbrownnyc> but I do not know if PROMISC will do the same job
[09:33] <mbrownnyc> I was referred here from #linux.  any assistance is appreciated
[09:33] <whaffle> The following conditions need to be met: PROMISC is enabled (bridges and applications like tcpdump will do this automatically, otherwise they won't function).
[09:34] <whaffle> If an interface is part of a bridge, then all packets that enter the bridge should already be visible in the raw table.
[09:35] <mbrownnyc> thanks whaffle PROMISC must be set manually for ipt_netflow to function, but
[09:36] <whaffle> promisc does not need to be set manually, because the bridge will do it for you.
[09:36] <whaffle> When you do not have a bridge, you can easily create one, thereby rendering any kernel patches moot.
[09:36] <mbrownnyc> whaffle: I speak without the bridge
[09:36] <whaffle> It is perfectly valid to have a "half-bridge" with only a single interface in it.
[09:36] <mbrownnyc> whaffle: I am unfamiliar with the raw table, does this mean that PROMISC allows the raw table to be populated with packets the same as if the interface was part of a bridge?
[09:37] <whaffle> Promisc mode will cause packets with {a dst MAC address that does not equal the interface's MAC address} to be delivered from the NIC into the kernel nevertheless.
[09:37] <mbrownnyc> whaffle: I suppose I mean to clearly ask: what benefit would creating a bridge have over setting an interface PROMISC?
[09:38] <mbrownnyc> whaffle: from your last answer I feel that the answer to my question is "none," is this correct?
[09:39] <whaffle> Furthermore, the linux kernel itself has a check for {packets with a non-local MAC address}, so that packets that will not enter a bridge will be discarded as well, even in the face of PROMISC.
[09:46] <mbrownnyc> whaffle: so, this last bit of information is quite clearly why I would need and want a bridge in my situation
[09:46] <mbrownnyc> okay, the ICMP echo reply duplicate issue is likely out of the realm of this channel, but I sincerely appreciate the info on the kernels inner-workings
[09:52] <whaffle> mbrownnyc: either the kernel patch, or a bridge with an interface. Since the latter is quicker, yes
[09:54] <mbrownnyc> thanks whaffle

[edit2]

Depois de remover a ponte e remover o módulo do kernel fictício, eu só tive uma única interface relaxando, solitária. Ainda recebi respostas de echo icmp duplicadas ... na verdade, recebi uma quantia aleatória: link

A mesma coisa não acontece em alguns outros hosts no mesmo switch, então isso tem a ver com o próprio linux box. Eu provavelmente vou acabar reconstruindo na próxima semana. Então ... você sabe ... essa mesma coisa ocorrerá novamente.

[edit3] Adivinha? Eu reconstruí a caixa e ainda estou recebendo respostas de eco ICMP duplicadas. Deve ser a infraestrutura de rede, embora as tabelas ARP não contenham várias entradas.

[edit4] Que ridículo.

A máquina era uma sonda de rede, então eu estava (entrada e saída) espelhando uma porta de uplink para um nó que era a NIC. Então, o fluxo (deve ter) foi assim:

1. ICMP echo request entra pelo mirrored uplink port .
2. (o real) ICMP echo request é recebido pela NIC
3. (o espelhado) ICMP echo request é recebido pela NIC
4. ICMP echo reply é enviado para ambos.

Tenho vergonha de mim mesmo, mas agora eu sei. Foi sugerido em #networking para isolar o tráfego espelhado a uma interface que não tenha o IP ativado. Outra solução é criar uma VLAN administrativa e remover o espelhamento de pacotes para a VLAN administrativa (infelizmente, não é uma opção no meu switch).

    

Answer 1

Eu vejo. O que você está procurando é um vínculo. O que você tem com a sua ponte são múltiplas interfaces que agem independentemente nos pacotes que recebem, tendo herdado o endereço da interface da bridge. Isso é bom quando você está conectando dois switches de rede através de sua máquina. Quando os dois estão ligados ao mesmo switch, você vê esse comportamento de várias respostas.

As ligações, por outro lado, oferecem um comportamento que garante que apenas um carro na ligação lidará com o tráfego. Isso pode ser por meio de failover ativo / passivo, ligação com o comutador ou rotação através de cartões, dependendo de como você configura a interface de ligação.

Você troca não faz parte da equação aqui, já que você tem apenas um cabo conectado à interface de ligação.

    

Answer 2

Eu fiz um clone de VM (com VMware) e tive o mesmo problema. A placa de rede, da nova VM, tinha novo endereço MAC. Há uma maneira de consertar isso (eu já fiz isso no passado), mas porque estava com pressa. Eu apago a nova VM e quando eu clona novamente, com o antigo endereço MAC, tudo deu certo.