Native VLAN

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

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

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

  • Это понятие привязано к транковому каналу передачи данных и без него не используется;
  • Если взять коммутатор 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;
  • Для любого транкового порта VLAN без тега всегда одна.

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

NV на роутере

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

Router-on-a-Stick

В этой схеме роутер связан с коммутатором транковым каналом, на роутере заводятся подынтерфейсы (тоже когда первый раз увидел, то удивился, но "подынтерфейс" — это правильное название), один подынтерфейс для одной 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 просто становится не нужен.

Настройка 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

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

Перемещаясь внутри VLAN в пределах одного коммутатора кадр не знает, что он принадлежит какой-то VLAN. Когда кадр попадает на транк для передачи на другой коммутатор, вот тогда тег и навешивается.

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

Таким образом: тег существует только внутри транка.

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

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

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

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

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

Сети native VLAN определены в спецификации IEEE 802.1Q для обеспечения обратной совместимости с нетегированным трафиком, характерным для устаревших сценариев локальных сетей. Сеть native VLAN служит общим идентификатором на противоположных концах транкового канала.

CCNA2 R&S

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

Когда удобно менять 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 не зависят.

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

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