☰

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

tag-icon • tag-icon linux bridge icmp
ダミー インターフェイスにブリッジするときに重複する ICMP エコー応答を停止しますか?

br0最近、メンバーをeth0(実数if) およびdummy0( ) としてブリッジを構成しましたdummy.ko if。

このマシンに 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から送信される icmp エコー応答を確認できました(奇妙なことに、2 つのエコー要求パケットが Windows ボックスから到着します)。eth0br0myhost

  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 上のホストは dup を認識しますicmp echo response)。

これはスイッチのテーブルが原因である可能性があると読んだことがありますARPが、 に直接関連する情報は見つかりませんでした。 問題はスイッチではなくbridges、bondsLinux のスタックにあるような気がしますが、何か提案があれば歓迎します。

システムは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

[編集2]

ブリッジを削除し、ダミー カーネル モジュールを削除した後、1 つのインターフェイスだけが寂しく落ち着いていました。それでも重複した icmp エコー応答を受信しました... 実際、ランダムな数を受信しました。http://pastebin.com/2LNs0GM8

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

[編集3] どうなったと思いますか? ボックスを再構築しましたが、まだ重複した ICMP エコー応答を受信して​​います。ARP テーブルに複数のエントリが含まれていないにもかかわらず、ネットワーク インフラストラクチャに問題があるに違いありません。

[編集4] 馬鹿げている。

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

  1. ICMP echo requestを通して入ってきますmirrored uplink port。
  2. （実際の）はICMP echo requestNICによって受信される
  3. （ミラーリングされたもの）はICMP echo requestNICによって受信される
  4. ICMP echo reply両方に送信されます。

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

答え1

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

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

ボンド インターフェイスにリンクされているケーブルは 1 本だけなので、スイッチはここでは考慮されません。

答え2

VM のクローン (VMware を使用) を作成しましたが、同じ問題が発生しました。新しい VM のネットワーク カードに新しい MAC アドレスが設定されました。修正方法はありますが (以前にすでに実行しました)、急いでいたため、新しい VM を削除し、古い MAC アドレスで再度クローンを作成すると、すべて正常になりました。

関連情報