ifcfg-eth0.200 не отвечает на широковещательные сообщения arp

У меня есть маршрутизатор Centos, который проделывает колоссальную работу в настройке, подобной этой:

• eth0 -> нет IP
• eth0.200 -> 192.168.200.1
• eth0.201 -> 192.168.201.1
• ... так до
• eth0.213 -> 192.168.213.1

У меня включена переадресация ipv4, чтобы разрешить маршрутизацию между vlan, а затем:

• eth1 -> нет IP
• eth1.201 -> 10.1.29.40
• eth0.202 -> 10.1.29.48
• ... так до
• eth0.213 -> 10.1.29.136

iptables выполняет SNAT, когда какая-либо из сетей eth0 ищет что-то в Интернете, используя диапазон IP-адресов от 10.198.29.138 до 10.198.29.142 в качестве общедоступных IP-адресов. Все отлично работает. Проблема в том, что мне нужен интерфейс VLAN 192.168.200.1 для размещения в eth1. Когда я перемещаю его в ifcfg-eth1.200, я вижу в захвате пакета, что многие клиенты пытаются заполнить свои таблицы ARP, спрашивая, какой MAC-адрес принадлежит 192.168.200.1, но eth1.200 никогда не отвечает! Я вижу, что другой eth0.XXX отвечает на широковещательную рассылку ARP, но не 200. Может быть, это связано с iptables или чем-то еще?

Мои iptables выглядят так:

РЕДАКТИРОВАНИЕ / РЕЗЮМЕ РЕШЕНИЯ БОЛЬШОЕ СПАСИБО ДЭВИДУ ХУДУ ЗА ЕГО КОММЕНТАРИЙ

Я смог поэкспериментировать с собой, устраняя другую проблему, что делает команда sysctl -w net.ipv4.conf.eth0 / 202.rp_filter = 0:

          SERVER
     <==eth0||eth1==>
  MAC FF:11 || MAC FF:22
 IP 1.1.1.1 || IP 3.3.3.1

если eth0 получает ARP-запрос для 3.3.3.1, СЕРВЕР по умолчанию не отвечает на него. После отключения фильтра обратного пути СЕРВЕР отвечает на запросы ARP на eth0, говоря «эй, IP 3.3.3.1 находится на MAC FF: 11», тогда как на самом деле он на eth1.

Затем следующий пакет прибывает на eth0, предназначенный для MAC FF: 11 и IP 3.3.3.1, и из-за таблицы маршрутизации все, что возвращается к IP 3.3.3.x, будет выходить из eth1, поэтому мои пакеты терялись в черная дыра, но это уже другая история.

В моем случае у меня примерно так:

          SERVER
     <==eth0||eth1==>
  MAC FF:11 || MAC FF:22

<==eth0.200 || eth1.200==>
 IP 3.3.3.1 || IP 1.1.0.1

<==eth0.201 || eth1.201==>
 IP 1.1.1.1 || IP 3.3.3.9

<==eth0.202 || eth1.202==>
 IP 1.1.2.1 || IP 3.3.3.17

<==eth0.203 || eth1.203==>
 IP 1.1.3.1 || IP 3.3.3.25

<==eth0.204 || eth1.204==>
 IP 1.1.4.1 || IP 3.3.3.33

так до eth0.213. Проблема в том, что, как вы можете видеть, сеть 1.1.0.0 находится на eth1, а 3.3.3.0 - на eth0, а остальные сети инвертированы.

Я надеюсь из того, что я обнаружил позже с помощью предложенной команды sysctl, что если RPF отключен, SERVER наконец-то ответит на те пакеты ARP, запрашивающие MAC 1.1.0.1 на eth1.200, но, к сожалению, я не смогу подтвердить.

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