Doppelte ICMP-Echoantworten beim Herstellen einer Überbrückung zu einer Dummy-Schnittstelle stoppen?

Question

Ich habe vor Kurzem eine Brücke br0mit den Mitgliedern eth0(real if) und dummy0( dummy.ko if) konfiguriert.

Wenn ich diesen Computer anpinge, erhalte ich doppelte Antworten wie:

  # 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!)

Mithilfe tcpdumpvon on SERVERAkonnte ich sehen, wie ICMP-Echoantworten von eth0und br0selbst wie folgt gesendet wurden (seltsamerweise kommen zwei Echoanforderungspakete „von“ meiner Windows-Box an 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

Beachten Sie, dass Tests ergeben, dass Hosts auf demselben physischen Switch kein DUP sehen icmp echo responses(ein Host im selben VLAN auf einem anderen Switch sieht jedoch ein DUP icmp echo response).

Ich habe gelesen, dass dies an der Tabelle eines Switches liegen könnte ARP, kann aber keine Informationen finden, die sich direkt auf beziehen bridges, nur auf bonds. Ich habe das Gefühl, dass mein Problem am Stack unter Linux liegt, nicht am Switch, bin aber für alle Vorschläge offen.

Das System führt den Kernel CentOS6/EL6 aus 2.6.32-71.29.1.el6.i686.

Wie verhindere ich, dass ICMP-Echoantworten beim Umgang mit einer Bridge-Schnittstelle/überbrückten Schnittstellen doppelt gesendet werden?

Danke,

Matt

[bearbeiten]

Kurzer Hinweis: In #linux wurde Folgendes empfohlen:

[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

Ich habe das gemacht und bin mit leeren Händen zurückgekommen. Dasselbe Dup-Problem.

Ich werde davon abrücken, die Dummy-Schnittstelle in die Brücke einzubinden, da:

[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

[Bearbeiten]

Nachdem ich die Bridge und das Dummy-Kernelmodul entfernt hatte, hatte ich nur noch eine einzige Schnittstelle, die einsam herumlungerte. Ich erhielt immer noch doppelte ICMP-Echo-Antworten ... tatsächlich erhielt ich eine zufällige Anzahl:http://pastebin.com/2LNs0GM8

Das Gleiche passiert auf einigen anderen Hosts auf demselben Switch nicht, es hat also mit der Linux-Box selbst zu tun. Ich werde sie wahrscheinlich nächste Woche neu aufbauen. Und dann ... wissen Sie ... wird das Gleiche wieder passieren.

[Bearbeiten] Und jetzt weißt du was? Ich habe die Box neu aufgebaut und erhalte immer noch doppelte ICMP-Echoantworten. Das muss an der Netzwerkinfrastruktur liegen, obwohl die ARP-Tabellen keine Mehrfacheinträge enthalten.

[Bearbeiten] Wie lächerlich.

Die Maschine war eine Netzwerksonde, also habe ich (Eingang und Ausgang) einen Uplink-Port auf einen Knoten gespiegelt, der die Netzwerkkarte war. Der Ablauf (muss) also folgendermaßen verlaufen sein:

1. ICMP echo requestkommt durch das herein mirrored uplink port.
2. (die reale) ICMP echo requestwird von der Netzwerkkarte empfangen
3. (die gespiegelte) ICMP echo requestwird von der Netzwerkkarte empfangen
4. ICMP echo replywird für beide gesendet.

Ich schäme mich, aber jetzt weiß ich es. Es wurde vorgeschlagen, #networkingden gespiegelten Datenverkehr entweder auf eine Schnittstelle zu isolieren, für die IP nicht aktiviert ist. Eine andere Lösung besteht darin, ein administratives VLAN zu erstellen und die Spiegelung von Paketen auf das administrative VLAN zu entfernen (leider keine Option auf meinem Switch).

Answer 1

Ich verstehe. Was Sie suchen, ist eine Verbindung. Was Sie mit Ihrer Bridge haben, sind mehrere Schnittstellen, die alle unabhängig voneinander auf empfangene Pakete reagieren, da sie die Adresse der Bridge-Schnittstelle geerbt haben. Das ist gut, wenn Sie zwei Netzwerk-Switches über Ihren Computer verbinden. Wenn Sie beide an denselben Switch angeschlossen haben, sehen Sie dieses Verhalten mehrerer Antworten.

Bonds hingegen bieten ein Verhalten, das sicherstellt, dass nur ein Auto im Bond den Verkehr abwickelt. Dies kann durch aktives/passives Failover, Bonding mit dem Switch oder Rotation durch Karten erfolgen, je nachdem, wie Sie die Bond-Schnittstelle konfigurieren.

Ihr Switch ist hier nicht wirklich Teil der Gleichung, da Sie nur ein Kabel haben, das mit der Bond-Schnittstelle verbunden ist.

Answer 2

Ich habe einen VM-Klon erstellt (mit VMware) und hatte das gleiche Problem. Die Netzwerkkarte der neuen VM hatte eine neue MAC-Adresse. Es gibt eine Möglichkeit, das Problem zu beheben (ich habe das in der Vergangenheit bereits getan), aber ich hatte es eilig. Ich lösche die neue VM und als ich sie erneut mit der alten MAC-Adresse klonte, war alles in Ordnung.