Cisco SG350 Core Stack hat 100 Prozent CPU Auslastung
Hallo zusammen,
bei uns läuft seit etwas über einem Jahr ein Cisco Core-Stack mit folgenden Geräten:
2x SG350XG-24F
2x SG350X-24P
Nun ist mir aufgefallen, dass die CPU Auslastung scheinbar dauerhaft bei 100% liegt.
Nach kurzer Recherche scheine ich nicht der einzige mit diesem Problem zu sein.
Empfehlung ist hier im Ersten Step ein Firmwareupdate auf die neueste Version -> Aber das wird ja meist empfohlen wenn es Probleme gibt.
Da sich hier ja einige gut mit Cisco auskennen (Danke nochmal an Aqui für den Support bei der Einführung der Cisco Switche), wollte ich vorher kurz nachfragen, ob es hier noch etwas zu beachten gibt?
Backup ist vorhanden.
Derzeitige FW: 2.4.5.71
Neue FW: 2.5.5.47
Vielen Dank im voraus!
bei uns läuft seit etwas über einem Jahr ein Cisco Core-Stack mit folgenden Geräten:
2x SG350XG-24F
2x SG350X-24P
Nun ist mir aufgefallen, dass die CPU Auslastung scheinbar dauerhaft bei 100% liegt.
Nach kurzer Recherche scheine ich nicht der einzige mit diesem Problem zu sein.
Empfehlung ist hier im Ersten Step ein Firmwareupdate auf die neueste Version -> Aber das wird ja meist empfohlen wenn es Probleme gibt.
Da sich hier ja einige gut mit Cisco auskennen (Danke nochmal an Aqui für den Support bei der Einführung der Cisco Switche), wollte ich vorher kurz nachfragen, ob es hier noch etwas zu beachten gibt?
Backup ist vorhanden.
Derzeitige FW: 2.4.5.71
Neue FW: 2.5.5.47
Vielen Dank im voraus!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 636075
Url: https://administrator.de/forum/cisco-sg350-core-stack-hat-100-prozent-cpu-auslastung-636075.html
Ausgedruckt am: 22.12.2024 um 02:12 Uhr
12 Kommentare
Neuester Kommentar
So sähe ein 2er Core Stack 48P mit annähernder Vollbestückung und 8 SG220 Access Switches in der CPU Last aus:
Klassischer Native Stack:
Die Hauptgründe für solche hohe CPU Last sind in der Regel
Das kann man aber nur machen wenn es keine anderen STP Verfahren im Netz gibt. Sehr häufig werdensolche Switches mit inkompatiblen PVSTP+ oder PVRSTP+ Komponenten gemischt was dann zu solchen Loops und Fehlern führt. Hier muss dann der STP Mode zwingend angepasst werden !
Thema Multicast.
IGMP Snooping sollte generell im Core (und auch in allen Access Komponenten) aktiviert sein. Beim SG ist dazu global in allen VLANs das MC Filtering zu aktivieren:
Danach muss man in den IGMP Snooping Settings das Snooping pro VLAN aktivieren. Wenn in den VLAN Segmenten kein aktiver Multicast PIM Router ist dann muss der Switch zwingend auch noch die Querrier Funktion erfüllen was dann unbedingt anzuhaken ist. IGMPv3 sollte man auch auswählen.
Als Infrastruktur Protokoll sollte man CDP global deaktiveren und rein nur LLDP laufen lassen.
PNP ist auch immer abzuschalten damit die Switches nicht nach Hause telefonieren...
Das wären so die größsten Housekeeping ToDos die auf einem Core zu machen sind um das sauber zu handhaben.
Klassischer Native Stack:
Die Hauptgründe für solche hohe CPU Last sind in der Regel
- Loops durch falsche oder fehlerhaftes Spanning Tree
- Fehlendes IGMP Snoopping (Multicast)
Das kann man aber nur machen wenn es keine anderen STP Verfahren im Netz gibt. Sehr häufig werdensolche Switches mit inkompatiblen PVSTP+ oder PVRSTP+ Komponenten gemischt was dann zu solchen Loops und Fehlern führt. Hier muss dann der STP Mode zwingend angepasst werden !
Thema Multicast.
IGMP Snooping sollte generell im Core (und auch in allen Access Komponenten) aktiviert sein. Beim SG ist dazu global in allen VLANs das MC Filtering zu aktivieren:
Danach muss man in den IGMP Snooping Settings das Snooping pro VLAN aktivieren. Wenn in den VLAN Segmenten kein aktiver Multicast PIM Router ist dann muss der Switch zwingend auch noch die Querrier Funktion erfüllen was dann unbedingt anzuhaken ist. IGMPv3 sollte man auch auswählen.
Als Infrastruktur Protokoll sollte man CDP global deaktiveren und rein nur LLDP laufen lassen.
PNP ist auch immer abzuschalten damit die Switches nicht nach Hause telefonieren...
Das wären so die größsten Housekeeping ToDos die auf einem Core zu machen sind um das sauber zu handhaben.
Spricht etwas gegen ein Update?
Nein, im Gegenteil, solltest du zwingend machen. Die Live Screenshots oben stammen von einem Core mit aktueller 2.5.5.47Kann ich einsehen, woher die CPU Auslastung kommt?
Im GUI nicht aber bei den IOS Switches gibt es das Kommando show proc cpu wo das geht. Ggf. haben die SG Modelle den auch über das CLI. Musst du mal checken.Du kannst sehen das du kein IGMP Snooping aktiviert hast ! Das ist schlecht, denn deine Switches müssen dann immer zwingend alle MC Pakete fluten auf alle Ports. Das passiert rein in CPU und kostet entsprechend Performance. Ein grober Fehler das nicht zu machen.
Wichtigste ToDos sind also erstmal
- Update
- Multicast IGMP Snooping aktivieren.
Moin,
hatte die gleiche Sch...
Ich kam von einer FW 2.3.5.63.
Nach einem Udpdate auf die 2.5.5.47 war dann Ruhe im Bau.
Switche (im Stack) sind hier SG350X-48 und SG350X-24P
Der Switch ackert bei uns nur im Layer zwei und Themen wie 802.1x sind nicht realisiert..
Habe keine Ahnung gehabt, woher der Mist kam, aber nach dem Update vor 6 Wochen ist nun alles im Lot.
Gruß
em-pie
hatte die gleiche Sch...
Ich kam von einer FW 2.3.5.63.
Nach einem Udpdate auf die 2.5.5.47 war dann Ruhe im Bau.
Switche (im Stack) sind hier SG350X-48 und SG350X-24P
Der Switch ackert bei uns nur im Layer zwei und Themen wie 802.1x sind nicht realisiert..
Habe keine Ahnung gehabt, woher der Mist kam, aber nach dem Update vor 6 Wochen ist nun alles im Lot.
Gruß
em-pie
Ich habe jetzt auf allen Switches folgendes gemacht:
Firmware solltest du in jedem Falle auch updaten !STP Aktiv.
Wenn, dann solltest du immer RSTP aktivieren und nicht mehr das völlig veraltete STP.Wenn CDP inaktiv solltest du aber immer LLDP als Infrastruktur Protokoll aktivieren.
Ansonsten alles richtig gemacht. Schaun mer also mal...
Der 350er kann doch wunderbar SNMP und das kleine STP Tool ist dein bester Freund...
RX Dropped Pkts Problem
CPU Last OID für 5 Sekunden = .1.3.6.1.4.1.9.6.1.101.1.7.0
CPU Last OID für 1 Minute = .1.3.6.1.4.1.9.6.1.101.1.8.0
CPU Last OID für 5 Minuten = .1.3.6.1.4.1.9.6.1.101.1.9.0
RX Dropped Pkts Problem
CPU Last OID für 5 Sekunden = .1.3.6.1.4.1.9.6.1.101.1.7.0
CPU Last OID für 1 Minute = .1.3.6.1.4.1.9.6.1.101.1.8.0
CPU Last OID für 5 Minuten = .1.3.6.1.4.1.9.6.1.101.1.9.0
Dadurch sank auch die Auslastung.
Mmmhh, kann es sein das du vergessen hast LACP beim LAG Setup zu setzen und den Hash auch IP/Mac ??