Jump to content
Калькуляторы

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

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


Имеется 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 

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

 

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

 

photo_2019-10-10_00-26-21.jpg

2019-10-10 9-12-28.png

2019-10-10 9-11-31.png

Share this post


Link to post
Share on other sites

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

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

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

 

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

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

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

Share this post


Link to post
Share on other sites

Только что, 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

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.