web-dev-qa-db-ja.com

ダミーインターフェイスにブリッジするときに重複するicmpエコー応答を停止しますか？

最近、メンバーをbr0（実際のif）およびeth0（dummy0if）としてブリッジdummy.koを構成しました。

このマシンにpingを実行すると、次のように重複した応答が返されます。

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

tcpdumpでSERVERAを使用すると、次のようにeth0およびbr0自体からicmpエコー応答が送信されているのを確認できました（奇妙なことに、2つのエコー要求パケットが「から」到着します）私の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

注目に値するのは、テストの結果、同じ物理スイッチ上のホストにはDUP icmp echo responsesが表示されないことです（同じVLAN別のスイッチ上のホストにはdupicmp echo responseが表示されます）） ）。

これはスイッチのARPテーブルが原因である可能性があることを読みましたが、bridgesに直接関連する情報は見つかりません。bondsだけです。私の問題は、スイッチではなくLinuxのスタックにあると感じていますが、提案はあります。

システムはcentos6/el6カーネル2.6.32-71.29.1.el6.i686を実行しています。

ブリッジインターフェイス/ブリッジインターフェイスを処理するときに、ICMPエコー応答が重複して送信されないようにするにはどうすればよいですか？

おかげで、

マット

[編集]

クイックノート：#linuxでは次のことが推奨されていました：

[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

私はこれをして空っぽになりました。同じ重複の問題。

次のように、ブリッジにダミーインターフェイスを含めることをやめます。

[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]

ブリッジを削除し、ダミーのカーネルモジュールを削除した後、1つのインターフェイスのみが落ち着いて孤独になりました。私はまだ重複したicmpエコー応答を受け取りました...実際、ランダムな量を受け取りました： http://Pastebin.com/2LNs0GM8

同じスイッチ上の他のいくつかのホストでは同じことが起こらないため、Linuxボックス自体に関係しています。私はおそらく来週それを再構築することになるでしょう。それから...あなたは知っています...これと同じことが再び起こります。

[edit3]何だと思いますか？私はボックスを再構築しましたが、それでも重複したICMPエコー応答を受信して​​います。 ARPテーブルには複数のエントリが含まれていませんが、ネットワークインフラストラクチャである必要があります。

[edit4]なんてばかげている。

マシンはネットワークプローブだったので、私は（入力と出力で）アップリンクポートをNICであるノードにミラーリングしていました。したがって、フローは（必ず）次のようになります。

  1. ICMP echo requestはmirrored uplink portから入ります。
  2. （実際の）ICMP echo requestはNICによって受信されます
  3. （ミラーリングされた）ICMP echo requestはNICによって受信されます
  4. ICMP echo replyが両方に送信されます。

私は自分を恥じていますが、今は知っています。 #networkingで、ミラーリングされたトラフィックをIPが有効になっていないインターフェイスに分離することが提案されました。別の解決策は、管理VLANを作成し、管理VLANへのパケットのミラーリングを削除することです（残念ながら、私のスイッチのオプションではありません）。

linuxbridgeicmp
4
mbrownnyc

そうですか。あなたが探しているのは絆です。ブリッジで得られるのは、ブリッジインターフェースのアドレスを継承した受信パケットですべて独立して動作する複数のインターフェースです。これは、マシンを介して2つのネットワークスイッチを接続する場合に適しています。両方が同じスイッチに接続されている場合、複数の応答のこの動作がわかります。

一方、ボンドは、ボンド内の1台の車だけがトラフィックを処理することを保証する動作を提供します。これは、アクティブ/パッシブフェイルオーバー、スイッチとのボンディング、またはボンドインターフェースの設定方法に応じてカードを循環することで実行できます。

ここでは、ボンドインターフェイスにリンクされているケーブルが1本しかないため、スイッチは実際には方程式の一部ではありません。

2
Jeff Ferland

VM（VMwareを使用）のクローンを作成しましたが、同じ問題が発生しました。新しいVMのネットワークカードに新しいMACアドレスがありました。これを修正する方法があります（I過去にこれを既に実行しました）が、私は急いでいたので、新しいVMを削除し、古いMACアドレスで再度クローンを作成すると、すべてが問題ありませんでした。

1
MBrito