Сразу оговорюсь, что данная статья про Router OS, а не Switch OS.
На мой взгляд, работа с VLAN в Mikrotik освещена хуже всего. Да, конечно есть набор статей на эту тему, например вот:
https://wiki.mikrotik.com/wiki/Manual:Interface/VLAN#InterVLAN_routing (за неуказание при публикации прямой ссылки на официальную доку прям словил хейта в личку)
https://настройка-микротик.укр/nastrojka-vlan-v-mikrotik-trunk-i-access-porty/
И тому подобное. Но лично я когда их все читал... У меня не складывалось глубокого понимания, как именно это всё работает, только возможность повторить типовую конфигурацию.
То есть, эти статьи хороши, но на мой взгляд написаны для специалистов по микротикам, которым понадобилось еще и в VLAN. А мне хотелось бы видеть статью, которая для специалистов по сетям, которым надо привычные вещи реализовать на железе Mikrotik. И соответственно, осветить эти вопросы на мой взгляд надо бы с несколько другой стороны. И поскольку я такой статьи не нашел, решил сесть и написать её сам :). Так что и говорить я буду привычные вещи, но другими словами. Итак, приступим...
Самое первое, что надо помнить -- сетевые операции происходят на пакетах без тэга. А тэги появляются только тогда, когда появился bridge (либо порт с тэгом, о чём ниже). То есть, если понадобилось например выдать адрес по DHCP, то для этого нужно чтобы DHCP-сервер микротика смотрел на собственный bridge со стороны без тэга. Аналогично со всеми остальными "высокоуровневыми" операциями. Никаких тэгов внутри "умной" чисти Микротика нет! Поэтому если нужны тегированные VLAN'ы, надо "довешивать" тэги позже.
Второе, что надо понимать на мой взгляд -- тег снимается (для исходящего и добавляется для входящего трафика) в тот момент, когда пакет доходит до порта (не важно, физического в мосту, виртуального или автоматически созданного чем-то вроде CapsMan'а), в свойствах которого этот самый тег указан. То есть, вот примеры точек, с одной стороны ("внутри" bridge) от которых тэг есть, а с другой -- уже нет (Рисунки 1, 2 и 3)
Третье, что надо понимать... Если в конфигурации используется мост, он умеет фильтровать теги. Если фильтрация тегов выключена вообще, то не на всех устройствах механизм работы с VLAN вообще будет работать, а если фильтрация запрещает лишние тэги, то искать проблемы можно долго. Лучший вариант на время диагностики поставить галку "VLAN filtering" и "Admit all".
И внутри моста какой-то один VLAN считается по-умолчанию и идёт без тега, а остальные -- с тегом. Добиться того, чтобы все VLAN были с тегом и не было ни одного дефолтного, но при этом всё работало, лично у меня не получилось. Поэтому лично я не тегирую сервисный VLAN 1, куда доступ открыт только авторизованным лицам и устройствам, во всей статье умолчания такие.
То есть, вписываем тэг "1" в свойства моста, после чего Vlan 1 считается в этом мосту нетегированным и порты, которые в этот мост включены и в свойствах которых прописан тэг 1, не будут пытаться его снимать.
Четвертое... Чтобы мост пропускал тегированный трафик мало поставить галку "Admit all", надо еще и добавить сам мост в конфигурацию VLAN в поле "tagged".
Пятое -- автоконфигурации работают несколько мимо этих механизмов. И поэтому если у вас в бридже есть порты, настроенные вручную и они наглухо не работают как надо, но при этом другие порты работают хорошо, но те настроены автоматически (туннель, капсман, прочее), то скорее всего конфигурация ошибочна и если ошибку исправить, то вручную настроенные интерфейсы заработают, а автоматически настроенные при этом не сломаются.
Шестое, в комментариях словил хейта за то, что не указал второй способ работы с этим счастьем, поэтому поправлюсь, еще можно использовать VLAN и без моста, для чего создаётся интерфейс VLAN, подключаемый напрямую к физическому порту. Тогда на физический порт пакет приходит с тэгом, потом на уровне виртуального интерфейса происходит его снятие и дальше он идёт нетегированным. Создаётся такой виртуальный порт ровно тем же путём: "Interfaces - Interface - '+' - VLAN", там надо указать "VLAN id" и физический порт, на который его посадить.
И надеюсь уж последнее, раз уж мы вспомнили эту конфигурацию, то седьмое, казалось бы, никто не мешает из таких портов как в п.6, с которых уже сняты теги на уровне виртуального интерфейса, опять же собрать мост. Таким способом например можно менять тэг между портами. Но есть два "но", во-первых, комбинировать способ из первых пяти пунктов со способом из последних двух не рекомендую категорически, потому что там сам черт ногу сломит. В том смысле, что поиск возможных проблем станет совсем гиблым делом. А во-вторых, как мне подсказали в комментариях, по официальной же документации с этим есть определенные сложности.
Пример работы со всем вышеперечисленным
Итак, есть сеть, в которой микротиковая точка доступа используется просто как точка доступа. А точнее, их две и между ними реализовано бесшовное переключение средствами CapsMan'а. Точки раздают по 2 сети, одна из которых -- техническая, вторая -- гостевая, внутри сети разделение происходит на уровне VLAN. Тэг 1 для технической, 2 -- для гостевой. Пока всё достаточно типовое и подробного описано много где.
Но у нас шлюз сделан не на микротике, является отдельно стоящей машиной и потому с точки зрения логики сети, микротики к второму влану не подключены, хотя его и раздают. Реализовано это очень просто: на микротике создан единственный бридж с тэгом 1 в свойствах фильтрации. При его создании на вкладке VLAN автоматически появилась первая запись, она описывает конфигурацию по-умолчанию и потому в левом столбике обозначена буквой "D". Далее, мы вручную создали второй VLAN с тэгом 2 и вручную добавили туда порты (Рис. 3).
А в CAPsMAN на вкладке Datapaths создали путь для тэгированного трафика (Рис. 1)
Порт ether1 воткнут в тот же свитч, что и управляющее устройство и схема работает на отлично: трафик от клиента приходит на вайфай, где на него навешивается тэг из-за настройки Datapath, благодаря которой капсман создаёт порт Wlan сразу с тэгом в свойствах, дальше это счастье идёт через мост и в конце тэг не снимается когда трафик проходит через порт eth1, потому что в свойствах порта стоит тэг 1, а потому тэг 2 он просто игнорирует, пропуская пакеты насквозь, дальше тэгированные пакеты уходят в сеть и проходя через любое количество оборудования прямо в таком виде, доходят до сервера, который в курсе, что с ними делать, а потому и ответы шлёт также, с тэгом, с которым они и проходят обратный путь, теряя его только перед уходом "в среду" WiFi.
Но через какое-то время появляется задача изменить настройку и сделать, чтобы гостевой трафик шел через саму точку доступа, а точнее, через порт eth2 и далее к провайдеру, а основной остался на том же маршруте, что и был. Идём и создаём "Interfaces - Interface - '+' - Vlan", указываем там бридж и нужный тэг (опять же как на рисунке 1), прописываем ему интерфейс, для проверки пингуем любой другой адрес в гостевой сети и... получаем облом.
А всё потому, что несмотря на то, что тегированный трафик, заданный капсманом через бридж идёт... Но "вы не понимаете, это другое", а вообще бридж тегированный трафик режет. И чтобы это исправить, надо применить четвертый постулат из списка выше и исправить конфигурацию вот так (да-да, бридж указан в собственных VLAN-ах во всех строчках и это правильно):
Теперь всё пингуется и можно настроить остальные вещи типа фильтрации, НАТ и прочее, но это типовые вещи, о которых можно прочитать в других местах и потому выходят за рамки этой статьи.
P.S. Еще существует механизм работы с VLAN через меню Switch, но он поддерживается не на всём оборудовании, да и вообще сейчас речь была не про него.
P.P.S. Опять же, в комментариях меня убедили дописать, что конфигурации, о которых я писал, на одних железках будут работать быстро потому, что указанные функции будут выполняться аппаратно, а на других -- медленно, потому что реализовано это будет программно с использованием ресурсов ЦПУ. И чтобы понять где аппаратно, а где -- программно надо прочитать примерно следующий список ссылок:
Комментарии (52)
horon
15.09.2021 18:34-1Вроде просто всё, делаем интерфейс vlan, прописываем ип, цепляем его к интерфейсу физическому и далее работаем с ним как с обычным интерфейсом. транк. его можно добавить в бриджи и т.д. Зачем пытаться реализовать влан бриджем?
nioliz Автор
15.09.2021 19:18Так конфигураций разных бывает много. Та, которую описываете Вы мне вот ни разу не пригождалась. Между двумя аппаратными портами может быть разница в том, что к одному порту влан должен быть подцеплен с тэгом, а к другому -- без, опять же, обычно речь идёт не про работу с одним портом, а про работу с разными... Короче, я описываю то, как можно начать понимать логику работы вланов, а не реализацию отдельно взятого случая.
lokkiuni
16.09.2021 09:56+1Потому что как минимум с 2018 это не best practice, сейчас рекомендация - bridge и в нём vlan и port с pvid и прочее прочее. Вот презентация на эту тему с MUM 2018.
@SerjVда, мощи меньше, 326/328 вытягивают порядка 300мбит в режиме нат (по крайней мере в той конфигурации что я тестировал), но - vlan там полностью аппаратный, и по идее может работать на полной скорости (почему по идее - потому что я не проверял). И в целом там много аппаратных фич, которых нет в роутерах, специфичных именно для свичей. Хороший пример - HeX он же 750gr3, очень быстрый роутер за мало денег, но те же vlan делает сравнительно медленно (потому что процом).
@amaraovxlan насколько знаю поддерживается, могу проверить насколько работает - всё равно маленькая лаба на виртуалках поднята. Из вышеописанного - разве что перезапись вланов может быть немного через пятую точку (но crs326/328 точно могут средствами SwichChip на скорости порта) - то есть не совсем "нативными" для routerOS.
SerjV
17.09.2021 03:17ну да 326/328 понятно, просто когда-то подумал над тем, чтобы заменить CSS на "более управляемый" CRS, и честно говоря подиспугался, как раз из-за того, что если всё навесить на процессор вместо аппаратного свитча - будет большая Ж. А потом в SwOS вроде как пофиксли наконец-то багу, когда коммутатор "уходил в себя", не реагируя на управление, и пропускал только мелкие пакеты (да и то не всегда, насколько помню; на форуме писали, что это только с SwOS, с routeros вроде нормально), и вроде как стало можно не рыпаться.
Хотя, вот за инфу про nat 300мбит/с спасибо, буду иметь в виду... Но эти опасения были уже из другого проекта - там была идея учинить vlan per port, ну и за отсутствием приличного роутера в ядре (да и ядра вообще толком у клиента - разве что для доступа в инет был какой-то кошак, но не слишком могучий...), маршрутизировать самим же коммутатором. Т.е. использовать его как своего рода 24-портовый маршрутизатор.
amarao
15.09.2021 19:48+1... какая дичь... Ощущение, что представления о сети у них образца 2000ого года.
Принять vxlan внутри которого vlan, внутри которого gre внутри которого l2 с vlan'ом... Ну, извращение как извращение. Можно развернуть, можно реврайтнуть vlan id на любом уровне, можно запретить использовать 22 порт внутри како-то из слоёв.
Можно. Но не на микротиках.
flif
16.09.2021 10:46Какое то у Вас странное представление о микротиках)))) vxlan не юзал, но инкапсуляции с фиговой тонной вложений использую каждый день именно на микротиках, ибо кошачьи и можжевеловые роутеры стоят как крылья от боинга))))
У автора статьи отсутствует понимание разницы между bridge vlan(это поведение коммутатора), и interface vlan(поведение любого классического роутера от кошачьих или можжевеловых брэндов). В части эффективности на рубль в сегменте малобюджетного mpls ему вообще нет равных))))
Мои рекомедации автору - и на коммутаторах, и на роутерах использовать каждый тип под свои задачи, и не пытаться применять садомию там где это дело излишне)))
amarao
16.09.2021 11:17+1Я из линуксовой школы, мне вот эти деления очень странно читать.
SerjV
17.09.2021 02:54какие именно деления странны?
amarao
17.09.2021 11:30bridge vlan и interface vlan. vlan - это vlan, и на чистом l2-интерфейсе он висит, или на интерфейсе с ip-адресом, разницы это не даёт никакой.
SerjV
17.09.2021 13:54ммм… смотря с точки зрения каких механизмов.
С т.з. маршрутизации не важно, есть ли vlan вообще (т.е. интерфейс это или сабинтерфейс, по-кошачьи говоря), с т.з. коммутатора — нет никаких IP-адресов, зато есть vlanid у фрейма и «виртуальные коммутационные таблицы», как тут сказали.
Сложность возникает, когда у нас в одном устройстве есть и коммутатор (причём аппаратный), и маршрутизатор, и оно реально выполняет функции и того, и другого.
Если в компе программно делать бридж из нескольких сетевых карт, разницы особо нет… Но не знаю, есть ли в природе сетевые карты со встроенным коммутационным чипом для компов, но если есть — то получится примерно та же проблема, что и с микротиком — рулить ли вланами на L2 средствами коммутатора, или «разобрать» коммутатор на сетевые интерфейсы и рулить как маршрутизатором, или делать программный бридж, или интегрировать реализацию бриджа с аппаратным коммутатором…amarao
17.09.2021 15:13Есть акселераторы для OVS'а например (те же netronome'ы), есть DPDK (который говорит о том, что современные компьютеры весьма быстры и могут перекладывать пакеты не хуже аппаратных чипов). В целом, "аппаратный свитч" - это довольно дурной костыль, потому что умеет он мало, только одним образом и про него надо постоянно помнить. Обычно такое впаивают в дешёвые железки на армах, которые сами не могут быстро работать.
SerjV
17.09.2021 16:02только один проц для компа будет стоит дороже, чем весь 26-портовый коммутатор… Причём, возможно, даже не гигабитный коммутатор, а 10G (без набивки SFPхами)…
SerjV
17.09.2021 16:59Хотя благодарю за информацию о DPDK.
Но насколько я понимаю, с ним линуксовый сетевой стек идёт лесом, вместе с драйверами сетевых интерфейсов.
А потому всё равно получается отдельная штука, на которой надо переписать всё, включая маршрутизацию, файрвол, нат, и тот же бридж…
Если я всё правильно понял.amarao
17.09.2021 20:28На самом деле даже голый OVS без акселерации способен 30-40ГБит отфигачить в ванильном режиме (если драйвера сетевой карты умеют irq раскидывать по процессорам).
SerjV
17.09.2021 20:48Тут было бы неплохо услышать, на каком порту и с каким количеством каких сетевых карт он это сделает.
Для сопоставления, указывавшийся выше 326-й — это 24x1G порта + 2x10G, что уже где-то на пределе, а есть вариант с немного другими цифирками в модели 326-24S+2Q — так там уже будет 24x10G + 2x40G, и указанные вами 40Gbit/s кончатся на одном-двух портах…
dani
15.09.2021 19:53+5Автор сочиняет собственное представление мира вместо чтения официальной документации. Вот именно поэтому написано то, что при чтении понять невозможно, хоть слова все по-отдельности понятные.
nioliz Автор
15.09.2021 21:55Ну, хорошо, добавил описание более стандартного механизма. На мой взгляд он не такой удобный, но это дело вкуса. И заодно ссылку на совсем официальную документацию.
RomanKu
16.09.2021 00:17+2Знаете, это напоминает шутку про N конкурирующих стандартов. Вы вместо того, чтобы разобраться в сути вопроса и сделать нормальный гайд для новичков тупо сделали свой велосипед и подаёте это как решение всех проблем, но при этом это всего лишь ещё одна проблема.
Официалтная документация достаточно подробна + имеет ветвление в зависимости от типа оборудования и это сделано не просто так. Вы же не ездите по левой стороне дороги в праворульной стране, потому что вам так удобней.
Плюс официальной документации ещё и в том, что она отражает актуальные подходы к решению конкретных задач, а статья 4 летней давности может уже не соответствовать реальности.
dani
16.09.2021 08:57+2Уважаемый @jscar в свое время сделал отличный гайд по VLAN для MT. Лучше уберите всё позорище и посмотрите https://vlanscorrectway.ml/
icCE
16.09.2021 09:51Саглсаен, автор не разобрался в вопросе.
Я бы понял, если бы речь шла о switch chip vlan, там действительно было с ходу очень так себе. После того как сделали через мост, то сильно проще и почти как у всех.
А то получилось ```Добиться того, чтобы все VLAN были с тегом и не было ни одного дефолтного, но при этом всё работало, лично у меня не получилось ```
Автору:
Может все же почитать доку и добиться как это делается ? Потом уже статьи писать ?
```То есть, если понадобилось например выдать адрес по DHCP, то для этого нужно чтобы DHCP-сервер микротика смотрел на собственный bridge со стороны без тэга. Аналогично со всеми остальными "высокоуровневыми" операциями. Никаких тэгов внутри "умной" чисти Микротика нет! Поэтому если нужны тегированные VLAN'ы, надо "довешивать" тэги позже. ``
Тэги они бывают не скольких типов и по разному работают.
DHCP вполне себе может смотреть на один из vlan портов и раздавать.
bridge-vlan по сути так и будет default vlan , access vlan по умолчанию.
итд итп.
nioliz Автор
16.09.2021 10:53VLAN-порт как раз и занимается тем, что снимает тэг, указанный в его свойствах. То есть, судя по тому, что я вижу, у Вас есть тегированный трафик, который приходит в таки VLAN-порт, где тэг снимается и дальше в логику сервера идёт уже нетегированным. Вот именно эта -- одна из тех особенностей, которые я и пытался показать. Пунктом 2, если быть более точным.
dani
16.09.2021 15:28Вы вообще не понимаете что такое L2 и что L3. Ваш "VLAN-порт" это на нормальном языке называется "Терминирование VLAN" и вообще никаким образом не относится только к микротику. Любой интерфейс, имеющий IP адрес - это L3, VID - это L2. Одно инкапсулируется в другое.
RomanKu
16.09.2021 16:08VLAN это 802.1Q
Не надо рассматривать интерфейсы, как средство снимания или установки тега. Если понимать, что VLAN - это всего лишь поле на уровне L2 и набор действий над ними, то станет намного легче и понятней. Вы просто навешиваете те действия, которые должны быть произведены над пакетом, а можете этого и не делать. Даже сам микротик, если это не CCR использует подкапотное навешивание тега на порты, чтобы потом их собрать в 1 линк на проце. А еще есть дефолтный vlan 1, который как бы и не vlan. В примере выше нетегированый трафик идет в 04_guest_dhcp, а тегированный терминируется на нужный интерфейс внутри бриджа.
nioliz Автор
16.09.2021 16:39Вот я не готов мыслить пространствами и полями. Я как раз привык мыслить на уровне тэгов, поэтому и не заходит мне родная документация. Ну и собственно я думаю, что такой не один, поэтому и попытался перевести на привычную мне терминологию обычные описания.
dani
16.09.2021 17:29У вас в голове каша. Вам даже ссылку на википедию дали, зайдите, прочитайте вместо того, чтобы нести чушь
nioliz Автор
16.09.2021 19:10Вам прямо с цитатами из этой самой википедии показать чем именно она мне не нравится? :) -- Но если коротко, по ней очень сложно понять, как жить когда микротик ни хрена не основная часть сети, а очень даже вторичная.
icCE
16.09.2021 20:23```VLAN-порт как раз и занимается тем, что снимает тэг, указанный в его свойствах.`` Что вы ему укажите, то он и будет делать. Вот вам картинка, что бы у вас голова вообще уплыла.
Вот bonding, на которого навешены vlan :)
Те vlan тут это виртуальное устройство , от bonding
В нормальной терминологии, vlan тут это access порт.
brdige-vlan это default access порт.
bonding как принимает теги от других коммутаторов , так их снимает (access port) , так и передает некоторые дальше Транк порт.
Ах да Забыл добавить, что bonding тут это 4 физических порта :)
В целом просто разберитесь в вопросе.
RomanKu
16.09.2021 00:39+1Порт ether1 воткнут в тот же свитч, что и управляющее устройство...
На самом деле Вам правильно нахейтили по поводу отсутствия ссылок на документацию.
Тут и далее написан полнейший бред, в документации все подробно расписано и нет никакой магии. Другой вопрос с CAPsMAN - там есть свои приколы, которые так и не пофиксили, но они на ваш случай не влияют.
nioliz Автор
16.09.2021 10:55Если Вы считаете, что надо было указать дополнительную ссылку -- кидайте её сюда, если она стоящая, я поправлю статью.
RomanKu
16.09.2021 11:14+2Я бы начинал читать отсюда - тут базовые основы для понимания, что это такое. Тут же есть информация по различиям.
Далее, уже кидали ссылку на табличку.
Ну и есть информация по конкретным чипам: раз, два
Пример с CAPsMAN и VLAN: вот тут
nioliz Автор
16.09.2021 15:03Про капсман лично мне конкретно эта ссылка и не помогла (как и вагон еще всяких) потому что она как раз и даёт типовое решение вместо понимания вопроса. Мне нужно было заворачивать трафик из капсмана вместо микротика на другой узел через тегированный порт и прочитав статью я тогда не понял, как именно это реализовать. Вроде готовая конфигурация работает, а как ей "доработать напильником" не понятно.
Остальные ссылки добавил в статью, хотя на мой взгляд в материале, помеченном как tutorial обсуждать такие тонкости как "на этом чипе оно будет работать, но возможно будет тормозить из-за программной реализации" не совсем верно и я действительно считаю, что это должно быть в другой статье, которую всё ещё прошу написать Вас :).
RomanKu
16.09.2021 15:27Может быть напишу статью, я на НГ 2020 года потратил больше недели на настройку у себя 5 микротиков на основе vlan и да, подход отличается от того, что написан в доке как основной. Я делал тоже только через vlan и local forwarding и трафик ходил через роутер только в интернет, а локалка вся напрямую.
falciloid
16.09.2021 10:56+2Сложновато было читать сию статью.. Придирки по сути:
сетевые операции происходят на пакетах без тэга. А тэги появляются только тогда, когда появился bridge.
Влан интерфейсы можно и не на бридж вешать. И это даже будет работать. Так делается если на порту нужно только терминировать вланы но не нужно их коммутировать на той же железке.
(увидел в конце статьи что упомянули, но как заметку оставлю)
тег снимается (для исходящего и добавляется для входящего трафика) в тот момент, когда пакет доходит до порта (не важно, физического в мосту, виртуального или автоматически созданного чем-то вроде CapsMan'а)
Снова мимо, с тегами можно работать ещё и через меню switch на железках где свич чип это умеет (список и таблицы есть в офф вики), и там теги будут ставиться и сниматься до попадания в bridge.
Кроме того на wlan интерфейсах вне капсмана есть фича VLAN mode + VLAN ID позволяющая интерфейсу "забирать" в бридже нужный VLAN с тегом и передавать дальше снимая тег.
Никаких тэгов внутри "умной" чисти Микротика нет!
Загляните в меню switch вкладка rules в окно создания нового правила. Даже если железка не умеет с этим работать то окно отобразится. Вот вам умная часть микротика с вланами
Чтобы мост пропускал тегированный трафик мало поставить галку "Admit all", надо еще и добавить сам мост в конфигурацию VLAN в поле "tagged"
Внезапно если не добавить сам бридж в меню bridge VLANs как tagged то пропускать влан через себя он будет. Но не будет с ним работать по L3 и соответственно влан интерфейсы на этом бридже с вланом которого нет этого бриджа как tagged в меню bridge VLANs работать не будут
никто не мешает из таких портов как в п.6, с которых уже сняты теги на уровне виртуального интерфейса, опять же собрать мост.
Это миссконфиг, на той же вики микротика есть статья "Layer 2 Missconfiguration" где описано то как не надо делать и почему, этот случай так же там фигурирует под седьмым номером
nioliz Автор
16.09.2021 11:12Оба-на, вот про меню switch спасибо, реально не сталкивался. Покурю маны на эту тему с интересом.
Но не будет с ним работать по L3 и соответственно влан интерфейсы на этом бридже с вланом которого нет этого бриджа как tagged в меню bridge VLANs работать не будут
А что тогда останется? -- Я не вижу практической разницы между своим высказыванием и Вашим.
rnd71
16.09.2021 15:28Мало того, вы перепутали наглухо саму систему работы с тегами везде.
На входе тег снимается и помещается в виртуальный коммутатор согласно тегу.
На выходе тег вешается, если вешается.
Выводы: теги существуют только вне коммутатора, а внутри они существуют в разных виртуальных коммутационных таблицах.
nioliz Автор
16.09.2021 15:54Ну, тэг как виртуальное свойство пакета работает ровно как я написал, а тэг как набор бит в заголовке я честно говоря не представляю как проверить когда по факту пропадает потому, что из самой таблицы маршрутизации пакет для анализа не выдернуть. А с точки зрения поведения оборудования нет никакой разницы между "тэг 3 прописан в пакете, идущем в коммунаторе с другими пакетами" или "тэг 3 прописан в виртуальном коммутаторе, в котором идут только пакеты для этого тэга".
Ну вот есть у нас бридж, в нём два VLAN, номера 1 и 2. В свойствах бриджа прописан тэг 1, тэг 2 создан через создание влана в бридже.
В бридж добавляем один интерфейс VLAN с тэгом 2, ставим туда айпишник и еще на сам интерфейс бриджа ставим айпишник. И в довершение добавляем туда же физический порт, например 1, при этом в свойствах моста ставим тэг 1 опять же.
Снаружи с 1 порта в такой конфигурации можно снимать нетегированный 1 влан и тегированный второй и пинговать соответствующие адреса.
И в принципе можно считать, что это по факту два разных виртуальных коммутатора, один для 1 влана, второй для 2. И что пакеты, входящие без тэга отправляются в одну таблицу коммутации, а с тэгом 2 -- в другую.
Но если мы считаем, что мост всё-таки один, то логика нисколько не меняется: пакет приходит без тэга на внешний порт, попадает в мост без тэга (потому что тэг порта и моста совпадают) и идёт на интерфейс с адресом.
Или второй пакет приходит с тэгом 2, идёт в тот же мост, тэг с него не снимается потому, что в свойствах порта указан другой тэг, в единой таблице коммутации тэг присутствует, по нему пакет идёт к интерфейсу VLAN, где с него снимается тэг постольку, поскольку в свойствах этого порта тэг 2 указан. И дальше идёт на обработку кому он там пологается без тэга.
Или если говорить ближе к программированию, с точки зрения поведения, нет разницы между цифрой в столбце таблицы и цифрой-номером таблицы. А это же гайд для пользователей, а не для разработчиков микротов.
rnd71
16.09.2021 16:00Демагогия, демагогия, демагогия.
Вы упорно придумываете свое видение мира, и плюете на стандарты.
С Вами не о чем дальше беседовать.
Рекомендую сходить на курсы CCNA к хорошему преподавателю, что бы он вам вбил в вашу голову правильные вещи.
Есть правильное поведение:
Снаружи коммутатора есть тег, внутри коммутатора нет тега. Исключение QinQ.
nioliz Автор
16.09.2021 15:07Ах да, еще не ответил на это:
Кроме того на wlan интерфейсах вне капсмана есть фича VLAN mode + VLAN ID позволяющая интерфейсу "забирать" в бридже нужный VLAN с тегом и передавать дальше снимая тег.
Так это на всех интерфейсах, не только wlan: стоит где-то в свойствах интерфейса вписать номер тэга, этот тэг снимается после интерфейса. И я об этом написал в пункте 2.
falciloid
17.09.2021 06:44Окей, где в свойствах самого EoIP интерфейса вне бриджа такие же фичи? В свойствах физического ethernet, PPPoE клиента?
То о чём вы говорите это касается интерфейсов которые являются портами бриджа и это не будет работать без bridge VLAN filtering, а эта фича отключает hardware offload от свич чипа везде помимо серии CRS 3XX и возможно в семёрке на некоторых других железках будет. И это как раз одна из причин зачем может понадобиться лезть колдовать со свич чипом если он таки умет вланы.
SerjV
и
И вот тут возникает резонный вопрос…
веб-интерфейс SwOS достаточно понятен тем, кто настраивал коммутаторы других производителей через веб-интерфейс. В этом его плюс, зато много других минусов типа обрезанности фич управления (по-моему, даже логирование на внешний syslog настроить нельзя, фиг бы там только отсутствие cli)
И вот кто-то решил заменить CSSxxx на аналогичный CRSxxx, который «всё то же самое, только флешка больше и в ней две операционки — SwOS и RouterOS», и перенести конфигурацию в RouterOS (потому что у него фич управления больше, роутер из 24-портового коммутатора скорее всего так себе будет из-за процессора, хотя для надёжности тут бы мнение спецов по микротику услышать), и задаётся вопросом «как бы во всём это изобилии фич нагрузку L2 всё-таки максимально прооффлоадить на чип коммутатора, а не на процессор, ну или быть уверенным, что сделал это правильно.
Но у вас несколько не о такой проблеме, а о маршрутизаторе (и даже конкретнее точке доступа), которому надо добавить элементы коммутатора?
Вопрос следующий… Насколько изложенное тут применимо к моделям микрота, у которых всё-таки есть встроенный „аппаратный“ коммутатор, типа тех же CRS или каких-то из hap? Или применимо, но там есть дополнительные нюансы?
nioliz Автор
Это всё отлично применимо ко всему, где есть Router OS, даже к тем свичам, которые перешиваются из Switch OS в Router OS, вне зависимости от аппаратной платформы.
RomanKu
Сама статья так себе с точки зрения микротика, а вот этот комментарий - совсем плох. Да, работать оно будет, т.к. в последнее время много работы проведено по переходу на VLAN в бриджах, но при этом работать будет не всегда оптимально. Сама тема VLAN так плохо расписана по той причине, что это одна из головных болей Микротика и несколько раз переделывалась + есть множество чипой для свитчей, в итоге для аппаратной поддержки VLAN приходится настраивать разными способами в зависимости от оборудования, например, у меня тот же CRS 125 имеет отдельное меню для настройки чипа, а уже 2 и 3 серия может нормально работать через бриджи.
Поэтому, вашу статью можно применять только для конкретного оборудования для решения конкретных задач.
nioliz Автор
Вот честно, я очень рад, что в комментариях так много людей, знающих вопрос лучше меня. И я буду еще больше рад, если скажем Вы (или кто угодно другой) напишите статью, где распишите подробнее те моменты, которые я упустил, включая разницу настройки тех же VLAN на разном оборудовании, сам с удовольствием её почитаю и скажу искреннее спасибо. Я сам всегда придерживаюсь позиции "критикуя -- предлагай" и другим советую действовать также. Лично мне вот того объёма информации, который я здесь привёл, не хватало на протяжении нескольких месяцев. И привёл тут я его с единственной целью -- помочь тем людям, которые попали в такую же ситуацию, как я раньше. И да, по нему лично я несколько железок от CRS до cAP ac. Перешитый свитч мы в этой конфигурации тоже смотрели, но на демо-стенде, где производительность конечно же было объективно не оценить.
И я буду еще больше рад, если из-за моей статьи начнётся холивар, по результатам которого подобных статей появится несколько, от разных авторов, дополняющих друг друга. :)
RomanKu
Написать подобную статью особого интереса и смысла нет. Но возникла идея написать тут статью на тему "создание производительной конфигурации MikroTik", где расписать в том числе об особенностях настройки VLAN
nioliz Автор
Да, согласен, звучит очень здорово :). Особенности выбора оборудования по производительности мне на глаза ни разу не попадались, а все знакомые обычно мыслят категориями "микротик тормозит, значит надо просто купить более дорогой".
AcidVenom
Зависит от серии. Если 3, то куда ни шло.
В бридж (обычно должен быть 1, смотри диаграмму модели) порты и уточнить, что появились флаги "H". Если нет, то смотреть табличку почему нет.
RomanKu
Совершенно верно, если для роутера это не так критично, то свитч может потерять производительности до нескольких порядков в случае, если что-то не понравилось свитчу и RouterOS выключил Hardware Offload.
SerjV
да даже CRS326-24G-2S+RM: CPU 98DX3236, CPU core count 1, CPU nominal frequency 800 MHz,
против hap ac^2: CPU IPQ-4018, CPU core count 4, CPU nominal frequency 716 MHz
при той же архитектуре ARM 32bit
если, конечно, у них маршрутизация однопоточная, то наверное да, разницы не будет, иначе выходит, что на 26 портов у CRS меньше "мощи", чем на 5 у hap (и по-моему, аппаратная коммутация есть у обоих, кстати).