12
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!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 636075
Url: https://administrator.de/contentid/636075
Printed on: April 16, 2024 at 23:04 o'clock
12 Comments
Latest comment
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.
- Loops durch falsche oder fehlerhaftes Spanning Tree
- Fehlendes IGMP Snoopping (Multicast)
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:
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.
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:
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.
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:
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.
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.
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
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.
;)
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
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.
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
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.
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.
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...
Zitat von @aqui:
Hatte ich doch schon.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...
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..).
Hast abschließend noch einen Tipp bzgl. der IGMP Querier Status Begrenzung?
Ich muss hier mal gucken wofür das überhaupt ist..
Vielen Dank!
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..Habe keine Ahnung gehabt, woher der Mist kam, aber nach dem Update vor 6 Wochen ist nun alles im Lot.
Muss ich wohl mal nachholen..
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 ??Zitat von @aqui:
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
Ich nutze bisher ein eher allg. SNMP-"Set" in Zabbix welches nur Traffic usw. monitort..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
Dadurch sank auch die Auslastung.
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 ??
Tatsächlich.. steht auf MAC.Werde es morgen oder so auf den Access Switchen und dann auf dem Core ändern.
Vielen Dank!!
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... Für CPU war ich bisher zu bequem.. werde ich nachholen.
Werde es morgen oder so auf den Access Switchen und dann auf dem Core ändern.
