вторник, 21 июля 2015 г.

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

суббота, 11 июля 2015 г.

Небольшие обновления Briseis и Dracon

Немного отвлекся от монстров в Diablo и обновил свои проекты Briseis и Dracon.

Dracon теперь умеет выгружать последний бекап из базы MongoDB. Если с коммутатора запросить у сервиса файл с именем backup, то будет выгружена последняя конфигурация для данного устройства (если она, конечно, ранее выгружалась в базу).

Еще удобно использовать переменную {$target}, которая будет заменена на IP-адрес коммутатора. Я добавил этот шаблон в конфиг:
config snmp system_name {$target}
И теперь по LLDP вижу не только MAC соседнего коммутатора, но и его IP (т.к. по LLDP передается system name)

Briseis теперь удобнее использовать для управления командами выгрузки и загрузки конфигурации, благодаря возможности сделать паузу между отправкой set-команд.

Я сделал такую последовательность SNMP-команд:
  1. Сохраняем конфигурацию в памяти коммутатора.
  2. Выгружаем конфигурацию на сервис Dracon.
  3. Получаем новую конфигурацию с сервиса Dracon.
Между каждой командой проходит 5 секунд, чтобы дать коммутатору время сделать свои дела и не получить ошибку с сообщением, что файловая система занята. Затем пишем в статистику, завершаем цикл и 2-3 секунды ждем до начала нового. Итого общее время на проход я выставил в 20 секунд. За раз из базы выбирается 10 коммутаторов. Получается в минуту сохраняются, бекапятся и обновляются 30 коммутаторов.

Как буду уверен, что новый конфиг применяется корректно, то обновлю все устройства по всей сети. Сейчас же обновил около трех сотен, для проверки самого механизма обновления через Briseis и Dracon.

пятница, 3 июля 2015 г.

Show log? No entry!

Случайно заметили проблему на коммутаторе DGS-3120-24SC - при попытке посмотреть лог командой show log устройство весело рапортовало No entry! Обновление ПО и перезагрузка не помогли. Решение, впрочем, нашлось довольно быстро при помощи Яндекса. Описано оно тут. Все, что нужно сделать, это выполнить команду clear log. Теме 6 лет, между прочим!

Очередной раз налицо подтверждение тому, что все новое - хорошо забытое старое. Век живи - век учись! :)