CCIE.pl

site 4 CCIE wannabies
Dzisiaj jest 18 gru 2017, 19:17

Strefa czasowa UTC+01:00




Nowy temat  Odpowiedz w temacie  [ Posty: 11 ] 
Autor Wiadomość
Post #1 : 25 lis 2016, 15:30 
Offline
wannabe
wannabe

Rejestracja: 31 lip 2012, 09:16
Posty: 304
Ostatnio trafiłem na dziwną rzecz. Nowa lokalizacja, nowy sprzęt, nowe okablowanie.
Lokalizacja została uruchomiona i po pewnym czasie rano odcięło ją od świata. Routery z firewallami w sieci transferowej odpowiadały. Switche nie odpowiadały. Na routerach flapowało HSRP. Cluster firewalli niestabilny, co chwilę zmieniał się master.
Próby restartowania firewalli i routerów nie pomogły.
Brzmi jak jakiś sztorm w sieci, routery i firewalle tracą komunikację.

Przyjechał serwisant, zrestartował switche, wszystko zaczęło działać.

Aby wyeliminować podejrzewany problem z światłowodami łączącymi switche uruchomiłem udld agressive na wszystkich uplinkach.

Kolejnego dnia z rana podobna sytuacja, choć tym razem trochę lepiej. Około połowa pingów do switchy działa. Z trudem, ale zdalnie się dostałem na switche po posprawdzałem co mi się udało.
W logach widziałem jakieś frapowanie adresów MAC, co zazwyczaj oznacza chyba pętlę w sieci.
Obrazek
Zacząłem szukać portów accessowe, które odpowiadają flapowaniu i było to pomiędzy portami accesowymi a uplinkami.
Zacząłem więc shutdownować porty, pomogło dopiero zshutdownowanie jednego uplinka.
Sieć się ustabilizowała, więc zacząłem po kolei uruchamiać wszystkie porty. Włączyłem wszystkie i cisza...

Znalazłem sporą utylizację portów, które podejrzewałem za tworzenie pętli:
reliability 255/255, txload 255/255, rxload 1/255
reliability 255/255, txload 194/255, rxload 1/255
reliability 255/255, txload 255/255, rxload 1/255
reliability 255/255, txload 194/255, rxload 1/255

Są to porty, do których podłączone są kasy, chyba z jakimś systemem Linux. Nic specjalnie nowego w sieci dla tej lokalizacji się nie pojawiło.

Kolejnego dnia przygotowałem się na poranną powtórkę z rozrywki, ale od 2 dni cisza...

Na portach uruchomione mam bpdu guard storm-control
storm-control broadcast level pps 1k
storm-control multicast level pps 1k
storm-control action shutdown
ip dhcp snooping limit rate 10

Switche 2960x, soft c2960x-universalk9-mz.152-3.E1.
Generalnie soft i switche są stabilne od bardzo dawna w wielu lokalizacjach, nic tutaj nowego nie wdrażaliśmy.

Czy ma ktoś może jakieś podejrzenia co to mogło być?
Gdyby te porty miały jakąś pętlę, pchały multicasty, breadcasty to by je storm-control wyciął.
Problem chwilowo się nie pojawia, ale zastanawiam się co jeszcze na przyszłość mogę zdiagnozować?

Jakieś pomysły?


Na górę
Post #2 : 29 lis 2016, 00:40 
Offline
wannabe
wannabe

Rejestracja: 31 lip 2012, 09:16
Posty: 304
Czyżby dopadła mnie klątwa Cisco Bug: CSCuu69332? :D

http://ccie.pl/viewtopic.php?f=43&t=220 ... 92#p155892

Cisco jest dość oszczędne w opisie na stronie: "special DesMac", dot1x system-auth-control "may help"...


Na górę
Post #3 : 29 lis 2016, 13:51 
Offline
CCIE
CCIE

Rejestracja: 30 lis 2006, 08:44
Posty: 3884
Jakiego używasz STP? Na pewno wszędzie takiego samego? Patrząc na to, że pętli Ci się ruch z dostępu via uplink... chyba coś się rozjeżdża. Uplinki (2?) z tych 2960 idą... do czego? Masz jakiś rysunek topologii?


Na górę
Post #4 : 29 lis 2016, 16:34 
Offline
wannabe
wannabe

Rejestracja: 31 lip 2012, 09:16
Posty: 304
Wszędzie spanning-tree mode rapid-pvst.
Topologia pierścienia. 5 switchy w pierścień, każdy switch dwa uplinki.
Kod:
sw4-sw5
|      |
sw6    |
|      |
sw8-sw7
Połączenia po świetle.


Na górę
Post #5 : 29 lis 2016, 22:43 
Offline
CCIE
CCIE

Rejestracja: 30 lis 2006, 08:44
Posty: 3884
Hm, a pokaż 'sh spanning detail | i VLAN|changes'. Trzeba znaleźć port, który zaczął całą zabawę.

Zakładam, że nigdzie nie popełniłeś błędu zapominając o jakimś VLANie (na przełączniku).


Na górę
Post #6 : 29 lis 2016, 23:24 
Offline
wannabe
wannabe

Rejestracja: 31 lip 2012, 09:16
Posty: 304
Jeszcze sprawdzę v-lany, ale powinny być wszędzie takie same. Czy rzeczywiście efekt były taki, gdyby na którymś nie było jakiegoś? Dumam i dumam i nie widzę przyczyny.
Zmieniłem IOSa i chwilowo stabilnie. Zobaczymy do jutra co się będzie działo. Już trochę mało czasu zostało a eksperymentowanie, bo czas uruchamiać produkcyjnie ;-)


Na górę
Post #7 : 30 lis 2016, 01:32 
Offline
CCIE
CCIE

Rejestracja: 30 lis 2006, 08:44
Posty: 3884
Zmienianie na czuja IOSów może i pomoże, ale nie będziesz pewien czy to znowu 'cisza' jak to pisałeś wyżej, czy faktycznie błąd w IOSie poprawiony w wersji, którą zainstalowałeś.


Na górę
Post #8 : 03 gru 2016, 07:50 
Offline
wannabe
wannabe
Awatar użytkownika

Rejestracja: 10 maja 2009, 12:17
Posty: 179
Ja miałem niedawno podobne zjawisko, okazało się, że na serwerze na którym stał vmware, teeming (grupowanie) kart sieciowych, albo było źle skonfigurowane albo głupiało ....


Na górę
Post #9 : 07 mar 2017, 09:18 
Offline
wannabe
wannabe

Rejestracja: 31 lip 2012, 09:16
Posty: 304
To nie jest tak całkiem na czuja, gdzieś w naszej korporacji, w innym kraju ktoś się z tym już spotkał i dawno temu przesłał krótkie info wszystkim.
Mam już to w pełni potwierdzone, w kilku lokalizacjach to się pojawiło, po podłączeniu pewnych urządzeń. Szkoda, że Cisco nie pisze więcej na temat tego błędu - boją, że ktoś tego użyje do utworzenia ataku?


Na górę
Post #10 : 31 mar 2017, 12:39 
Offline
wannabe
wannabe

Rejestracja: 31 lip 2012, 09:16
Posty: 304
Cytuj:
Zmienianie na czuja IOSów może i pomoże, ale nie będziesz pewien czy to znowu 'cisza' jak to pisałeś wyżej, czy faktycznie błąd w IOSie poprawiony w wersji, którą zainstalowałeś.
A w tym coś jest. Wygląda na to, że gdy do sieci są wpinane hosty stojące na VMWare to wysyłają dziwne pakiety potrafiące tworzyć pętlę. Albo wysyłają te specyficzne pakiety z którymi związany jest opis BUGa, albo mają źle skonfigurowany teaming (potrzebujący wsparcia po stronie switchy). Muszę jeszcze sprawdzić dokładnie temat.

EDIT - te hosty są podpięte jedną nogą, więc raczej teaming wykluczony.


Na górę
Post #11 : 04 kwie 2017, 08:38 
Offline
member
member

Rejestracja: 14 sty 2011, 16:57
Posty: 48
Lokalizacja: WRO
Sprawdź sterowniki kart sieciowych pod vmwarem. Spotkałem się kiedyś z taką sytuacją. Pod Hyper-V było jeszcze ciekawiej bo po 5 minutach firewalle/switche wysyłające logi do serwera syslog (wirtualka na hyper-v) zaczynały broadcastować logami na całą podsiec mgmt.
Po analizie okazało się, że wirtualki nie wysyłały ARP requestów co około 5 minut i w tablicach MAC firewalli timeoutowały się wpisy dotyczące syslog serwera (MAC Address Table Aging-timeout, default = 5 minutes). Dlatego leciały logcasty ;). Problem udało się rozwiązać łopatologicznie - puszczałem przez cron table 1 pinga co 4min50sek z sysloga na firewalla.


Na górę
Wyświetl posty nie starsze niż:  Sortuj wg  
Nowy temat  Odpowiedz w temacie  [ Posty: 11 ] 

Strefa czasowa UTC+01:00


Kto jest online

Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 2 gości


Nie możesz tworzyć nowych tematów
Nie możesz odpowiadać w tematach
Nie możesz zmieniać swoich postów
Nie możesz usuwać swoich postów
Nie możesz dodawać załączników

Szukaj:
Przejdź do:  
cron
This Website is not sponsored by, endorsed by or affiliated with Cisco Systems, Inc. Cisco, Cisco Systems, CCDA, CCNA, CCDP, CCNP, CCIE, CCSI, CCIP, the Cisco Systems logo and the CCIE logo are trademarks or registered trademarks of Cisco Systems, Inc. in the United States and certain other countries. Używamy informacji zapisanych za pomocą cookies i podobnych technologii m.in. w celach reklamowych i statystycznych oraz w celu dostosowania naszych serwisów do indywidualnych potrzeb użytkowników. Mogą też stosować je współpracujące z nami firmy. W programie służącym do obsługi internetu można zmienić ustawienia dotyczące cookies. Korzystanie z naszych serwisów internetowych bez zmiany ustawień dotyczących cookies oznacza, że będą one zapisane w pamięci urządzenia.



Technologię dostarcza phpBB® Forum Software © phpBB Limited
Polski pakiet językowy dostarcza phpBB.pl