☰

橋接到虛擬介面時停止重複的 icmp echo 回覆？

tag-icon • tag-icon linux bridge icmp
橋接到虛擬介面時停止重複的 icmp echo 回覆？

我最近配置了一個橋接器br0，其成員為eth0(real 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!)

使用tcpdumpon SERVERA，我能夠看到 icmp 回顯回復從其自身發送eth0，br0如下所示（奇怪的是，兩個回顯請求資料包「從」我的 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 上的主機確實看到 dup icmp 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

[編輯2]

刪除橋接器並刪除虛擬核心模組後，我只有一個單獨的介面，令人放鬆，孤獨。我仍然收到重複的 icmp echo 回覆...事實上我收到了隨機數量：http://pastebin.com/2LNs0GM8

同樣的事情不會發生在同一台交換器上的其他一些主機上，因此它與 linux 盒子本身有關。我可能會在下週重建它。然後...你知道...同樣的事情會再發生。

[編輯3] 你猜怎麼了？我重建了盒子，但仍然收到重複的 ICMP 回顯回應。必須是網路基礎設施，儘管 ARP 表不包含多個條目。

[編輯4] 多麼可笑。

該機器是網路探測器，因此我（入口和出口）將上行鏈路連接埠鏡像到作為 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 的映像（不幸的是，我的交換器上沒有此選項）。

答案1

我懂了。你正在尋找的是一種紐帶。您的網橋擁有多個接口，這些接口都獨立地對它們收到的繼承了網橋接口地址的資料包進行操作。當您透過電腦連接兩台網路交換器時，這非常有用。當您將它們都連接到同一個交換器時，您會看到多個回應的這種行為。

另一方面，債券提供了一種確保債券中只有一輛車可以處理交通的行為。這可以透過主動/被動故障轉移、與交換器綁定或透過卡片輪換來實現，具體取決於您配置綁定介面的方式。

您的開關實際上並不是這裡等式的一部分，因為您只有一條電纜連接到綁定介面。

答案2

我克隆了虛擬機器（使用 VMware），也遇到了同樣的問題。新虛擬機器中的網路卡具有新的 MAC 位址。有一種方法可以解決這個問題（我過去已經這樣做過），但因為我很著急。我刪除了新的虛擬機，當我使用舊的 MAC 位址再次克隆時，一切正常。

相關內容