VLAN между двумя микротиками с коммутатором между ними

Обсуждение ПО и его настройки
Ответить
Аватара пользователя
Vlad-2
Модератор
Сообщения: 2531
Зарегистрирован: 08 апр 2016, 19:19
Откуда: Петропавловск-Камчатский (п-ов Камчатка)
Контактная информация:

mrrc писал(а):Но т.к. коммутаторы "умные", видимо нужно разрешить прохождение VLAN на портах коммутатора, чтобы для конечных подключенных устройств имелась возможность создания VLAN между ними. Предполагал, что порты по умолчанию работают в данном режиме, но видимо ошибался.

Да, умные/управляемые коммутаторы по-умолчанию вилан через себя не пропустит.
Надо настраивать.
mrrc писал(а):В каких режимах должны находиться порты коммутатора в свете описанной проблемы?

К сожалению у разных вендоров по-разному режимы пишутся, но всё же некий стандарт есть,
акцес-порт = порт который работает с обычным трафиком
транк-порт = порт по которому "бегает" тегированный трафик (один минимум вилан) и/или
ещё там же может бегать и обычный трафик
также надо "вкурить" что такое PVID
mrrc писал(а):Или же в случае непрямого кабельного соединения микротик-микротик настройка VLAN производится как-то иначе?

В данном случаи вилан на одном устройстве создали(выделили), этот вилан можно пропустить по куче свитчей,
главное чтобы они его приняли и также отдали дальше, и уже принимаете вилан на другом микротике,
а вот уже внутри микротика как вилан принять - тут уже надо от конфигурации исходить, и ещё
отталкиваться что Вам надо. Иногда сразу удобно на вилан-интерфейс в микротике адрес повесить, и работать
уже с этой адресацией(НАТить, маршрутизировать), а если надо внутри вилана запустить DHCP и ещё что-то в таком духе,
то тогда трафик превращаем в обычный (засунув его в бридж) и с ним(с трафиком) уже на бридже уже работаем.
mrrc писал(а):Пока без конфигов, чтобы принципиально вначале понять, в какую сторону смотреть.

Виланы надо понимать, немного поиграться и будет очень потом легче делать ряд моментов.
У меня тоже и видеокамеры и все провайдеры и ряд какие то сетей/DMZ "обвернуты" моими виланами,
это позволяет их про-коммутировать из нужного одного места в нужный порт другого управляемого свитча,
засунуть на сервер(а)/виртуализации, и так далее, что даёт удобство быстро работать с трафиком/поднимать
нужные сервисы/сервера, при этом ни нарушая иную работу.

Маленький пример:
а) три провайдера (виланами я их обернул и подал в микротик)
б) 4 сети, приходят по виланам, но сами сети, я их терминирую на бриджах (там в каждом свой DHCP)

Изображение



На работе(ах): 2xCCR1016-12G, RB3011UiAS и hAP lite (RB941)
Дома: CCR1016-12G, RBcAP2n (standalone), RB wAP LTE kit
Для тестов(под рукой): RB3011UiAS, hAP mini (RB931) и что-то ещё по мелочи
MTCNA
MTCRE
Аватара пользователя
Vlad-2
Модератор
Сообщения: 2531
Зарегистрирован: 08 апр 2016, 19:19
Откуда: Петропавловск-Камчатский (п-ов Камчатка)
Контактная информация:

mrrc писал(а):Благодарю, как всегда дорого-богато развернули вопрос.

Спасибо.
mrrc писал(а):Значит будем раскуривать дальше по этой теме, как раз на примере конкретной текущей задачи попробую разобраться.
В моем случае порты должны работать в транке, как я понимаю, чтобы обеспечить прохождение как vlan, так и обычного трафика, последнее очень важно, потому как от места предполагаемого расположения точек до нахождения контроллера может оказаться несколько коммутаторов и через какие именно их порты осуществляется физическая коммутация узнать не представляется возможным из-за большого масштаба самой сети (ethernet, оптические магистральные сегменты, конвертеры, все замиксировано).

Имейте ввиду, и во многих документациях, да и я наступал один раз = объединение в одном порту нативного(обычного) и тегированного трафика = плохой путь и подход.
Хотя знаю, порой никак, но если можете, старайтесь для транковых портов использовать отдельные порты.
А плохой он в том контексте, что где-то при ошибки конфигурации или при коммутации проводов = может произойти так, что два трафика (тегированный, и не тегированный)
объединяться, и по факту это настоящая "петля".
И ещё: пассивное сетевое оборудование, обычно это и конверторы и медиаконверторы и тупой хаб = им пофиг на тег, и они такой трафик пропустят, неуправляемый свитч
тоже должен пропустить через себя трафик, поэтому в целом тегированный трафик не мешает и не заметен, но на свитчах умных = без настроек (ещё раз повторюсь) никак.
mrrc писал(а):По этой причине получается, что все порты коммутаторов (х24 и х48), как минимум активные, придется переводить в режим, обеспечивающий одновременное прохождение VLAN и остального трафика? :men:
Существует VTP (VLAN Trunking Protocol), в теории позволяющий информацию о VLAN внести централизованно, на одном коммутаторе, и эти изменения распространятся на другие коммутаторы в сети. Должны ли при этом коммутаторы быть одного производителя - фз и насколько это может затронуть работоспособность всей сетевой инфраструктуры, которая в идеале не должна пострадать при решении текущей задачи. Да и не мой это случай вроде, задача больше обеспечить прозрачность прохождения одновременно VLAN и остального трафика по портам коммутаторов.

Ну ко всем новым и ещё масштабным протоколам надо подходить аккуратно, да и тестирование никто не отменял.
Опять же, в своих свитчах SG300 и SG200 (это свитчи от Циски) для средне-малых предприятий, я там VTP не видел,
а вот GVRP видел, и как раз GVRP более стандартизирован для многих сетевых вендарах.
Попробуйте в любом случаи и узнаете.
А вообще совет: лучше один свитч снять, поставить в разрыв двух микротиков, и почти на 90% с эммулировать Вашу
задачу и проверить прохождения пакетов, и так далее...На живой сети такое делать точно нельзя.
mrrc писал(а):Если удастся поднять VLAN в рамках сетевой инфраструктуры, обеспечив его прохождение через ряд коммутаторов, поле для деятельности по выбору вариантов конфигурации будет достаточное, чтобы выбрать наиболее подходящее в данном конкретном случае и на перспективу.

Работа в VLAN'ах - это планомерный и закономерный переход любой развИвающейся и увеличивающейся сети.
Да и админу(ам) легче, гибче, удобнее. Но начинать надо с малого.



На работе(ах): 2xCCR1016-12G, RB3011UiAS и hAP lite (RB941)
Дома: CCR1016-12G, RBcAP2n (standalone), RB wAP LTE kit
Для тестов(под рукой): RB3011UiAS, hAP mini (RB931) и что-то ещё по мелочи
MTCNA
MTCRE
Аватара пользователя
Vlad-2
Модератор
Сообщения: 2531
Зарегистрирован: 08 апр 2016, 19:19
Откуда: Петропавловск-Камчатский (п-ов Камчатка)
Контактная информация:

mrrc писал(а):Коммутатор имеется, как раз он может быть площадкой для вникания. Это тот же используемый Catalyst 2960-S Series.

У меня модели другие, они более чтоли френдли-юзерные.
mrrc писал(а):Покопавшись в веб-интерфейсе управления, настроек непосредственно по VLAN и Trunk Port-ам не вижу, но есть раздел конфигурирования Smartports, где требуемым портам можно задать т.н. роли, в которых они должны работать. По дефолту ничего не назначено. Из наиболее подходящих видится Switch (Switch—Switch-to-switch connection. Select the native VLAN number from the Native VLAN drop-down menu.). Оно это или нет? :du_ma_et:

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



На работе(ах): 2xCCR1016-12G, RB3011UiAS и hAP lite (RB941)
Дома: CCR1016-12G, RBcAP2n (standalone), RB wAP LTE kit
Для тестов(под рукой): RB3011UiAS, hAP mini (RB931) и что-то ещё по мелочи
MTCNA
MTCRE
kt72ru
Сообщения: 141
Зарегистрирован: 23 июн 2017, 07:55

Зачем вам этот Cisco Network Assistant, у Cisco прекрасная командная строка и огромное количество документации на нее в интернете.

входим в режим конфигурации
configure terminal

создаем вланы
vlan 10
name TEST_VLAN_10
vlan 20
name TEST_VLAN_20
exit

прописываем транковые порты и разрешаем прохождение через них определенных вланов
int gi0/1
desc FIRST_TRUNK_PORT
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 10,20
switchport mode trunk
int gi0/2
desc SECOND_TRUNK_PORT
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 10,20
switchport mode trunk
exit
exit

сохраняем конфиг
write


gmx
Модератор
Сообщения: 3290
Зарегистрирован: 01 окт 2012, 14:48

mrrc писал(а):Кстати, с указанием trunk allowed через порты проходит только vlan, обычный трафик не пропускается.


Посмотрите, возможно есть еще тип general или mixed для порта, тогда можно смешивать тегированный и нетегированный трафик.


kt72ru
Сообщения: 141
Зарегистрирован: 23 июн 2017, 07:55

gmx писал(а):Посмотрите, возможно есть еще тип general или mixed для порта, тогда можно смешивать тегированный и нетегированный трафик.


у 2960S нет таких типов порта.
ТС достаточно прописать в allowed 1 влан, так как все остальные порты в его сети в нем и живут.


kt72ru
Сообщения: 141
Зарегистрирован: 23 июн 2017, 07:55

mrrc писал(а):В trunk allowed по умолчанию стоит ALL, проходит тегированный и нетегированный трафик, 1-й общий для всех портов прописывать туда не пробовал.

если уже стоит ALL то пробовать прописывать 1 нет надобности.


Аватара пользователя
Vlad-2
Модератор
Сообщения: 2531
Зарегистрирован: 08 апр 2016, 19:19
Откуда: Петропавловск-Камчатский (п-ов Камчатка)
Контактная информация:

mrrc писал(а):Несколько приземлив вопрос к реальным полевым условиям, получается, чтобы пропустить созданный vlan через ethernet-порт коммутатора (S-1), который в свою очередь через оптический порт подключен к следующему головному коммутатору (M), и далее также через оптический порт подключение идет к целевому коммутатору (S-2), уже с ethernet-порта которого и требуется получить пропущенный через весь каскад разношерстных портов нескольких коммутаторов ранее созданный vlan, перевести в trunk придется все вовлеченные в цепочку порты? При этом порты должны пропускать как нетегированный, так и наш тегированный трафик.

Если кратко - то да. Несколько виланов + обычный трафик и всё это в путь. Обычный трафик для обычных клиентов,
а уже тегированный идут по свитчам и/или сквозняком до нужного объекта и там, на последнем свитче делаем тегированному трафику UN-tag на каком-то порту.
Так же обычно между корневыми свитчами гоняют только виланы, а уже на свитчах-доступа эти виланы на портах нужных делают UN-tag.



На работе(ах): 2xCCR1016-12G, RB3011UiAS и hAP lite (RB941)
Дома: CCR1016-12G, RBcAP2n (standalone), RB wAP LTE kit
Для тестов(под рукой): RB3011UiAS, hAP mini (RB931) и что-то ещё по мелочи
MTCNA
MTCRE
Ответить