☰

桥接至虚拟接口时停止重复的 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!)

使用，我能够看到从和其本身发送的 icmp echo 回复tcpdump，如下所示（奇怪的是两个 echo 请求数据包“来自”我的 Windows 机器）：SERVERAeth0br0myhost

  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由网卡接收
  4. ICMP echo reply发送给两者。

我为自己感到羞愧，但现在我知道了。有人建议#networking将镜像流量隔离到未启用 IP 的接口。另一个解决方案是创建一个管理 VLAN，并删除到管理 VLAN 的数据包镜像（不幸的是，我的交换机上没有这个选项）。

答案1

我明白了。你要找的是绑定。你的网桥有多个接口，它们都独立处理它们收到的数据包，并继承了网桥接口的地址。当你通过你的机器连接两个网络交换机时，这很有用。当你把它们都挂在同一个交换机上时，你会看到这种多重回复的行为。

另一方面，绑定提供了一种行为，可确保绑定中只有一辆汽车会处理流量。这可以通过主动/被动故障转移、与交换机绑定或轮换卡来实现，具体取决于您如何配置绑定接口。

由于您只有一根电缆连接到绑定接口，因此您的交换机实际上并不是这里方程的一部分。

答案2

我克隆了一个虚拟机（使用 VMware），但遇到了同样的问题。新虚拟机的网卡有新的 MAC 地址。有一种方法可以修复它（我以前已经这样做过），但因为我太着急了。我删除了新的虚拟机，当我再次克隆时，使用旧的 MAC 地址，一切都正常了。

相关内容