disappointed Опубликовано 10 октября, 2019 · Жалоба Нашёл какой-то кошмарный баг архитектуры. Имеется 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 трафик, и всё. Приехали. Я так понимаю писать в саппорт? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 10 октября, 2019 (изменено) · Жалоба Статическую запись с маком сервера не исправит проблему? Изменено 10 октября, 2019 пользователем VolanD666 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
disappointed Опубликовано 10 октября, 2019 · Жалоба В 10.10.2019 в 13:26, VolanD666 сказал: Статическую запись с маком сервера не исправит проблему? Я это так и починил. Что делать с возможностью любого транзитного клиента, уложить в полку CPU свитча. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 14 октября, 2019 · Жалоба В 10.10.2019 в 07:22, disappointed сказал: Я так понимаю писать в саппорт? угу, возможно лет через 5-7 исправят... ессно если посчитают это багой, а не фичей. В 10.10.2019 в 21:16, disappointed сказал: Что делать с возможностью любого транзитного клиента, уложить в полку CPU свитча. "транзитные клиенты и вланы - это устаревшая технология, и вообще надо л3 на доступ" (с) сааб Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
disappointed Опубликовано 14 октября, 2019 · Жалоба Только что, 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 15 октября, 2019 · Жалоба ну учитывая что они вис от частых коннектов ssh фиксили несколько лет - не думаю что тут будет быстрее. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
disappointed Опубликовано 17 октября, 2022 · Жалоба Сейчас снова столкнулся с необходимостью прогнать через эту модель юникастовый трафик, строго в одну сторону и увидел, что поведение на текущем софте изменилось. Теперь он не пропускает вообще пакеты, если в таблице маков нет мака назначения. Приходится добавлять руками. Вот так починили) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
gard Опубликовано 18 октября, 2022 · Жалоба А у вас бридж (проц) не заглядывает в транзитный трафик? Просто странно.. так долго.. такая проблема.. и не совсем очевидное "лечение"... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Negator Опубликовано 19 октября, 2022 · Жалоба А на бридже галка use ip firewall не стоит случаем? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...