+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Пытаюсь разобраться с vlan-filtering и datapath.vlan-id в capsman AX

Пытаюсь разобраться с vlan-filtering и datapath.vlan-id в capsman AX, RouterOS

dulasau

Guest

01.11.2024 23:48:00

Я пытаюсь разобраться с изоляцией VLAN при использовании CAPsMAN. Моя конфигурация: CCR2116 в роли CAPsMAN и два hAP ax2 и один hAP ax3 в качестве CAP'ов. Две Wi-Fi сети: «trusted» (vlan-id 10) и «untrusted» (vlan-id 30).

/interface wifi datapath
add bridge=bridge bridge-horizon=10 client-isolation=yes name=untrusted-datapath vlan-id=30
add bridge=bridge name=trusted-datapath vlan-id=10

Всё работает идеально на CAP, я могу динамически создавать интерфейсы с правильными VLAN ID:
5 D wifi1 bridgeLocal 10 0x80 none
6 D wifi11 bridgeLocal 30 0x80 none

Но… vlan-filtering на самом мосту выставлен в «no», и мне кажется, это рушит саму идею изоляции Wi-Fi сетей. Что я упускаю? Кстати, bridge horizon из datapath тоже не применяется.

lzs

Guest

06.02.2025 13:14:00

У меня есть связанный вопрос. К автору темы: думаю, что без vlan-фильтрации это просто значит, что мост не знает о VLAN, и это работает нормально, хоть и не так безопасно. Мой вопрос касается ситуации, когда включена vlan-фильтрация. Похоже, что мои Wi-Fi интерфейсы добавляются с установленным PVID от datapath, и при этом они ещё и промаркированы тегом. Другими словами, если у моего datapath VLAN ID=4, то у Wi-Fi интерфейса PVID=4, и интерфейс в таблице VLAN тоже помечен этим VLAN. Такая настройка не работает (Wi-Fi клиент может подключаться, но получить IP не получается). Я считаю, что трафик должен входить в мост с Wi-Fi интерфейса с тегом VLAN 4. Значит, PVID не должен быть установлен (то есть по умолчанию 1). Интересно, как правильно это настроить, если хочу включить vlan-фильтрацию?

mkx

Guest

06.02.2025 14:49:00

В общем, когда речь идет о bridge с включённым VLAN, история делится на две части, которые более-менее не связаны между собой (насколько именно — зависит от некоторых деталей конфигурации):
/interface/bridge/port — это про входящий трафик. Там задаётся PVID, который влияет на входящие нетегированные кадры. Если frame-types стоит в положение all или untagged, то нетегированные входящие кадры получают тег PVID. Если frame-types установлено в all, то кадры, уже промаркированные VID, равным PVID, принимаются и проходят дальше без изменений (ведь PVID влияет только на нетегированные входящие кадры).
/interface/bridge/vlan — это про исходящий трафик. Если порт настроен как tagged member, то кадры с соответствующим VID будут отправляться с тегом. Если как untagged member — кадры с соответствующим VID будут уходить без тега. Кадры с VID, не совпадающим ни с одним из настроенных VLAN, через такой порт не выйдут.

А теперь про настройки, которые связывают пункты а) и б):
- Установка PVID на порту, согласно пункту а), автоматически добавляет порт как untagged member в указанный VLAN, согласно пункту б).
- Включение ingress-filtering=yes на порту будет фильтровать входящие кадры на этом порту в соответствии с членством порта из пункта б). Без этой настройки устройство, подключенное к порту, может "вставить" кадр с любым VID, и он будет принят на входе и доставлен соответствующим устройствам в целевом VLAN.
- Настройки из пункта б) блокируют двунаправленный трафик (но если другое устройство воспользуется той же "дырой", тогда даже двунаправленная связь между устройствами, которые предположительно находятся в разных VLAN, станет возможной).
- Значение PVID не имеет значения, если подключённое устройство передаёт кадры с тегами. Автоматическое добавление порта как untagged member VLAN из-за настройки PVID (пункт а)) отменяется, если порт при этом назначен tagged member того же VID (пункт б)).

В случае капманов с datapath.vlan-id и wifi-qcom (не -ac) на CAP, Wi-Fi интерфейс действительно настраивается с pvid и frame-types=all в секции порта, но также назначается tagged member для того же VLAN. И поскольку драйвер Wi-Fi реально управляет VLAN-тегами, всё работает как задумано.

Проблемы возникают с CAP, использующими wifi-qcom-ac… для них нужны некоторые ручные обходные решения.

Joni

Guest

07.02.2025 15:12:00

Мы специально заходим на этот форум, чтобы не знать, что за «некоторые» ручные обходные пути существуют. Здорово, что ты о них знаешь и уделяешь время, чтобы их упомянуть, но лучше бы потратил это время на то, чтобы их действительно добавить. Иначе пост получается почти бессмысленным, ведь это известное серьёзное изменение/проблема для управления жизненным циклом. Не забывай при этом абстрагироваться от темы и не вставлять сравнимые фрагменты указанных различий в конфигурации. И уж точно не стоит забывать про бедолаг, которые используют устройства https://help.mikrotik.com/docs/spaces/ROS/pages/103841836/CRS1xx+2xx+series+switches+examples — там VLAN настроены совсем по-другому.

holvoetn

Guest

07.02.2025 15:28:00

Без обид, но тебе стоит чуть изменить тон. Ты не тот, кто изначально просил помощи, а в его посте говорилось только об устройствах AX, поэтому mkx справедливо отметил, что для устройств ac всё немного по-другому. Нет никакого смысла добавлять эту информацию сюда, в эту тему, потому что в этом контексте она совсем неуместна. Если тебе нужна именно эта информация — просто попроси. И лучше сделать это вежливо. Наверняка найдутся знающие участники, которые поделятся нужными сведениями.

lzs

Guest

08.02.2025 02:06:00

Привет, mkx! Спасибо. Твой ответ понятен. Я примерно понял, как всё должно работать, но начал сомневаться в себе, когда что-то не сработало так, как ожидал. Тем не менее, твой ответ заставил меня копнуть глубже и рассмотреть другие варианты. Вкратце, думаю, моя проблема была связана с VLAN-фильтрацией и аппаратным ускорением (hw-offload) на мультикоммутаторе RB4011.

Хотя это уже не совсем оригинальная тема этой ветки, всё же хочу поделиться предысторией. Вот мой тестовый стенд, где VLAN-фильтрация на hAP ax не сработала, как ожидалось: RB5009 (WAN/роутер/capsman) — RB4011 — hAP ax (cap).

Проблем не возникало, если подключаться напрямую от RB5009 к hAP ax. Так что я сузил поиск проблемы до RB4011. Раньше я этого не учитывал, потому что в предыдущем тесте проверял такую схему: RB5009 — (ether1) RB4011 (ether4) — тестовый ПК, и всё работало нормально.

Это и вправду работало, потому что ether1 и ether4 находятся на одном чипе. Но у моего hAP ax был порт ether10 — совсем другой сетевой чип, чем ether1 на RB4011: RB5009 — (ether1) RB4011 (ether10) — hAP ax.

Отключение аппаратного ускорения на RB4011 помогло. Замена RB4011 на старый RB962 тоже решила проблему. И, конечно, теперь, когда я знаю источник проблемы, есть много других путей, например, все подключить к одному чипу внутри RB4011, если хочется сохранить hw-offload.

Надеюсь, это кому-то пригодится.

mkx Guest	#7 0 08.02.2025 15:46:00 Какая версия ROS установлена на вашем RB4011? Когда был внедрён HW offload, в нём была ошибка: порты CPU на коммутирующих чипах не становились tagged-участниками VLAN, если мост (порт моста, направленный к CPU) не был участником того же VLAN (хотя должен был быть, потому что порты на разных коммутаторах входили в один VLAN). Если я правильно помню, эту проблему обещали исправить. Обходной путь — назначить порт моста tagged-участником этого VLAN (хотя интерфейс VLAN не нужен). HW offload при этом продолжает работать…

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры