Как я сломал (половину) мою сеть?

Я ищу совет после события, чтобы это событие больше не повторилось.

У нас есть сетевое ядро ​​из двух коммутаторов Cisco 4500x, настроенных на резервирование VSS. Из них у нас есть устройства iSCSI, наш blade-центр HP для нашей vSphere, а также агрегированные ссылки на наши пользовательские коммутаторы доступа и пара коммутаторов 4948e для медных устройств в нашей серверной комнате. Из 4948 у нас есть пара коммутаторов 2960 для двух каналов ISP и пара ASA в качестве брандмауэров. Довольно приличная избыточность, за исключением того, что многие устройства, которые подключаются к 4948e, имеют только одну сетевую карту - только столько, сколько мы можем сделать.

Мы готовимся заменить наши текущие пользовательские переключатели доступа (старые Extremes) на Meraki. Мы также внедряем точки доступа Meraki для замены наших нынешних Arubas. Часть беспроводного проекта включает создание новых VLAN и подсетей для управления AP и гостевой беспроводной сети.

У нас были две определенные VLAN (20 и 40) на 4500x, которые нигде не использовались - подтвердили, что подсети были пусты, порты их не использовали и т. Д. Я вошел в 4500x и выдал « no interface vlan 20», а затем перестроил его с подсетью Я хотел. Затем я добавил его в два порта 10Gb, которые подключены к Meraki

switchport trunk allowed <previous list plus two VLANs above plus existing wireless VLAN>

Я заметил, что 20 и 40 VLAN были отключены, поэтому я выдал no shutdownих. В тот момент я потерял доступ к Merakis, поэтому понял, что не добавил VLAN в интерфейс канала порта для этого канала.

На этом этапе половина нашей среды стала недоступной

Наша интернет-ссылка стала чрезвычайно ненадежной. Наши телефоны Avaya VoIP не могут входить или выходить. У нас есть несколько iSCSI-устройств с медным подключением, которые стали недоступны - никаких перебоев в работе с пользовательским интерфейсом, но это повлияло на наши резервные копии и почтовый архив. Я вошел в серверную комнату и отключил Merakis от 4500x (отключил оба оптоволоконных порта 10 Гбит) на случай, если я каким-то образом создал петлю - без изменений. Я признаю, что просто смотрю на это некоторое время в этой точке.

Я поднял Orion и заметил, что один из наших внешних коммутаторов (Cat2960) и одна из нашей пары ASA также были неисправны. Очевидно, что у нас произошла какая-то частичная потеря подключения к локальной сети, но пара ASA также связана с кроссовером друг к другу, и их восходящие каналы не были разорваны, поэтому они не переключались на то, чего могли достичь наши внутренние устройства. Я выключил "отключенный" ASA, и Интернет снова стал доступным.

Я позвонил в TAC, и после нескольких часов борьбы с техником, который продолжал придираться к каждой конфигурации порта для каждого сбитого хоста, который я показывал ему на 4500x, я вошел в один из наших коммутаторов 4948e и показал, как он не может пинговать вещи которые были подключены напрямую - одно из наших медных устройств iSCSI на базе Windows, интерфейс iLO в нашем blade-центре и т. д.

Он просмотрел журналы и ничего не нашел, но в этот момент он сказал: «Похоже на ошибку связующего дерева, даже если я не вижу этого в журналах», поэтому мы перезагрузили 4948e и все его напрямую подключенные хосты вернулись обратно - включая шкаф Avaya, поэтому наши телефоны снова заработали. У нас все еще были проблемы с 4500x волоконно-оптическими устройствами - мертвые пути, так как все это было избыточно. Он хотел изящно выключить и снова включить и выключить его, но в нем есть все наши 10-гигабитные iSCSI, и это сделало бы нашу среду vSphere (в основном все наши серверы) плохой неделей. Я уговорил его на постепенное переключение в режим резервирования, которое позаботилось об оставшихся проблемах.

TL; DR: Я внес довольно безобидные изменения в наше ядро ​​и вызвал ужасную проблему. Я сделал ошибку конфигурации, которая должна была быть предсказана, чтобы вызвать это - например, если бы я сначала не отключил VLAN и добавил их в portchannel, а затем в port, этого можно было бы избежать? Технический специалист Cisco не сказал этого; он сказал, что с периодами простоя более года и старыми версиями IOS подобные ситуации неудивительны.

4500x: программное обеспечение Cisco IOS, программное обеспечение IOS-XE, программное обеспечение коммутатора Catalyst 4500 L3 (cat4500e-UNIVERSALK9-M), версия 03.04.05.SG RELEASE SOFTWARE (fc1) ROM: 15.0 (1r) SG10

4948e: программное обеспечение Cisco IOS, программное обеспечение коммутатора Catalyst 4500 L3 (cat4500e-IPBASEK9-M), версия 15.0 (2) SG10, RELEASE SOFTWARE (fc1) ROM: 12.2 (44r) SG11

Похоже, вы создали широковещательный шторм, и единственный способ остановить его - отключить питание. Пройдя через это несколько раз, мы приняли некоторые рекомендации, рекомендованные Cisco:

• Вы должны иметь расширение VLAN до одного коммутатора доступа. Вы можете иметь столько VLAN, сколько вам нужно на коммутаторе доступа, но VLAN на любом коммутаторе доступа не должны соединяться транкингом с любым другим коммутатором доступа, а только с коммутатором распределения. Выполните это, вручную отключив все другие VLAN в магистрали с помощью switchport trunk allowed vlan команды.
• На распределительном коммутаторе не должно быть никаких интерфейсов доступа, только интерфейсы магистрали распространения.
• Не используйте VTP (установите все переключатели в transparentрежим).
• Ваши интерфейсы доступа должны быть portfastи bpduguard включены. Вы можете включить их глобально для всех ваших интерфейсов доступа, и ваши магистральные интерфейсы останутся неизменными. Если вы случайно подключите коммутатор к интерфейсу доступа, это заставит интерфейс войти err-diableи предотвратит петли STP.
• Не подключайте коммутатор доступа к другому коммутатору доступа. Подключайте коммутаторы доступа только к распределительным коммутаторам и только на магистральных интерфейсах.

Эти передовые методы предотвратят почти все проблемы STP и изолируют любые проблемы, которые случаются с одним коммутатором доступа.

В дополнение к превосходному совету Рона Мопина выше, я также нашел несколько сообщений на форуме Cisco о потенциальной большой ошибке, которую я сделал в процессе. Сначала я добавил виртуальные локальные сети к интерфейсам физических портов, а не к интерфейсу порт-канал, членами которого они были. Последнее является правильным способом сделать это, и я, возможно, вызвал проблему.