Меня сбивает с толку следующее странное поведение bridge / arp под Linux. Кажется, что он каким-то образом фильтрует направленные запросы ARP, тогда как он должен пересылать их на другой конец моста. Чтобы проверить, я запускаю следующую команду на рабочей станции в той же сети:
arping -t 00:de:ad:be:ef:00 xx.xx.xx.102
Адрес xx.xx.xx.102 нигде в сети не существует, как и MAC-адрес (очевидно: P)
Если сервер настроен без моста, произойдет ожидаемый результат: tcpdump в неразборчивом режиме видит входящие запросы ARP на интерфейсе. То же самое для других машин в сети. Это свидетельствует о том, что сетевая инфраструктура работает, то есть проблема не в коммутаторе.
Теперь, если я добавлю eth0 к интерфейсу моста, он перестает работать: tcpdump больше не показывает эти ARP-запросы, не на eth0, ни на br0! Как будто запросы где-то фильтруются, но я совершенно не понимаю, где это должно происходить.
Что еще интереснее, это машина с хрипой Debian. Сжимающая машина такого поведения не демонстрирует. У обоих есть карты Broadcom, использующие tg3 Водитель. Изменилось ли что-нибудь в ядрах серии 3.2 по сравнению с ядрами серии 2.6 в отношении моста, фильтрации MAC или чего-то подобного?
Итак, я наконец обнаружил основную причину этой проблемы. Отключение поддержки IMPI для сетевых карт заставляет все работать волшебным образом! Итак, для всех разочарованных системных администраторов, которые ищут в Google эту проблему: загрузите диагностический инструмент Broadcom (см. Вот), попробуйте найти что-нибудь, с чего вы можете загрузиться в DOS (что оказалось проблемой), и запустите b57udiag -c 0 -ipmi 0 и b57udiag -c 1 -ipmi 0 отключить IMPI на обеих картах, и это исправлено! Обратите внимание, что выключения IPMI в BMC недостаточно, его нужно отключить в самой сетевой карте.