Переключатель VLAN: резервный режим или безопасный?

Мой WAN подключен к Ether1, Ether1 находится на свитче 1, на свитче 1 VLAN отключён, на CPU свитча 1 тоже VLAN отключён. Моя VLAN60 подключена к Ether6, Ether6 на свитче 2, на свитче 2 VLAN включён в режиме fallback, на CPU свитча 2 VLAN тоже в режиме fallback. Если мне придётся менять настройки на свитче 1, я могу случайно заблокировать себе доступ к роутеру, поэтому не могу продолжать — делаю это удалённо и ближайшие пару месяцев планов поехать на объект нет. Единственные мосты, которые у меня сейчас есть, — это те, что обслуживают беспроводные точки доступа, хотспот и Ether5, к которым они подключены. Я не совсем понимаю, зачем нужен мост, если трафик не доходит до роутера, а останавливается на интерфейсе, так зачем тогда мостить интерфейс/VLAN — какое от этого толк? Меня ещё смущает момент, что VLAN-тегирование вроде как «снимается при входе и добавляется при выходе», или, может, я это неправильно понял. В любом случае, спасибо за помощь, но я не могу рисковать потерять доступ, так что оставлю всё как есть до своего визита через несколько месяцев — тогда смогу разобраться лично.

Мне пришлось отлаживать это, и как побочный эффект я обнаружил, что в версии 6.43.2 есть проблема (см. выделенное серым ниже). Чтобы использовать режим безопасности для тегированных кадров на etherX в 6.43.2, достаточно настроить всего два параметра в конфигурации коммутаторного чипа при условии, что /interface vlan размещён непосредственно на etherX (как в вашем случае): etherX должен быть указан в списке портов строки /interface ethernet switch vlan для нужного vlan-id, vlan-mode у etherX должен быть установлен в secure.

Если вы используете порт на AR8327 и подключенное оборудование ожидает от вас тегированные кадры, default-vlan-id у etherX не должен совпадать с этим VLAN, так как AR8327 снимет тег с кадров с этим VID при выходе. Поэтому default-vlan-id=60 будет ошибкой на порту AR8327, но в вашей конкретной конфигурации это не критично.

Если /interface vlan размещён на мосте, в котором etherX — член порта, тогда также CPU-порт коммутатора должен быть указан в списке портов строки /interface ethernet switch vlan для соответствующего vlan-id (независимо от vlan-mode на CPU-порту).

В общем и целом, поведение в 6.40.9 может отличаться от 6.43.2, и узнать это можно только проверив одну и ту же конфигурацию на обеих версиях. Но самое главное — поскольку вы подключили /interface vlan напрямую к ether6, а не через master port, обновление до 6.41+ никак не повлияет на работу без включённой фильтрации vlan на чипе коммутатора. Только конфигурации через master-port автоматически конвертируются в мостовые при обновлении.

Единственное преимущество фильтрации vlan на чипе — это уже сбрасывать кадры с тегами, которые не разрешены, и не передавать их на CPU.

На RB2011 порты ether1–ether5 работают на AR8327, который может тегировать при входе и снимать тег при выходе в зависимости от default-vlan-id, и это работает, как проверено ранее.

Однако ether6–ether10 — это AR8227, который тегирует на входе в зависимости от default-vlan-id, но не может выборочно снимать теги при выходе по VID — согласно руководству, можно либо оставить кадры с тегами и без тегов как есть (leave-as-is), либо всегда снимать теги (always-strip), либо даже тегировать безтеговые кадры при выходе (add-if-missing) — но я никогда не проверял, что именно это делает.

Проблема, которую я нашёл — always-strip просто не работает, по крайней мере в 6.43.2 (на hAP ac lite, у меня нет RB2011 для теста), по крайней мере для кадров, входящих через CPU-порт. Независимо от выбранного режима обработки тегов на выходе, порт продолжает отправлять в сеть тегированные кадры.

Не исключаю, что это связано с тем, как CPU сообщает чипу, через какой порт нужно выводить кадр — для этого используется проприетарный тег, которого нет у кадров, пересылаемых с одного не-CPU порта на другой.

Вы можете выложить соответствующую часть конфигурации (например, /interface export), и мы посмотрим.

Когда я установил порт коммутатора в режим secure и наблюдал трафик на интерфейсе, через него не проходило ничего, кроме служебных пакетов обнаружения. При мониторинге уровней передачи (tx) и приёма (rx) интерфейса tx оставался равным нулю, а rx показывал небольшую активность. Странно, что на графике интерфейса был зафиксирован некоторый сигнальный трафик в обоих направлениях, но он не отображался в Torch для этого интерфейса, то есть реально через интерфейс вообще ничего не проходило, что Torch мог бы увидеть. Телефоны получают IP-адрес из пула DHCP на интерфейсе Vlan60. Как только я вернул настройку в режим fallback, в Torch сразу появился VLAN-трафик с тегом (60) на интерфейсе. Вот мой экспорт настроек /interface, кстати, трафик VLAN60 идёт через отдельный публичный IP, но я не думаю, что это влияет на проблему.

# oct/12/2018 08:35:59 by RouterOS 6.40.9  
# software id = F79J-8IIS  
# model = 2011UiAS-2HnD  
# serial number =  

/interface ethernet  
set [ find default-name=ether1 ] comment="WAN Link" name=ether1-gateway
set [ find default-name=ether6 ] comment="[VLAN60] - 192.168.60.0/24" name=ether6-TRUNK-local

/interface vlan  
add interface=ether6-TRUNK-local name=vlan60 vlan-id=60  

/interface ethernet switch port  
set 6 default-vlan-id=60 vlan-mode=fallback

Это железо, так что не стоит ждать, что всё будет связно и изящно работать. Значение default-vlan-id используется только для решения, тегировать или нет кадр при входе/выходе, но оно не меняет автоматически содержимое таблицы vlan<->порт, которая проверяется на другом этапе обработки кадра в чипе. И да, я согласен, что в руководстве это не очень понятно: в разделе VLAN Table есть фраза, что таблица содержит записи, сопоставляющие конкретные ID VLAN с группой из одного или нескольких портов, но про существование подветки конфигурации /interface ethernet switch vlan там не сказано, и её приходится искать в примерах ниже.