Native VLAN

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

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


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

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

  • Это понятие привязано к транковому каналу передачи данных и без него не используется;
  • Если взять коммутатор CISCO "из коробки", то на нём присутствует только одна VLAN — VLAN1 (всякая устаревшая экзотика типа VLANs 1002 - 1005 не в счёт), в этой же VLAN1 изначально находятся все порты;
  • Далее, если настроить на коммутаторе ещё несколько VLANs и настроить транковые порты, то для всех транковых портов по умолчанию будет NV=VLAN1:
Switch(config)#vlan 10
Switch(config-vlan)#vlan 11
Switch(config-vlan)#vlan 12
Switch(config)#interface gigabitEthernet 0/0
Switch(config-if)#switchport trunk encapsulation dot1q
Switch(config-if)#switchport mode trunk
Switch(config-if)#end
Switch#show interfaces trunk

Port   Mode Encapsulation  Status     Native vlan
Gi0/0  on   802.1q         trunking   1
  • На одном коммутаторе у разных транковых портов может быть разная NV. Это нормально и часто используется. Меняется NV для танкового порта командой:
Switch(config)#interface gigabitEthernet 0/0
Switch(config-if)#switchport trunk native vlan 12
  • Любой кадр без тега, поступивший из транка на коммутатор, пересылается в NV;
  • Для любого транкового порта VLAN без тега всегда одна;

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

  • NV с обоих сторон транка, то есть на разных коммутаторах, должна быть одинаковой, иначе в консоль выдаётся предупреждающее сообщение;
%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on GigabitEthernet1/1 (169), with S2 GigabitEthernet1/1 (1)

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

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

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

  • Если транковый порт получает тегированный кадр с таким же идентификатором как у NV, то он отбрасывает кадр;
If an 802.1Q trunk port receives a tagged frame with the VLAN ID the same as the native VLAN, it drops the frame.

CCNA R&S: Routing and Switching Essentials

Тут возникает вопрос: а как тогда вообще возможна атака с двойным тегированием? Подробнее далее.

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

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

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

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

Native VLANs are defined in the IEEE 802.1Q specification to maintain backward compatibility with untagged traffic common to legacy LAN scenarios. A native VLAN serves as a common identifier on opposite ends of a trunk link.

CCNA R&S: Routing and Switching Essentials

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

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

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

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


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

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

Remember that the native VLAN must match on both sides of the trunk link for 802.1Q; otherwise the link will not work. If there is a native VLAN mismatch, Spanning Tree Protocol (STP) places the port in a port VLAN ID (PVID) inconsistent state and will not forward on the link.

Проверим эту ситуацию. Накидал лабу в 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 из рисунка):

interface GigabitEthernet0/0/0.1
encapsulation dot1Q 10
ip vrf forwarding Special-Users
ip address 10.0.12.1 255.255.255.0
ipv6 address 2001:db8:acad:12::1/64
ipv6 address fe80::1:1 link-local
!
interface GigabitEthernet0/0/0.2
encapsulation dot1Q 12
ip vrf forwarding General-Users
ip address 10.0.12.1 255.255.255.0
ipv6 address 2001:db8:acad:12::1/64
ipv6 address fe80::1:1 link-local

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

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

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

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

Router(config)#interface GigabitEthernet 0/0
Router(config-if)#no shutdown
Router(config-if)#interface GigabitEthernet 0/0.10
Router(config-subif)#encapsulation dot1Q 10
Router(config-subif)#ip address 192.168.10.1 255.255.255.0
Router(config-if)#interface GigabitEthernet 0/0.11
Router(config-subif)#encapsulation dot1Q 11
Router(config-subif)#ip address 192.168.11.1 255.255.255.0
Router(config-if)#interface GigabitEthernet 0/0.12
Router(config-subif)#encapsulation dot1Q 12
Router(config-subif)#ip address 192.168.12.1 255.255.255.0

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

Router#show vlans

Virtual LAN ID: 1 (IEEE 802.1Q Encapsulation)

vLAN Trunk Interface: GigabitEthernet0/0

This is configured as native Vlan for the following interface(s) :
GigabitEthernet0/0 Native-vlan Tx-type: Untagged

...

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

Router(config-if)#interface GigabitEthernet 0/0.12
Router(config-subif)#encapsulation dot1Q 12 native

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

Router#show vlans

Virtual LAN ID: 1 (IEEE 802.1Q Encapsulation)

vLAN Trunk Interface: GigabitEthernet0/0

...

Virtual LAN ID: 12 (IEEE 802.1Q Encapsulation)

vLAN Trunk Interface: GigabitEthernet0/0.12

This is configured as native Vlan for the following interface(s) :
GigabitEthernet0/0 Native-vlan Tx-type: Untagged
Что делать если роутер не 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, то:

The standard Ethernet frame header does not contain information about the VLAN to which the frame belongs; thus, when Ethernet frames are placed on a trunk, information about the VLANs to which they belong must be added. This process, called tagging, is accomplished by using the IEEE 802.1Q header, specified in the IEEE 802.1Q standard. 

CCNA R&S: Routing and Switching Essentials

Поэтому обобщённо-упрощённая рабочая версия процесса тегирования при отсутствии 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.

Предлагаю самостоятельно найти несостыковки с теорией. И возможно объяснить их. Пытался много раз, так и не смог объяснить.

Кроме этого есть специальная технология двойного тегирования 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

Начнём с D-Link:

Native VLAN

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

Native VLAN

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

Проверка №2

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

Native VLAN

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

Native VLAN

Количество полученных 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 должна передаваться служебная информация? Для этого конкретного случая инфу нашёл:

Only a single instance of STP is used for all VLANs. If there are 500 VLANs, only 1 instance of STP will be running. This is called the Common Spanning Tree (CST) and operates over the trunk’s native VLAN. 

CCNP Routing and Switching SWITCH 300-115 Official Cert Guide

Заключение

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

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

2 thoughts on “Native VLAN”

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

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

Leave a Comment

Scroll to Top