jakby pętla w sieci...
jakby pętla w sieci...
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.
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?
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.
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?
Re: jakby pętla w sieci...
Czyżby dopadła mnie klątwa Cisco Bug: CSCuu69332?
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"...
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"...
Re: jakby pętla w sieci...
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?
Re: jakby pętla w sieci...
Wszędzie spanning-tree mode rapid-pvst.
Topologia pierścienia. 5 switchy w pierścień, każdy switch dwa uplinki.
Połączenia po świetle.
Topologia pierścienia. 5 switchy w pierścień, każdy switch dwa uplinki.
Kod: Zaznacz cały
sw4-sw5
| |
sw6 |
| |
sw8-sw7
Re: jakby pętla w sieci...
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).
Zakładam, że nigdzie nie popełniłeś błędu zapominając o jakimś VLANie (na przełączniku).
Re: jakby pętla w sieci...
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
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
Re: jakby pętla w sieci...
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ś.
Re: jakby pętla w sieci...
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 ....
Re: jakby pętla w sieci...
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?
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?
Re: jakby pętla w sieci...
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.lbromirs pisze: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ś.
EDIT - te hosty są podpięte jedną nogą, więc raczej teaming wykluczony.
Re: jakby pętla w sieci...
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.
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.