停止桥接到虚拟接口时重复ICMP回应答复？

我最近configuration了一个网桥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!) 

在SERVERA上使用tcpdump ，我能够看到从eth0和br0本身发送的icmp echo回复，如下所示（奇怪的是两个回应请求包“从”我的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 

值得注意的是，testing表明同一物理交换机上的主机看不到DUP icmp echo responses （另一台交换机上同一VLAN上的主机看到dup icmp echo response ）。

• 通过VPN隧道的Nmap ping扫描返回所有活着的主机？
• Traceroute，ICMP，UDP和TCP
• 由于ICMP主机不可达，Linux ping命令提前退出
• 如何在Cisco ASA 55xx路由器上允许ICMP回显请求？
• 否认ICMPtypes3代码4stream量 – 好还是坏？

我读过，这可能是由于交换机的ARP表，但我找不到任何直接关系到bridges ，只是bonds 。 我有一个感觉我的问题躺在Linux上的堆栈，而不是开关，但我打开任何build议。

系统运行centos6 / el6内核2.6.32-71.29.1.el6.i686 。

在处理网桥接口/桥接接口时，如何阻止ICMP Echo回复被重复发送？

谢谢，

马特

[编辑]

快速提示：在#linux中build议：

 [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 

我做了这个，空了。 相同的dup问题。

我将从包含桥接中的虚拟接口的方式转移到：

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

拆除桥接器，去掉虚拟内核模块之后，我只有一个界面变冷，寂寞。 我仍然收到icmp的重复回复…其实我收到了一个随机的数量： http : //pastebin.com/2LNs0GM8

在同一交换机上的其他几台主机上也不会发生同样的事情，所以它必须与Linux盒本身相关。 我可能最终会在下周重build。 那么…你知道…同样的事情会再次发生。

猜猜是什么？ 我重build了这个盒子，而且我仍然收到重复的ICMP回应回复。 必须是networking基础结构，尽pipeARP表不包含多个条目。

多么荒谬。

机器是一个networking探测器，所以我（入口和出口）将上行链路端口镜像到NIC的节点。 所以，stream量（必须）是这样的：

1. ICMP echo request通过mirrored uplink port进入。
2. （真实的） ICMP echo request由NIC接收
3. （镜像的） ICMP echo request由NIC接收
4. 两者都发送ICMP echo reply 。

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