У меня есть система, в которой на каждой виртуальной машине (кроме клиентов) работает OVS. Мосты (br0) каждой виртуальной машины изолированы и не предполагают другие интерфейсы IP и / или MA C. Клиентский шлюз - это интерфейс eth2 каждой виртуальной машины. Шлюз виртуальной машины - это eth2 сервера. Таблица ARP каждого элемента заполняется всеми IP-адресами и MAC-адресами сетевых интерфейсов. Существует туннель, соединяющий интерфейсы eth1 виртуальных машин с eth2 сервера. Это туннели vxlan, которые были добавлены к мостам как порт. Диаграмма системы и соответствующих IP-адресов изображена ниже:
В обычном потоке клиенты пингуют Inte rnet (он же 8,8 .8.8) и запросы ICMP появляются на сервере br0. Запрос и ответ появляются на сервере eth1, но по какой-то причине ответ никогда не отправляется обратно на br0, и он отбрасывается. Таким образом, я добавил на сервере 2 stati c маршрута, один для сети клиента 1, а другой для сети клиента 2 (192.168.10.0/24 и 192.168.20.0/24). Теперь ответ достигает клиента, но независимо от того, какую запись потока я устанавливаю на сервере br0, ответы никогда не достигают моста. Пример:
$ ovs-ofctl -O openflow13 br0 priority=100,ip,nw_dst=192.168.20.0/24,actions=output:tep2
(tep2 - конечная точка туннеля в br0 сервера, который подключается к eth1 VM2)
Мне нужен ответ на go через выбранный туннель (с потоком запись), потому что я также использую систему балансировки нагрузки, где, если соединение VM1 с сервером не работает, пакеты от клиента 1 будут перенаправлены на VM2 и, таким образом, через туннель конечной точки с 193.168.1.20 по 193.168.1.50. С маршрутами stati c ответы достигают клиента только с маршрутизацией, но никогда не достигают моста, и я не хочу этот тип конфигурации stati c. Как я должен сделать это с OVS? Почему ответы не доходят до br0 сервера, когда они появляются на eth1?