Я использую ядро 3.0, и я настроил контейнер Linux, который подключен к интерфейсу Tap на моем хост-компьютере. Это конфигурация моста:
:~$ brctl show bridge-1
bridge name bridge id STP enabled interfaces
bridge-1 8000.9249c78a510b no ns3-mesh-tap-1
vethjUErij
Моя проблема в том, что этот мост отбрасывает ARP-ответы, поступающие от интерфейса ns3-mesh-tap-1. Вместо этого, если я статически заполняю таблицы ARP и пингую напрямую, все работает, так что это должно быть связано с ARP.
Я читал о подобных проблемах в связанных сообщениях, и я пробовал решения, описанные в них, но, похоже, ничего не работает. В частности:
~$ grep net.bridge /etc/sysctl.conf
net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-filter-vlan-tagged = 0
net.bridge.bridge-nf-filter-pppoe-tagged = 0
arptables и ebtables не устанавливаются.
iptables FORWARD настроен на принятие:
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Мостовые интерфейсы настроены на PROMISC:
~$ ifconfig
ns3-mesh-tap-1 Link encap:Ethernet HWaddr 1a:c7:24:ef:36:1a
...
UP BROADCAST PROMISC MULTICAST MTU:1500 Metric:1
vethjUErij Link encap:Ethernet HWaddr aa:b0:d1:3b:9a:0a
....
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
Макинтоши, изученные мостом, верны (проверено с помощью brctl showmacs).
Приветствуется любое понимание того, что я делаю неправильно.
Наилучшие пожелания
Даниэль
Наконец-то я смог решить проблему. Что происходило, так это то, что за мостом у меня была ячеистая сеть с ошибками, которая ретранслировала запрос ARP обратно в сегмент Ethernet, откуда он пришел, что заставляло мост назначать этот исходный адрес другому порту, и поэтому, когда ARP ответ возвращался, мост не переадресовал его в нужный порт.