knorkator
Goto Top

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!

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

aqui
Lösung aqui 29.12.2020 aktualisiert um 10:35:34 Uhr
Goto Top
So sähe ein 2er Core Stack 48P mit annähernder Vollbestückung und 8 SG220 Access Switches in der CPU Last aus:
cpu
Klassischer Native Stack:
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)
Sehr wichtig ist die STP Priority im Core anzupassen und auf einen hohen Wert (modulo 4096) zu setzen damit der Core immer zwimngend Root Switch ist:
prio
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:
mcfilter
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.
vlansnoop
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.
Knorkator
Knorkator 29.12.2020, aktualisiert am 21.04.2022 um 16:17:54 Uhr
Goto Top
Hallo Aqui,

vielen Dank für die Antwort.

Kann ich einsehen, woher die CPU Auslastung kommt?

Spricht etwas gegen ein Update?
Nicht, dass der aufgrund der hohen Auslastung irgendwie abbricht?

Gruß

Edit:
Habe die letzten 3 Bilder erst eben gesehen.... keine Ahnung warum.
Bei mir sieht es wie folgt aus:

igmp

stp

multicast

Du schreibst, dass man dies nur machen darf, wenn sonst keine weiteren STP Verfahren aktiv sind.
Bzgl. der restlichen Umgebung:

Ich habe auf dem Core mehrere LAGs zu weiteren SG350X-24P Stacks (max 2 ohne Routing) konfiguriert.
Jeder Switch ist mit einer 10GB Glasfaser-Leitung an einem SG350XG-24F des Core-Switches verbunden.
Hier ist nichts bzgl. STP konfiguriert.
Die 4096 auf dem Core habe ich damals gemäß Deinem Ratschlag schon konfiguriert.
aqui
Lösung aqui 29.12.2020 aktualisiert um 10:43:32 Uhr
Goto Top
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.47
Kann 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.
.
Knorkator
Knorkator 29.12.2020 aktualisiert um 11:40:22 Uhr
Goto Top
Ok. Bin dran.. hoffentlich bis gleich..
;)

Edit:
So.. ich bin etwas weiter mit dem Core

1. Das Update ist drauf auf dem Core. -> Die anderen Switche haben das Update schon erhalten.
2. CDP Status unter Administration, Discovery - CDP, Properties habe ich Disabled.
3. Bridge Multicast Filtering Status habe ich enabled und auf "source specifig ip group address" umgestellt.
4. IPV4 IGMP Snooping habe ich Enabled und die Vlans entsprechend umgestellt.... fast..

1. Brechen mir nun ständig die Verbindungen zu den anderen Switchen weg - Zum Glück bin ich alleine in der Firma face-smile
2. Habe ich reichlich VLANs und erhalte während der Aktivierung von IGMP Querier Status nun die Meldung: "The Snooping Querier has reached the limit of Supported VLANS"
Hier muss noch erwähnt werden, dass nicht alle VLANs vom Core geroutet werden.
Einige laufen zur Firewall durch und werden dort verwaltet bzw. reglementiert.
Kann ich diese vom "IGMP Querier Status" ausnehmen?

Was mir noch nicht ganz klar ist..
Muss ich das IGMP Snooping auch auf allen Access-Switchen aktivieren?
Und auch für die Vlans?

Vielen Dank für die Unterstützung.
em-pie
em-pie 29.12.2020 um 12:26:37 Uhr
Goto Top
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
Knorkator
Knorkator 29.12.2020 um 12:55:02 Uhr
Goto Top
So..

Ich habe jetzt auf allen Switches folgendes gemacht:
CDP inaktiv.
STP Aktiv.
Bridge Multicast Filtering auf allen Enabled und im entsprechenden VLAN auf Source Specific IP Group Address umgestellt.
IPV4, IGMP Snooping Status auf Enabled sowie auf allen Vlans den IGMP Status auf Enabled gesetzt.
Den IGMP Querier Status habe ich nur auf dem Core aktiviert.. hier ist ja fraglich, wie ich mit der Limitierung umgehen soll.

Die Situation hat sich inzwischen etwas beruhig.
Ein Pinginfoview von einem am Core angeschlossenen Client ping jetzt alle Switches an.. mal schauen.
aqui
Lösung aqui 29.12.2020 aktualisiert um 14:41:16 Uhr
Goto Top
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... face-wink
Knorkator
Knorkator 29.12.2020, aktualisiert am 21.04.2022 um 16:16:52 Uhr
Goto Top
Zitat von @aqui:

Ich habe jetzt auf allen Switches folgendes gemacht:
Firmware solltest du in jedem Falle auch updaten !
Hatte ich doch schon.
;)

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... face-wink
RSTP ist ja per Default eingestellt... hätte also RSTP schreiben müssen.
face-smile

Obwohl alle Switch passend eingestellt waren, hatte ich weiterhin permantent Ping-Abbrüche (sowie Reihenweise Fehler im Log des Core-Switches).
Ich bin davon ausgegangen, dass es mit den LAG´s zu tun hat.
Hier habe ich dann jeder LAG einen Link Deaktiviert.
Dadurch sank auch die Auslastung.
Dann habe ich die Links nach und nach wieder aktiviert und die Auslastung beobachtet.
Inzwischen sind alle seit ner h wieder aktiv und die Auslastung ist im Rahmen denke ich (Bin ja derzeit eh der einzige User im Unternehmen..).

cpu

Hast abschließend noch einen Tipp bzgl. der IGMP Querier Status Begrenzung?
Ich muss hier mal gucken wofür das überhaupt ist..
face-smile

Vielen Dank!
Knorkator
Knorkator 29.12.2020 um 15:26:20 Uhr
Goto Top
Zitat von @em-pie:
Habe keine Ahnung gehabt, woher der Mist kam, aber nach dem Update vor 6 Wochen ist nun alles im Lot.
Da ich die CPU Auslastung nicht im Monitoring habe, kann es durchaus sein, dass der Switch nun schon seit 2019 unter Volldampf steht..

Muss ich wohl mal nachholen..
aqui
aqui 29.12.2020 aktualisiert um 19:58:44 Uhr
Goto Top
Der 350er kann doch wunderbar SNMP und das kleine STP Tool ist dein bester Freund... face-wink
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 ??
lag1
lag2
Knorkator
Knorkator 29.12.2020 um 20:04:07 Uhr
Goto Top
Zitat von @aqui:
Der 350er kann doch wunderbar SNMP und das kleine STP Tool ist dein bester Freund... face-wink
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.
Ich nutze bisher ein eher allg. SNMP-"Set" in Zabbix welches nur Traffic usw. monitort..
Für CPU war ich bisher zu bequem.. werde ich nachholen.

Mmmhh, kann es sein das du vergessen hast LACP beim LAG Setup zu setzen und den Hash auch IP/Mac ??
lag1
lag2
Tatsächlich.. steht auf MAC.

Werde es morgen oder so auf den Access Switchen und dann auf dem Core ändern.

Vielen Dank!!
aqui
aqui 30.12.2020 um 11:48:36 Uhr
Goto Top
Ich nutze bisher ein eher allg. SNMP-"Set" in Zabbix welches nur Traffic usw. monitort..
Für CPU war ich bisher zu bequem.. werde ich nachholen.
Umso besser. Zabbix ist natürlich schöner... face-wink
Werde es morgen oder so auf den Access Switchen und dann auf dem Core ändern.