Switchport trunk native как убрать

Запретить использование native VLAN

Коллеги, доброго времени суток!
Хочу поинтересоваться, можно ли запретить коммутатору использовать native vlan, т.е. настроить его таким образом, чтобы все vlan-ы имели тег? Помнится где-то видел такой вопрос. Поиском в нете нашел пару команд
dot1q native vlan tagging
и
vlan dot1q tag native
К сожалению, в UNL они не поддерживаются, а живого коммутатора для проверки под руками сейчас нет.
Спасибо!

В коммутаторах таких производителей, как Huawei, HP это настраивается посредством

switchport mode hybrid
switchport hybrid allowed vlan [vlan_number] tagged

switchport trunk encapsulation dot1q

switchport trunk native vlan 666

switchport trunk allowed vlan remove 666

switchport mode trunk

Но на IOU L2 не прокатило, на старом 2950 тоже — команд таких не знают.

CAT6509sup2t#sh vlan dot1q tag native
dot1q native vlan tagging is disabled globally

Gi1/46 trunk disabled
Te4/3 trunk disabled
Te4/4 trunk disabled
Gi5/1 trunk disabled
Gi5/3 trunk disabled
Te6/3 trunk disabled
Te6/7 trunk disabled
Po11 trunk disabled
Po24 trunk disabled
Po36 trunk disabled

(config)#vlan dot1q tag native ?

cat3750E#sh vlan dot1q tag native
dot1q native vlan tagging is disabled

На большой железке — пер порт, на маленькой — только глобально.

switchport trunk encapsulation dot1q

switchport trunk native vlan 666

switchport trunk allowed vlan remove 666

switchport mode trunk

Look at the configuration of port F0/1 on switch S1 as a trunk port. The native VLAN is changed to VLAN 99 and the allowed VLAN list is restricted to 10, 20, and 30. If the native VLAN is not allowed on the trunk link, the trunk will not allow any data traffic for the native VLAN.

S1(config)# interface fastethernet0/1
S1(config-if)# switchport mode trunk
S1(config-if)# switchport trunk native vlan 99
S1(config-if)# switchport trunk allowed vlan 10,20,30
S1(config-if)# end

Специально перепроверил это в UNL: создал interface vlan с номером native vlan, но в список разрешенных его не добавил. Пинг с одного коммутатора на другой не проходит.

Сети для самых маленьких. Часть вторая. Коммутация

После скучного рассказа о подключении к кошкам переходим к настройке сети. В этот раз темы будут для новичков сложные, для старичков избитые. Впрочем сетевым аксакалам едва ли удастся почерпнуть что-то новое из этого цикла. Итак, сегодня:
а) аккуратно впитываем теорию о коммутаторах, уровнях сетевой модели, понятии инкапсуляции и заголовков (не пугайтесь — еще не время),
б) собираем спланированную в нулевой части цикла сеть,
в) настраиваем VLAN’ы, разбираемся с access и trunk-портами и тегированными Ethernet-фреймами,
г) соотносим текущие знания со стеком протоколов TCP/IP и моделью OSI (да, наконец-то мы ее коснёмся).

Перед тем, как вы обратитесь к практике, настоятельно рекомендуем почитать нулевую часть, где мы всё спланировали и запротоколировали.

Теория

Для начала необходимо определится с определениями и детерминировать терминологию. В начале пути с этим могут быть трудности, несмотря на горы википедии и прорву технических статей.
Рассмотрим самые общие термины, поскольку что такое коммутатор и маршрутизатор вы, во-первых, представляете, во-вторых, по ходу не раз ещё их затронем. Итак, тронулись:
СКС — структурированная кабельная система — это определение вы в любом яндексе найдёте. На деле это все провода, розетки, патчпанели и патчкорды, то есть грубо говоря, это физика вашей сети в узком смысле, в широком — это совокупность сетей: ЛВС, телефонные сети, системы видеонаблюдения и прочее. Это отдельный очень большой и порой сложный пласт знаний и технологий, который вообще не имеет точек пересечения с настройкой, поэтому к нему мы более обращаться не будем. Привели мы этот термин по большей части для того, чтобы читатель чувствовал отличие от следующего.
ЛВС = Локальная Вычислительная Сеть = LAN = Local Area Network. Актуальность слова “Вычислительная” сейчас можно поставить под сомнение, так же, как в слове ЭВМ. Всё-таки, говоря о современных сетях и устройствах, мы давно уже не держим в уме термин «вычисления», несмотря на то, что глубинная суть осталась неизменной. В этом плане буржуйские термин более универсален и даёт более простое представление о своём значении.
Итак, локальная сеть — в первом приближении — это сеть вашей организации. Вот, к примеру, обслуживаем мы сейчас сеть компании «Лифт ми Ап» с двумя офисам, так вот сети этих двух офисов и будут являться локальной сетью.
При втором приближении, локальной называют сеть, которая находится под управлением одного сетевого администратора. То есть, например, вы отвечаете за районный сегмент сети провайдера, в таком случае ваша районная сеть со всеми подсетями будет являться локальной, в то время, как вышестоящая сеть и сети других районов уже нет, так как за них отвечает уже другие люди. Вообще говоря, это уже MAN — Metropolian Area Network — сеть уровня города. Но в какой-то степени к ней можно применить понятие LAN и уж тем более VLAN.
С точки зрения меня, как абонента этого провайдера, моя локальная сеть — это всё, что до моего домашнего роутера. Интуитивно, наверно, все понимают о чём идёт речь.
Именно с локальными сетями мы и будем иметь дело в ближайших выпусках.

И последнее, что хотелось бы отметить в связи с ЛВС — это IP-адресация.
Все вы знаете, что когда вы включаете какой-нибудь домашний Wi-Fi-роутер в сеть, он обычно выдаёт вам IP-адрес, вроде 192.168.1.x. Почему именно 192.168 в начале?

Дело в том, что все IP адреса делятся на приватные (private, он же внутренний, “серый”, локальный), и публичные. Публичные используются в интернет, каждый адрес уникален, их распределение контролирует организация IANA(Internet Assigned Numbers Authority).

Приватные используются для адресации хостов (ну, строго говоря, не хостов, а интерфейсов) внутри ЛВС, их распределение никто не контролирует. Для них выделили три диапазона адресов (по одному из каждого класса):

10.0.0.0 — 10.255.255.255
172.16.0.0 — 172.31.255.255
192.168.0.0 — 192.168.255.255

Это те адреса, которые вы можете использовать в своей частной сети. Они вполне могут повторяться (и повторяются) в разных локальных сетях, и за её пределы они не выходят. Приватный адрес на то и приватный, поэтому любой пакет с адресом из диапазонов, указанных выше, попавший к провайдеру, будет отбрасываться.

Если вернуться к нашей старой схеме то вы увидите, что для своей сети мы выбрали приватные адреса из диапазона 172.16.0.0 — 172.31.255.255.
Достаточно подробно об IP-адресах можно почитать тут и тут.
У всех провайдеров и во внутренней сети любой крупной организации используются именно эти серые подсети. Если только вы не государственный ВУЗ, которому в своё время выпала сеть на несколько тысяч публичных адресов: Кемеровский Государственный Университет, к примеру, не озадачивается NAT’ом и прочей чепухой — просто на все компьютеры университетской сети раздаются белые IP.

Широковещательный домен — область сети, в которой происходит обмен широковещательными сообщениями, и устройства могут отправлять друг другу сообщения непосредственно, без участия маршрутизатора.
О чём это мы тут говорим? Ну, например, послал ваш компьютер широковещательный запрос в сеть в поисках DHCP-сервера. Фрейм этот (он же кадр) адресован всем устройствам и имеет MAC-адрес получателя FF:FF:FF:FF:FF:FF. Сначала он попадает на коммутатор, с которого его копии рассылаются на все порты. Потом часть попадает на другие компьютеры, часть уходят в соседние коммутаторы, кто-то доходит до маршрутизатора, а одну копию принимает-таки DHCP-сервер. И вот участок сети, внутри которого могут жить эти кадры и называется широковещательным доменом. А кончают свою жизнь они на конечных хостах (компьютеры, серверы) или на маршрутизаторах, которые их отбрасывают, если они им не предназначены:

Если же на коммутаторе заведены VLAN’ы, то они также разделяют широковещательные домены, потому что пакет между ними обязательно должен проходить через маршрутизатор, который отбросит широковещательные сообщения. Таким образом, один VLAN — это один широковещательный домен.

Ещё раз: у нас есть три способа разграничить широковещательные домены:
1) Поставить маршрутизатор и разнести хосты в разные подсети,
2) Разделить сеть VLAN’ами,
3) Порвать кабель.

Ну и самая жесть, которой часто сторонятся начинающие: OSI. Open System Interconnection. Вообще в двух словах, чтобы мозг не захламить за одно занятие. Эту модель называют эталонной, потому что в реальном мире дело не дошло до реализации. Но она само совершенство, поэтому инженеры и админы вворачивают это слово повсюду.
В основе лежат 7 китов сетевой иерархии: 7 уровней. Сегодня коснёмся двух нижних: первый — физический — это представление информации в виде сигналов, прямо скажем, битов. Задача этого уровня сгенерировать электрический, оптический или радиосигнал, передать его в среду и принять его. К нему относится вся физика: интерфейсы, кабели, антенны, медиаконвертеры (конвертеры среды), репитеры, старые хабы. В общем низкоуровневая это работа. Это первый уровень модели OSI и стека TCP/IP.
Второй — канальный. На этом уровне работают коммутаторы. Идентификатор устройства здесь, это MAC-адрес. У каждого узла (компьютер, маршрутизатор, ноутбук, IP-телефон, любой Wi-Fi-клиент) есть этот уникальный адрес, который однозначно определяет устройство в локальной сети. В теории MAC-адреса не должны повторяться вообще, но на практике такое однако случается и в рамках одного широковещательного домена может приводить к сложноотлавливаемым проблемам.
Наиболее известным протоколом этого уровня является Ethernet. Данные на этом уровне передаются кусками, каждый из которых называется Ethernet-фрейм (он же Ethernet-кадр, он же PDU канального уровня). Что он представляет из себя?

Payload — это полезная нагрузка — данные сетевого уровня, которые вкладываются (инкапсулируются) в кадр. MAC Header (Заголовок) — это служебная информация канального (второго) уровня. Самые важные пока для нас элементы — это source MAC-address (адрес отправителя кадра) и Destination MAC-address (адрес получателя кадра).

Третий уровень — сетевой (IP, ARP)
Четвёртый — транспортный (TCP, UDP, ICMP)
С пятого по седьмой — сеансовый, представления и прикладной (в стеке TCP/IP они не различаются и называются просто прикладным. На нём работают протоколы вроде HTTP, FTP, telnet и многие другие)

Сегодня мы акцентируемся на 1-м и 2-м уровнях, особенно на втором. Третьего и четвертого коснёмся в следующих выпусках.

Теперь проследим нелёгкий путь кадра.
Состояние покоя сети — утопия.

Вы пытаетесь пропинговать, например, адрес соседнего компьютера командой ping 192.168.1.118. Данные этого приложения показаны фиолетовым параллелепипедом.

За это отвечает протокол ICMP. В него инкапсулируется информация от приложения — это означает, что к данным 5-го уровня добавляется заголовок со служебной информацией 4-го уровня.

Его данные упаковываются (инкапсулируются) в IP-пакеты, где в заголовке указан IP-адрес получателя (192.168.1.118) и IP-адрес отправителя — логические адреса.

А затем всё это инкапсулируется в Ethernet-кадры с MAC-адресами отправителя и получателя — физическими адресами.

При формировании кадров в заголовке в качестве MAC-адреса источника (source) подставляется адрес вашего компьютера, а адресом получателя (destinantion) будет MAC-адрес компьютера — владельца IP-адреса 192.168.1.118 (о механизмах такого преобразования поговорим в следующий раз). То есть если бы вы смогли сфотографировать кадр, то вы бы увидели все эти данные в разрезе, так сказать.

На самом деле, нет ничего проще: запускаете какой-нибудь анализатор трафика, например, замечательный Wireshark и Ethereal, на своём компьютере и пингуете другой хост. Вот такую картину вы сможете лицезреть:

Вы это можете сделать прямо сейчас, читая эти строки, просто установив и запустив анализатор трафика.

В последнюю очередь сетевая карта вашего компьютера дробит фрейм на биты и отправляет их в кабель.

Коммутатор из поступивших битов собирает первоначальный кадр

Далее начинается интеллектуальный труд: из заголовка извлекается адрес получателя, перетрясается таблица MAC-адресов на предмет совпадения и, как только оное найдено, кадр без изменений отправляется в указанный порт. Если же адреса пока ещё нет или кадр пришёл широковещательный, то он направляется на все порты, кроме того, откуда пришёл.

Если адреса отправителя в таблице до сих пор не было, то в этот момент коммутатор добавит его.
Естественно, кадр опять передаётся в виде битов — это закон электроники, и вы должны просто всегда иметь это в виду.

Конечный хост, получив поток битов, собирает из них кадр, ещё только предполагая, что он предназначается ему.

Далее он сравнивает MAC-адрес получателя со своим и, если они совпадают, то заголовок второго уровня отбрасывается, а IP-данные передаются на обработку вышестоящему протоколу. Если адреса не совпадают, то кадр отбрасывается вместе со всем содержимым.

Далее сравниваются IP-адрес получателя и этого устройства. Если совпадают, то заголовок сетевого уровня отбрасывается, и данные передаются транспортному уровню (ICMP)

Конечный хост обработал ICMP-запрос (echo-request) и готов послать ICMP-ответ (echo-reply) вашему компьютеру с адресом 192.168.1.131 и далее пункты 1-3 повторяются уже для нового кадра

То, о чём мы писали до сих пор — это принцип работы любого коммутатора. Так делают даже простые длинки за 300 рублей.

Ну а теперь, давайте, коллеги, финальный рывок: добавим сюда ещё VLAN’ы.

С ними работают уже только управляемые коммутаторы.
Напомним, что вланы нужны для разделения сетей. Соответственно появляется некий идентификатор, которым маркируется трафик разных подсетей на коммутаторе.
Говоря о VLAN’ах, часто используют заклинание 802.1q. Это и есть стандарт, описывающий как именно кадр маркируется/тегируется. Пугаться такого шифра не стоит. Так же, например, Wi-Fi описывается стандартом 802.11n, а протокол аутентификации — 802.1x. Нам с этим предстоит столкнуться в будущем, поэтому отложите это в своей энергонезависимой памяти.

Что же именно происходит на кухне коммутации?
Внутрь фрейма после Source MAC-адреса добавляется ещё одно поле, очень грубо говоря, содержащее номер VLAN’а. Длина, выделенная для номера влана равна 12 битам, это означает, что максимальное число вланов 4096. Мы хотим обратить внимание молодых инженеров на такие подробности. Дело в том, что мы в своём цикле в силу объективных причин, не можем обо всём рассказать, но такие вопросы, во-первых, часто задают на собеседованиях, во-вторых, это просто надо знать.

Кадры первого влана обычно не тегируются — он является родным вланом (native vlan).

Каждый коммутатор принимает теперь решение на основе этой метки-тега (или его отсутствия).
В таблицу МАС-адресов добавляется ещё столбец с номером VLAN’а и при поиске пары MAC-адрес/порт теперь будет сравниваться тег кадра с номером VLAN’а в таблице.

Существует два типа портов:
1. Access port — порт доступа — к нему подключаются, как правило, конечные узлы. Трафик между этим портом и устройством нетегированный. За каждым access-портом закреплён определённый VLAN, иногда этот параметр называют PVID. Весь трафик, приходящий на этот порт от конечного устройства, получает метку этого влана, а исходящий уходит без метки.

2. Trunk port. У этого порта два основных применения — линия между двумя коммутаторами или от коммутатора к маршрутизатору. Внутри такой линии, называемой в народе, что логично, транком, передаётся трафик нескольких вланов. Разумеется, тут трафик уже идёт с тегами, чтобы принимающая сторона могла отличить кадр, который идёт в бухгалтерию, от кадра, предназначенного для ИТ-отдела. За транковым портом закрепляется целый диапазон вланов.
Кроме того, существует вышеупомянутый native vlan. Трафик этого влана не тегируется даже в транке, по умолчанию это 1-й влан и по умолчанию он разрешён. Вы можете переопределить эти параметры.
Нужен он для совместимости с устройствами, незнакомыми с инкапсуляцией 802.1q. Например, вам нужно через Wi-Fi мост передать 3 влана, и один из них является вланом управления. Если Wi-Fi-модули не понимают стандарт 802.1q, то управлять ими вы сможете, только если этот влан настроите, как native vlan с обеих сторон.

Что происходит в сети с вланами?

1) Итак, от вашего компьютера с IP-адресом, например, 192.168.1.131 отправляется пакет другому компьютеру в вашей же сети. Этот пакет инкапсулируется в кадр, и пока никто ничего не знает о вланах, поэтому кадр уходит, как есть, на ближайший коммутатор.
2) На коммутаторе этот порт отмечен, как член, например, 2-го VLAN’а командой

Это означает, что любой кадр, пришедший на этот интерфейс, автоматический тегируется: на него вешается ленточка с номером VLAN’а. В данном случае с номером 2.
Далее коммутатор ищет в своей таблице MAC-адресов среди портов, принадлежащих 2-му влану, порт, к которому подключено устройство с MAC-адресом получателя.
3) Если получатель подключен к такому же access-порту, то ленточка с кадра отвязывается, и кадр отправляется в этот самый порт таким, каким он был изначально. То есть получателю также нет необходимости знать о существовании вланов.
4) Если же искомый порт, является транковым, то ленточка на нём остаётся.

Попробуем провести аналогию с реальными миром. Вы с другом, например, пакеты-туристы и летите отдыхать дикарями самолётом авиалиний Ethernet Airlines. Но по дороге вы поссорились, и потому, когда в аэропорту назначения, вас спрашивают в какую гостиницу вас везти, вы отвечаете “Рога”, а ваш товарищ говорит “Копыта”. И сразу после этого вас инкапсулируют в разные кадры-машины: вас в такси с тегом “Таксопарк “На рогах”, а вашего товарища с его грузом в КамАЗ с тегом “Транспортная компания “В копыто”. Теперь вам нельзя на автобусные полосы, а вашему другу под знаки, запрещающие проезд грузовиков.
Так вот две гостиницы — это МАС-адреса назначения, а ограничения по маршруту — порты других вланов.
Петляя, по улочкам, вам, как IP-пакету не о чем беспокоиться — кадр-автомобиль доставит вас до места назначения, и, грубо говоря, в зависимости от тега на каждом перекрёстке будет приниматься решение, как ехать дальше.

Q: Что произойдёт, если тегированный кадр прилетит на access-порт?
A: Он будет отброшен.

Q: Что произойдёт, если нетегированный кадр прилетит на trunk-порт?
A: Он будет помещён в Native VLAN. По умолчанию им является 1-й VLAN. Но вы можете поменять его командой switchport trunk native vlan 2
В этом случае все кадры, помеченные 2-м вланом будут уходить в этот порт нетегироваными, а нетегированные кадры, приходящий на этот интерфейс, помечаться 2-м вланом.
Кадры с тегами других вланов останутся неизменными, проходя, через такой порт.

Q: Можно ли конечным узлам (компьютерам, ноутбукам, планшетам, телефонам) отправлять тегированные кадры и соответственно подключать их к транковым портам?
A: Да, можно. Если сетевая карта и программное обеспечение поддерживает стандарт 802.1q, то узел может работать с тегированными кадрами.

Q: Что будет с тегированными кадрами, если они попадут на обычный неуправляемый коммутатор или другое устройство, не понимающее стандарт 802.1q?
A: Поскольку при добавлении тега заголовок кадра не меняется, то все устройства второго уровня без поддержки этого стандарта вполне справляются с коммутацией такого кадра. Поэтому, если например, вы захотите организовать канал через Wi-Fi мост, то это никак не помешает вам пробросить через него несколько вланов в транке.

Практика. Настройка сети “Лифт ми Ап”

Ну и наконец-то обратимся к настройке. Вива ля практис!

Будет у нас такая сеть:

Мы могли бы сейчас броситься сразу настраивать всё по порядку: полностью одно устройство, потом другое. Но так не будет, пожалуй, понимания значения процессов.

Порты доступа (access)

Поэтому начнём с простого: настроим два порта на msk-arbat-asw3 как access для влана 101 (ПТО):

Все настройки делаем сразу в соответствии с планом.

Заметили, что коммутатор ругается на отсутствие влана? Тут надо быть аккуратным. Некоторые версии ПО работают несколько нелогично.
Даже если вы его не создадите, то настройки применятся и при отладке на первый взгляд всё будет нормально, но связи не будет. Причём коварство заключается в том, что фраза Creating vlan 101 вовсе не означает, что этот самый влан будет создан. Поэтому отправляемся в режим глобальной конфигурации и создаём его (а заодно и все другие вланы, нужные на этом коммутаторе):

Теперь подключите компьютеры к портам FE0/1 и FE0/2, настройте на них адреса 172.16.3.2 и 172.16.3.3 с маской подсети 255.255.255.0 и шлюзом 172.16.3.1 и проверьте связь:

После того, как это получилось, настроим порт FE0/16, как access, для 104-го влана (сеть других пользователей):

Подключите к нему компьютер и настройте адрес из той же подсети, что ПТО, например, 172.16.3.5 с маской 255.255.255.0.
Если вы попытаетесь теперь пропинговать этот адрес, то у вас не должно этого получиться — компьютеры находятся в разных вланах и изолированы друг от друга:

То есть ещё раз, что происходит? От вашего компьютера приходит на 1-й порт широковещательный запрос: “Кто такой 172.16.3.5”, потому что сам компьютер пока не знает MAC-адреса получателя. Кадр, который несёт в себе этот запрос помечается, как принадлежащий 101-му VLAN’у в соответствии с портом, на который он поступил. И далее, чтобы узнать где-же находится компьютер 172.16.3.5, кадр рассылается на все порты-члены 101-го VLAN’а. А в их числе нет порта FE0/16, поэтому, естественно, этот адрес считается недостижимым, что приводит к ответу “Request timed out”.

Внимание! Если в этом VLAN’е все-таки окажется устройство с таким IP, то это не будет тем же самым ноутбуком Other и при этом они не буду конфликтовать друг с другом, поскольку логически находятся в разных широковещательных доменах.

Транковые порты (trunk)

Итак, врата для вас открылись, теперь вам предстоит создать коридор — транк между тремя коммутаторами: msk-arbat-asw3, msk-arbat-dsw1 и msk-rubl-asw1.

Uplink портом на msk-arbat-asw3 является GE1/1. Ну а поскольку нам всё равно все вланы нужно будет пробросить, то сделаем это сейчас, то есть помимо 101 и 104 пропишем 2, 102 и 103:

На самом деле на интерфейсе достаточно команды #switchport mode trunk, чтобы у вас через этот порт уже пошли тегированные кадры всех вланов, потому что по умолчанию транковый порт пропускает всё. Но мы же инженеры, а не эникейщики. Где это видано, чтобы безлимит творился за нашей спиной? Поэтому через нас проходит только то, что мы разрешаем. Как только вы дали команду switchport trunk allowed vlan 101, через порт не пройдёт кадр никаких вланов, кроме 101 (VLAN 1 ходит по умолчанию и нетегированным).

Внимание! Если вы хотите в транковый порт добавить ещё один влан, то вам необходимо использовать следующий синтаксис команды:

В противном случае (написав switchport trunk allowed vlan 105) вы сотрёте все старые разрешения и добавите новый 105-й влан. И хорошо ещё, если при этом вы не потеряете доступ на этот коммутататор. Но за простой связи всё равно вы получите по пятое число)

Переходим к msk-arbat-dsw1. На нём необходимо создать все вланы и настроить два порта:
GE1/2 в сторону msk-arbat-asw3
FE0/1 в сторону msk-rubl-asw1:

Ну и настроим, конечно, порты на msk-rubl-asw1:

Снова нужно настроить вланы. И заметьте, при настройке транковых портов никаких сообщений нет.

Если вы всё настроили правильно (в чём не приходится сомневаться), то с первого порта msk-rubl-asw1 вы увидите компьютеры ПТО, подключённые к msk-arbat-asw3.

Для уверенности проверим ещё и 104-й влан. Через транк мы его сюда уже доставили.

Подключаем компьютер к 16-му порт и настраиваем на нём IP-адрес 172.16.6.3 с маской 255.255.255.0 и шлюзом 172.16.6.1. А IP-адрес ноутбука на арбате поменяйте на 172.16.6.2 с теми же маской и шлюзом.

Сеть управления

Настроим IP-адрес для управления.
В наших лабах они не понадобятся, потому что мы настраиваем устройство через окно РТ. А вот в реальной жизни это вам жизненно необходимо.
Для этого мы создаём виртуальный интерфейс и указываем номер интересующего нас влана. А далее работаем с ним, как с самым обычным физическим интерфейсом.

msk-arbat-dsw1:

msk-arbat-asw3:

С msk-arbat-asw3 запускаем пинг до msk-arbat-dsw1:

Первые пару пакетов могут потеряться на работу протокола ARP: определение соответствия IP-адрес — MAC-адрес. При этом MAC-адрес, порт и номер влана добавляются в таблицу коммутатора.
Самостоятельно настройте IP-адреса сети управления на остальных коммутаторах и проверьте их доступность

Собственно вот и вся магия. Зачастую к подобного рода действиям и сводится вся настройка, если вы не работаете в провайдере. С другой стороны, если вы работаете в провайдере, то, наверняка, такие вещи вам объяснять не нужно.
Если желаете знать больше об этом, читайте: VTP, QinQ, зарезервированные номера VLAN

Ещё один небольшой инструмент, который может немного увеличить удобство работы: banner. Это объявление, которое циска покажет перед авторизацией на устройство.

После motd вы указываете символ, который будет служить сигналом о том, что строка закончена. В это примере мы поставили “q”.

Для упорядочивания знаний по пунктам разберём, что вам необходимо сделать:

1) Настроить hostname. Это поможет вам в будущем на реальной сети быстро сориентироваться, где вы находитесь.

2) Создать все вланы и дать им название

3) Настроить все access-порты и задать им имя

Удобно иногда бывает настраивать интерфейсы пачками:

4) Настроить все транковые порты и задать им имя:

5) Не забывайте сохраняться:

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

Здесь вы можете скачать конфигурацию всех устройств:
Lift-me-Up_Configuration.zip
И наш проект РТ:
Lift-me-UP_v2-VLANs.pkt

P.S.
Важное дополнение: в предыдущей части, говоря о native vlan мы вас немного дезинформировали. На оборудовании cisco такая схема работы невозможна.
Напомним, что нами предлагалось передавать на коммутатор msk-rubl-asw1 нетегированными кадры 101-го влана и принимать их там в первый.
Дело в том, что, как мы уже упомянули выше, с точки зрения cisco с обеих сторон на коммутаторах должен быть настроен одинаковый номер влана, иначе начинаются проблемы с протоколом STP и в логах можно увидеть предупреждения о неверной настройке. Поэтому 101-й влан мы передаём на устройство обычным образом, кадры будут тегированными и соответственно, 101-й влан тоже необходимо создавать на msk-rubl-asw1.

Ещё раз хотим заметить, что при всём желании мы не сможем охватить все нюансы и тонкости, поэтому и не ставим перед собой такой задачи. Такие вещи, как принцип построения MAC-адреса, значения поля Ether Type или для чего нужен CRC в конце кадра, вам предстоит изучить самостоятельно.

Спасибо соавтору этого цикла, хабравчанину thegluck.
За предоставление дополнительных материалов хочу поблагодарить Наташу Самойленко

Читатели, не имеющие учётки на хабре, но имеющие вопросы, как и прежде, могут концентрировать их в ЖЖ.

Native VLAN

Все слышали краем уха про Native VLAN (далее NV), расскажу подробнее что это такое (на примере CISCO). Те кто знает про NV «от и до» — вам жму руку и обязуюсь выложить что-то интересненькое и для вас.

Что известно о Native VLAN?

В переводе с английского native — родной, естественный, встроенный:

• Это понятие привязано к транковому каналу передачи данных и без него не используется;
• Если взять коммутатор CISCO «из коробки», то на нём присутствует только одна VLAN — VLAN1 (всякая устаревшая экзотика типа VLANs 1002 — 1005 не в счёт), в этой же VLAN1 изначально находятся все порты;

• Далее, если настроить на коммутаторе ещё несколько VLANs и настроить транковые порты, то для всех транковых портов по умолчанию будет NV=VLAN1:

• На одном коммутаторе у разных транковых портов может быть разная NV. Это нормально и часто используется. Меняется NV для танкового порта командой:

• Любой кадр без тега, поступивший из транка на коммутатор, пересылается в NV;
• Для любого транкового порта VLAN без тега всегда одна;

Дополнительно: любой порт в режиме доступа принадлежит только одной VLAN. Тут есть исключение: Asymmetric VLAN. Эту технологию использует D-Link. Вещь специфическая, область применения — SOHO. Кто хочет сломать мозги, подробнее тут. Ради справедливости надо сказать, что CISCO тоже применяет понятие Asymmetric VLAN для коммутаторов. Только используется совсем в другом контексте. Подробный гайдлайн легко ищется через поисковик.

• NV с обоих сторон транка, то есть на разных коммутаторах, должна быть одинаковой, иначе в консоль выдаётся предупреждающее сообщение;

Почему одинаковой? Любой кадр без тега, поступивший из транка на коммутатор, пересылается в NV. Допустим 2 коммутатора S1 и S2, у S1 NV=VLAN1, у S2 NV=VLAN10. Тогда кадры из VLAN1 с коммутатора S1 будут попадать во VLAN10 на S2 и наоборот. Это ошибка в конфигурации и нарушение безопасности.

• Кадры, пересылаемые через транк для NV не тегируются;

Это можно изменить глобальной настройкой. Пользоваться этой настройкой крайне не рекомендуется. Да и честно даже не знаю в каком случае это может пригодиться. Возможно разве при траблшутинге подключения коммутатора CISCO к какому-то специфическому оборудованию.

• Если транковый порт получает тегированный кадр с таким же идентификатором как у NV, то он отбрасывает кадр;

Тут возникает вопрос: а как тогда вообще возможна атака с двойным тегированием? О чём я говорю и какие тут трудности, разбираю далее.

Для чего же была придумана Native VLAN?

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

• Отбросить такой трафик;
• Обработать такой трафик

Чтобы была возможность обрабатывать трафик без тега, поступающий из транкового канала и отсылать в транк трафик без тега, была придумана Native VLAN:

Отсюда интересное явление: со стороны коммутатора транковый порт, к нему подключен PC. Трафик будет ходить? Будет:

• Приходит нетегированный (естественно) трафик от PC, коммутатор отправляет этот трафик в NV;
• Приходят данные со стороны коммутатора на порт для NV, данные будут переданы без тега и PC сможет их обработать.

На этом построено подключение компьютера через IP-телефон. К телефону от коммутатора прокинут транк с двумя VLANs, допустим, NV=VLAN3 и ещё VLAN5. Тогда телефон работает через VLAN5 с тегом, а PC через VLAN3 без тега (подробнее: //ciscomaster.ru/node/89 ).

Вот собственно и всё про данное понятие. Далее будут уже более специфичные особенности NV.

Несовпадение NV на концах транка

Что говорит по этому поводу сама CISCO:

Проверим эту ситуацию. Накидал лабу в EVE-NG:

Задал всем трём VPC адресацию 192.168.1.0/24. По идее если транк работоспособен, VPC1 должен пинговать VPC3, так как они в одной VLAN10. И VPC1 должен пинговать VPC2 через NV.

Проверяем: VPC1 пингует VPC2. Проверяем дальше: VPC1 не пингует VPC3. Немного подумав становится понятно, что при пинге VPC3, VPC1 отправит пакеты ARP и кадры содержащие эти пакты будут переданы без тега в транке, а кадры без тега на S2 перенаправляются в NV, то есть в VLAN20. И VPC2 эти ARP увидит, а VPC3 соответственно нет.

Что касается STP, попробовал все три режима MST, PVST+, Rapid PVST+ и каждый раз порты Gi0/0 были в режиме передачи (FWD) для всех VLANs.

Итого: при несовпадении NV транк работает, некорректно но работает. Вот такое расхождение с теорией. Хотя надо учитывать что пробовалось всё не на реальном железе, а на эмуляторе и возможно зависит от версии IOS.

NV на роутере

А может присутствовать NV на роутере? Конечно. Используется это в не очень хорошей схеме Router-on-a-Stick (роутер на палочке).

Схемы применения Router-on-a-Stick

Типовая, в этой схеме роутер связан с коммутатором транковым каналом, на роутере заводятся сабинтерфейсы (sub-interface) или есть русское слово подынтерфейс, но мне оно не нравится. Итак, один сабинтерфейс для одной VLAN. На каждом сабинтерфейсе настраивается IP адрес. Этот адрес используется как шлюз по умолчанию для данной VLAN. Таким образом достигается маршрутизация между VLANs посредством роутера. Недостатки такого метода:

• Слабая масштабируемость — максимум 50 VLANs для такого метода;
• При маршрутизации пакет проходит 2 раза по транковому каналу: первый раз от коммутатора к роутеру в составе кадра для исходной VLAN и второй раз от роутера к коммутатору в составе кадра для VLAN назначения. Таким образом, этот линк потенциальное узкое место при интенсивном трафике между VLANs.

А если данный линк 100 мегабитный, то это просто мрак. CISCO рекомендует настраивать маршрутизацию между VLANs на коммутаторе 3 уровня. В продакшене перевод схемы Router-on-a-Stick со 100Mbit линком в схему маршрутизации на коммутаторе, давал сокращение времени архивации сервера на сервер в другой VLAN в 3 с лишним раза.

Для VRF, когда между двумя роутерами один интерфейс и его надо поделить на несколько VRF, чтобы форвардить через каждый VRF свои VLANs. Это не совсем Router-on-a-Stick в привычном понимании, но принцип тот же (для R1 из рисунка):

Экзотические, в интернете наткнулся на интересную схему Router-on-a-Stick. Можно так сделать? Можно, работать будет. А нужно? Нет, не нужно. У меня даже больше вопросы не по безопасности, хотя данная схема полностью противоречит архитектуре иерархической сети, а то что оба провайдера висят на одном линке. Логичнее было бы каждого провайдера подключить к отдельному интерфейсу роутера напрямую и тогда Router-on-a-Stick просто становится не нужен.

Когда такую схему подключения полезно было бы задействовать? В ситуации когда у ротера остался только 1 рабочий порт, нет другого роутера и нет модулей расширения HWIC. Как временное решение.

Настройка NV на роутере

Возвращаемся к настройке Router-on-a-Stick, создаём логические сабинтерфейсы на роутере для примера выше, когда на коммутаторе настраивались VLANs 10,11,12:

Сабинтерфейсы включать не надо. Они будут включены автоматически, когда включён GigabitEthernet0/0. Теперь смотрим информацию о VLANs:

По умолчанию NV всё та же VLAN1. Теперь сменим её:

Снова смотрим информацию о VLANs:

Что делать если роутер не CISCO?

Если устройство не CISCO и у него нет возможности явной настройки NV на сабинтерфейсе, то NV нужно размещать на основном интерфейсе.

Пример. На коммутаторе NV=VLAN1, на роутере сабинтерфейс для VLAN1 не создаём. Почему? Если его создать, то трафик со стороны роутера будет тегироваться, коммутатор откинет тегированный трафик для NV. То есть IP адрес для NV (VLAN1) должен висеть на самом interface GigabitEthernet 0/0 роутера для примера сверху. Немного странная схема, но она работает.

Проверено на Dionis NX, ASA 55X0 (ASA хоть и CISCO, но не роутер и многое тут по-другому).

Немного о теге

Для того чтобы прикладывать тег, размер кадра пришлось увеличивать на 4 байта. Размер нетегированного кадра от 64 до 1518 байт, тегированного от 68 до 1522.

• TPID — устанавливается значение 0x8100 для идентификации кадра в качестве кадра с разметкой IEEE 802.1Q;
• Priority — поле указывается уровень приоритетности кадра, который можно использовать для приоритизации трафика. Полем может задаваться 8 уровней (от 0 до 7);
• CFI — раньше был CFI, для отличия кадра FDDI, Token Ring от кадра Etnernet. Поскольку давно никаких FDDI нет, а поле пропадает, то оно было перепрофилировано в DEI. DEI указывает может ли кадр быть отброшен в случае затора на интерфейсе;
• VID — уникальным образом идентифицирует VLAN, которой принадлежит кадр. В этом поле могут содержаться значения от 0 до 4095.

Процесс тегирования

У меня с коллегой по работе один раз вышел спор: внутри коммутатора кадр перемещается с тегом или без? Однозначного ответа тут нет. Постараюсь пояснить почему.

Нет единого стандарта как делать коммутаторы. Логика работы и начинка коммутатора различается от вендора к вендору. Вспомнить хотя бы D-Link и его Asymmetric VLAN.

Стандартом является только транк 802.1Q: внутри транка кадры передаются с тегом, кроме кадров NV. Это обеспечивает совместимость между коммутаторами разных вендоров.

Если брать коммутаторы CISCO, то по приходу кадра на порт коммутатора, управляющий портом ASIC (Application Specific Integrated Circuit) навесит на кадр дополнительный служебный заголовок. Этот заголовок называется shim header и существует только внутри коммутатора. В этом заголовке точно есть информация о VLAN, так коммутатор различает кадры из разных VLANs.

А что насчёт тега 802.1Q? Если размышлять в рамках CCNA R&S, то:

Поэтому обобщённо-упрощённая рабочая версия процесса тегирования при отсутствии CoS и сабинтерфейсов такая:

• Кадр приходит на порт доступа коммутатора, поверх к нему цепляется служебный заголовок, определяющий в том числе к какой VLAN кадр принадлежит;
• Затем кадр попадает на транковый порт для передачи, внутрь его заголовка L2 помещается тег 802.1Q, а служебный заголовок снимается;
• По приходу кадра на транковый порт принимающего коммутатора тег 802.1Q отрывается и снова навешивается служебный заголовок.

Если же используется CoS (маркировка трафика на втором уровне, при этом инфа записывается в поле Pri, соотвественно без тега не обойтись) или сабинтерфейсы то, тег 802.1Q вставляется в заголовок уже по приходу кадра на порт доступа.

Если я не прав — поправьте, вопрос открытый.

Рекомендации CISCO

Что рекомендует CISCO:

• Менять NV с дефолтного VLAN1;
• Не использовать NV для передачи пользовательского трафика.

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

Суть этой атаки, как объясняет сама CISCO:

Допустим у нас для транков NV = VLAN10. И эта же VLAN10 используется для пользовательских компьютеров. А VLAN20 используется для серверов.

• С помощью специального софта зловред отправляет кадр с двумя тегами:

• Первый (внешний) тег для VLAN10, второй (внутренний) тег для VLAN20;
• Когда кадр придёт на коммутатор он срежет внешний тег. Наличие других тегов коммутатор не проверяет;
• После этого коммутатор разошлёт кадр через VLAN10, так кадр попадёт на транк между коммутаторами;
• Поскольку NV = VLAN10, то при отправке кадра через транк коммутатор не будет навешивать новый тег;
• Кадр поступает на второй коммутатор, там тег для VLAN20 срезается и кадр рассылается через VLAN20.

Всё вроде бы хорошо, но есть несостыковки с теорией. Как исходный кадр попадает на первый коммутатор? Что это за порт?

• Если зловред использует порт доступа во VLAN10, то тегированный кадр должен быть отброшен коммутатором на порту доступа. Какая такая особая ситуация, чтобы кадр был обработан, мне неизвестно;
• Вторая ситуация, когда компьютер подключен через телефон, тогда у нас транковый порт с NV = VLAN10. То есть кадр отправляется с внешним тегом для NV. Такой кадр тоже должен быть отброшен.

Как-нибудь соберу лабу и поразбираюсь, пока только вопросы без ответов.

Кроме этого есть специальная технология двойного тегирования Q-in-Q (или dot1q tunneling ). С ней работать не приходилось, поэтому подробнее не расскажу. Но надо знать что двойной тег в общем-то возможен, хотя конечно зависит от реализации вендором.

Когда удобно менять Native VLAN?

Хоть NV и не рекомендуется использовать для пользовательского трафика, иногда это бывает весьма удобно.

Пример. Коллега из серверного отдела попросил меня настроить коммутатор. На коммутаторе будут только севера. Все сервера находятся в серверной VLAN. Однако неизвестно в какие порты будут подключены серверы виртуализации. Подключать будет сотрудник первой линии, максимум чего можно ждать, что он привинтит коммутатор, подаст питание, подключит патч-корды. A нужно чтобы 100% всё заработало сразу.

Делаем все «пользовательские» порты коммутатора транками. В качестве NV выбираем серверную VLAN:

• Обычные сервера с акцесными портами нормально заработают (описано выше почему);
• У серверов виртуализации настроен транк. Сам сервер виртуализации будет работать через NV транка без тега, а его виртуальные машины из разных VLANs через транк с тегом. Профит.

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

Проблема из продакшена

Чтобы не ограничиваться сухой теорий, небольшой пример из продакшена. Он заставил меня поломать голову. Пример лишь косвенно связан с Native VLAN. С другой стороны роскошь, что хоть такой пример удалось подобрать.

Итак, есть 10 коммутаторов CISCO, 4 коммутатора Qtech и 1 D-Link, подключённых по топологии звезда. «Звезда смерти»: если посмотреть Иерархическую модель сети CISCO, то никакой звезды в продакшене быть не должно.

У каждого периферийного свича 1 транк до центрального CISCO 3750X. Конфигурации однотипные, центральный свич настроен корневым мостом STP. На CISCO используется Rapid PVST+ (1 дерево RSTP на каждую VLAN), на остальных RSTP (1 дерево RSTP на все VLANs).

При этом 4 периферийных Qtech также считают себя корневыми. Поскольку топология звезда, то для возникновения петли надо очень постараться и долгое время всё это так работало.

Самым правильным было бы изменить для всех коммутаторов протокол на MSTP. Но с другой стороны Rapid PVST+ и RSTP совместимы? Совместимы. Значит должно работать.

Разбираемся

Настройка приоритета STP и другие потуги именно с STP ничего не дают. Перекидываем аплинки к центральному коммутатору между одним из проблемных Qtech и нормально работающим D-Link, Qtech начинает «видеть» в разрезе STP корневой свич, D-Link перестаёт. Поэтому проблема, очевидно, не в марке Qtech.

Дальнейшее изучение показывает: проблемные свичи Qtech/D-Link не получают кадров BPDU. Далее обнаруживается, что для всех транков со стороны центрального свича не разрешена явным образом VLAN1. Она же является NV для всех транков. Добавление VLAN1 в список разрешённых сразу решает проблему.

При этом для периферийных коммутаторов CISCO никакой проблемы не было и нет.

Логика человека настраивавшего коммутаторы понятна. Нарезали VLANs, перевели туда все порты, во VLAN1 портов нет? Нет. Стало быть, зачем её разрешать на транке?

Постановка вопроса

Теперь нужно выяснить для D-Link и Qtech:

• Проблема в Native VLAN и Native VLAN должна быть разрешена в явном виде;
• Проблема во VLAN1 и VLAN1 должна быть разрешёна в явном виде.

Проверка №1

Всё нормально, Root Port, Root Bridge. Убираем на центральном коммутаторе для транка на D-Link VLAN1 из списка разрешённых и ждём 20 секунд:

Коммутатор D-Link считает себя корневым.

Проверка №2

Теперь повторяем всё тоже самое с Qtech. Сначала VLAN1 разрешена в явном виде:

Всё гуд. Точно так же убираем на центральном свиче с транка на Qtech VLAN1 из разрешенных:

Количество полученных BPDU не меняется с этого момента. И коммутатор Qtech, рассчитав STP, считает себя корневым. Проблема актуальна.

Проверка №3

Теперь создаём VLAN 99, меняем NV с 1 на 99 с обоих сторон транка, удаляем VLAN 99 из разрешённых, а VLAN 1 наоборот добавляем в разрешённые и ещё раз проверяем. Если ситуация повторится, то данные STP для D-Link/Qtech привязаны к Native VLAN, нет — привязаны к VLAN 1.

Моя ставка была на Native VLAN, так как именно через неё должна передаваться служебная информация в случает CST, но я ошибся. Как оказалось после проверки — данные привязаны к VLAN1 и от NV не зависят. Скорее всего это особенности реализации технологии совместимости Rapid PVST+ и RSTP данными вендорами на данных моделях коммутаторов.

Откуда я вообще взял что именно через NV должна передаваться служебная информация? Для этого конкретного случая инфу нашёл:

Заключение

Первый вывод простой и очевидный: для лучшей совместимости не стоит делать «солянку» из коммутаторов разных вендоров. А если такая солянка уже есть, то не нужно использовать проприетарные протоколы на группе коммутаторов одного вендора. Наоборот необходимо использовать открытые протоколы IEEE на всех коммутаторах сразу.

Вывод второй: работа Native Vlan, тегирование 802.1Q — не такие уж простые вещи, как может показаться на первый взгляд.