LINUX.ORG.RU
Форум — Admin  

Игнорируется routing table при отправке arp запросов

 , , ,


0

1

Добрый день. Сеть настроена следующим образом: два физических порта eth0 и eth1. На eth0 настроены два vlan (vlanid 2 и 3), трафик без vlan-ов на нём не нужен. + есть мост между eth1 и одним из vlan-ов.

      port eth1               bridge br0             vlan eth0.2
     ip 0.0.0.0      ----  ip 192.168.1.103   ----    ip 0.0.0.0       ----  
mac 0a:81:c7:64:2c:8b    mac 0a:81:c7:64:2c:8b    mac 0a:81:c7:64:2c:8b   |         port eth0 
                                                                          |----    ip 0.0.0.0     
                                                      vlan eth0.3         |     mac d2:37:d1:13:3c:42
                                                   ip 100.255.255.0    ----
                                                 mac d2:37:d1:13:3c:42

В системе видится так:

br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.103  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 0a:81:c7:64:2c:8b  txqueuelen 1000  (Ethernet)

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether d2:37:d1:13:3c:42  txqueuelen 1000  (Ethernet)

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 0a:81:c7:64:2c:8b  txqueuelen 1000  (Ethernet)

eth0.2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 0a:81:c7:64:2c:8b  txqueuelen 1000  (Ethernet)

eth0.3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 100.255.255.2  netmask 255.255.255.0  broadcast 0.0.0.0
        ether d2:37:d1:13:3c:42  txqueuelen 1000  (Ethernet)

и соответствующая этим настройкам routing table:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br0
100.255.255.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0.3

При выполнении ping 192.168.1.1 я ожидаю, что система обратится к routing table, там увидит что для этой подсети указан интерфейс br0. В этот интерфейс отправится широковещательный arp запрос «who has 192.168.1.0 ?». И если я буду смотреть wireshark-ом снаружи трафик с порта eth0, я должен увидеть, что этот запрос выйдет с VLAN_tag_id=2 и dst=0a:81:c7:64:2c:8b. Но вылетает пакет без тега vlan и dst=d2:37:d1:13:3c:42. Как будто пакет был отправлен не в br0, а в eth0, которого в routing вообще нет. Чтобы убедиться в этом, пробую сделать arpping, явно указав интерфейс.

arping 192.168.1.1 -I br0

Так всё работает - вылетает пакет с VLAN_tag_id=2 и dst=0a:81:c7:64:2c:8b. Вопрос - почему система игнорирует routing table и посылает arp пакеты не в br0 а в eth0 когда я делаю обычный пинг? Как изменить это поведение?

есть мост между eth1 и одним из vlan-ов

  1. Зачем? Вам нужна связанность eth1 и одного из VLAN’ов на L2?

  2. покажите sudo brctl show, на всякий случай.

При выполнении ping 192.168.1.1 …. я должен увидеть, что этот запрос выйдет с VLAN_tag_id=2

Для этого у Вас 192.168.1.103/24 должен быть назначен не на br0, а на интерфейс с vlan’ом.

Опишите, какие задачи Вы таким образом решаете. Возможно, предложим реорганизацию сети.

Harliff ★★★★★
()
Последнее исправление: Harliff (всего исправлений: 1)
Ответ на: комментарий от Harliff

вангую, что мутит что-то с виртуалками.

недосуг вчитываться, но явно либо разбираться с топологией и менять что-то в сетке, либо надо играться с настройкой ARP в /proc, ну там запрещать рассылку и т.п. в proc/sys/net/ipv4/conf/IFACE/arp_ignore, /proc/sys/net/ipv4/conf/IFACE/arp_announce

mumpster ★★★★★
()
Ответ на: комментарий от Bloody

не-не-не!
у меня на днях была подобная джигурда и там было именно на почве br0, влан филтеринг и этого вот всего.
кстати, попутно выяснилось, что невозможно без ovs штатными средствами пропустить ШВ пакет через бридж в тегированном виде. только если PVID. это был bootp/dhcp запрос.

в моём случае оказалось проще сделать соответствующий PVID на нормальном коммутаторе и васякот!

и да - повесить dhcpd на br0 - не предлагать. по услвоиям задачи не подходило.

и были очень похожие проблемы с ARP.

mumpster ★★★★★
()
Ответ на: комментарий от mumpster

что невозможно без ovs штатными средствами пропустить ШВ пакет через бридж в тегированном виде. только если PVID. это был bootp/dhcp запрос.

В смысле броадкаст не проходит?!

dhcpd с кучкой vlan-ов замечательно живет в контейнере который к хосту подключен через мост c vlan_filtering.

Раньше я наступал на интересные грабли с dhcp(udp) через veth + bridge, но они лечаться либо через «ethtool -K vethX rx off tx off», либо через «iptables ... -o brX -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill»

PS ovs нужен для всяких хитровыдуманных кейсов.

vel ★★★★★
()
Ответ на: комментарий от vel

у меня не veth был, попроще конфиг (на скору руку)

говорю же, тупо не проходили только ШВ, никаких видимых причин для этого не было, юникасты все шли нормально

mumpster ★★★★★
()
Admin