Помогите разобраться, у меня 2 Cisco: 3550 и 2950, на них несколько vlan, соединены между собой через trunk (на порту GigabitEthernet0/2), все работает, но все время в syslog валится ошибка Native VLAN mismatch discovered on GigabitEthernet0/2.
Всё дело в том, что один из девайсов шлет пакеты без меток в натив влан, а второй с метками, ну и они кумекают, что это всё к одному влану относится.
Как избавится от ошибки?
interface GigabitEthernet0/2 description link_to_2950 switchport trunk encapsulation dot1q switchport trunk native vlan 4 switchport mode trunk no ip address ! interface Vlan4 ip address 192.168.2.1 255.255.255.0 ip directed-broadcast ip pim dense-mode !
interface GigabitEthernet0/2 description link_to_3550 switchport mode trunk no ip address ! interface Vlan1 description management VLAN ip address 192.168.2.3 255.255.255.0 ip directed-broadcast no ip route-cache !
1. «Native VLAN mismatch discovered»
+ / –
Сообщение от Ярослав Росомахо on 05-Фев-07, 14:22
>Помогите разобраться, у меня 2 Cisco: 3550 и 2950, на них несколько >vlan, соединены между собой через trunk (на порту GigabitEthernet0/2), все работает, >но все время в syslog валится ошибка Native VLAN mismatch discovered >on GigabitEthernet0/2. > >Всё дело в том, что один из девайсов шлет пакеты без меток >в натив влан, а второй с метками, ну и они кумекают, >что это всё к одному влану относится. > >Как избавится от ошибки?
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 — не такие уж простые вещи, как может показаться на первый взгляд.
Определить Root-бридж согласно документации. Для того, чтобы не предоставлять возможность STP принимать решении о назначение корневого коммутатора для STP топологии, необходимо в Global Configuration Mode, для каждого из настроенных на коммутаторе VLAN, выполнить команду
Для того чтобы установить необходимый режим STP необходимо в Global Configuration Mode выполнить команду
SwitchX (config)#spanning-tree mode rapid-pvst
Данная тема (Диагностика и устранение неполадок в работе) является одной из самых сложных в рамках курса CCNA. Ее нельзя просто взять и выучить. Поэтому необходимо уделить особое внимание пунктам 3 и 4, и проверить на топологии, которая использовалась в Лабораторная работа №18 Per-VLAN Spanning Tree Protocol Plus ( PVST+ ).
Итак, все у нас вроде как хорошо, сеть работает, но, заглянув в логи Cisco мы обнаруживаем часто повторяющиеся сообщения вида:
Что такое сообщение значит?
Почему?
Во-первых, это не сообщение об ошибке. Нередко CDP-4-NATIVE_VLAN_MISMATCH — это только информация для администратора.
Во-вторых, как и сказано в сообщении (Native VLAN mismatch discovered): Cisco обнаружила, что на другом ее конце порт имеет другой Native VLAN. Т.е., например, с одной стороны нетеггированный трафик выходит/входит по VLAN=A, а с другой стороны — по VLAN=B. Т.к. пакеты нетеггированные, т.е. проходят по ACCESS-порту или через Native VLAN порта Trunk, то такая ситуция возможна и, более того, имеет место быть использована для соединения разнонастроенных сетей.
Как пример: на стороне одного из центральных коммутаторов мы ходим видеть трафик из удаленного офиса по VLAN=20, а на стороне самого офиса VLAN ЛВС — например, VLAN 50. Как нам их соединить? Самое простое — это перевести порты в Access режим и сказать на одной стороне, что Access=VLAN_20, а на другой — что Access=VLAN_50. Если же требуется прокинуть еще и другие вланы — то вместо Access порты конфигурируем как Trunk в разными Native VLAN.
И что мы получаем в итоге? Все работает, но сыпет сообщениями «%CDP-4-NATIVE_VLAN_MISMATCH» и «Native VLAN mismatch discovered» в логах.
Почему? Да потому, что Cisco используют VTP и проверяют конфигурации между собой дабы сразу известить администратора о возможных проблемах. В том числе — девайсы проверяют — а одинаковые ли на обоих сторонах порта Native VLAN, причем даже если на какой-то из сторон порт сконфигурирован как Access.
С точки зрения Cisco конфигурации должны быть одинаковы в одном VTP домене. Если же происходит описанная выше ситуация (т.е. действительно соединяются сети с разными VLAN через Access-ветку), то домены должны быть разными.
Решение.
Если все работает как надо и сообщение, на Ваш взгляд, это лишнее (не нужное) предупреждение — то давайте от него избавимся. Зачем загромождать логи ненужной информацией (при том, что длинна лога ограничена и действительно важное сообщение из-за этих «%CDP-4-NATIVE_VLAN_MISMATCH» может быть затерто).
Решением является перевод одного из устройств в другой VTP домен. Да-да, достаточно, чтобы хотя-бы одна из цисок была в другом VTP домене — и такие сообщения пропадут.
Итак, логинимся на одну из цисок и переводим ее в другой домен:
где вместо MY_NEW_VTP_NAME укажите новое имя домена VTP (без особой привязки).
Pseudo-random groups of words that compose what we call knowledge
Cisco switches support CDP and use it to help us in a number of ways. One of them is to detect native VLAN mismatch between two connected ports. For 99% of the time this is a “good thing to do” ™ but there are some corner cases where this is not what you want.
For example, if you have a switch that is connected with another switch and their connected ports are configured as access ports (and not trunk ports) then this message doesn’t make much sense.
Cisco switches also support VTP which eases the VLAN management task. For VTP to work, switches that are under the same “local network” are also under the same “VTP domain”. A VTP domain logically groups switches.
Now, here is the problem: Two switches connected using access mode that are in the same VTP domain should share the same VLAN configuration, even if they are configured as transparent.
What to do: To bypass this problem you have to change the vtp domain on those switches so that it doesn’t match. If you haven’t changed that already, they most probably are not in any VTP domain at all or they are in the same VTP domain.
Switch(config)# vtp domain a_unique_name
(you may want to use the hostname)
… and this annoying message:
Oct 27 12:16:29.352 EET: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on GigabitEthernet2/6 (2), with sw-el0 GigabitEthernet0/8 (1).
I have a problem with vlan mismath with one Routers 7600 between two switches that run CDP Neighborns Protocol.
Can anyone help me know because I have this message in the log and how I can fix it, this does not affect the operation of the network.
Oct 5 23:29:16: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on GigabitEthernet11/43 (512), with WS-C2950-12 FastEthernet0/6 (1).
Hi Martin. well the interfaces are diferent, it don´t be conected, it is interfaces conected to another switches, Interface Gigabit 11/16 and 11/43 are 7600 router series.
3. Re: %CDP-4-NATIVE_VLAN_MISMATCH
The log message tells you the problem. In the GigabitEthernet11/43 you have configured the native VLAN 512 and in the other part of the link you have native VLAN 1. Set the native VLAN to be consistent in both sides of the link.
Example of how you can change it:
switchport trunk native vlan 1
4. Re: %CDP-4-NATIVE_VLAN_MISMATCH
Normally the error message is displayed when the two ends of a trunk link are configured with different VLANs (they must match). The misconfiguration can be fixed with the command that Elvin posted. However, you seem to have an interesting configuration. Why are the switchports statically configured in access mode? Links between switch-switch or switch-router should be in trunking mode and the native VLAN must match on both ends (by default, VLAN 1).
5. Re: %CDP-4-NATIVE_VLAN_MISMATCH
the client set up that way because the switch that is connected to all ports work in vlan512 to gigabitethernet11/43 and the same is to other interface
6. Re: %CDP-4-NATIVE_VLAN_MISMATCH
You have a mismatch in Duplex speeds. One is set at (Full Duplex) and the other is set at (half duplex) that’s one problem that I see at first glance.
7. Re: %CDP-4-NATIVE_VLAN_MISMATCH
I see; you change color of text and I d > might be bad idea?
Oct 5 23:29:16: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on GigabitEthernet11/43 (512),
8. Re: %CDP-4-NATIVE_VLAN_MISMATCH
are two links differents, not are links betwen same switches.
9. Re: %CDP-4-NATIVE_VLAN_MISMATCH
I have seen this errror on a production switch. Normally InterVlan routing is being used on the router and is being transferred to the switch. Just for review, a switch is going to be in data or trunking mode. If the port is configured to be switchport mode access; it is connecting to a workstation. If the port is configured to be a trunking port; it is connected to a hub, switch, bridge, or router. More than likely, this is a configuration issue and you should work your way from the furtherest switch and move towards the router to fix the issue.
on 05-Фев-07, 14:22
