¿Parar duplicado icmp eco respuestas cuando puente a una interfaz dummy?

Hace poco configuré un puente br0 con miembros como eth0 (real if ) y dummy0 ( dummy.ko if ).

Cuando hago ping a esta máquina, recibo respuestas 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!) 

Utilizando tcpdump en SERVERA , pude ver las respuestas de eco de icmp enviadas desde eth0 y br0 como sigue (extrañamente dos packages de request de eco llegan "desde" mi casilla de 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 la pena anotar que las testings revelan que los hosts en el mismo conmutador físico no ven las icmp echo responses DUP icmp echo responses (un host en la misma VLAN en otro switch ve una icmp echo response dup icmp echo response ).

He leído que esto podría deberse a la tabla ARP de un switch, pero no puedo encontrar ninguna información directamente relacionada con bridges , sólo bonds . Tengo la sensación de que mi problema estaba en la stack de linux, no el interruptor, pero estoy abierto a cualquier sugerencia.

El sistema está ejecutando centos6 / el6 kernel 2.6.32-71.29.1.el6.i686 .

¿Cómo puedo evitar que las respuestas de eco ICMP se envíen por duplicado cuando se trata de una interfaz puente / interfaces puenteadas?

Gracias,

Mate

[editar]

Nota rápida: Se recomendó en #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 

Hice esto y me quedé vacío. El mismo problema de dup.

Me alejaré de include la interfaz ficticia en el puente 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 refernetworking 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 delivenetworking 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]

Después de quitar el puente, y de quitar el module muerto del kernel, tuve solamente una sola interfaz que me relajaba, solo. Todavía recibí duplicado icmp eco respuestas … de hecho he recibido una cantidad aleatoria: http://pastebin.com/2LNs0GM8

La misma cosa no sucede en algunos otros anfitriones en el mismo interruptor, así que tiene que hacer con la caja del linux sí mismo. Probablemente terminaré reconstruyendo la próxima semana. Entonces … sabes … esta misma cosa ocurrirá otra vez.

[editar3] ¿Adivina qué? He reconstruido la caja, y todavía estoy recibiendo duplicado ICMP respuestas de eco. Debe ser la infraestructura de networking, aunque las tablas ARP no contienen varias inputs.

[edit4] Qué ridículo.

La máquina era una sonda de networking, por lo que era (input y salida) reflection de un puerto de enlace ascendente a un nodo que era el NIC. Por lo tanto, el flujo (debe haber) ido así:

  1. ICMP echo request llega a través del mirronetworking uplink port .
  2. (el real) ICMP echo request es recibido por el NIC
  3. (la ICMP echo request reflejada) es recibida por el NIC
  4. ICMP echo reply para ambos.

Me avergüenzo de mí mismo, pero ahora lo sé. Se sugirió en #networking para aislar el tráfico duplicado en una interfaz que no tiene IP habilitada. Otra solución es crear una VLAN administrativa y eliminar el reflection de los packages a la VLAN administrativa (por desgracia, no es una opción en mi conmutador).

One Solution collect form web for “¿Parar duplicado icmp eco respuestas cuando puente a una interfaz dummy?”

Ya veo. Lo que buscas es un bono. Lo que tienes con tu bridge son múltiples interfaces que actúan de manera independiente en los packages que reciben al henetworkingar la dirección de la interfaz del puente. Esto es bueno cuando conecta dos conmutadores de networking a través de su máquina. Cuando los tiene conectados al mismo conmutador, ve este comportamiento de varias respuestas.

Los bonos, por otro lado, ofrecen un comportamiento que asegura que sólo un coche en el bono manejará el tráfico. Esto puede ser a través de conmutación por error activa / pasiva, enlace con el conmutador o rotation a través de tarjetas, dependiendo de cómo se configura la interfaz de enlace.

Usted cambia realmente no es parte de la ecuación aquí ya que sólo tiene un cable vinculado a la interfaz de enlace.

  • Xen VM no se pudo instalar
  • Cuando tengo que administrar un server Linux existente, ¿cuál es la mejor manera de comprobar si es seguro?
  • Encuentra la location de inicio del process desde linux
  • Linux: ¿Cómo saber qué process (s) está accediendo a mis files?
  • Redireccionar IP a un nombre de dominio mediante htaccess
  • no puede insall mysql-server después de la actualización a debian wheezy
  • Abrir mysql sólo a localhost y una dirección particular
  • (túnel ssh?) Acceso a server remoto con IP privada a través de un * DIFERENTE * server con IP pública
  • SCP a un server donde tengo permiso de SSH
  • Importando usuarios de passwd
  • No se pueden encontrar inodes usados ​​en el server
  • El linux y los temas del servidor de Windows, como ubuntu, centos, apache, nginx, debian y consejos de red.