Прекратить дублирование эхо-ответов icmp при подключении к фиктивному интерфейсу?
Я недавно настроил мост br0 с членами как eth0 (реальный if) а также dummy0 (dummy.koif).
Когда я пингую эту машину, я получаю дубликаты ответов:
# 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, отправленные с 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 на другом коммутаторе видит icmp echo response).
Я читал, что это может быть связано с ARP таблица переключателя, но я не могу найти информацию, непосредственно связанную с bridges, просто bonds, Я чувствую, что моя проблема лежит в стеке на Linux, а не на коммутаторе, но я открыт для любых предложений.
В системе работает ядро centos6/el6 2.6.32-71.29.1.el6.i686,
Как я могу предотвратить повторную отправку эхо-ответов ICMP при работе с мостовым интерфейсом / мостовыми интерфейсами?
Спасибо,
Matt
[редактировать]
Краткое примечание: в #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] Как смешно.
Машина была сетевым зондом, поэтому я (вход и выход) зеркалировал порт восходящей линии связи с узлом, который был сетевой картой. Итак, поток (должно быть) пошел так:
ICMP echo requestприходит черезmirrored uplink port,- (реальный)
ICMP echo requestполучен NIC - (зеркальный)
ICMP echo requestполучен NIC ICMP echo replyотправлено для обоих.
Мне стыдно за себя, но теперь я знаю. Было предложено на #networking либо изолировать зеркальный трафик к интерфейсу, для которого не включен IP-адрес. Другим решением является создание административной VLAN и удаление зеркалирования пакетов в административной VLAN (к сожалению, на моем коммутаторе это не вариант).
2 ответа
Понимаю. То, что вы ищете, это связь. То, что у вас есть с вашим мостом, это несколько интерфейсов, которые все действуют независимо от пакетов, которые они получают, унаследовав адрес интерфейса моста. Это хорошо, когда вы подключаете два сетевых коммутатора через ваш компьютер. Когда вы подключите их обоих к одному и тому же коммутатору, вы увидите поведение нескольких ответов.
Облигации, с другой стороны, предлагают поведение, которое гарантирует, что только один автомобиль в облигации будет обрабатывать трафик. Это может быть активным / пассивным переключением при сбое, соединением с коммутатором или вращением через карты в зависимости от того, как вы настроили интерфейс связывания.
Вы переключаетесь на самом деле не является частью уравнения здесь, поскольку у вас есть только один кабель, связанный с интерфейсом связи.
Я сделал клон VM (с VMware), и у меня возникла та же проблема. Сетевая карта новой виртуальной машины имела новый MAC-адрес. Есть способ исправить это, (я уже делал это в прошлом), но потому что я спешил. Я удаляю новую ВМ, и когда я снова клонируюсь, со старым MAC-адресом, все было в порядке.