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

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

Edited by VolanD666

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this