Jak zepsułem (połowę) mojej sieci?

Szukam porady po wydarzeniu, aby to wydarzenie się nie powtórzyło.

Mamy rdzeń sieciowy dwóch przełączników Cisco 4500x skonfigurowanych do redundancji VSS. Spośród nich mamy urządzenia iSCSI, nasze bladecenter HP dla naszego vSphere, a także zagregowane łącza do naszych przełączników dostępu użytkownika oraz parę przełączników 4948e dla urządzeń miedzianych w naszej serwerowni. Poza 4948es mamy parę przełączników 2960 dla dwóch łączy ISP oraz parę ASA jako zapory ogniowe. Całkiem przyzwoita redundancja, z wyjątkiem wielu urządzeń, które łączą się z 4948e mają tylko pojedyncze karty sieciowe - tyle tylko możemy zrobić.

Przygotowujemy się do zastąpienia naszych obecnych przełączników dostępu użytkowników (stare Ekstremalne) Meraki. Wdrażamy również AP Meraki, aby zastąpić nasze obecne Aruby. Część projektu bezprzewodowego obejmuje utworzenie nowych sieci VLAN i podsieci do zarządzania punktem dostępowym i gości bezprzewodowych.

Mieliśmy dwie zdefiniowane sieci VLAN (20 i 40) na 4500x, które nie były nigdzie używane - potwierdziło, że podsieci były puste, nie używały ich porty itp. Wszedłem do 4500x i wydałem „ no interface vlan 20”, a następnie przebudowałem je z podsiecią Chciałem. Następnie dodałem go do dwóch portów 10 Gb, które są podłączone do Meraki

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

Zauważyłem, że 20 i 40 sieci VLAN zostały zamknięte, więc wydałem no shutdownje. W tym momencie straciłem dostęp do Merakis, więc zdałem sobie sprawę, że nie dodałem sieci VLAN do interfejsu kanału portu dla tego łącza.

Połowa naszego środowiska stała się w tym momencie niedostępna

Nasz link do Internetu poszedł bardzo płatkowo. Nasze telefony VoIP Avaya nie mogły się wybierać ani wybierać. Mamy kilka połączonych miedzią urządzeń iSCSI, które stały się niedostępne - nie ma przerwy w działaniu dla użytkownika, ale wpłynęło to na nasze kopie zapasowe i archiwum poczty. Poszedłem do serwerowni i odłączyłem Merakis od 4500x (odłączyłem oba porty światłowodowe 10 Gb) na wypadek, gdyby jakoś stworzyłem pętlę - bez zmian. Przyznaję, że wpatrywałem się w to przez chwilę.

Podniosłem Oriona i zauważyłem, że jeden z naszych zewnętrznych przełączników (Cat2960) i jedna z naszych par ASA również nie działa. Wygląda na to, że mieliśmy częściową utratę łączności LAN, ale para ASA jest również połączona ze sobą zwrotnicą, a ich łącza zwrotne nie spadły, więc nie przełączyły się w tryb failover do tego, co nasze wewnętrzne urządzenia mogłyby osiągnąć. Wyłączyłem „wyłączony” ASA i internet ponownie stał się dostępny.

Zadzwoniłem do TAC i po kilku godzinach zmagań z technologem, który ciągle poprawiał każdą konfigurację portów dla każdego powalonego hosta, który pokazywałem mu na 4500x, zalogowałem się do jednego z naszych przełączników 4948e i pokazałem, jak nie może pingować rzeczy które były bezpośrednio podłączone i podłączone - jedno z naszych miedzianych urządzeń iSCSI opartych na systemie Windows, interfejs iLO w naszym bladecenter itp.

Przejrzał dzienniki i niczego nie znalazł, ale w tym momencie powiedział: „Wygląda jak błąd drzewa opinającego, nawet jeśli nie widzę tego w dziennikach”, więc ponownie uruchomiliśmy 4948e i wszystkie bezpośrednio połączone hosty wróciły z powrotem - w tym szafka Avaya, więc nasze telefony znów zaczęły działać. Nadal mieliśmy problemy z urządzeniami 4500x połączonymi światłowodem - martwe ścieżki, ponieważ wszystko było nadmiarowe. Chciał w nieuczciwy sposób włączyć zasilanie, ale ma to wszystkie nasze 10 Gbit iSCSI, a to spowodowałoby, że nasze środowisko vSphere (zasadniczo wszystkie nasze serwery) miałby zły tydzień. Namówiłem go, by dokonał płynnego przejścia na nadmiarowość, który zajął się pozostałymi problemami.

TL; DR: Dokonałem dość niewinnej zmiany w naszym rdzeniu i spowodowałem ohydny problem. Czy popełniłem błąd konfiguracji, który powinien był być przewidziany, aby to spowodować - np. Jeśli najpierw nie zamknę sieci VLAN i dodam je do kanału portowego, a następnie portów, czy można tego uniknąć? Technik Cisco tego nie powiedział; powiedział, przy ponad rocznych przestojach i starych wersjach IOS, takie sytuacje nie są zaskakujące.

4500x: Oprogramowanie Cisco IOS, oprogramowanie IOS-XE, oprogramowanie Catalyst 4500 L3 Switch (cat4500e-UNIVERSALK9-M), wersja 03.04.05.SG RELEASE SOFTWARE (fc1) ROM: 15.0 (1r) SG10

4948e: Oprogramowanie Cisco IOS, oprogramowanie Catalyst 4500 L3 Switch (cat4500e-IPBASEK9-M), wersja 15.0 (2) SG10, RELEASE SOFTWARE (fc1) ROM: 12.2 (44r) SG11

Wygląda na to, że stworzyłeś burzę rozgłoszeniową, a jedynym sposobem na jej zatrzymanie jest wyłączenie przełączników. Po kilkakrotnym przeżyciu tego, przyjęliśmy kilka najlepszych praktyk zalecanych przez Cisco:

• Sieć VLAN powinna mieć tylko jeden przełącznik dostępu. Możesz mieć tyle sieci VLAN, ile chcesz na przełączniku dostępu, ale sieci VLAN na dowolnym przełączniku dostępu nie powinny być połączone do żadnego innego przełącznika dostępu, tylko do przełącznika dystrybucji. Wymuszaj to, ręcznie wyłączając wszystkie inne sieci VLAN w linii głównej za pomocą switchport trunk allowed vlan polecenia.
• Przełącznik dystrybucji nie powinien mieć żadnych interfejsów dostępu, a jedynie interfejsy magistrali dystrybucyjnej.
• Nie używaj VTP (ustaw wszystkie przełączniki w transparenttryb).
• Twoje interfejsy dostępu powinny mieć portfasti bpduguard włączone. Możesz włączyć je globalnie dla wszystkich interfejsów dostępu, a interfejsy trunkingowe pozostaną nienaruszone. Jeśli przypadkowo podłączysz przełącznik do interfejsu dostępu, spowoduje to przejście interfejsu err-diablei zapobiegnie pętlom STP.
• Nie podłączaj przełącznika dostępu do innego przełącznika dostępu. Przełączniki dostępu podłączaj tylko do przełączników dystrybucyjnych i tylko na interfejsach magistrali.

Te najlepsze praktyki zapobiegną prawie wszystkim problemom STP i wyodrębnią wszelkie problemy, które zdarzają się w przypadku pojedynczego przełącznika dostępu.

Oprócz doskonałej porady Rona Maupina powyżej, znalazłem także kilka postów na forum Cisco o potencjalnym wielkim błędzie, jaki popełniłem w trakcie tego procesu. Najpierw dodałem VLAN do fizycznych interfejsów portów, a nie interfejs port-kanał, którego byli członkami. To drugie jest właściwym sposobem na zrobienie tego i mogłem spowodować problem.