Данная заметка содержит описание проблемы «нетегированного» аплинка и потери доступа к коммутатору при загрузке конфигурации, где меняется 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
Доступ к коммутатору будет потерян.
Как выйти из этой ситуации?
Чтобы получить доступ нужно кое-что перенастроить:
Как все это работает?
Таким вот способом можно «достать» недоступный коммутатор без его перезагрузки ремонтником.
Подсказка: При манипуляциях с интерфейсом System на вышестоящем коммутаторе желательно запланировать перезагрузку через 5-10 минут и постоянно сдвигать ее. Это поможет получить доступ к данному коммутатору, когда вы ошибетесь. :)
(Заметка является адаптированной под блог статьей из корпоративной 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 минут и постоянно сдвигать ее. Это поможет получить доступ к данному коммутатору, когда вы ошибетесь. :)
