Назад | Перейти на главную страницу

Ответ ARP отсутствует на другом порту моста linux на основе ubuntu 13.10

Недавно я построил мост на базе Linux для мониторинга пакетов, но есть БОЛЬШАЯ проблема.

окружающая среда,

  1. общий окр.
    • цель мониторинга - виртуальные машины в vSphere.
    • два vSwitch настроены на хосте vSphere.
    • vSwitch 1 настроен с NIC для связи по внешнему мосту.
    • vSwitch 2 настроен без сетевого адаптера для подключения мост-виртуальная машина.
    • оба настроены как «Разрешить беспорядочный режим».
  2. окр. моста.
    • на основе ubuntu 13.10, установленной как минимальная виртуальная машина.
    • br0 был настроен с помощью eth0 (для vS1) и eth1 (для vS2)

Моя проблема в том, что когда виртуальная машина пингует GW, выполняется запрос ARP и есть ответ от GW. но ответный пакет отображается только на eth0 и br0.

superhero@vim-firewall:~$ sudo tcpdump -i eth0 -n host 192.168.10.172
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:13:45.809949 ARP, Request who-has 192.168.10.1 tell 192.168.10.172, length 46
12:13:45.810060 ARP, Request who-has 192.168.10.1 tell 192.168.10.172, length 46
12:13:45.810742 ARP, Reply 192.168.10.1 is-at 00:00:aa:aa:aa:d9, length 46
...
superhero@vim-firewall:~$ sudo tcpdump -i br0 -n host 192.168.10.172
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:13:51.810928 ARP, Request who-has 192.168.10.1 tell 192.168.10.172, length 46
12:13:51.811031 ARP, Request who-has 192.168.10.1 tell 192.168.10.172, length 46
12:13:51.811579 ARP, Reply 192.168.10.1 is-at 00:aa:aa:aa:aa:d9, length 46
...
superhero@vim-firewall:~$ sudo tcpdump -i eth1 -n host 192.168.10.172
tcpdump: WARNING: eth1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
12:13:57.812937 ARP, Request who-has 192.168.10.1 tell 192.168.10.172, length 46
12:13:57.813040 ARP, Request who-has 192.168.10.1 tell 192.168.10.172, length 46
...

Мне нужна помощь!

PS. в настоящее время проблемой является только ARP. если я добавлю MAC-адрес GW вручную, сетевое соединение в порядке, кроме доступа к локальной подсети.

Нашел еще одно рабочее решение этой проблемы! https://communities.vmware.com/message/2141853#2141853

Вы можете установить опцию Advanced System для хоста Esxi: Net.ReversePathFwdCheckPromisc = 1 Эта опция отключает дублирование пакета на vSwitch с несколькими восходящими каналами и группой портов в неразборчивом режиме.

Надеюсь, эта информация вам поможет.

Ой! Наконец-то нашел рабочее решение!

Я потратил около 10+ часов на решение этой проблемы в течение трех дней, но решение не совсем чистое, оно ближе к временному решению. Для этого мне нужно реальное решение или лучший обходной путь. пожалуйста помоги.

во всяком случае, я нашел ниже информацию от vmware cummunity. (основная причина проблемы связана с vmware.)

  1. https://communities.vmware.com/message/1509541#1509541
  2. https://communities.vmware.com/message/2208190#2208190

URL (1) - это комментарий оригинального автора, у которого такая же проблема, о причине проблемы. проблема вызвана поведением vSwitch. если подключены два или более физических сетевых адаптера, они сделали дублированный запрос ARP, и мост Linux получит дублированный запрос от внешнего сетевого адаптера / порта. так попадается в заблуждение карта MAC-портов.

Я проверил это (отсоедините резервный сетевой адаптер от vSwitch), тогда сеть работает нормально. (с vSwitch с одной сетевой картой)

другой комментарий, номер URL (2), описывает обходной путь. если я установил время устаревания на 0 с моста linux, он работает как фиктивный концентратор (отправляет все пакеты на все порты), поэтому ответ ARP будет достигнут виртуальной машины во внутренней сети.

В моем случае у моего моста всего два порта для внутреннего и внешнего подключения, так что ИМХО это не большая проблема. но есть что-то непонятное.

Если есть способ заблокировать зацикленный / дублированный запрос от резервного сетевого адаптера или проигнорировать дублирующийся запрос или другой умный способ обработки таблицы MAC-адресов моста, позвольте мне сейчас.

Спасибо, что прочитали, и надеюсь помочь с той же проблемой!

В VMWARE ESXI 6.x 7.x необходимо оставить принять режим в следующих вариантах: "Беспорядочный режим" и "Подделанные трансмиссии"

https://www.virtuallyghetto.com/2013/11/why-is-promiscuous-mode-forged.html