Uplink без метки 802.1q и неверный PVID

Данная заметка содержит описание проблемы «нетегированного» аплинка и потери доступа к коммутатору при загрузке конфигурации, где меняется PVID на магистральных портах. Описан способ, которым можно попытаться вернуть доступ к устройству.
 
(Заметка является адаптированной под блог статьей из корпоративной wiki)

Суть проблемы

Чтобы пользователи не могли генерировать фреймы с меткой 802.1q на коммутаторах включается функционал Ingress Checking, который проверяет поступающие фреймы на «попадание» в допустимый vlan. При этом, правда, перестает работать LLDP, т.к. Ingress Checking проверяет и такие пакетики. Чтобы LLDP заработал, на порту должен быть PVID реально существующего VLAN. Поскольку настраивать каждый коммутатор с учетом его собственных VLAN неудобно и, поскольку в моей сети есть multicast vlan, который одинаковый на всех устройствах, то PVID на магистральных портах приравнивается к ID мультикаст-vlan'а. Этим зайцем убиваются все выстрелы (или наоборот) и все работает как задумано.

Проблема появляется тогда, когда сеть управления на стыковочных портах отдается без метки 802.1q, то есть «антегом» (в моей сети такая ситуация - результат ошибки при настройке; при правильной настройке стыки всегда «тегированные»). В этом случае на порту коммутатора PVID равен ID управляющего VLAN. После загрузки новой конфигурации он становится равен 50 (ID моего мультикаст-vlan'а). Доступ к коммутатору при этом пропадает.
 

"Куда нажать?"

Чтобы поднять коммутатор без отправки на ремонтника потребуется сделать финт ушами. Для этого неплохо сначала поскрести по сусекам и отыскать конфигурацию недоступного коммутатора.

Так, например, нас интересуют строчки:

enable pvid auto_assign
config vlan default delete 1-28
config vlan default add untagged 25
...
config ipif System vlan default ipaddress 10.99.91.13/25 state enable

Нетрудно догадаться, что при применении к ним команды из нового конфига:

config gvrp 25-28 pvid 50

Доступ к коммутатору будет потерян.

Как выйти из этой ситуации?

Подсказка: Несмотря на неправильную настройку VLAN, порт 25 по прежнему member в default vlan! Этим и надо воспользоваться! 

Необходимые условия

Чтобы получить доступ нужно кое-что перенастроить:

• На вышестоящем устройстве получить интерфейс из сети проблемного коммутатора и в таком же VLAN.
• Настроить управляющий VLAN недоступного коммутатора на стыковочном порту вышестоящего коммутатора как tagged.
• Проверить, чтобы PVID на стыковочном порту был равен ID управляющего VLAN недоступного коммутатора.

Теперь можно попробовать обратиться с доступного интерфейса на «потерянный» коммутатор. Он должен быть доступен.

Шта?

Как все это работает?

• Фрейм с доступного хоста в управляющей сети недоступного коммутатора отдается в стыковочный порт с меткой 802.1q.
• Поскольку на недоступном коммутаторе порт все еще является member данного VLAN, то фрейм попадает в управляющий VLAN и неправильный PVID здесь не помеха, т.к. он оказывает влияние только на фреймы без метки 802.1q.
• Обратный фрейм с недоступного коммутатора отдается в стыковочный порт без метки 802.1q, т.к. изначально данный порт был настроен как untagged для управляющего VLAN.
• На доступный коммутатор этот фрейм заворачивается в управляющий VLAN благодаря заранее установленному PVID.

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

Подсказка: При манипуляциях с интерфейсом System на вышестоящем коммутаторе желательно запланировать перезагрузку через 5-10 минут и постоянно сдвигать ее. Это поможет получить доступ к данному коммутатору, когда вы ошибетесь. :)