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

Фильтрация VLAN на мосту

Фильтрация VLAN на мосту, RouterOS

marktomlinson

Guest

20.06.2018 19:30:00

Всем привет! Нужна небольшая помощь с настройкой bridge vlan-filtering по совету поддержки MikroTik — теперь именно так это должно работать. Конфигурация в тестовой сети довольно простая: есть 3011RB и CRS. Мне удалось настроить порты с назначенным PVID, узлы, подключённые к ether2 и ether8, получают IP из подсети 10.46.1.0/24, но на VLAN у CRS ничего не появляется.

Конфиг 3011RB:

/interface bridge
add fast-forward=no name=bridge vlan-filtering=yes
/interface vlan
add interface=bridge name=vlan5-management vlan-id=5
/interface bridge port
add bridge=bridge hw=no interface=ether2-management pvid=5
add bridge=bridge hw=no interface=ether5-voip
add bridge=bridge hw=no interface=ether1-downstairs
add bridge=bridge interface=ether8-printer pvid=5
add bridge=bridge hw=no interface=ether3-dell
add bridge=bridge hw=no interface=ether7-WiFi
add bridge=bridge hw=no interface=sfp1-switch
/interface bridge vlan
add bridge=bridge tagged=bridge,ether1-downstairs untagged=ether2-management,ether8-printer vlan-ids=5
/ip address
add address=10.46.1.1/24 interface=vlan5-management network=10.46.1.0
add address=172.16.1.10/24 interface=bridge network=172.16.1.0
/ip dhcp-server
add address-pool=dhcp-management authoritative=after-2sec-delay disabled=no interface=vlan5-management lease-time=1w1d name=dhcp-management
add address-pool=dhcp-BTnet disabled=no interface=bridge lease-time=1w1d name=dhcp-LAN

CRS:

/interface bridge
add admin-mac=CC:2D:E0:2E:04:B5 auto-mac=no fast-forward=no name=LAN vlan-filtering=yes
/interface vlan
add interface=LAN name=vlan5-management vlan-id=5
/interface bridge port
add bridge=LAN hw=no interface=ether1
add bridge=LAN hw=no interface=ether2
add bridge=LAN hw=no interface=ether3
add bridge=LAN hw=no interface=ether4
add bridge=LAN hw=no interface=ether5
add bridge=LAN hw=no interface=ether6
add bridge=LAN hw=no interface=ether7
add bridge=LAN hw=no interface=ether8
/interface bridge vlan
add bridge=LAN tagged=LAN vlan-ids=5
/ip dhcp-client
add dhcp-options=hostname,clientid disabled=no interface=LAN
add add-default-route=no dhcp-options=hostname,clientid disabled=no interface=vlan5-management

Заранее спасибо!
Mark

stormeporm

Guest

10.07.2018 15:52:00

Есть ли шанс, что фильтрация VLAN на мосту с аппаратным ускорением будет расширена на устройства, которые на данный момент могут это делать в чипе коммутатора, такие как CRS, RB2011, RB3011? Раньше я делал это прямо в чипе коммутатора, а потом появилась новая функция моста, и я думал, что уже не нужно настраивать это вручную в настройках коммутатора, но оказалось, что нужно. Вы усложнили работу с VLAN сильнее, чем было раньше. Хотя признаю, базовое переключение стало проще.

mkx

Guest

21.08.2018 07:05:00

Я экспериментирую с bridge VLAN на hAP ac2 (ROS версия 6.42.7). Хочу делать это только "новым способом", поэтому не хочу трогать настройки /interface ethernet switch… Мне непонятно, что меняет установка vlan-filtering=yes на мосту по сравнению с vlan-filtering=no в плане VLAN-функционала моста? Я настроил VLANы на портах моста, и всё вроде работает, независимо от того, как я выставляю vlan-filtering. Есть несколько VLANов, которые должны проходить через CPU (либо из-за админского доступа, либо из-за мостового соединения WLAN-интерфейсов), и есть VLANы, которые через CPU идти не должны (для них RBD52G должен выступать как VLAN-совместимый коммутатор). Установка vlan-filtering в yes отключает HW offload на всех Ethernet-портах (а это мне не очень нравится), но действительно ли мне нужно ставить это в yes?

xvo

Guest

21.08.2018 08:39:00

При vlan-filtering=no все остальные настройки, касающиеся VLAN на мосту, игнорируются, мост не будет добавлять или убирать теги у входящих пакетов, всё пройдет как есть. Так что если кажется, что всё работает нормально, это либо совпадение... либо новый баг в версии 6.42.7. Чип коммутатора hAP ac2 не поддерживает аппаратное ускорение при включённой фильтрации VLAN, поэтому исчезновение аппаратного флага — это ожидаемое поведение.

sindy

Guest

21.08.2018 08:50:00

Это нужно для того, чтобы обеспечить возможность тегирования и снятия тегов на портах доступа (гибридных портах). Без vlan-filtering=yes значения pvid в /interface bridge port и tagged/untagged в /interface bridge vlan использовать нельзя, потому что чип коммутатора просто не отправляет кадры в процессор. Некоторые чипы могут делать аналогичную обработку через настройки /interface ethernet switch port и /interface ethernet switch vlan, но не все.

Главный момент, который не так очевиден — хотя мы и привыкли говорить о чипах коммутаторов, функционал на самом деле обеспечивает отдельный блок SOC (система-на-чипе), а не отдельный чип коммутатора. Поэтому возможности этого блока — не единственный критерий, по которому аппаратчики выбирают SOC.

Кроме того, это помогает обойти разные аппаратные ограничения у разных коммутаторных чипов. Например, BPDU-кадры обычно (за исключением Cisco PVST/PVST+ и старой реализации RSTP от Mikrotik) не содержат тег с VID, что более простые чипы не могут обработать, так как не умеют отличать BPDU от других кадров. Программный коммутатор это умеет, поэтому можно реализовать «настоящий» MSTP.

mkx

Guest

21.08.2018 11:17:00

Спасибо, @xvo и @sindy. Мне просто показалось, что всё работает благодаря причине, которую озвучил @sindy: использованию гибридных портов. Я ещё не тестировал этот сценарий, собирался сделать это сегодня. Вчера я использовал только транковые порты и явный vlan-интерфейс поверх моста (не собираюсь использовать мост напрямую с его настройкой pvid, мне больше нравится более явный способ с vlan-устройствами. К тому же через мост с pvid можно работать только с одним VLAN, а мне нужно одновременно с тремя). У меня настроены пара портов как гибридные, и я использую pvid на этих портах, чтобы помечать непомеченные пакеты (чтобы мост никогда не видел непомеченный трафик). Думаю, сегодня это могло бы меня подвести, если бы vlan-фильтрация не была включена.

В моей простой конфигурации мне не нужен активный протокол STP, поэтому причина включения vlan-фильтрации для меня не актуальна. Тегирование и снятие тегов на гибридных портах — именно то, что мне нужно. Мне осталось проверить загрузку процессора при передаче данных внутри VLAN с порта на порт, чтобы понять, не будет ли устройство греться из-за отсутствия аппаратного ускорения. И я, конечно, надеюсь, что разработчики Mikrotik улучшат работу с VLAN в будущих обновлениях.

Блок-схема для RBD52G показывает AR8327 как коммутатор внутри SoC IPQ4018 (подозреваю, что на самом деле это не AR8327), и при этом AR8327 тоже используется в RB951G. Если я настрою коммутатор на RB951G, устройство вполне способно работать с гибридными портами (тегирование/снятие тегов), так что, думаю, это функционал, который пока нужно разгружать аппаратно на подходящих устройствах.

mkx

Guest

21.08.2018 11:23:00

Это вся правда? Действительно, я попытался воссоздать настройку коммутатора, включив мост, который должен быть отмечен в большинстве VLAN, и, кажется, это сработало. Есть один VLAN, который должен полностью обходить процессор RB, и мост не настроен на передачу этого VLAN. Думаю, может случиться так (если не установлен vlan-фильтр), что пакеты из этого VLAN не будут проходить с одного Ethernet-порта на другой. Мне придется проверить это самому.

sindy

Guest

21.08.2018 13:11:00

Суть «аппаратного ускорения» моста — это обход CPU. То есть кадры пересылаются самим коммутаторным чипом напрямую с одного его порта на другой, используя собственную таблицу MAC-адресов чипа. Можно ли в этом случае использовать гибридные порты, зависит от функционала коммутаторного чипа: с 8327 — можно, с 8227 — нет. Это снова возвращает нас к разным возможностям коммутаторных чипов и объёму работы, которую нужно на них потратить.

Например, чтобы работать с MSTP и при этом сохранять аппаратное ускорение, для 8327 должно быть достаточно добавить такое «динамическое» правило чипа, если MSTP настроен на мосту:
/interface ethernet switch rule add dst-mac-address=01:80:c2:00:00:f00/ff:ff:ff:ff:ff:ff redirect-to-cpu=yes switch=switch1 ports=ether1,ether2,ether3,ether4,ether5

И позволить CPU убрать VLAN тег, который, скорее всего, добавит чип перед обработкой BPDU. Аналоги пунктов /interface bridge port и /interface bridge vlan тоже придётся добавить как динамические элементы в /interface ethernet switch port и /interface ethernet switch vlan соответственно; ещё сложнее — настройки /interface ethernet switch vlan придётся динамически менять, отключая и включая отдельные порты в конкретных VLAN в зависимости от текущего состояния spanning tree.

Но будет ли именно этим заниматься команда разработчиков Mikrotik, — ну, это уже вопрос к Mikrotik R&D.

mkx

Guest

22.08.2018 05:52:00

Я проверил разделы /interface ethernet switch на моём hAP ac2, когда VLAN настроены на мосту. Команда /interface ethernet switch export выдаёт пустой скрипт, что ожидаемо, так как там ничего не настроено. Команда /interface ethernet switch port print detail даёт такой вывод: Flags: I - invalid
0 name="ether1" switch=switch1 vlan-mode=disabled vlan-header=leave-as-is
default-vlan-id=auto

1 name="ether2" switch=switch1 vlan-mode=disabled vlan-header=leave-as-is
default-vlan-id=auto

2 name="ether3" switch=switch1 vlan-mode=disabled vlan-header=leave-as-is
default-vlan-id=auto

3 name="ether4" switch=switch1 vlan-mode=disabled vlan-header=leave-as-is
default-vlan-id=auto

4 name="ether5" switch=switch1 vlan-mode=disabled vlan-header=leave-as-is
default-vlan-id=auto

5 name="switch1-cpu" switch=switch1 vlan-mode=disabled
vlan-header=leave-as-is default-vlan-id=auto

А команда /interface ethernet switch vlan print detail ничего не выводит. Значит, свитч настроен так, что фактически ничего не делает.

Теперь к моей текущей проблеме: я настроил VLAN на мосту, и вроде всё работает, как задумано, включая транковые порты, гибридные порты (один VLAN с тегом, другой без тега) и access-порты (один VLAN без тега). Но у меня проблемы с WLAN... Клиенты WiFi подключаются (успешно аутентифицируются по WPA2 с предустановленным ключом), но, очевидно, L2 связь не работает (например, они не получают DHCP-адреса).

Моя конфигурация:

/interface bridge
add admin-mac=B8:69:F4:20:A5:4A auto-mac=no comment=defconf name=bridge protocol-mode=none vlan-filtering=yes

/interface bridge port
add bridge=bridge comment=defconf interface=ether2 pvid=40
add bridge=bridge comment=defconf interface=ether3 pvid=42
add bridge=bridge comment=defconf interface=ether4 pvid=42
add bridge=bridge comment=defconf interface=ether5 pvid=42
add bridge=bridge comment=defconf interface=wlan1 pvid=42
add bridge=bridge comment=defconf interface=wlan2 pvid=42
add bridge=bridge frame-types=admit-only-vlan-tagged ingress-filtering=yes interface=ether1

/interface bridge vlan
add bridge=bridge tagged=bridge,ether1 untagged=ether3,ether4,ether5 vlan-ids=42
add bridge=bridge tagged=bridge,ether1 vlan-ids=2
add bridge=bridge tagged=ether1,ether2 vlan-ids=3999
add bridge=bridge tagged=bridge,ether1 vlan-ids=41
add bridge=bridge tagged=bridge,ether1 untagged=ether2 vlan-ids=40

/interface wireless
set [ find default-name=wlan1 ] band=2ghz-g/n channel-width=20/40mhz-Ce country=slovenia disabled=no distance=indoors frequency=auto frequency-mode=regulatory-domain mode=ap-bridge security-profile=mkxNet ssid=mkxNet-2G vlan-id=42 vlan-mode=use-tag wireless-protocol=802.11 wps-mode=disabled
set [ find default-name=wlan2 ] band=5ghz-n/ac channel-width=20/40/80mhz-Ceee country=slovenia disabled=no distance=indoors frequency=auto frequency-mode=regulatory-domain mode=ap-bridge security-profile=mkxNet ssid=mkxNet-5G vlan-id=42 vlan-mode=use-tag wireless-protocol=802.11 wps-mode=disabled

Похоже, что с обработкой VLAN-тегов что-то не так. Что я делаю неправильно?

mkx

Guest

#10

22.08.2018 06:11:00

Проверяя свою настройку VLAN (она пока ещё неверная, см. мой предыдущий пост), я также провёл некоторые тесты пропускной способности. Использовал iperf UDP-тесты, Windows-ноутбук в роли клиента и Linux-сервер в «ядре LAN». Linux подключён по гигабитному Ethernet, а ноутбук — либо через гигабитный Ethernet, либо по WiFi. Результаты получились довольно интересными: Windows jperf не смог выдать больше примерно 120 Мбит/с в одном UDP-потоке (у Linux почти гигабит), поэтому для теста проводного подключения пришлось запускать 12 параллельных UDP-потоков, чтобы суммарно получить пропускную способность близкую к гигабиту. С WiFi получилось наоборот (с RB951G в роли точки доступа): если запускать больше трёх параллельных UDP-потоков, приём данных сильно ограничивался — процессор RB уходил в 100% загрузку. При одном или двух UDP-потоках загрузка CPU оставалась ниже 100%, и скорость приёма была неплохой (но всё равно ниже, чем при передаче)… Во время передачи CPU загружался менее чем на 50%, и пропускная способность не ограничивалась. При тестах через RB951G, настроенный на работу с VLAN в составе процессора коммутатора, процессор, очевидно, почти не напрягался. А при тестах через RBD52G с VLAN на мосту нагрузка на CPU увеличивалась, но оставалась относительно небольшой. При 12 UDP-потоках при приёме общая загрузка CPU повышалась примерно до 10% (от одного ядра), а при передаче — до 20% (одного ядра). Так как у RBD52G четыре ядра и нагрузка распределялась между ними, это значит, что RBD52G в «коммутаторном» режиме должен обеспечивать передачу на скоростях порта во все стороны одновременно. Но: да, RBD52G действительно напрягается на высоких скоростях, когда нет аппаратного разгрузителя. Когда WiFi на RBD52G будет работать, я тоже сделаю тесты пропускной способности и опубликую результаты (с сравнением с RB951G).

mkx

Guest

#11

22.08.2018 06:50:00

Хмм, заметил, что интерфейсы wlan1 и wlan2 нигде не упоминаются в настройках /interface bridge vlan. Я добавил их в /interface bridge vlan:
add bridge=bridge tagged=bridge,ether1,wlan1,wlan2 untagged=ether3,ether4,ether5 vlan-ids=42
Проверю, изменилось ли что-нибудь вечером, когда вернусь домой.

sindy Guest	#12 0 22.08.2018 07:16:00 Да, это так. Если я правильно помню, беспроводные интерфейсы недавно начали автоматически добавляться в строки vlan-ids в /interface bridge vlan, если ими управляют через CAPsMAN.

mkx Guest	#13 0 22.08.2018 18:05:00 Действительно получилось. Следующим делом приведу в порядок настройки, проведу тесты, чтобы проверить нагрузку на процессор при передаче данных на полной скорости по WiFi, и тогда я смогу окончательно забыть про плату за коммутатор, которую оплатил.

Читают тему

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