У меня странное виртуальное (докер-мосты) сетевое состояние

У меня есть два докера, подключенных к одному и тому же мосту через docker-compose. Один докер — «зонд», а другой — «инжектор». Инжектор использует tcpreplay для воспроизведения захвата, и «зонд» должен получить его через tcpdump. Излишне говорить, что воспроизведенный захват не имеет никакого отношения к IP-адресам или компьютерам Mac NICS, подключенным к мосту. пинг между хостами работает нормально.

Теперь есть третий сетевой адаптер, автоматически открываемый докером для хост-компьютера.

       +--->NIC1 ["injector" docker / uses tcpreplay to inject ]
bridge +--->NIC2 ["probe" docker / uses tcpdump to listen]
|
+--- NIC3 host [used for testing sometimes as injector and sometimes as listener]  

Что на самом деле происходит, так это то, что когда tcpreplay запускается с HOST (вводит захват через NIC3), все работает нормально, а tcpdump на «зонде» показывает воспроизведенный трафик. Однако, когда tcpreplay используется на инжекторе и внедряет захват через NIC1, только первые два пакета захвата можно увидеть на «зонде», а затем весь трафик на «зонде» останавливается (также перестанет работать внедрение с хоста). если tcpdump запущен на NIC3, он нормально получает весь захваченный трафик от инжектора.

  • ifconfig на «пробе» не показывает отброшенных пакетов
  • iptables на хосте не увеличивает счетчики отброшенных пакетов (надеюсь, я делаю это правильно «sudo iptables -L -v -n | grep -i drop»)
  • tcpdump автоматически включает неразборчивый режим на зонде

У кого-нибудь есть объяснение этому асимметричному поведению? Есть идеи, как его отлаживать?

Инжектор и хост - AlmaLinux:8, зонд -Centos:7 tcpreplay версии 4.4.1

answer

Причина, по которой мост не пропускал кадры, связана с механизмом обучения Mac. Допустим, мы хотим инжектить трафик с MAC1->MAC2 на NIC1 в контейнере инжектора, фильтр моста пропустит (направит на зонд) трафик с MAC1 --> MAC2 и узнает, что MAC1 находится на NIC1, но затем он откажется заливать все, что приходит с MAC2-->MAC1 на тот же порт, потому что думает, что MAC1 находится на том же порту, с которого идет трафик. Опять же, введенный трафик был записан где-то еще и не имеет никакого отношения к фактической топологии моста.

Отключение механизма обучения Mac на мосту, как описано здесь, решает проблему, и все кадры, введенные из инжектора, будут переданы для проверки.

Причина асимметричного поведения при вводе трафика с хоста не ясна. Но я вижу, что мост на самом деле не активирует свой механизм обучения, когда трафик вводится из NIC3, например, маки из введенного трафика по какой-то причине не появляются в списке изученных маков с самого начала.