Recientemente configuré un puente br0con 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!)
Usando tcpdumpon SERVERA, pude ver que las respuestas de eco de icmp se envían desde eth0y br0de sí mismo de la siguiente manera (curiosamente, dos paquetes de solicitud de eco llegan "desde" mi cuadro 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 señalar que las pruebas revelan que los hosts en el mismo conmutador físico no ven un DUP icmp echo responses(un host en la misma VLAN en otro conmutador sí ve un dup icmp echo response).
Leí que esto podría deberse a la ARPtabla de un conmutador, pero no puedo encontrar ninguna información directamente relacionada con bridges, solo bonds. Tengo la sensación de que mi problema radica en la pila de Linux, no en el conmutador, pero estoy abierto a cualquier sugerencia.
El sistema ejecuta el kernel centos6/el6 2.6.32-71.29.1.el6.i686.
¿Cómo evito 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: En #linux se recomendó:
[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 quedé vacío. El mismo problema de duplicación.
Dejaré de incluir 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 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
[editar2]
Después de quitar el puente y quitar el módulo de kernel ficticio, solo tenía una interfaz relajándose, solitaria. Todavía recibí respuestas duplicadas de icmp echo... de hecho, recibí una cantidad aleatoria:http://pastebin.com/2LNs0GM8
No sucede lo mismo en algunos otros hosts en el mismo conmutador, por lo que tiene que ver con la propia caja de Linux. Probablemente terminaré reconstruyéndolo la próxima semana. Entonces... ya sabes... esto mismo volverá a ocurrir.
[editar3] ¿Adivina qué? Reconstruí la caja y sigo recibiendo respuestas de eco ICMP duplicadas. Debe ser la infraestructura de red, aunque las tablas ARP no contienen múltiples entradas.
[editar4] Que ridículo.
La máquina era una sonda de red, por lo que estaba (entrada y salida) reflejando un puerto de enlace ascendente en un nodo que era la NIC. Entonces, el flujo (debe haber) sido así:
ICMP echo requestentra por elmirrored uplink port.- (lo real)
ICMP echo requestes recibido por la NIC - (el reflejado)
ICMP echo requestes recibido por la NIC ICMP echo replySe envía para ambos.
Me avergüenzo de mí mismo, pero ahora lo sé. Se sugirió #networkingaislar el tráfico reflejado en una interfaz que no tenga IP habilitada. Otra solución es crear una VLAN administrativa y eliminar la duplicación de paquetes en la VLAN administrativa (desafortunadamente, no es una opción en mi conmutador).
Respuesta1
Veo. Lo que estás buscando es un vínculo. Lo que tiene con su puente son múltiples interfaces que actúan de forma independiente en los paquetes que reciben habiendo heredado la dirección de la interfaz del puente. Esto es bueno cuando conectas dos conmutadores de red a través de tu máquina. Cuando los tienes a ambos conectados al mismo interruptor, ves este comportamiento de respuestas múltiples.
Los bonos, por otro lado, ofrecen un comportamiento que garantiza que solo un automóvil del bono manejará el tráfico. Esto puede realizarse mediante conmutación por error activa/pasiva, vinculación con el conmutador o rotación de tarjetas, dependiendo de cómo configure la interfaz de vinculación.
Su cambio no es realmente parte de la ecuación aquí ya que solo tiene un cable conectado a la interfaz de enlace.
Respuesta2
Hice un clon de VM (con VMware) y tuve el mismo problema. La tarjeta de red, de la nueva VM, tenía una nueva dirección MAC. Hay una manera de solucionarlo (ya lo hice en el pasado) pero porque tenía prisa. Elimino la nueva VM y cuando vuelvo a clonar, con la antigua dirección MAC, todo estaba bien.