我最近配置了一个桥接器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回复如下(奇怪的是两个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,length 40 23:19:05.324217 IP myhost.domain.local > SERVERA.domain.local: ICMP echo request,length 40 23:19:05.324221 IP SERVERA.domain.local > myhost.domain.local: ICMP echo reply,length 40 23:19:05.324264 IP SERVERA.domain.local > myhost.domain.local: ICMP echo reply,length 40 23:19:05.324272 IP SERVERA.domain.local > myhost.domain.local: ICMP echo reply,length 40
值得注意的是,测试显示同一物理交换机上的主机没有看到DUP icmp echo响应(另一台交换机上同一VLAN上的主机确实看到了重复的icmp echo响应).
我读过这可能是由于交换机的ARP表,但我找不到任何与网桥直接相关的信息,只是债券.我有一种感觉我的问题在于Linux上的堆栈,而不是交换机,但我对任何建议都开放了.
系统运行centos6 / el6 kernel 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]
删除桥接器,并删除虚拟内核模块后,我只有一个接口放松,孤独.我仍然收到了重复的icmp echo回复…实际上我收到了一个随机数量：http://pastebin.com/2LNs0GM8
在同一台交换机上的其他几台主机上也不会发生同样的事情,因此它与linux机箱本身有关.我可能最终会在下周重建它.然后……你知道……同样的事情会再次发生.
[EDIT3]
你猜怎么着？我重建了这个盒子,我仍然收到重复的ICMP回复回复.必须是网络基础结构,尽管ARP表不包含多个条目.
[edit4]
多么荒谬.
这台机器是一个网络探测器,所以我(入口和出口)将上行链路端口镜像到作为NIC的节点.所以,流程(必须有)就像这样：
> ICMP echo请求通过镜像上行链路端口进入.
>(真实的)ICMP回应请求由NIC接收
>(镜像的)ICMP回应请求由NIC接收
>为两者发送ICMP回送回复.
我为自己感到羞耻,但现在我知道了.在#networking上建议将镜像流量隔离到未启用IP的接口.另一种解决方案是创建管理VLAN,并删除数据包到管理VLAN的镜像(遗憾的是,我的交换机上没有选项).
