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

Почему одинаковой? Допустим 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

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

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

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

Несовпадение 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).

Итого: при несовпадении 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 с лишним раза.

В интернете наткнулся на интересную схему 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, CISCO ASA 55X0.


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

Для того чтобы прикладывать тег, размер кадра пришлось увеличивать на 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 или сабинтерфейсы то, тег 802.1Q вставляется в заголовок уже по приходу кадра на порт доступа.

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


Для чего же была придумана 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 без тега.

Хотя это не самая правильная настройка подключения компьютера к коммутатору CISCO через телефон CISCO (подробнее: //ciscomaster.ru/node/89)

Вот собственно и всё про данное понятие.

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

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

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

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

Суть этой атаки:

  • Злоумышленник сидит на транковом канале, иначе тегированные кадры на порте доступа отбрасывались бы. Реализуется такой транковый порт через IP-телефон;
  • NV этого пользовательского транка совпадает с NV других транков данного коммутатора. В частности с NV транков к остальным коммутаторам;
  • Зловред отправляет кадр с двумя тегами, первый тег с идентификатором NV, второй с идентификатором атакуемой VLAN:

И.. этот кадр должен быть отброшен, как тегированный в NV. Как тогда атака возможна? Нет ответа на этот вопрос, явное противоречие. Единственное объяснение: возможно зависит от IOS и в каких-то версиях IOS логика работы NV другая.

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

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

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

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

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

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

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

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

У каждого периферийного свича 1 транк до центрального CISCO 3750X. Конфигурации однотипные, центральный свич настроен корневым мостом STP.

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

Разбираемся

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

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

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

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

Воспроизводим на EVE-NG

Берём простую конфигурацию EVE на образах CISCO vIOS L2. Два коммутатора S1 и S2 соединены транком.

Для S1

Создаём VLAN2, транковые порты, включаем Rapid-PVST+, делаем S1 корневым:

S1(config)# vlan 2
S1(config-vlan)#span mode rapid
S1(config)# interface GigabitEthernet 0/0
S1(config-if)# switchport trunk encapsulation dot1q
S1(config-if-range)# switchport mode trunk
S1(config-if)# switchport trunk allowed vlan 2
S1(config-if-range)# exit
S1(config)# spanning-tree vlan 2 root primary

По транку со стороны S1 будет форвардится только VLAN2.

Для S2
S2(config)# vlan 2
S2(config-vlan)# span mode rapid
S2(config)# interface gigabitEthernet 0/0
S2(config-if)# switchport trunk encapsulation dot1q
S2(config-if)# switchport mode trunk
S2(config-if)# end

Смотрим на S2, проблем не возникло:

S2# show spanning-tree vlan 2 detail

VLAN0002 is executing the rstp compatible Spanning Tree protocol
Bridge Identifier has priority 32768, sysid 2, address 5000.0002.0000
...
Current root has priority 24578, address 5000.0001.0000
Root port is 1 (GigabitEthernet0/0), cost of root path is 4
...
Port 1 (GigabitEthernet0/0) of VLAN0002 is root forwarding
...
Link type is shared by default
BPDU: sent 35, received 133

Для CISCO проблема неактуальна, как и в продакшене, так и в эмуляции — одинаковые результаты.

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

Теперь нужно выяснить для 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

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

Проверка №3

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

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

Заключение

Первый вывод простой и очевидный: для лучшей совместимости не стоит делать "солянку" из коммутаторов разных вендоров.

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *