Comments 52
Сразу оговорюсь, что данная статья про Router OS, а не Switch OS.
и
А мне хотелось бы видеть статью, которая для специалистов по сетям, которым надо привычные вещи реализовать на железе Mikrotik.
И вот тут возникает резонный вопрос…
веб-интерфейс SwOS достаточно понятен тем, кто настраивал коммутаторы других производителей через веб-интерфейс. В этом его плюс, зато много других минусов типа обрезанности фич управления (по-моему, даже логирование на внешний syslog настроить нельзя, фиг бы там только отсутствие cli)
И вот кто-то решил заменить CSSxxx на аналогичный CRSxxx, который «всё то же самое, только флешка больше и в ней две операционки — SwOS и RouterOS», и перенести конфигурацию в RouterOS (потому что у него фич управления больше, роутер из 24-портового коммутатора скорее всего так себе будет из-за процессора, хотя для надёжности тут бы мнение спецов по микротику услышать), и задаётся вопросом «как бы во всём это изобилии фич нагрузку L2 всё-таки максимально прооффлоадить на чип коммутатора, а не на процессор, ну или быть уверенным, что сделал это правильно.
Но у вас несколько не о такой проблеме, а о маршрутизаторе (и даже конкретнее точке доступа), которому надо добавить элементы коммутатора?
Вопрос следующий… Насколько изложенное тут применимо к моделям микрота, у которых всё-таки есть встроенный „аппаратный“ коммутатор, типа тех же CRS или каких-то из hap? Или применимо, но там есть дополнительные нюансы?
Это всё отлично применимо ко всему, где есть Router OS, даже к тем свичам, которые перешиваются из Switch OS в Router OS, вне зависимости от аппаратной платформы.
Сама статья так себе с точки зрения микротика, а вот этот комментарий - совсем плох. Да, работать оно будет, т.к. в последнее время много работы проведено по переходу на VLAN в бриджах, но при этом работать будет не всегда оптимально. Сама тема VLAN так плохо расписана по той причине, что это одна из головных болей Микротика и несколько раз переделывалась + есть множество чипой для свитчей, в итоге для аппаратной поддержки VLAN приходится настраивать разными способами в зависимости от оборудования, например, у меня тот же CRS 125 имеет отдельное меню для настройки чипа, а уже 2 и 3 серия может нормально работать через бриджи.
Поэтому, вашу статью можно применять только для конкретного оборудования для решения конкретных задач.
Вот честно, я очень рад, что в комментариях так много людей, знающих вопрос лучше меня. И я буду еще больше рад, если скажем Вы (или кто угодно другой) напишите статью, где распишите подробнее те моменты, которые я упустил, включая разницу настройки тех же VLAN на разном оборудовании, сам с удовольствием её почитаю и скажу искреннее спасибо. Я сам всегда придерживаюсь позиции "критикуя -- предлагай" и другим советую действовать также. Лично мне вот того объёма информации, который я здесь привёл, не хватало на протяжении нескольких месяцев. И привёл тут я его с единственной целью -- помочь тем людям, которые попали в такую же ситуацию, как я раньше. И да, по нему лично я несколько железок от CRS до cAP ac. Перешитый свитч мы в этой конфигурации тоже смотрели, но на демо-стенде, где производительность конечно же было объективно не оценить.
И я буду еще больше рад, если из-за моей статьи начнётся холивар, по результатам которого подобных статей появится несколько, от разных авторов, дополняющих друг друга. :)
Написать подобную статью особого интереса и смысла нет. Но возникла идея написать тут статью на тему "создание производительной конфигурации MikroTik", где расписать в том числе об особенностях настройки VLAN
Совершенно верно, если для роутера это не так критично, то свитч может потерять производительности до нескольких порядков в случае, если что-то не понравилось свитчу и RouterOS выключил Hardware Offload.
да даже 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 (и по-моему, аппаратная коммутация есть у обоих, кстати).
Вроде просто всё, делаем интерфейс vlan, прописываем ип, цепляем его к интерфейсу физическому и далее работаем с ним как с обычным интерфейсом. транк. его можно добавить в бриджи и т.д. Зачем пытаться реализовать влан бриджем?
Так конфигураций разных бывает много. Та, которую описываете Вы мне вот ни разу не пригождалась. Между двумя аппаратными портами может быть разница в том, что к одному порту влан должен быть подцеплен с тэгом, а к другому -- без, опять же, обычно речь идёт не про работу с одним портом, а про работу с разными... Короче, я описываю то, как можно начать понимать логику работы вланов, а не реализацию отдельно взятого случая.
Потому что как минимум с 2018 это не best practice, сейчас рекомендация - bridge и в нём vlan и port с pvid и прочее прочее. Вот презентация на эту тему с MUM 2018.
@SerjVда, мощи меньше, 326/328 вытягивают порядка 300мбит в режиме нат (по крайней мере в той конфигурации что я тестировал), но - vlan там полностью аппаратный, и по идее может работать на полной скорости (почему по идее - потому что я не проверял). И в целом там много аппаратных фич, которых нет в роутерах, специфичных именно для свичей. Хороший пример - HeX он же 750gr3, очень быстрый роутер за мало денег, но те же vlan делает сравнительно медленно (потому что процом).
@amaraovxlan насколько знаю поддерживается, могу проверить насколько работает - всё равно маленькая лаба на виртуалках поднята. Из вышеописанного - разве что перезапись вланов может быть немного через пятую точку (но crs326/328 точно могут средствами SwichChip на скорости порта) - то есть не совсем "нативными" для routerOS.
ну да 326/328 понятно, просто когда-то подумал над тем, чтобы заменить CSS на "более управляемый" CRS, и честно говоря подиспугался, как раз из-за того, что если всё навесить на процессор вместо аппаратного свитча - будет большая Ж. А потом в SwOS вроде как пофиксли наконец-то багу, когда коммутатор "уходил в себя", не реагируя на управление, и пропускал только мелкие пакеты (да и то не всегда, насколько помню; на форуме писали, что это только с SwOS, с routeros вроде нормально), и вроде как стало можно не рыпаться.
Хотя, вот за инфу про nat 300мбит/с спасибо, буду иметь в виду... Но эти опасения были уже из другого проекта - там была идея учинить vlan per port, ну и за отсутствием приличного роутера в ядре (да и ядра вообще толком у клиента - разве что для доступа в инет был какой-то кошак, но не слишком могучий...), маршрутизировать самим же коммутатором. Т.е. использовать его как своего рода 24-портовый маршрутизатор.
... какая дичь... Ощущение, что представления о сети у них образца 2000ого года.
Принять vxlan внутри которого vlan, внутри которого gre внутри которого l2 с vlan'ом... Ну, извращение как извращение. Можно развернуть, можно реврайтнуть vlan id на любом уровне, можно запретить использовать 22 порт внутри како-то из слоёв.
Можно. Но не на микротиках.
Какое то у Вас странное представление о микротиках)))) vxlan не юзал, но инкапсуляции с фиговой тонной вложений использую каждый день именно на микротиках, ибо кошачьи и можжевеловые роутеры стоят как крылья от боинга))))
У автора статьи отсутствует понимание разницы между bridge vlan(это поведение коммутатора), и interface vlan(поведение любого классического роутера от кошачьих или можжевеловых брэндов). В части эффективности на рубль в сегменте малобюджетного mpls ему вообще нет равных))))
Мои рекомедации автору - и на коммутаторах, и на роутерах использовать каждый тип под свои задачи, и не пытаться применять садомию там где это дело излишне)))
Я из линуксовой школы, мне вот эти деления очень странно читать.
какие именно деления странны?
bridge vlan и interface vlan. vlan - это vlan, и на чистом l2-интерфейсе он висит, или на интерфейсе с ip-адресом, разницы это не даёт никакой.
С т.з. маршрутизации не важно, есть ли vlan вообще (т.е. интерфейс это или сабинтерфейс, по-кошачьи говоря), с т.з. коммутатора — нет никаких IP-адресов, зато есть vlanid у фрейма и «виртуальные коммутационные таблицы», как тут сказали.
Сложность возникает, когда у нас в одном устройстве есть и коммутатор (причём аппаратный), и маршрутизатор, и оно реально выполняет функции и того, и другого.
Если в компе программно делать бридж из нескольких сетевых карт, разницы особо нет… Но не знаю, есть ли в природе сетевые карты со встроенным коммутационным чипом для компов, но если есть — то получится примерно та же проблема, что и с микротиком — рулить ли вланами на L2 средствами коммутатора, или «разобрать» коммутатор на сетевые интерфейсы и рулить как маршрутизатором, или делать программный бридж, или интегрировать реализацию бриджа с аппаратным коммутатором…
Есть акселераторы для OVS'а например (те же netronome'ы), есть DPDK (который говорит о том, что современные компьютеры весьма быстры и могут перекладывать пакеты не хуже аппаратных чипов). В целом, "аппаратный свитч" - это довольно дурной костыль, потому что умеет он мало, только одним образом и про него надо постоянно помнить. Обычно такое впаивают в дешёвые железки на армах, которые сами не могут быстро работать.
Но насколько я понимаю, с ним линуксовый сетевой стек идёт лесом, вместе с драйверами сетевых интерфейсов.
А потому всё равно получается отдельная штука, на которой надо переписать всё, включая маршрутизацию, файрвол, нат, и тот же бридж…
Если я всё правильно понял.
На самом деле даже голый OVS без акселерации способен 30-40ГБит отфигачить в ванильном режиме (если драйвера сетевой карты умеют irq раскидывать по процессорам).
Для сопоставления, указывавшийся выше 326-й — это 24x1G порта + 2x10G, что уже где-то на пределе, а есть вариант с немного другими цифирками в модели 326-24S+2Q — так там уже будет 24x10G + 2x40G, и указанные вами 40Gbit/s кончатся на одном-двух портах…
Автор сочиняет собственное представление мира вместо чтения официальной документации. Вот именно поэтому написано то, что при чтении понять невозможно, хоть слова все по-отдельности понятные.
Ну, хорошо, добавил описание более стандартного механизма. На мой взгляд он не такой удобный, но это дело вкуса. И заодно ссылку на совсем официальную документацию.
Знаете, это напоминает шутку про N конкурирующих стандартов. Вы вместо того, чтобы разобраться в сути вопроса и сделать нормальный гайд для новичков тупо сделали свой велосипед и подаёте это как решение всех проблем, но при этом это всего лишь ещё одна проблема.
Официалтная документация достаточно подробна + имеет ветвление в зависимости от типа оборудования и это сделано не просто так. Вы же не ездите по левой стороне дороги в праворульной стране, потому что вам так удобней.
Плюс официальной документации ещё и в том, что она отражает актуальные подходы к решению конкретных задач, а статья 4 летней давности может уже не соответствовать реальности.
Уважаемый @jscar в свое время сделал отличный гайд по VLAN для MT. Лучше уберите всё позорище и посмотрите https://vlanscorrectway.ml/
Саглсаен, автор не разобрался в вопросе.
Я бы понял, если бы речь шла о switch chip vlan, там действительно было с ходу очень так себе. После того как сделали через мост, то сильно проще и почти как у всех.
А то получилось ```Добиться того, чтобы все VLAN были с тегом и не было ни одного дефолтного, но при этом всё работало, лично у меня не получилось ```
Автору:
Может все же почитать доку и добиться как это делается ? Потом уже статьи писать ?
```То есть, если понадобилось например выдать адрес по DHCP, то для этого нужно чтобы DHCP-сервер микротика смотрел на собственный bridge со стороны без тэга. Аналогично со всеми остальными "высокоуровневыми" операциями. Никаких тэгов внутри "умной" чисти Микротика нет! Поэтому если нужны тегированные VLAN'ы, надо "довешивать" тэги позже. ``
Тэги они бывают не скольких типов и по разному работают.
DHCP вполне себе может смотреть на один из vlan портов и раздавать.
![](https://habrastorage.org/getpro/habr/upload_files/c5b/b56/8ca/c5bb568ca915065269cd7defbaab529b.png)
bridge-vlan по сути так и будет default vlan , access vlan по умолчанию.
итд итп.
VLAN-порт как раз и занимается тем, что снимает тэг, указанный в его свойствах. То есть, судя по тому, что я вижу, у Вас есть тегированный трафик, который приходит в таки VLAN-порт, где тэг снимается и дальше в логику сервера идёт уже нетегированным. Вот именно эта -- одна из тех особенностей, которые я и пытался показать. Пунктом 2, если быть более точным.
Вы вообще не понимаете что такое L2 и что L3. Ваш "VLAN-порт" это на нормальном языке называется "Терминирование VLAN" и вообще никаким образом не относится только к микротику. Любой интерфейс, имеющий IP адрес - это L3, VID - это L2. Одно инкапсулируется в другое.
VLAN это 802.1Q
Не надо рассматривать интерфейсы, как средство снимания или установки тега. Если понимать, что VLAN - это всего лишь поле на уровне L2 и набор действий над ними, то станет намного легче и понятней. Вы просто навешиваете те действия, которые должны быть произведены над пакетом, а можете этого и не делать. Даже сам микротик, если это не CCR использует подкапотное навешивание тега на порты, чтобы потом их собрать в 1 линк на проце. А еще есть дефолтный vlan 1, который как бы и не vlan. В примере выше нетегированый трафик идет в 04_guest_dhcp, а тегированный терминируется на нужный интерфейс внутри бриджа.
Вот я не готов мыслить пространствами и полями. Я как раз привык мыслить на уровне тэгов, поэтому и не заходит мне родная документация. Ну и собственно я думаю, что такой не один, поэтому и попытался перевести на привычную мне терминологию обычные описания.
У вас в голове каша. Вам даже ссылку на википедию дали, зайдите, прочитайте вместо того, чтобы нести чушь
```VLAN-порт как раз и занимается тем, что снимает тэг, указанный в его свойствах.`` Что вы ему укажите, то он и будет делать. Вот вам картинка, что бы у вас голова вообще уплыла.
Вот bonding, на которого навешены vlan :)
![](https://habrastorage.org/getpro/habr/upload_files/aff/2f3/507/aff2f3507a4e015cc9d3cb2261e5870e.png)
Те vlan тут это виртуальное устройство , от bonding
В нормальной терминологии, vlan тут это access порт.
brdige-vlan это default access порт.
bonding как принимает теги от других коммутаторов , так их снимает (access port) , так и передает некоторые дальше Транк порт.
Ах да Забыл добавить, что bonding тут это 4 физических порта :)
В целом просто разберитесь в вопросе.
Порт ether1 воткнут в тот же свитч, что и управляющее устройство...
На самом деле Вам правильно нахейтили по поводу отсутствия ссылок на документацию.
Тут и далее написан полнейший бред, в документации все подробно расписано и нет никакой магии. Другой вопрос с CAPsMAN - там есть свои приколы, которые так и не пофиксили, но они на ваш случай не влияют.
Если Вы считаете, что надо было указать дополнительную ссылку -- кидайте её сюда, если она стоящая, я поправлю статью.
Про капсман лично мне конкретно эта ссылка и не помогла (как и вагон еще всяких) потому что она как раз и даёт типовое решение вместо понимания вопроса. Мне нужно было заворачивать трафик из капсмана вместо микротика на другой узел через тегированный порт и прочитав статью я тогда не понял, как именно это реализовать. Вроде готовая конфигурация работает, а как ей "доработать напильником" не понятно.
Остальные ссылки добавил в статью, хотя на мой взгляд в материале, помеченном как tutorial обсуждать такие тонкости как "на этом чипе оно будет работать, но возможно будет тормозить из-за программной реализации" не совсем верно и я действительно считаю, что это должно быть в другой статье, которую всё ещё прошу написать Вас :).
Может быть напишу статью, я на НГ 2020 года потратил больше недели на настройку у себя 5 микротиков на основе vlan и да, подход отличается от того, что написан в доке как основной. Я делал тоже только через vlan и local forwarding и трафик ходил через роутер только в интернет, а локалка вся напрямую.
Сложновато было читать сию статью.. Придирки по сути:
сетевые операции происходят на пакетах без тэга. А тэги появляются только тогда, когда появился 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" где описано то как не надо делать и почему, этот случай так же там фигурирует под седьмым номером
Оба-на, вот про меню switch спасибо, реально не сталкивался. Покурю маны на эту тему с интересом.
Но не будет с ним работать по L3 и соответственно влан интерфейсы на этом бридже с вланом которого нет этого бриджа как tagged в меню bridge VLANs работать не будут
А что тогда останется? -- Я не вижу практической разницы между своим высказыванием и Вашим.
Мало того, вы перепутали наглухо саму систему работы с тегами везде.
На входе тег снимается и помещается в виртуальный коммутатор согласно тегу.
На выходе тег вешается, если вешается.
Выводы: теги существуют только вне коммутатора, а внутри они существуют в разных виртуальных коммутационных таблицах.
Ну, тэг как виртуальное свойство пакета работает ровно как я написал, а тэг как набор бит в заголовке я честно говоря не представляю как проверить когда по факту пропадает потому, что из самой таблицы маршрутизации пакет для анализа не выдернуть. А с точки зрения поведения оборудования нет никакой разницы между "тэг 3 прописан в пакете, идущем в коммунаторе с другими пакетами" или "тэг 3 прописан в виртуальном коммутаторе, в котором идут только пакеты для этого тэга".
Ну вот есть у нас бридж, в нём два VLAN, номера 1 и 2. В свойствах бриджа прописан тэг 1, тэг 2 создан через создание влана в бридже.
В бридж добавляем один интерфейс VLAN с тэгом 2, ставим туда айпишник и еще на сам интерфейс бриджа ставим айпишник. И в довершение добавляем туда же физический порт, например 1, при этом в свойствах моста ставим тэг 1 опять же.
Снаружи с 1 порта в такой конфигурации можно снимать нетегированный 1 влан и тегированный второй и пинговать соответствующие адреса.
И в принципе можно считать, что это по факту два разных виртуальных коммутатора, один для 1 влана, второй для 2. И что пакеты, входящие без тэга отправляются в одну таблицу коммутации, а с тэгом 2 -- в другую.
Но если мы считаем, что мост всё-таки один, то логика нисколько не меняется: пакет приходит без тэга на внешний порт, попадает в мост без тэга (потому что тэг порта и моста совпадают) и идёт на интерфейс с адресом.
Или второй пакет приходит с тэгом 2, идёт в тот же мост, тэг с него не снимается потому, что в свойствах порта указан другой тэг, в единой таблице коммутации тэг присутствует, по нему пакет идёт к интерфейсу VLAN, где с него снимается тэг постольку, поскольку в свойствах этого порта тэг 2 указан. И дальше идёт на обработку кому он там пологается без тэга.
Или если говорить ближе к программированию, с точки зрения поведения, нет разницы между цифрой в столбце таблицы и цифрой-номером таблицы. А это же гайд для пользователей, а не для разработчиков микротов.
Демагогия, демагогия, демагогия.
Вы упорно придумываете свое видение мира, и плюете на стандарты.
С Вами не о чем дальше беседовать.
Рекомендую сходить на курсы CCNA к хорошему преподавателю, что бы он вам вбил в вашу голову правильные вещи.
Есть правильное поведение:
Снаружи коммутатора есть тег, внутри коммутатора нет тега. Исключение QinQ.
Ах да, еще не ответил на это:
Кроме того на wlan интерфейсах вне капсмана есть фича VLAN mode + VLAN ID позволяющая интерфейсу "забирать" в бридже нужный VLAN с тегом и передавать дальше снимая тег.
Так это на всех интерфейсах, не только wlan: стоит где-то в свойствах интерфейса вписать номер тэга, этот тэг снимается после интерфейса. И я об этом написал в пункте 2.
Окей, где в свойствах самого EoIP интерфейса вне бриджа такие же фичи? В свойствах физического ethernet, PPPoE клиента?
То о чём вы говорите это касается интерфейсов которые являются портами бриджа и это не будет работать без bridge VLAN filtering, а эта фича отключает hardware offload от свич чипа везде помимо серии CRS 3XX и возможно в семёрке на некоторых других железках будет. И это как раз одна из причин зачем может понадобиться лезть колдовать со свич чипом если он таки умет вланы.
Mikrotik и VLAN