Мост — как хаб, затапливает все порты.

Извини, что не ответил раньше. Прикрепил более подробные снимки моей настройки. Я правда не понимаю, почему так происходит. Странно, но эта ситуация возникает только на первом мосту (trunk), на других — такого нет.

Всё сводится к тому, как работают мосты и коммутаторы. Мост поддерживает таблицу соответствия между MAC-адресами и портами. Когда мост решает, куда отправить кадр с уникастовым MAC-адресом, он ищет этот адрес в таблице. Если находит порт, связанный с этим MAC-адресом, он отправляет кадр только на этот порт; если нет — рассылает пакет на все порты. Причина в том, что таблица строится на основе источников MAC-адресов входящих кадров. Пока мост не получит кадр от конкретного уникастового MAC-адреса, он посылает все кадры для этого адреса на все порты. Такая же ситуация и с мультикаст-адресами, то есть с теми, у которых младший бит первого байта MAC-адреса равен 1. Простейший пример мультикаст-кадров — широковещательные ARP-запросы. Обратите внимание, что мост использует только исходный MAC-адрес кадра для обучения. Поэтому если подключённый элемент отправляет ARP-ответ, в котором в части ответа указан MAC-адрес, отличный от исходного в заголовке Ethernet, мост запоминает именно последний, но отправитель ARP-запроса начнёт слать пакеты на первый, и мост при этом будет рассылать пакеты от этого хоста на все порты. На этом механизме основаны некоторые протоколы избыточности. Таблица MAC-адресов в большинстве мостов имеет ограниченный размер, поэтому если поступает больше источников MAC-адресов, чем размер таблицы, самые старые записи перезаписываются. Это хорошо работает в большинстве случаев, но если сеть действительно огромна или кто-то специально заливает мост поддельными MAC-адресами, мост начинает работать как хаб для большинства кадров, пока атака продолжается. Ещё одна проблема — петли. Поскольку в Ethernet-кадре нет счётчика прыжков, если кадр, отправленный мостом, возвращается к нему же, мост отправляет его снова. Поэтому Ethernet-петли нужно избегать. Если же петля проходит через устройство с ограничением пропускной способности или задержкой, она может не полностью загрузить мост, и нормальный трафик всё же будет проходить. Используйте сниффер пакетов и Wireshark, чтобы проверить заголовки Ethernet и понять, какая из описанных выше ситуаций вызывает у вас проблему.

Извините, я не нашёл эту важную деталь нигде в вашем описании.

Ранее это уже говорили, но я хочу ещё раз подчеркнуть: недорогие «коммутаторы» имеют таблицы MAC-адресов, которые быстро переполняются, и в корпоративных условиях они начинают вести себя как хабы. С таким я сталкиваюсь постоянно. Плюс ко всему, когда люди подключают эти устройства, они создают L2-петли, потому что у них нет никакой защиты от этого.

Ну, чтобы опровергнуть предположение @acruhl, нужно понять, содержится ли там только пара адресов или же тысячи других. Я попытался еще раз взглянуть на ваши снимки, но единственные MAC-адреса, которые я там увидел, — это адреса CAP-интерфейсов. Похоже, где-то что-то упущено, то есть изученный MAC-адрес и MAC-адрес назначения могут отличаться в каком-то бите посередине.

Можете, пожалуйста, предоставить результат команды “/export hide-sensitive”, заменив IP-адреса на фейковые, но сохранив между ними соотношения (чтобы, к примеру, не потому что настройки DHCP имеют к вашей проблеме отношение, а просто чтобы было видно взаимосвязь между локальным IP, пулом DHCP и настройками DHCP-сети).

Также можете выложить результат команды /interface bridge host print, где bridge~"your-bridge-name" тоже замаскирован так, чтобы была видна важная информация, но без раскрытия личных данных?

Я заметил, что вы используете кучу VLAN-интерфейсов, возможно, здесь есть связь: если пакет размечен с неправильным VLAN ID, он может рассылаться повсюду, если таблица Ethernet-хостов учитывает VLAN ID (а это происходит, если включен vlan-filtering). Но, поскольку вы говорите, что «всегда так работало», скорее всего, у вас vlan-filtering не включен.