Баг с CRS-317? Неотключаемый unknown unicast flood на CPU

[disappointed]

Нашёл какой-то кошмарный баг архитектуры.

Имеется CRS-317 с последней прошивкой (на старых тоже самое).

Настроен в ROS бридж со всеми портами, включён vlan filtering, и используется как свитч с hw offload.

Всё работает вроде как хорошо. Пока не потребовалось прогнать через него ТВ потоки.

 

Схема простейшая, в один из портов приходит тегированный VLAN, с unicast-ом с DVB приёмников, в сумме 650Мбит.

В этот влан добавлен второй порт, исходящий - из него уникаст улетает в сетевуху сервера, особенность в том, что сетевуха там ТОЛЬКО слушает, ни одного обратного пакета нет.

Поэтому в микротике отсутствует мак адрес получателя unicast-а в таблице коммутации.

Трафик проходит нормально НО, дополнительно весь(!) этот unicast падает на CPU.

 

Его видно через Torch, так как будто в Switch создано правило Copy to CPU для входящего порта.

Он пригружает одно ядро и в перспективе вообще вынесет CPU в полку.

 

Стоит проявить с сервера в этом влане любую активность в сторону DVB приёмников, чтобы в таблицу влетел динамический мак - проблема моментально устраняется.

Тоже самое соответственно если добавить мак адрес получателя статической записью в Switch - Hosts.
Я дополнительно проверил эту ситуацию своим генератором сырых l2 пакетов на другой инсталяции CRS-317,

пакетами на несуществующий в таблице мак - и всё ещё раз подтвердилось, unknown unicast полностью копируется в CPU и это ничем не отключается.

 

Получаем такой результат, любой клиент в транзитном влане через данный коммутатор, может вдуть односторонний l2 

трафик, и всё. Приехали.

 

Я так понимаю писать в саппорт?

 

[VolanD666]

Статическую запись с маком сервера не исправит проблему?

Edited October 10, 2019 by VolanD666

[disappointed]

В 10.10.2019 в 13:26, VolanD666 сказал:

Статическую запись с маком сервера не исправит проблему?

 

Я это так и починил.

Что делать с возможностью любого транзитного клиента, уложить в полку CPU свитча.

[NiTr0]

В 10.10.2019 в 07:22, disappointed сказал:

Я так понимаю писать в саппорт?

угу, возможно лет через 5-7 исправят... ессно если посчитают это багой, а не фичей.

 

В 10.10.2019 в 21:16, disappointed сказал:

Что делать с возможностью любого транзитного клиента, уложить в полку CPU свитча.

"транзитные клиенты и вланы - это устаревшая технология, и вообще надо л3 на доступ" (с) сааб

[disappointed]

Только что, NiTr0 сказал:

угу, возможно лет через 5-7 исправят... ессно если посчитают это багой, а не фичей.

 

"транзитные клиенты и вланы - это устаревшая технология, и вообще надо л3 на доступ" (с) сааб

Саппорт ответил быстро. Но ответ надежду не вселяет.

 

Цитата

We will try to improve this in further RouterOS versions, but currently I cannot provide any ETA. 

There are two workarounds possible:
1. use static host MAC addresses;
2. use switch rules to force this traffic to a specific destination interface.
https://wiki.mikrotik.com/wiki/Manual:CRS3xx_series_switches#Switch_Rules_.28ACL.29

 

[NiTr0]

ну учитывая что они вис от частых коннектов ssh фиксили несколько лет - не думаю что тут будет быстрее.

[disappointed]

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

и увидел, что поведение на текущем софте изменилось.

Теперь он не пропускает вообще пакеты, если в таблице маков нет мака назначения.

Приходится добавлять руками. Вот так починили)

[gard]

А у вас бридж (проц) не заглядывает в транзитный трафик?

Просто странно.. так долго.. такая проблема.. и не совсем очевидное "лечение"...

[Negator]

А на бридже галка use ip firewall не стоит случаем?