Nadmiernie obciążony CPU przełącznika Cisco

Zarządzając nawet niewielką siecią w firmie możemy zetknąć się od czasu do czasu z problemem nadmiernego obciążenia CPU na przełącznikach. Pokażę dziś jak odnaleźć przyczynę problemu na urządzeniach Cisco. Procesor w switchach nie bierze udziału w normalnym ruchu pakietów, te zadania realizowane są sprzętowo, odpowiada jednak za szereg innych czynności: przesyłanie broadcastów, zarządzanie wewnętrzną tablicą ARP, zarządzanie i monitorowanie poszczególnych portów, obsługa protokołu spanning-tree czy nawet sterowanie diodami na panelu.

Symptomy

Gdy CPU jest zajęty przez nadmierną ilość nadzwyczajnych zadań nie nadąża z wykonywaniem tych obowiązkowych, prowadzi to do wielu nietypowych zachowań i może również wpłynąć na inne urządzenia w sieci lub inne switche. Poniżej jedne z najczęściej pojawiających się symptomów:

  • zmiana topologii Spanning-tree – switch nie zdąży odpowiedzieć na pakiety BPDU i powoduje przeliczanie algorytmu
  • brak lub długi czas odpowiedzi na zapytania ICMP, SNMP lub odrzucone próby połączenia poprzez telnet
  • niestabilność połączeń EtherChannel
  • problemy z przekazywaniem pakietów DHCP – stacje klienckie nie dostają adresów z serwera
  • straty pakietów
  • niepoprawne działanie protokołu UDLD

O nadmiernym wykorzystaniu procesora dowiedzieć się możemy również z logów i programów monitorujących nasze urządzenia, o ile takie posiadamy. Polecam stosowanie choćby najprostszych, dzięki nim o problemach dowiadujemy się o wiele szybciej i zadziałać możemy zanim pojawią się nieprzyjemne w skutkach symptomy.

Sprawdzamy obciążenie

Najszybsza metodą na sprawdzenie co obciąża nasze urządzenie. Gdy nie możemy podłączyć się zdalnie łączymy się bezpośrednio podłączając się kablem konsolowym. Logujemy się do trybu uprzywilejowanego i używamy komendy:

show processes cpu sorted


dzięki temu otrzymamy listę wszystkich procesów oraz procentową wartość obciążenia jakie powodują. Najważniejsze informacje to całkowita wartość wykorzystania CPU przez ostatnie pięć sekund, minutę oraz pięć minut. Dzięki temu możemy ocenić czy sytuacja się poprawia. Wynik dla ostatnich pięciu sekund składa się z dwóch liczb, pierwsza to obciążenie, druga natomiast określa jak wiele czasu procesor poświęcał na odbieranie pakietów.

Podczas normalnego ruchu sieciowego procesor wykorzystywany jest od kilku do 30-40%, podczas obsługi zdarzeń rzadszych takich jak przeliczanie STP, wykonywanie niektórych komend IOS, włączone dubugowanie lub połączeń SNMP obciążenie może chwilowo podskoczyć do wyższych poziomów, lecz nie powinno to wpływać na problemy z działaniem urządzenia. Dopiero dłużej utrzymujący sie natłok zadań sięgający 80-90% powodowac będzie widoczne symptomy.

Jeżeli chcemy sprawdzić historię zajętości procesora użyć możemy komendy:

show processes cpu history


otrzymamy urocze wykresy ASCII dla ostatnich 60 sekund, 60 minut i 72 godzin. Pomimo swojej prostoty zawierają wszelkie interesujące nas informacje, na czele z wartością obciążenia i oznaczeniem chwilowych skoków. Dane na wykresie przedstawione są w taki sposób, że z lewej strony znajdują się najświeższe dane.

Odnajdowanie przyczyny

Mając do dyspozycji dane, możemy zająć się odnajdowaniem przyczyny. Zazwyczaj sprowadzać się to będzie do odnalezienia procesu, który powoduje największe obciążenie. W przypadku jakiego ostatnio uświadczyłem, winowajca był serwer IPAM, który obciążał switcha zapytaniemi poprzez SNMP, tymczasowo pomagał restart serwisu na serwerze, ale ostatecznym rozwiązaniem była aktualizacja firmware’u switcha, który jak się okazało niepoprawnie obsługiwał zapytania. Jedne z częściej występujących problemów to:

  • błędy oprogramowania
  • zbyt duża ilość VLANów lub instancji STP – process Spanning Tree
  • duża ilość pakietów broadcast, w tym DHCP
  • błędy w konfiguracji routingu w switchach warstwy 3
  • obszerne zapytania SNMP
  • problemy z zasilaniem

Analizą i przeciwdziałaniem na poszczególne przyczyny zajmiemy się w jednym z późniejszych wpisów.

Przeczytaj także...

Dodaj komentarz