Профессиональная настройка VLAN в MikroTik: переход на стандарт Bridge VLAN Filtering

Основы Bridge VLAN Filtering и архитектурные особенности RouterOS

Представьте, что вы строите многоэтажное здание, где каждый этаж должен быть изолирован от соседа, но при этом иметь доступ к общим коммуникациям. В мире сетевых технологий MikroTik долгое время предлагал несколько способов возведения таких «стен»: через настройки чипа коммутации (Switch Chip), создание отдельных интерфейсов VLAN поверх физических портов или объединение портов в программные мосты. Однако с выходом RouterOS v6.41 архитектурный подход радикально изменился. Появление стандарта Bridge VLAN Filtering превратило MikroTik из устройства с «особым путем» настройки в систему, следующую общеиндустриальному стандарту IEEE 802.1Q. Понимание этой логики — это не просто изучение новой вкладки в Winbox, а фундаментальный сдвиг в понимании того, как пакеты перемещаются внутри процессора и свитч-чипа вашего роутера.

Эволюция логики VLAN в экосистеме MikroTik

До появления Bridge VLAN Filtering администраторы MikroTik часто сталкивались с дилеммой. Если нужно было настроить VLAN, существовало два основных пути, каждый из которых имел критические недостатки.

Первый путь — создание VLAN-интерфейсов на каждом физическом порту и последующее объединение их в программные мосты (Bridge). Например, для VLAN 10 создавался vlan10-ether1 и vlan10-ether2, которые затем помещались в bridge-vlan10. Этот метод интуитивно понятен, но он катастрофически нагружает центральный процессор (CPU). Каждый пакет вынужден покидать чип коммутации, проходить через шину данных в CPU, обрабатываться программно и возвращаться обратно. На устройствах вроде RB2011 или даже мощных CCR это приводило к тому, что гигабитные порты выдавали едва ли 200–300 Мбит/с при межсегментном обмене.

Второй путь — использование меню /interface ethernet switch. Это «путь джедая», позволяющий задействовать аппаратное ускорение (L2 Hardware Offloading). Пакеты коммутируются внутри свитч-чипа со скоростью провода (Wire Speed), не нагружая процессор. Однако проблема заключалась в фрагментации: настройки для чипов Atheros8327, Marvell и Realtek различались. Синтаксис, который работал на hAP ac2, не подходил для CRS326. Это создавало огромные сложности при масштабировании сети и переносе конфигураций.

Bridge VLAN Filtering стал мостом между этими мирами. Он предложил унифицированный синтаксис, который выглядит одинаково для любого устройства, и, что более важно, научился автоматически транслировать программные настройки в правила свитч-чипа там, где это поддерживает железо.

Архитектурная модель Bridge VLAN Filtering

В основе новой концепции лежит идея, что мост (Bridge) — это не просто «хаб», объединяющий порты, а полноценный виртуальный коммутатор с поддержкой тегирования. Теперь мы не создаем десятки мостов под каждый VLAN. У нас есть один-единственный мост, внутри которого мы определяем правила прохождения тегированного и нетегированного трафика.

Ключевое изменение произошло в иерархии объектов. Если раньше VLAN-интерфейс был «родителем» для порта в мосту, то теперь Bridge является фундаментом, а VLAN — атрибутом внутри этого фундамента.

Важно различать три типа сущностей в этой архитектуре:

Bridge Interface — сам виртуальный коммутатор.

Bridge Ports — физические или виртуальные интерфейсы (Ethernet, SFP, WLAN), подключенные к этому коммутатору.

Bridge VLAN Table — таблица соответствия, определяющая, какие ID (VLAN ID) разрешены на конкретных портах и в каком виде (Tagged/Untagged).

Когда мы активируем опцию vlan-filtering=yes, RouterOS начинает проверять каждый входящий и исходящий кадр на соответствие таблице VLAN. Если порт получает кадр с VLAN ID, который не прописан для этого порта в таблице, кадр будет немедленно отброшен. Это обеспечивает безопасность на уровне L2 «из коробки».

Роль CPU и аппаратное ускорение (L2HW)

Одним из самых тонких моментов в освоении Bridge VLAN Filtering является понимание того, когда трафик обрабатывается аппаратно, а когда «улетает» в процессор. В MikroTik это обозначается флагом H (Hardware Offload) в списке портов моста.

Для современных линеек устройств, таких как CRS3xx, CRS5xx, а также новых моделей серий hAP и cAP (на чипах Marvell или Mediatek), Bridge VLAN Filtering полностью поддерживает аппаратное ускорение. Это означает, что даже при включенной фильтрации коммутация внутри одного VLAN между портами происходит на уровне микросхем, минуя CPU.

Однако есть нюанс: как только пакету требуется маршрутизация (переход из VLAN 10 в VLAN 20), он обязан попасть в CPU. В архитектуре Bridge VLAN Filtering для этого используется специальный «внутренний порт» самого моста.

Рассмотрим это на примере взаимодействия уровней:

L2-уровень: Трафик внутри VLAN 10 между ether1 и ether2. Проходит через таблицу Bridge VLAN, проверяется на теги и пересылается чипом коммутации. CPU спит.

L3-уровень: Трафик из VLAN 10 (отдел продаж) в VLAN 30 (серверная). Пакет приходит на ether1, понимает, что его получатель в другой подсети, и направляется на логический интерфейс Bridge. Здесь происходит переход из коммутации в маршрутизацию.

Если ваше устройство не поддерживает аппаратное ускорение для Bridge VLAN Filtering (например, старые модели на чипах Atheros 7420), включение vlan-filtering=yes приведет к тому, что весь трафик, даже внутри одного VLAN, пойдет через CPU. В таких случаях нагрузка на процессор может вырасти в 5–10 раз. Поэтому перед внедрением стандарта всегда важно проверять таблицу совместимости Hardware Offloading в официальной документации MikroTik.

Логика работы с тегированным и нетегированным трафиком

В классических коммутаторах (Cisco, HP) мы привыкли к понятиям Access и Trunk. В MikroTik Bridge VLAN Filtering эти понятия реализуются через два параметра: PVID (Port VLAN ID) и записи в Bridge VLAN.

PVID (Port VLAN ID) — это идентификатор, который присваивается любому нетегированному кадру, пришедшему в порт. Если мы настраиваем Access-порт для компьютера в VLAN 10, мы указываем pvid=10 в настройках порта моста. Как только пакет от компьютера попадает внутрь моста, он «окрашивается» в десятый VLAN.

Bridge VLAN Table — здесь мы указываем, как кадры должны покидать порты.

Если порт указан как untagged, мост при отправке кадра снимет с него тег.

Если порт указан как tagged, мост оставит тег (или добавит его).

Особенность MikroTik в том, что настройка Access-порта требует синхронности в двух местах: указания pvid в меню /interface bridge port и добавления этого же порта в список untagged для соответствующего VLAN в /interface bridge vlan. К счастью, начиная с последних версий RouterOS v6 и в v7, система умеет автоматически добавлять динамические записи в таблицу VLAN на основе параметра PVID, что упрощает конфигурацию.

Межсегментное взаимодействие и интерфейс моста

Частая ошибка новичков — непонимание того, как роутер сам «видит» свои VLAN. Чтобы RouterBoard мог выступать в роли шлюза для VLAN (Inter-VLAN Routing), сам интерфейс моста должен стать участником процесса тегирования.

Представьте, что Bridge — это невидимый кабель, соединяющий порты. Чтобы процессор роутера «услышал» трафик из VLAN 10, мы должны:

Добавить интерфейс bridge в список tagged портов для VLAN 10 в таблице /interface bridge vlan.

Создать IP-интерфейс: /interface vlan add interface=bridge vlan-id=10.

Назначить IP-адрес на этот созданный VLAN-интерфейс.

В этой схеме interface=bridge выступает в роли Trunk-порта, который смотрит внутрь самого процессора. Если вы забудете добавить bridge в список tagged портов для конкретного VLAN ID, роутер не сможет пинговать устройства в этом сегменте и не будет маршрутизировать их трафик, даже если IP-адреса настроены верно.

Безопасность и фильтрация на входе

Одним из преимуществ Bridge VLAN Filtering является возможность жесткой фильтрации типов кадров. В настройках порта моста (/interface bridge port) есть параметр frame-types, который позволяет минимизировать риски атак и ошибок конфигурации:

admit-only-vlan-tagged: порт будет принимать только кадры с тегом. Идеально для Trunk-портов между коммутаторами. Любой нетегированный пакет (например, от случайно подключенного ноутбука) будет немедленно отброшен.

admit-only-untagged-and-priority-tagged: порт будет игнорировать любые входящие тегированные кадры. Это стандарт для Access-портов, куда подключены конечные устройства. Это предотвращает атаку типа "VLAN Hopping", когда злоумышленник пытается отправить тегированный кадр, чтобы попасть в другой сегмент сети.

Также параметр ingress-filtering=yes заставляет мост проверять, разрешен ли входящий VLAN ID на данном порту согласно таблице VLAN. Если устройство присылает кадр с VLAN 20 на порт, где разрешен только VLAN 10, пакет не пройдет.

Почему стоит переходить на новый стандарт?

Переход на Bridge VLAN Filtering — это не просто следование моде. Это вопрос предсказуемости сети. При использовании старых методов (множество мостов) таблица MAC-адресов раздувается, а логика работы STP (Spanning Tree Protocol) становится запутанной. В новом стандарте один экземпляр STP работает над одним мостом, корректно обрабатывая все VLAN, что предотвращает петли на уровне всей физической инфраструктуры.

Кроме того, в RouterOS v7 именно этот метод является приоритетным для реализации аппаратного ускорения маршрутизации (L3 Hardware Offloading). Если вы планируете использовать возможности новых чипов Marvell Prestera для маршрутизации трафика между VLAN на скорости 10 или 40 Гбит/с, использование Bridge VLAN Filtering является обязательным условием.

Таким образом, архитектура современного MikroTik строится на принципе «один мост — много VLAN». Это упрощает визуальное восприятие конфигурации: заглянув в /interface bridge vlan, вы видите всю карту вашей сети — какие VLAN куда приходят и где они терминируются. Это делает диагностику прозрачной: если трафик не идет, вы проверяете цепочку: PVID на входе → запись в таблице VLAN → наличие интерфейса моста в Tagged портах → IP-адрес на VLAN-интерфейсе.

В следующих частях мы подробно разберем практическую реализацию этих принципов, но фундамент остается неизменным: мост — это ваш главный коммутатор, а фильтрация — это правила игры, по которым этот коммутатор живет.

Конфигурация Access и Trunk портов в рамках современного стандарта

Представьте, что вы строите многоэтажный бизнес-центр, где на каждом этаже работают разные компании. У них общие лифтовые шахты и лестничные пролеты, но доступ в офисы строго разграничен. В мире MikroTik роль таких изолированных офисов играют VLAN, а лифтовых шахт — Trunk-порты. Однако до появления стандарта Bridge VLAN Filtering системные администраторы часто напоминали строителей, которые пытаются прорубить двери в произвольных местах, путаясь в настройках чипов коммутации и программных интерфейсов. Современный стандарт превращает этот хаос в строгую архитектурную схему, где каждый порт точно знает свою роль: быть «входной дверью» для клиента или «магистралью» для всего здания.

Анатомия порта в логике Bridge VLAN Filtering

В классической RouterOS мы привыкли создавать интерфейсы типа VLAN поверх физических портов. В современном стандарте логика инвертируется: мы работаем с одним мощным Bridge-интерфейсом, а физические порты становятся его «рабами» (slaves), чье поведение определяется параметрами внутри таблицы /interface bridge port и /interface bridge vlan.

Ключевым параметром, определяющим поведение порта, является PVID (Port VLAN ID). Если пакет приходит на порт без тега (обычный трафик от компьютера или принтера), коммутатор должен решить, к какой «виртуальной реальности» его отнести. Именно PVID навешивает этот невидимый ярлык внутри моста.

Режимы фильтрации кадров

Для обеспечения безопасности и исключения утечек трафика между сегментами, MikroTik ввел параметр frame-types. Это своего рода фейс-контроль на входе в порт:

admit-only-untagged-and-priority-tagged: идеальный выбор для Access-портов. Порт будет принимать только «чистые» кадры без тегов. Если кто-то попытается отправить тегированный пакет в такой порт (например, злоумышленник с ноутбуком), MikroTik его отбросит.

admit-only-vlan-tagged: обязательный параметр для Trunk-портов. Здесь логика обратная: принимаются только кадры, у которых уже есть 802.1Q тег. Весь нетегированный шум игнорируется.

admit-all: режим по умолчанию, который часто становится причиной «петель» и дыр в безопасности. В профессиональной настройке его стараются избегать, за исключением специфических случаев (например, гибридных портов для IP-телефонов).

Практическая реализация Access-портов

Рассмотрим сценарий: у нас есть MikroTik RB4011, к которому подключены компьютеры отдела бухгалтерии (VLAN 10) и принтеры (VLAN 20). Наша задача — превратить порты ether2 и ether3 в надежные точки доступа для этих устройств.

Первым делом мы добавляем порты в мост. На этом этапе крайне важно указать PVID непосредственно в настройках порта.

Здесь мы применили «золотой стандарт» настройки Access-порта. Мы не только указали номер сети, но и запретили прием тегированного трафика. Однако настройки в /interface bridge port недостаточно. Это лишь входные ворота. Теперь нам нужно прописать правила выхода и нахождения внутри моста в таблице /interface bridge vlan.

Динамические vs Статические записи

Многие новички замечают, что после указания PVID в списке портов, в таблице /interface bridge vlan автоматически появляются динамические записи (обозначаются буквой D). Однако полагаться на них в продакшене — дурной тон. Для стабильной работы и понимания структуры сети все связи должны быть описаны статически.

Обратите внимание на параметр untagged. Он указывает мосту, что при выходе пакета через этот порт тег нужно снять. Таким образом, компьютер в ether2 даже не подозревает, что он находится в VLAN 10 — для него это обычная сеть, а всю тяжелую работу по маркировке берет на себя MikroTik.

Магистральные каналы: Настройка Trunk-портов

Trunk-порт — это «труба», по которой текут потоки всех ваших VLAN. Обычно это аплинк к другому коммутатору или серверу виртуализации. В нашем примере пусть это будет порт ether1.

Главное отличие Trunk-порта в том, что он никогда не снимает теги (за исключением редких случаев Native VLAN, о которых позже) и не вешает их на входе для основных данных. Его задача — прозрачно пропускать маркированные кадры.

Заметьте, мы не указали PVID (по умолчанию он равен 1, но в режиме admit-only-vlan-tagged он фактически игнорируется для входящего трафика). Теперь мы должны «прописать» этот порт во всех VLAN, которые хотим через него передавать.

Теперь порт ether1 является участником VLAN 10 и VLAN 20. Если на него придет пакет с тегом 10, мост перенаправит его в сторону ether2. Если придет нетегированный пакет — он будет уничтожен согласно правилу frame-types.

Гибридные порты: Кейс с IP-телефонией

Одной из самых сложных задач для начинающих является настройка порта, к которому подключен IP-телефон, а уже в телефон — компьютер. Телефон должен работать в своем «голосовом» VLAN (например, 30) и понимать теги, а компьютер за ним должен получать нетегированный трафик (VLAN 10).

Такой порт называется гибридным. Для его настройки нам придется разрешить оба типа кадров:

Устанавливаем PVID=10 для трафика компьютера.

Разрешаем прием всех типов кадров (admit-all).

В таблице /interface bridge vlan добавляем порт как untagged для VLAN 10 и как tagged для VLAN 30.

Этот сценарий требует осторожности: если злоумышленник подменит телефон и настроит на своем устройстве тегированный интерфейс, он сможет попасть в голосовую сеть. Для минимизации рисков на таких портах рекомендуется использовать дополнительные механизмы защиты, такие как Port Security или 802.1X.

Аппаратное ускорение и его ограничения

Важнейшим аспектом настройки портов является сохранение L2 Hardware Offloading. Когда мы используем Bridge VLAN Filtering, RouterOS пытается передать таблицу коммутации непосредственно в чип (Switch Chip).

Если вы видите букву H рядом с портом в списке /interface bridge port, значит, трафик между портами внутри одного VLAN будет летать на скорости провода, не нагружая центральный процессор. Однако есть нюансы:

Смешивание чипов: Если вы объедините в один мост порты, управляемые разными чипами коммутации (актуально для таких моделей, как RB2011 или RB3011), аппаратное ускорение может отключиться или работать некорректно.

Сложные правила: Использование некоторых функций (например, Bridge IGMP Snooping на старых чипах) может привести к сбросу в программную обработку.

Чтобы проверить статус аппаратного ускорения для VLAN, используйте команду: /interface bridge port monitor [find] Ищите строку hw-offload: yes. Если там no, ваш роутер превращается в дорогую грелку при больших нагрузках.

Взаимодействие с CPU: Роль интерфейса Bridge

До сих пор мы говорили о пересылке кадров между физическими портами. Но что, если роутеру самому нужно «увидеть» этот трафик? Например, чтобы выдать IP-адрес по DHCP или маршрутизировать пакеты в интернет.

Для этого существует логический порт самого моста — bridge1. В таблице /interface bridge vlan он ведет себя как обычный порт. Если вы хотите, чтобы MikroTik был шлюзом для VLAN 10, вы должны добавить bridge1 в список tagged портов для этой VLAN:

Это создает виртуальный путь от чипа коммутации к центральному процессору. Только после этого вы сможете создать IP-адрес на интерфейсе vlan10, который «смотрит» внутрь моста.

Безопасность и Ingress Filtering

Финальный штрих в настройке портов — включение ingress-filtering=yes. По умолчанию MikroTik может быть излишне доверчивым. Этот параметр заставляет мост сверяться с таблицей /interface bridge vlan в момент поступления кадра.

Представьте ситуацию: на порт ether2 (Access-порт бухгалтерии) приходит кадр с тегом VLAN 99. Если ingress-filtering выключен, мост может принять этот кадр и, если в таблице VLAN 99 этот порт не значится, он просто не будет знать, что с ним делать, но ресурс чипа будет потрачен. С включенным фильтром такой пакет будет отброшен немедленно.

Важно помнить: активацию vlan-filtering=yes на самом мосту нужно делать в последнюю очередь. Как только вы нажмете «Apply» или введете команду, MikroTik применит все правила фильтрации. Если вы не успели правильно настроить Trunk-порт до этого момента, вы потеряете доступ к устройству (эффект «отпиливания сука, на котором сидишь»).

Граничные случаи: VLAN 1 и нетегированный трафик

В стандартах 802.1Q VLAN 1 часто является «родным» (Native VLAN). В MikroTik Bridge VLAN Filtering рекомендуется избегать использования VLAN 1 для передачи пользовательских данных. По умолчанию все порты имеют PVID=1. Если вы строите чистую конфигурацию, лучше перевести все управление в отдельный Management VLAN (например, 99), а VLAN 1 оставить неиспользуемым или явно запретить его прохождение.

Если же вам необходимо передать нетегированный трафик через Trunk (например, для совместимости со старым оборудованием), вы указываете этот VLAN как untagged для Trunk-порта и устанавливаете соответствующий PVID на этом порту. Но помните: в рамках одной «трубы» (Trunk) может быть только один нетегированный поток.

Завершая настройку портов, всегда проверяйте итоговую таблицу командой: /interface bridge vlan print Вы должны четко видеть, какие порты являются tagged (магистральные), а какие untagged (абонентские). Любое расхождение между физической схемой и этой таблицей приведет к тому, что пакеты будут «теряться» внутри моста, создавая иллюзию проблем с кабелем или сетевой картой.

Организация Inter-VLAN маршрутизации и механизмы фильтрации трафика

Представьте, что вы успешно разделили сеть предприятия на изолированные сегменты: бухгалтерия не видит гостевой Wi-Fi, а принтеры вынесены в отдельный широковещательный домен. Однако работа в современной организации невозможна в условиях полной изоляции. Бухгалтеру нужно отправить документ на печать, администратору — получить доступ к управлению коммутатором из рабочей сети, а всем пользователям необходим выход в интернет. Здесь возникает парадокс: мы потратили усилия на разделение сети на втором уровне (L2), чтобы теперь соединить их на третьем (L3). Основная задача сетевого инженера при настройке MikroTik заключается в том, чтобы сделать это соединение контролируемым, не превратив маршрутизатор в «проходной двор».

Механика взаимодействия L2-бриджа и L3-маршрутизатора

В архитектуре Bridge VLAN Filtering интерфейс самого моста (bridge) выступает в роли «магистрали», соединяющей логические сегменты коммутатора с центральным процессором. Когда мы говорим об Inter-VLAN маршрутизации, мы подразумеваем создание виртуальных интерфейсов, которые будут служить шлюзами по умолчанию (Default Gateway) для каждого сегмента.

Ключевой нюанс заключается в том, как трафик попадает из таблицы коммутации в таблицу маршрутизации. Для этого интерфейс bridge должен быть добавлен в список тегированных портов для каждого VLAN, который требует маршрутизации. В терминологии RouterOS это выглядит как передача кадра с порта коммутатора на внутренний порт CPU.

Создание VLAN-интерфейсов на базе моста

Чтобы маршрутизатор «услышал» трафик конкретного VLAN, необходимо создать логический интерфейс в разделе /interface vlan. Важно понимать, что родителем (interface) для этих сущностей всегда должен выступать сам bridge, а не физические порты (ether1, ether2 и т.д.). Если привязать VLAN-интерфейс к физическому порту, который уже является частью моста с включенным vlan-filtering=yes, связь будет нарушена из-за конфликта логики обработки кадров.

Пример создания интерфейсов для двух сегментов — управления (VLAN 10) и серверов (VLAN 20):

После создания интерфейсов им назначаются IP-адреса. Эти адреса станут шлюзами для клиентских устройств:

С этого момента маршрутизатор начинает автоматически пересылать пакеты между этими сетями. Если компьютер в VLAN 10 отправит пакет на сервер в VLAN 20, маршрутизатор примет его на интерфейсе vlan10-mgmt, заглянет в таблицу маршрутизации и перенаправит в интерфейс vlan20-servers.

Конфигурация таблицы Bridge VLAN для маршрутизации

Просто создать VLAN-интерфейс недостаточно. Необходимо явно указать мосту, что он должен принимать тегированный трафик этих VLAN. Это делается в меню /interface bridge vlan. Если вы забудете добавить bridge в список tagged портов, пакеты от клиентов будут доходить до коммутатора, но «упираться в стену» перед процессором.

Рассмотрим конфигурацию, где порт ether1 является транком к другому коммутатору, а маршрутизатор должен терминировать (маршрутизировать) VLAN 10 и 20:

Здесь tagged=bridge — это критический элемент. Он означает, что CPU маршрутизатора становится участником данных VLAN. Без этого параметра Inter-VLAN маршрутизация работать не будет, так как процессор просто не увидит тегированные кадры, приходящие от чипа коммутации.

Безопасность и фильтрация: концепция Forwarding в Firewall

Как только мы настроили IP-адреса на VLAN-интерфейсах, маршрутизатор по умолчанию разрешает весь трафик между ними. В корпоративной среде это недопустимо. Основным инструментом ограничения здесь выступает цепочка forward в /ip firewall filter.

Важно различать цепочки:

input: трафик, направленный самому маршрутизатору (например, попытка зайти в Winbox или DNS-запрос к роутеру).

forward: трафик, проходящий через маршрутизатор из одной сети в другую.

Принцип «Запрещено всё, что не разрешено»

Профессиональный подход к фильтрации Inter-VLAN трафика строится на создании запрещающего правила в конце цепочки forward и добавлении разрешающих правил выше него. Однако перед этим крайне важно разрешить прохождение уже установленных и связанных соединений. Это значительно снижает нагрузку на CPU, так как маршрутизатор проверяет только первый пакет сессии, а остальные пропускает автоматически.

Где — общий поток пакетов, а и обрабатываются механизмом FastTrack или просто пропускаются первыми правилами Firewall для оптимизации.

Базовая структура правил фильтрации:

В этой схеме пакеты из гостевого VLAN не смогут попасть в корпоративный сегмент, так как для них нет разрешающего правила выше финального drop.

Глубокая фильтрация и использование Address Lists

Иногда требуется более тонкая настройка. Например, разрешить только определенным серверам из VLAN 20 доступ к базе данных в VLAN 30. Использование IP-адресов в правилах напрямую делает конфигурацию громоздкой. Профессионалы используют Address Lists.

Предположим, у нас есть список привилегированных устройств, которым разрешен доступ к камерам видеонаблюдения:

Такой подход позволяет изменять состав групп доступа, не затрагивая основные правила фильтрации. Это критически важно для поддержания чистоты конфигурации в больших сетях.

Изоляция внутри одного VLAN (Port Isolation)

Inter-VLAN маршрутизация управляет трафиком между разными подсетями. Но что если нам нужно запретить устройствам внутри одного и того же VLAN общаться друг с другом? Например, в гостевом Wi-Fi или в сети провайдера.

На уровне L3 (Firewall) мы не можем этого сделать, так как трафик внутри одной подсети не проходит через шлюз — устройства общаются напрямую по MAC-адресам через L2-таблицу моста. Для решения этой задачи в MikroTik используется механизм Horizon или параметры порта моста.

Если назначить нескольким портам в мосту одинаковое значение horizon (целое число), трафик между этими портами будет запрещен на уровне аппаратной или программной логики моста.

> Механизм Horizon: Кадр, пришедший с порта с установленным значением , никогда не будет передан в порт с тем же значением .

Это эффективный способ создания «изолированных» портов без дробления сети на сотни мелких VLAN.

Нюансы производительности: CPU vs L3HW

При настройке маршрутизации между VLAN важно помнить о нагрузке на центральный процессор. В классических моделях MikroTik (например, серия RB2011 или RB3011) любая маршрутизация выполняется процессором. Это означает, что при передаче данных между VLAN 10 и VLAN 20 на скорости 1 Гбит/с, нагрузка на CPU может достичь 100%.

В современных устройствах (линейки CRS3xx, CRS5xx, а также некоторые модели CCR2xxx и RB5009) появилась поддержка L3 Hardware Offloading. Это позволяет переносить таблицу маршрутизации и правила фильтрации непосредственно в чип коммутации.

Чтобы L3HW работал корректно при использовании Bridge VLAN Filtering, необходимо:

Иметь совместимое оборудование.

Включить поддержку в настройках моста (l3-hw-offloading=yes).

Следить за тем, чтобы правила Firewall были совместимы с возможностями чипа (некоторые сложные условия, такие как Layer7-фильтрация или сложные Matchers, могут «сбрасывать» трафик обратно на CPU).

Если ваша инфраструктура предполагает интенсивный обмен данными между сегментами (например, работа с бэкап-серверами или хранилищами данных), использование L3HW становится не просто преимуществом, а необходимостью.

Диагностика прохождения трафика

Когда маршрутизация настроена, но «ничего не работает», первым инструментом диагностики должен стать Torch на интерфейсе VLAN. Он позволяет увидеть, доходят ли пакеты до маршрутизатора и есть ли на них теги.

Второй важный инструмент — счетчики правил в Firewall. Если вы видите, что пакеты попадают в правило drop, значит, логика маршрутизации верна, но безопасность блокирует проход. Если же счетчики на разрешающих правилах и на финальном drop молчат, значит, проблема находится на уровне L2 (неправильный PVID, отсутствие bridge в списке tagged или ошибки в настройке транк-портов на соседних коммутаторах).

Проверка таблицы маршрутизации также обязательна:

Вы должны видеть флаги DAC (Dynamic, Active, Connected) для всех созданных VLAN-интерфейсов. Если интерфейс находится в состоянии stopped (например, из-за того, что в мосту нет ни одного активного порта в этом VLAN), маршрут станет неактивным, и связь прервется.

Завершая настройку, всегда проверяйте симметричность маршрутизации. В сетях с несколькими роутерами часто возникает ситуация, когда пакет уходит через один шлюз, а ответ пытается вернуться через другой. В случае с MikroTik и включенным strict режимом проверки обратного пути (RP-Filter), такие пакеты будут отброшены как подозрительные. Для большинства стандартных офисных конфигураций достаточно убедиться, что все устройства в сегменте используют IP-адрес соответствующего VLAN-интерфейса MikroTik в качестве единственного шлюза.

Сегментация беспроводных сетей и приоритезация трафика IP-телефонии

Когда в офисе появляется необходимость разделить сотрудников, гостей и мультимедийные устройства, беспроводная сеть становится «узким местом» безопасности. Трафик гостевого смартфона в классической сети без сегментации физически находится в том же широковещательном домене, что и сервер с базой данных 1С. В MikroTik реализация безопасности на уровне Wi-Fi не ограничивается вводом пароля WPA2/WPA3; она требует жесткой привязки виртуальных точек доступа к конкретным VLAN внутри моста. Ситуация осложняется, когда в ту же сеть добавляется IP-телефония: задержка в 150 мс, незаметная при загрузке страницы, превращает разговор в обрывистый набор звуков.

Интеграция беспроводных интерфейсов в Bridge VLAN Filtering

В RouterOS беспроводной интерфейс (wlan) рассматривается мостом как обычный порт, аналогичный Ethernet. Однако ключевое отличие заключается в том, что Wi-Fi адаптер может обслуживать несколько логических сетей одновременно через механизм Virtual AP (VAP).

При использовании стандарта Bridge VLAN Filtering каждый беспроводной интерфейс (физический или виртуальный) должен быть сопоставлен с конкретным PVID. Это позволяет мосту автоматически тегировать входящий от беспроводных клиентов трафик.

Конфигурация Virtual AP и привязка к VLAN

Предположим, у нас есть физический интерфейс wlan1 для сотрудников (VLAN 10) и виртуальный vlan-guest для посетителей (VLAN 30). Логика настройки в современном стандарте выглядит следующим образом:

Создание профилей безопасности: Для каждой группы пользователей создается свой security-profile с уникальным паролем и методами шифрования.

Настройка интерфейсов: Физический интерфейс настраивается как основная точка доступа. Виртуальный интерфейс создается как дочерний по отношению к wlan1.

Привязка к Bridge: Оба интерфейса добавляются в /interface bridge port. Здесь кроется критическая деталь: для беспроводных интерфейсов в 99% случаев используется режим Access-порта. Это означает, что в настройках порта моста мы жестко задаем pvid=10 для основного интерфейса и pvid=30 для гостевого.

> Важно понимать: настройка vlan-id и vlan-mode непосредственно в меню /interface wireless является устаревшим методом (Legacy). При использовании Bridge VLAN Filtering эти параметры в настройках беспроводного адаптера должны оставаться в значении по умолчанию (vlan-mode=no-tag, vlan-id=1), так как тегированием теперь управляет мост на основании PVID порта.

После добавления портов необходимо обновить таблицу /interface bridge vlan, указав, какие транковые порты (например, аплинк к серверу или другому коммутатору) должны пропускать трафик этих VLAN.

Особенности обработки мультикаста в беспроводных VLAN

Одной из проблем при сегментации Wi-Fi является деградация производительности из-за широковещательного и мультикаст-трафика (mDNS, SSDP, ARP). В проводной сети это решается фильтрацией, но в Wi-Fi мультикаст передается на самой низкой базовой скорости (Basic Rate), чтобы его могли услышать все клиенты, включая самые удаленные.

Для оптимизации работы сегментированного Wi-Fi в MikroTik рекомендуется использовать параметр multicast-helper. При значении full маршрутизатор преобразует мультикаст-пакеты в юникаст для каждого беспроводного клиента. Это увеличивает нагрузку на эфир, но гарантирует доставку пакетов и позволяет избежать «замирания» сети при работе протоколов обнаружения устройств в разных VLAN.

Приоритезация трафика IP-телефонии: механизмы QoS

Голосовой трафик (VoIP) крайне чувствителен к двум параметрам: джиттеру (колебанию задержки) и потере пакетов. В сетях, где один и тот же канал используется для передачи файлов и разговоров, пакеты с голосом могут встать в очередь за «тяжелым» HTTP-трафиком.

Для решения этой задачи в RouterOS применяется механизм Quality of Service (QoS), состоящий из трех этапов: классификация, маркировка и управление очередями.

Классификация через Mangle и DSCP

IP-телефоны обычно помечают свои пакеты на уровне L3, используя поле DSCP (Differentiated Services Code Point). Чаще всего для голоса используется значение EF (Expedited Forwarding, код 46), а для сигнального трафика (SIP) — CS3 или AF31 (код 24/26).

Если телефоны не умеют маркировать трафик самостоятельно, мы должны сделать это на маршрутизаторе в таблице /ip firewall mangle.

Где приоритет определяется функцией соответствия IP-адресу телефона или диапазону UDP-портов (обычно 10000-20000 для RTP).

Пример логики маркировки:

Пакеты из VLAN 40 (Voice) с протоколом UDP помечаются меткой соединения voip_conn.

Пакеты внутри этого соединения получают метку пакета voip_packet.

Параллельно проверяется поле DSCP: если пакет уже пришел с кодом 46, ему безусловно присваивается высший приоритет.

Обработка приоритетов на уровне Bridge

Современный стандарт Bridge VLAN Filtering позволяет учитывать приоритеты и на уровне L2. В настройках моста существует параметр frame-types, но более важен ingress-priority-map. Если входящий кадр имеет тег приоритета 802.1p (CoS), MikroTik может транслировать его во внутренний приоритет пакета в RouterOS.

Для IP-телефонии, работающей через гибридные порты (где компьютер подключен через телефон), важно, чтобы мост корректно обрабатывал тегированный голосовой трафик, не смешивая его с нетегированным трафиком данных.

Иерархия очередей (Queue Tree) и ограничение «мусорного» трафика

После того как трафик промаркирован, его нужно поместить в очередь. Использование Simple Queues удобно для простых задач, но для профессиональной настройки VoIP предпочтительнее Queue Tree.

Создается дерево очередей, привязанное к исходящему интерфейсу (например, ether1 или combo1).

Parent Queue: Общая пропускная способность канала (например, 100 Мбит/с).

Child Queue (Voice): Приоритет 1, гарантированная полоса (Limit At) — 5 Мбит/с, максимальная (Max Limit) — 10 Мбит/с.

Child Queue (Data): Приоритет 8, гарантированная полоса — 10 Мбит/с, максимальная — весь остаток канала.

При такой структуре, как только появляется голосовой пакет, планировщик RouterOS немедленно прерывает передачу пакетов из очереди Data, чтобы отправить Voice.

Гибридные порты и Voice VLAN в офисной инфраструктуре

Типичный сценарий: на рабочем столе одна розетка Ethernet. К ней подключается IP-телефон, а компьютер подключается в LAN-порт телефона. Телефон должен работать в VLAN 40 (Voice), а компьютер — в VLAN 10 (Office).

В MikroTik это реализуется через настройку гибридного порта в Bridge VLAN Filtering:

PVID=10: нетегированный трафик от ПК будет попадать в офисную сеть.

Tagged=40: тегированный трафик от телефона будет приниматься мостом и направляться в голосовой сегмент.

Для автоматизации этого процесса часто используется протокол LLDP-MED. MikroTik в разделе /ip neighbor discovery-settings позволяет обнаруживать устройства, но полноценная передача номера VLAN через LLDP-MED для автонастройки телефонов в RouterOS требует внимательной настройки. Телефон запрашивает у коммутатора информацию о Voice VLAN, получает ID=40 и начинает тегировать свой трафик самостоятельно.

Граничные случаи: когда VLAN в Wi-Fi снижает производительность

Существует нюанс, связанный с аппаратным ускорением. На многих устройствах MikroTik (особенно серии hAP, cAP) беспроводные чипы подключены к CPU, а не к свитч-чипу напрямую. Это означает, что при включении vlan-filtering=yes на мосту, весь трафик между Wi-Fi и проводными портами будет проходить через центральный процессор.

Если загрузка CPU приближается к 100%, задержки в IP-телефонии вырастут независимо от настроек очередей. В таких случаях необходимо:

Использовать FastTrack для маркированного трафика данных (но помнить, что FastTrack несовместим с Queue Tree для этих же пакетов).

Разделять очереди: приоритизировать только Voice, оставляя остальной трафик на откуп стандартной обработке.

Применять L3 Hardware Offloading на поддерживаемых устройствах (например, серия CRS3xx или CCR2xxx), чтобы разгрузить процессор от маршрутизации между VLAN.

Безопасность и изоляция внутри беспроводных сегментов

Сегментация не будет полной без изоляции клиентов внутри одного VLAN, особенно в гостевых сетях. В настройках беспроводного интерфейса за это отвечает параметр default-forwarding. Если его отключить, клиенты одной точки доступа не смогут общаться друг с другом напрямую.

Однако, если клиенты находятся на разных точках доступа, но в одном VLAN, они смогут связаться через мост. Для предотвращения этого используется параметр horizon, который мы рассматривали ранее для проводных портов. Присвоение одинакового значения horizon всем беспроводным интерфейсам гостевой сети гарантирует, что трафик, пришедший из одного порта с этим ID, никогда не будет отправлен в другой порт с тем же ID.

Такой комплексный подход — от маркировки трафика на входе в порт до управления очередями на выходе из маршрутизатора — превращает MikroTik в мощный инструмент управления качеством обслуживания, гарантируя стабильность критически важных сервисов в условиях ограниченной полосы пропускания.

Методы оптимизации и глубокая диагностика распределенных сетевых структур

Когда сетевая инфраструктура выходит за пределы одного коммутатора и превращается в распределенную систему с десятками VLAN, риск возникновения каскадных ошибок возрастает экспоненциально. Ошибка в конфигурации одного транка может парализовать работу целого отдела, а скрытая петля в топологии — вызвать «шторм», который положит центральный процессор маршрутизатора. На этом этапе администратору недостаточно просто «уметь настраивать VLAN»; необходимо понимать, как оптимизировать прохождение трафика и какие инструменты использовать, когда пакеты внезапно перестают доходить до адресата.

Предотвращение петель в распределенных VLAN-структурах

В сетях с избыточными связями (например, когда два коммутатора соединены двумя кабелями для отказоустойчивости) протоколы семейства Spanning Tree Protocol (STP) являются критически важными. Однако при использовании Bridge VLAN Filtering стандартный STP или RSTP может работать неэффективно, так как они строят одно дерево для всех VLAN сразу. Это приводит к ситуации, когда один из физических линков блокируется полностью, даже если он мог бы полезно передавать трафик определенных сегментов.

Решением является MSTP (Multiple Spanning Tree Protocol). Он позволяет группировать несколько VLAN в один «инстанс» (instance) и строить для каждого инстанса свою топологию.

Настройка MSTP в контексте Bridge VLAN

Для корректной работы MSTP в RouterOS на всех коммутаторах должны совпадать три параметра: region-name, region-revision и соответствие VLAN конкретным инстансам (vlan-mapping).

Настройка приоритетов моста определяет, какой коммутатор станет корневым (Root Bridge). В иерархических сетях это всегда должен быть коммутатор ядра (Core). Значение приоритета задается кратно 4096.

Где — целое число от 0 до 15. Чем ниже значение, тем выше приоритет. Например, для ядра сети устанавливается , для коммутаторов распределения — , для уровня доступа — .

Если мы хотим, чтобы VLAN 10-20 использовали один физический линк как основной, а VLAN 30-40 — другой, мы создаем два инстанса MSTP. Это позволяет сбалансировать нагрузку на каналы связи, не допуская при этом логических петель.

Оптимизация MTU и фрагментация в тегированных сетях

Одной из самых труднодиагностируемых проблем в распределенных сетях является несоответствие максимального размера кадра (MTU). При добавлении тега 802.1Q к стандартному Ethernet-кадру его размер увеличивается на 4 байта. Если на промежуточном оборудовании или на самих портах MikroTik значение L2 MTU настроено без запаса, кадры будут отбрасываться или фрагментироваться.

В RouterOS существует три типа MTU:

MTU (L3 MTU): Максимальный размер IP-пакета (обычно 1500 байт).

L2 MTU: Максимальный размер кадра, который может обработать чип коммутации без фрагментации.

Full MTU: Общий размер кадра с учетом всех заголовков и контрольных сумм.

Для стабильной работы VLAN значение L2 MTU должно быть как минимум на 4 байта больше, чем L3 MTU. В современных устройствах MikroTik (линейки CRS3xx, CCR2xx) заводское значение L2 MTU обычно составляет 1592-9000 байт, что позволяет передавать даже вложенные теги (QinQ). Однако при объединении старого и нового оборудования необходимо проверять это значение командой: /interface print detail where name=ether1

Если вы наблюдаете, что мелкие пакеты (ping) проходят, а тяжелые данные (HTTP, SMB) «замерзают», это верный признак проблем с MTU.

Глубокая диагностика с помощью инструментов Torch и Sniffer

Когда логика VLAN настроена, но связи нет, первым инструментом администратора становится Torch. Это встроенный в RouterOS анализатор трафика в реальном времени.

Использование Torch для проверки тегов

Запуская Torch на физическом интерфейсе (например, ether1), который является транком, важно включить опцию VLAN ID. Если вы видите входящий трафик с VLAN ID: 0 или отсутствующим идентификатором там, где ожидаете VLAN 10, значит, на противоположной стороне порт настроен как Access или неверно указан Native VLAN.

Параметры фильтрации в Torch:

Src. Address / Dst. Address: Позволяют сузить поиск до конкретного узла.

Port: Помогает увидеть, доходит ли трафик конкретного сервиса (например, 5060 для SIP).

VLAN ID: Критически важен для проверки правильности тегирования на транках.

Packet Sniffer и Wireshark

Если Torch показывает наличие трафика, но причина сбоев остается неясной (например, некорректные флаги TCP или ошибки в заголовках), используется Packet Sniffer. В отличие от Torch, Sniffer позволяет сохранить дамп трафика в файл .pcap для последующего анализа в Wireshark.

Особое внимание стоит уделить параметру streaming-server. Вы можете транслировать перехваченные пакеты с MikroTik прямо на свой компьютер с запущенным Wireshark в режиме реального времени. Это незаменимо при отладке Inter-VLAN маршрутизации, когда нужно понять, на каком этапе пакет теряет тег или блокируется файрволом.

Мониторинг таблицы хостов и Bridge VLAN

Для диагностики L2-связности необходимо анализировать таблицу пересылки кадров (FDB). В контексте Bridge VLAN Filtering это делается через меню /interface bridge host.

Здесь мы можем увидеть:

MAC-адрес: Уникальный идентификатор устройства.

On Interface: Порт, за которым «виден» этот адрес.

VLAN ID: В каком именно сегменте находится устройство.

Если один и тот же MAC-адрес «прыгает» между разными портами (MAC Flapping), это явный признак петли в сети, которую STP не смог заблокировать, или конфликта IP-адресов.

Проверка текущего состояния VLAN в мосту осуществляется командой: /interface bridge vlan monitor [find vlan-ids=10] Она показывает, какие порты в данный момент активны (Current Tagged/Untagged). Если порт настроен в конфигурации, но отсутствует в current-tagged, значит, интерфейс находится в состоянии down или заблокирован протоколом STP.

Особенности L3 Hardware Offloading в сложных структурах

В RouterOS v7 для устройств на чипах Marvell (например, серия CRS3xx) появилась поддержка L3 Hardware Offloading. Это позволяет маршрутизировать трафик между VLAN на скорости провода, не нагружая CPU. Однако при диагностике это создает «слепую зону»: трафик, обрабатываемый чипом, не виден инструментами Torch и Sniffer, так как он не проходит через центральный процессор.

Если вам нужно продиагностировать такой трафик, необходимо временно отключить hw-offload на конкретном VLAN-интерфейсе или использовать зеркалирование портов (Switch Chip Mirroring).

Зеркалирование портов (Port Mirroring) для аппаратного анализа

Когда сеть работает на скоростях 10 Гбит/с и выше, CPU маршрутизатора может не справиться с анализом всего потока через Sniffer. В этом случае используется аппаратное зеркалирование.

Мы назначаем mirror-source (порт, трафик которого хотим изучить) и mirror-target (порт, к которому подключен анализатор с Wireshark). Поскольку это происходит на уровне чипа коммутации, это никак не влияет на производительность устройства и позволяет видеть реальную картину прохождения тегированных кадров.

Пример настройки через меню Switch (для CRS3xx):

Выбрать целевой порт для мониторинга.

Указать исходный порт и направление трафика (ingress/egress/both).

Это позволяет обнаружить тонкие аномалии, такие как поврежденные контрольные суммы кадров (FCS errors), которые часто возникают из-за некачественных SFP-модулей или заломов оптического патч-корда в магистральных каналах.

Финализация сетевой архитектуры

Оптимизация распределенной сети — это процесс постоянного контроля. Использование Bridge VLAN Filtering дает нам стройную логику, где вся конфигурация L2 сосредоточена в одном месте. Однако надежность этой логики зиждется на трех столпах:

Правильный выбор протокола устранения петель (MSTP для многосвязных топологий).

Контроль за MTU на всех участках цепи.

Умение использовать инструменты глубокого анализа (Torch, Sniffer, FDB table).

Понимание того, как пакет проходит путь от порта доступа через транк, обрабатывается в таблице VLAN моста и, при необходимости, уходит на маршрутизацию через виртуальный VLAN-интерфейс, позволяет администратору не просто «чинить» сеть, а проектировать её устойчивой к нагрузкам и ошибкам человеческого фактора.