Что такое native vlan

Native VLAN

Материал из Xgu.ru

В некоторых моделях коммутаторов, например, cisco, это можно изменить, указав другой VLAN как native.

Если коммутатор получает нетегированные кадры на транковом порту, он автоматически причисляет их к Native VLAN. И точно так же кадры, генерируемые с не распределенных портов, при попадании в транк-порт причисляются к Native VLAN.

Трафик, который принадлежит другим VLANам, тегируется с указанием соответствующего VLAN ID внутри тега.

Содержание

[править] Примеры настройки Native VLAN

[править] Коммутаторы Cisco

Настройка VLAN 5 как native:

Теперь весь трафик принадлежащий VLAN’у 5 будет передаваться через транковый интерфейс нетегированным, а весь пришедший на транковый интерфейс нетегированный трафик будет промаркирован как принадлежащий VLAN’у 5 (по умолчанию VLAN 1).

Проверить какой VLAN настроен как Native:

Из соображений безопасности (например, для защиты от VLAN Hopping) рекомендуется в транке выполнять тегирование даже для native VLAN. Включить тегирование фреймов для native VLAN глобально можно с помощью команды vlan dot1q tag native, просмотреть текущий статус тегирования можно используя команду show vlan dot1q tag native.

[править] Коммутаторы HP (ProCurve)

Для коммутаторов HP нет явной команды, которая настраивает Native VLAN. Для того чтобы настроить Native VLAN на этих коммутаторах, нужно просто указать, что в нужном VLAN определенный порт будет нетегированный:

Источник

Заметки о кошководстве 🙂

или Just Another CCNA Blog

суббота, 14 мая 2011 г.

Маленькое дополнение про Native VLAN.

Так как кадры Native VLAN обязаны проходить по транк-линкам без тегов, появление в транк-линке кадра с тегом номер которого совпадает с номером Native VLAN является не допустимым, и коммутатор получив такой кадр его уничтожает.
Скачать: pkt-файл

PS в pkt-файле есть небольшое изменение. Порты коммутаторов fa 0/2 переведены в режим trunk. Результат точно такой же, кадры идут без тега и дублируются на порты распределенные в первый влан (т.к. он же native) и наоборот.
PPS если задать на коммутаторах разные Native vlan, то можно получить ситуацию с отбрасыванием кадров при совпадении тега с номером native vlan.

18 комментариев:

Тогда не должен пройти пинг от pc5 к pc6(транковый vlan совпадет с тегом vlan1), и судя по всему 1 коммутатор должен такой пакет отбросить.Я правильно понимаю?

Пройдёт элементарно этот пинг.
А что значит транковый vlan? Транк тегирует кадр, указывая там принадлежность кадра к определённому vlan, если это кадр native vlan, то транк с ним ничего не делает.

пинг будет проходить потому, что в данной лабе native vlan на коммутаторах совпадает.

тоесть Native vlan совпадает с vlan1(судя по написаному вами выше «Так как кадры Native VLAN обязаны проходить по транк-линкам без тегов, появление в транк-линке кадра с тегом номер которого совпадает с номером Native VLAN является не допустимым, и коммутатор получив такой кадр его уничтожает.»)
Это уточнение к первому вопросу,хочу разобраться.Спасибо.

native vlan совпадает с vlan1 по умолчанию, но вы при желании можете это изменить.
Да, он действительно его уничтожит, потому как это будет означать, что на коммутаторах не совпадает native vlan, эта проблема довольно просто исправляется, на одном из коммутаторов просто меняете native vlan на такой же самый (как и на других устройствах домена).

Если в транк с native vlan 10 попадет тегированный траффик(vlan 10) транк просто снимет этот тэг.

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

Я бы немного уточнил последнее предложение, добавив некоторые слова для более лучшего восприятия. Вот как это бы выглядело: «Так как кадры ПРИНАДЛЕЖАЩИЕ Native VLAN обязаны проходить по транк-линкам без тегов, появление в транк-линке кадра с тегом номер которого совпадает с номером Native VLAN КОММУТАТОРА, КОТОРЫЙ ПОЛУЧАЕТ ЭТОТ КАДР, является не допустимым, и коммутатор, получив такой кадр, его уничтожает.»

насчет того, отбрасывается ли такой кадр это еще под вопросом. все никак не проверю на оборудовании

Смоделировал схему в PT по которой коммутатор получив из транка номер Native VLAN’а должен удалять такой VLAN. Ну. Ни хрена. Не удаляет. Коммутатору не фильтрует номера VLAN’ов в транке, если они совпадают с Native VLAN’ом. Он их пропускает через себя без ограничений.
Если интересно, попробуйте сами:
ROUTER1:
interface FastEthernet0/0.10
encapsulation dot1Q 10
ip address 192.168.10.1 255.255.255.0
!
interface FastEthernet0/0.20
encapsulation dot1Q 20
ip address 192.168.20.1 255.255.255.0

ROUTER2:
interface FastEthernet0/0.10
encapsulation dot1Q 10
ip address 192.168.10.2 255.255.255.0
!
interface FastEthernet0/0.20
encapsulation dot1Q 20
ip address 192.168.20.2 255.255.255.0

SW1, SW2:
interface FastEthernet0/1
switchport trunk native vlan 10
switchport mode trunk
!
interface FastEthernet0/2
switchport trunk native vlan 10
switchport mode trunk

Схема: ROUTER1 SW1 SW2 ROUTER2

да я в курсе. последнюю неделю как раз этот вопрос разбирал )))
видимо все таки в курсе ошибка или неверная формулировка.

Источник

Сайт ARNY.RU

Native VLAN — некоторое количество информации о данном виде VLAN. Что это такое, для чего нужна Native VLAN и откуда она взялась.

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

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

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

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

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

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

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

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

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

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

Отсюда интересное явление: со стороны коммутатора транковый порт, к нему подключен 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 посредством роутера. Недостатки такого метода:

А если данный линк 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, CISCO ASA 55X0.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы не ограничиваться сухой теорий, небольшой пример из продакшена. Он заставил меня поломать голову. Пример лишь косвенно связан с 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:

Проверка №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 — не такие уж простые вещи, как может показаться на первый взгляд.

Источник

Основы компьютерных сетей. Тема №6. Понятие VLAN, Trunk и протоколы VTP и DTP

P.S. Возможно, со временем список дополнится.

Мы пока не будем затрагивать маршрутизаторы и разные подсети. Допустим все узлы находятся в одной подсети.

Сразу приведу список IP-адресов:

Кто хочет увидеть это в виде анимации, открывайте спойлер (там показан ping от PC1 до PC5).

Красиво да? Мы в прошлых статьях уже не раз говорили о работе протокола ARP, но это было еще в прошлом году, поэтому вкратце объясню. Так как PC1 не знает MAC-адрес (или адрес канального уровня) PC2, то он отправляет в разведку ARP, чтобы тот ему сообщил. Он приходит на коммутатор, откуда ретранслируется на все активные порты, то есть к PC2 и на центральный коммутатор. Из центрального коммутатора вылетит на соседние коммутаторы и так далее, пока не дойдет до всех. Вот такой не маленький трафик вызвало одно ARP-сообщение. Его получили все участники сети. Большой и не нужный трафик — это первая проблема. Вторая проблема — это безопасность. Думаю, заметили, что сообщение дошло даже до бухгалтерии, компьютеры которой вообще не участвовали в этом. Любой злоумышленник, подключившись к любому из коммутаторов, будет иметь доступ ко всей сети. В принципе сети раньше так и работали. Компьютеры находились в одной канальной среде и разделялись только при помощи маршрутизаторов. Но время шло и нужно было решать эту проблему на канальном уровне. Cisco, как пионер, придумала свой протокол, который тегировал кадры и определял принадлежность к определенной канальной среде. Назывался он ISL (Inter-Switch Link). Идея эта понравилась всем и IEEE решили разработать аналогичный открытый стандарт. Стандарт получил название 802.1q. Получил он огромное распространение и Cisco решила тоже перейти на него.
И вот как раз технология VLAN основывается на работе протокола 802.1q. Давайте уже начнем говорить про нее.

В 3-ей части я показал, как выглядит ethernet-кадр. Посмотрите на него и освежите в памяти. Вот так выглядит не тегированный кадр.

Теперь взглянем на тегированный.

Как видим, отличие в том, что появляется некий Тег. Это то, что нам и интересно. Копнем глубже. Состоит он из 4-х частей.

1) TPID (англ. Tag Protocol ID) или Идентификатор тегированного протокола — состоит из 2-х байт и для VLAN всегда равен 0x8100.
2) PCP (англ. Priority Code Point) или значение приоритета — состоит из 3-х бит. Используется для приоритезации трафика. Крутые и бородатые сисадмины знают, как правильно им управлять и оперирует им, когда в сети гуляет разный трафик (голос, видео, данные и т.д.)
3) CFI (англ. Canonical Format Indicator) или индикатор каноничного формата — простое поле, состоящее из одного бита. Если стоит 0, то это стандартный формат MAC-адреса.
4) VID (англ. VLAN ID) или идентификатор VLAN — состоит из 12 бит и показывает, в каком VLAN находится кадр.

Хочу заострить внимание на том, что тегирование кадров осуществляется между сетевыми устройствами (коммутаторы, маршрутизаторы и т.д.), а между конечным узлом (компьютер, ноутбук) и сетевым устройством кадры не тегируются. Поэтому порт сетевого устройства может находиться в 2-х состояниях: access или trunk.

Набираю команду show vlan.

Выстраиваются несколько таблиц. Нам по сути важна только самая первая. Теперь покажу как ее читать.

1 столбец — это номер VLAN. Здесь изначально присутствует номер 1 — это стандартный VLAN, который изначально есть на каждом коммутаторе. Он выполняет еще одну функцию, о которой чуть ниже напишу. Также присутствуют зарезервированные с 1002-1005. Это для других канальных сред, которые вряд ли сейчас используются. Удалить их тоже нельзя.

При удалении Cisco выводит сообщение, что этот VLAN удалить нельзя. Поэтому живем и эти 4 VLANа не трогаем.

2 столбец — это имя VLAN. При создании VLAN, вы можете на свое усмотрение придумывать им осмысленные имена, чтобы потом их идентифицировать. Тут уже есть default, fddi-default, token-ring-default, fddinet-default, trnet-default.

3 столбец — статус. Здесь показывается в каком состоянии находится VLAN. На данный момент VLAN 1 или default в состоянии active, а 4 следующих act/unsup (хоть и активные, но не поддерживаются).

4 столбец — порты. Здесь показано к каким VLAN-ам принадлежат порты. Сейчас, когда мы еще ничего не трогали, они находятся в default.

Приступаем к настройке коммутаторов. Правилом хорошего тона будет дать коммутаторам осмысленные имена. Чем и займемся. Привожу команду.

Остальные настраиваются аналогично, поэтому покажу обновленную схему топологии.

Начнем настройку с коммутатора SW1. Для начала создадим VLAN на коммутаторе.

VLAN создан. Теперь переходим к портам. Интерфейс FastEthernet0/1 смотрит на PC1, а FastEthernet0/2 на PC2. Как говорилось ранее, кадры между ними должны передаваться не тегированными, поэтому переведем их в состояние Access.

Так как оба порта закрепляются под одинаковым VLAN-ом, то их еще можно было настроить группой.

Настроили access порты. Теперь настроим trunk между SW1 и CentrSW.

Сразу видим, что порт перенастроился. В принципе для работы этого достаточно. Но с точки зрения безопасности разрешать для передачи нужно только те VLAN, которые действительно нужны. Приступим.

Без этой команды передаваться будут все имеющиеся VLAN. Посмотрим, как изменилась таблица командой show vlan.

Появился 2-ой VLAN с именем Dir-ya и видим принадлежащие ему порты fa0/1 и fa0/2.

Чтобы вывести только верхнюю таблицу, можно воспользоваться командой show vlan brief.

Можно еще укоротить вывод, если указать определенный ID VLANа.

Вся информациях о VLAN хранится в flash памяти в файле vlan.dat.

Как вы заметили, ни в одной из команд, нет информации о trunk. Ее можно посмотреть другой командой show interfaces trunk.

Здесь есть информация и о trunk портах, и о том какие VLAN они передают. Еще тут есть столбец Native vlan. Это как раз тот трафик, который не должен тегироваться. Если на коммутатор приходит не тегированный кадр, то он автоматически причисляется к Native Vlan (по умолчанию и в нашем случае это VLAN 1). Native VLAN можно, а многие говорят, что нужно менять в целях безопасности. Для этого в режиме настройки транкового порта нужно применить команду — switchport trunk native vlan X, где X — номер присваиваемого VLAN. В этой топологии мы менять не будем, но знать, как это делать полезно.

Осталось настроить остальные устройства.

CentrSW:
Центральный коммутатор является связующим звеном, а значит он должен знать обо всех VLAN-ах. Поэтому сначала создаем их, а потом переводим все интерфейсы в транковый режим.

Не забываем сохранять конфиг. Команда copy running-config startup-config.

Обратите внимание на то, что мы подняли и настроили VLAN, но адресацию узлов оставили такой же. То есть, фактически все узлы в одной подсети, но разделены VLAN-ами. Так делать нельзя. Каждому VLAN надо выделять отдельную подсеть. Я это сделал исключительно в учебных целях. Если бы каждый отдел сидел в своей подсети, то они бы априори были ограничены, так как коммутатор не умеет маршрутизировать трафик из одной подсети в другую (плюс это уже ограничение на сетевом уровне). А нам нужно ограничить отделы на канальном уровне.
Снова отправляю ping с PC1 к PC3.

Идет в ход ARP, который нам и нужен сейчас. Откроем его.

Пока что ничего нового. ARP инкапсулирован в ethernet.

Кадр прилетает на коммутатор и тегируется. Теперь там не обычный ethernet, а 802.1q. Добавились поля, о которых я писал ранее. Это TPID, который равен 8100 и показывающий, что это 802.1q. И TCI, которое объединяет 3 поля PCP, CFI и VID. Число, которое в этом поле — это номер VLAN. Двигаемся дальше.

После тега он отправляет кадр на PC2 (т.к. он в том же VLAN) и на центральный коммутатор по транковому порту.

Так как жестко не было прописано какие типы VLAN пропускать по каким портам, то он отправит на оба коммутатора. И вот здесь коммутаторы, увидев номер VLAN, понимают, что устройств с таким VLAN-ом у них нет и смело его отбрасывают.

PC1 ожидает ответ, который так и не приходит. Можно под спойлером посмотреть в виде анимации.

Теперь следующая ситуация. В состав дирекции нанимают еще одного человека, но в кабинете дирекции нет места и на время просят разместить человека в отделе бухгалтерии. Решаем эту проблему.

Подключили компьютер к порту FastEthernet 0/3 коммутатора и присвою IP-адрес 192.168.1.8/24.
Теперь настрою коммутатор SW2. Так как компьютер должен находиться во 2-ом VLAN, о котором коммутатор не знает, то создам его на коммутаторе.

Дальше настраиваем порт FastEthernet 0/3, который смотрит на PC7.

И последнее — настроить транковый порт.

Чтобы кадры ходили красиво, подкорректирую центральный коммутатор CentrSW.

Время проверки. Отправляю ping с PC1 на PC7.

И вот он приходит на SW2. Открываем и видим, что он еще тегированный. Но следующим узлом стоит компьютер и тег надо снимать. Нажимаем на «Outbound PDU Details», чтобы посмотреть в каком виде кадр вылетит из коммутатора.

И действительно. Коммутатор отправит кадр в «чистом» виде, то есть без тегов.

Доходит ARP до PC7. Открываем его и убеждаемся, что кадр не тегированный PC7 узнал себя и отправляет ответ.

Открываем кадр на коммутаторе и видим, что на отправку он уйдет тегированным. Дальше кадр будет путешествовать тем же путем, что и пришел.

ARP доходит до PC1, о чем свидетельствует галочка на конверте. Теперь ему известен MAC-адрес и он пускает в ход ICMP.

Открываем пакет на коммутаторе и наблюдаем такую же картину. На канальном уровне кадр тегируется коммутатором. Так будет с каждым сообщением.

Видим, что пакет успешно доходит до PC7. Обратный путь я показывать не буду, так как он аналогичен. Если кому интересно, можно весь путь увидеть на анимации под спойлером ниже. А если охота самому поковырять эту топологию, прикладываю ссылку на лабораторку.

Вот в принципе самое популярное применение VLAN-ов. Независимо от физического расположения, можно логически объединять узлы в группы, там самым изолируя их от других. Очень удобно, когда сотрудники физически работают в разных местах, но должны быть объединены. И конечно с точки зрения безопасности VLAN не заменимы. Главное, чтобы к сетевым устройствам имели доступ ограниченный круг лиц, но это уже отдельная тема.
Добились ограничения на канальном уровне. Трафик теперь не гуляет где попало, а ходит строго по назначению. Но теперь встает вопрос в том, что отделам между собой нужно общаться. А так как они в разных канальных средах, то в дело вступает маршрутизация. Но перед началом, приведем топологию в порядок. Самое первое к чему приложим руку — это адресация узлов. Повторюсь, что каждый отдел должен находиться в своей подсети. Итого получаем:

Раз подсети определены, то сразу адресуем узлы.

Осталось настроить маршрутизатор, и я открываю его CLI. По традиции дам осмысленное имя.

Далее переходим к настройке интерфейсов.

Теперь внимание! Мы включили интерфейс, но не повесили на него IP-адрес. Дело в том, что от физического интерфейса (fastethernet 0/0) нужен только линк или канал. Роль шлюзов будут выполнять виртуальные интерфейсы или сабинтерфейсы (англ. subinterface). На данный момент 3 типа VLAN. Значит и сабинтерфейсов будет 3. Приступаем к настройке.

Маршрутизатор настроен. Переходим к центральному коммутатору и настроим на нем транковый порт, чтобы он пропускал тегированные кадры на маршрутизатор.

Конфигурация закончена и переходим к практике. Отправляю ping с PC1 на PC6 (то есть на 192.168.3.3).

PC1 понятия не имеет, кто такой PC6 или 192.168.3.3, но знает, что они находятся в разных подсетях (как он это понимает описано в предыдущей статье). Поэтому он отправит сообщение через основной шлюз, адрес которого указан в его настройках. И хоть PC1 знает IP-адрес основного шлюза, для полного счастья не хватает MAC-адреса. И он пускает в ход ARP.

Обратите внимание. Как только кадр прибывает на CentrSW, коммутатор не рассылает его кому попало. Он рассылает только на те порты, где разрешен пропуск 2-го VLAN. То есть на маршрутизатор и на SW2 (там есть пользователь, сидящий во 2-ом VLAN).

Маршрутизатор узнает себя и отправляет ответ (показан стрелочкой). И обратите внимание на нижний кадр. Когда SW2 получил ARP от центрального коммутатора, он аналогично не стал рассылать его на все компьютеры, а отправил только PC7, который сидит во 2-ом VLAN. Но PC7 его отбрасывает, так как он не для него. Смотрим дальше.

ARP дошел до PC1. Теперь ему все известно и можно отправлять ICMP. Еще раз обращу внимание на то, что в качестве MAC-адреса назначения (канальный уровень), будет адрес маршрутизатора, а в качестве IP-адреса назначения (сетевой уровень), адрес PC6.

Доходит ICMP до маршрутизатора. Он смотрит в свою таблицу и понимает, что не знает никого под адресом 192.168.3.3. Отбрасывает прибывший ICMP и пускает разведать ARP.

PC6 узнает себя и отправляет ответ.

Доходит до маршрутизатора ответ и он добавляет запись в своей таблице. Посмотреть таблицу ARP можно командой show arp.

Двигаемся дальше. PC1 недоволен, что ему никто не отвечает и отправляет следующее ICMP-сообщение.

Первый пакет затерялся (в результате работы ARP), а второй дошел без проблем.
Кому интересно увидеть в анимации, добро пожаловать под спойлер.

Итак. Мы добились того, что если узлы находятся в одной подсети и в одном VLAN, то ходить они будут напрямую через коммутаторы. В случае, когда нужно передать сообщение в другую подсеть и VLAN, то передавать будут через роутер Gateway, который осуществляет «межвлановую» маршрутизацию. Данная топология получила название «router on a stick» или «роутер на палочке». Как вы поняли она очень удобна. Мы создали 3 виртуальных интерфейса и по одному проводу гоняли разные тегированные кадры. Без использования сабинтерфейсов и VLAN-ов, пришлось бы для каждой подсети задействовать отдельный физический интерфейс, что совсем не выгодно.

Кстати очень хорошо этот вопрос разобран в этом видео (видео идет около 3-х часов, поэтому ссылка с привязкой именно к тому моменту времени). Если после прочтения и просмотра видео захочется добить все собственными руками, прикладываю ссылку на скачивание.

Разобрались с VLAN-ами и переходим к одному из протоколов, работающего с ним.
DTP (англ. Dynamic Trunking Protocol) или на русском динамический транковый протокол — проприетарный протокол компании Cisco, служащий для реализации trunk режима между коммутаторами. Хотя в зависимости от состояния, они могут согласоваться и в режим access.

В DTP есть 4 режима: Dynamic auto, Dynamic desirable, Trunk, Access. Рассмотрим как они согласуются.

То есть левая колонка это 1-ое устройство, а верхняя строка 2-ое устройство. По-умолчанию коммутаторы находятся в режиме «dynamic auto». Если посмотреть таблицу сопоставления, то два коммутатора в режиме «dynamic auto» согласуются в режим «access». Давайте это и проверим. Создаю я новую лабораторную работу и добавлю 2 коммутатора.

Соединять их пока не буду. Мне надо убедиться, что оба коммутатора в режиме «dynamic auto». Проверять буду командой show interfaces switchport.

Результат этой команды очень большой, поэтому я его обрезал и выделил интересующие пункты. Начнем с Administrative Mode. Эта строка показывает, в каком из 4-режимов работает данный порт на коммутаторе. Убеждаемся, что на обоих коммутаторах порты в режиме «Dynamic auto». А строка Operational Mode показывает, в каком режиме работы они согласовали работу. Мы пока их не соединяли, поэтому они в состоянии «down».

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

Перевожу CPT в режим simulation и отфильтрую все протоколы, кроме DTP.

Думаю здесь все понятно. Соединяю коммутаторы кабелем и, при поднятии линков, один из коммутаторов генерирует DTP-сообщение.

Открываю и вижу, что это DTP инкапсулированный в Ethernet-кадр. Отправляет он его на мультикастовый адрес «0100.0ccc.cccc», который относится к протоколам DTP, VTP, CDP.
И обращу внимание на 2 поля в заголовке DTP.

1) DTP Type — сюда отправляющий вставляет предложение. То есть в какой режим он хочет согласоваться. В нашем случае он предлагает согласовать «access».
2) Neighbor MAC-address — в это поле он записывает MAC-адрес своего порта.

Отправляет он и ждет реакции от соседа.

Доходит до SW1 сообщение и он генерирует ответный. Где также согласует режим «access», вставляет свой MAC-адрес и отправляет в путь до SW2.

Успешно доходит DTP. По идее они должны были согласоваться в режиме «access». Проверю.

Как и предполагалось, согласовались они в режим «access».
Кто то говорит, что технология удобная и пользуется ею. Но я крайне не рекомендую использовать этот протокол в своей сети. Рекомендую это не только я, и сейчас объясню почему. Смысл в том, что этот протокол открывает большую дыру в безопасности. Я открою лабораторку, в которой разбиралась работа «Router on a stick» и добавлю туда еще один коммутатор.

Теперь зайду в настройки нового коммутатора и жестко пропишу на порту работу в режиме trunk.

Соединяю их и смотрю, как они согласовались.

Все верно. Режимы «dynamic auto» и «trunk» согласуются в режим trunk. Теперь ждем, когда кто- то начнет проявлять активность. Допустим PC1 решил кому то отправить сообщение. Формирует ARP и выпускает в сеть.

Пропустим его путь до того момента, когда он попадет на SW2.

И вот самое интересное.

Но здесь настройки порта пустые. Ввожу show interfaces switchport и проматываю до fa0/4.

А вот здесь видим, что согласован trunk. Не всегда show running-config дает исчерпывающую информацию. Поэтому запоминайте и другие команды.

Думаю понятно почему нельзя доверять этому протоколу. Он вроде облегчает жизнь, но в то же время может создать огромную проблему. Поэтому полагайтесь на ручной метод. При настройке сразу же обозначьте себе какие порты будут работать в режиме trunk, а какие в access. И самое главное — всегда отключайте согласование. Чтобы коммутаторы не пытались ни с кем согласоваться. Делается это командой «switchport nonegotiate».

Переходим к следующему протоколу.

VTP (англ. VLAN Trunking Protocol) — проприетарный протокол компании Cisco, служащий для обмена информацией о VLAN-ах.

Представьте ситуацию, что у вас 40 коммутаторов и 70 VLAN-ов. По хорошему нужно вручную на каждом коммутаторе их создать и прописать на каких trunk-ых портах разрешать передачу. Дело это муторное и долгое. Поэтому эту задачу может взвалить на себя VTP. Вы создаете VLAN на одном коммутаторе, а все остальные синхронизируются с его базой. Взгляните на следующую топологию.

Здесь присутствуют 4 коммутатора. Один из них является VTP-сервером, а 3 остальных клиентами. Те VLAN, которые будут созданы на сервере, автоматически синхронизируются на клиентах. Объясню как работает VTP и что он умеет.

Итак. VTP может создавать, изменять и удалять VLAN. Каждое такое действие влечет к тому, что увеличивается номер ревизии (каждое действие увеличивает номер на +1). После он рассылает объявления, где указан номер ревизии. Клиенты, получившие это объявление, сравнивают свой номер ревизии с пришедшим. И если пришедший номер выше, они синхронизируют свою базу с ней. В противном случае объявление игнорируется.

Но это еще не все. У VTP есть роли. По-умолчанию все коммутаторы работают в роли сервера. Расскажу про них.

Начитались теории и переходим к практике. Проверим, что центральный коммутатор в режиме Server. Вводим команду show vtp status.

Видим, что VTP Operating Mode: Server. Также можно заметить, что версия VTP 2-ая. К сожалению, в CPT 3-ья версия не поддерживается. Версия ревизии нулевая.
Теперь настроим нижние коммутаторы.

Видим сообщение, что устройство перешло в клиентский режим. Остальные настраиваются точно также.

Чтобы устройства смогли обмениваться объявлениями, они должны находиться в одном домене. Причем тут есть особенность. Если устройство (в режиме Server или Client) не состоит ни в одном домене, то при первом полученном объявлении, перейдет в объявленный домен. Если же клиент состоит в каком то домене, то принимать объявления от других доменов не будет. Откроем SW1 и убедимся, что он не состоит ни в одном домене.

Убеждаемся, что тут пусто.

Теперь переходим центральному коммутатору и переведем его в домен.

Видим сообщение, что он перевелся в домен cisadmin.ru.
Проверим статус.

И действительно. Имя домена изменилось. Обратите внимание, что номер ревизии пока что нулевой. Он изменится, как только мы создадим на нем VLAN. Но перед созданием надо перевести симулятор в режим simulation, чтобы посмотреть как он сгенерирует объявления. Создаем 20-ый VLAN и видим следующую картинку.

Как только создан VLAN и увеличился номер ревизии, сервер генерирует объявления. У него их два. Сначала откроем тот, что левее. Это объявление называется «Summary Advertisement» или на русском «сводное объявление». Это объявление генерируется коммутатором раз в 5 минут, где он рассказывает о имени домена и текущей ревизии. Смотрим как выглядит.

В Ethernet-кадре обратите внимание на Destination MAC-адрес. Он такой же, как и выше, когда генерировался DTP. То есть, в нашем случае на него отреагируют только те, у кого запущен VTP. Теперь посмотрим на следующее поле.

Здесь как раз вся информация. Пройдусь по самым важным полям.

Думаю здесь понятно. Отдельный заголовок для каждого типа VLAN. Список настолько длинный, что не поместился в экран. Но они точно такие, за исключением названий. Заморачивать голову, что означает каждый код не буду. Да и в CPT они тут больше условность.
Смотрим, что происходит дальше.

Получают клиенты объявления. Видят, что номер ревизии выше, чем у них и синхронизируют базу. И отправляют сообщение серверу о том, что база VLAN-ов изменилась.

Вот так в принципе работает протокол VTP. Но у него есть очень большие минусы. И минусы эти в плане безопасности. Объясню на примере этой же лабораторки. У нас есть центральный коммутатор, на котором создаются VLAN, а потом по мультикасту он их синхронизирует со всеми коммутаторами. В нашем случае он рассказывает про VLAN 20. Предлагаю еще раз глянуть на его конфигурацию.

И тут в сеть мы добавляем новый коммутатор. У него нет новых VLAN-ов, кроме стандартных и он не состоит ни в одном VTP-домене, но подкручен номер ревизии.

И перед тем как его воткнуть в сеть, переводим порт в режим trunk.

Теперь переключаю CPT в «Simulation Mode» и отфильтровываю все, кроме VTP. Подключаюсь и смотрю, что происходит.

Через какое то время до NewSW доходит VTP сообщение, откуда он узнает, что в сети есть VTP-домен «cisadmin.ru». Так как он не состоял до этого в другом домене, он автоматически в него переходит. Проверим.

Теперь он в том же домене, но с номером ревизии выше. Он формирует VTP-сообщение, где рассказывает об этом.

Первым под раздачу попадет SW1.

Заметьте, что на SW1 приходят сразу 2 VTP-сообщения (от NewSW и от CentrSW). В сообщении от NewSW он видит, что номер ревизии выше, чем его и синхронизирует свою базу. А вот сообщение от CentrSW для него уже устарело, и он отбрасывает его. Проверим, что изменилось на SW1.

Обновился номер ревизии и, что самое интересное, база VLAN. Теперь она пустая. Смотрим дальше.

Обратите внимание. До сервера доходит VTP-сообщение, где номер ревизии выше, чем у него. Он понимает, что сеть изменилась и надо под нее подстроиться. Проверим конфигурацию.

Конфигурация центрального сервера изменилась и теперь он будет вещать именно ее.
А теперь представьте, что у нас не один VLAN, а сотни. Вот таким простым способом можно положить сеть. Конечно домен может быть запаролен и злоумышленнику будет тяжелее нанести вред. А представьте ситуацию, что у вас сломался коммутатор и срочно надо его заменить. Вы или ваш коллега бежите на склад за старым коммутатором и забываете проверить номер ревизии. Он оказывается выше чем у остальных. Что произойдет дальше, вы уже видели. Поэтому я рекомендую не использовать этот протокол. Особенно в больших корпоративных сетях. Если используете VTP 3-ей версии, то смело переводите коммутаторы в режим «Off». Если же используется 2-ая версия, то переводите в режим «Transparent».

Кому интересно посмотреть это в виде анимации, открывайте спойлер.

Источник