20
Cisco Switche verlieren ständig Verbindung untereinander
Hallo zusammen,
ich benötige mal dringend eure Hilfe.
Bei uns in der Firma haben wir folgenden Aufbau:
DrayteK Vigor 2962 Uplink Ethernet-> Cisco SX350 10Gbit SFP-> Cisco CBS350SFP und von hier aus aus per SFP auf diverse andere Switche zb. Cisco SG200 / SG220
leider tritt vermehrt auf das Unterbrechungen stattfinden zb zum Draytek siehe Bild.
beobachtet man Nagios einige Zeit brechen stellenweise auch die Switche weg und sind nach einer gewissen Zeit wieder da.
Was kann das sein.
Wir arbeiten natürlich auch mit Vlans diese funktionieren aus unserer Sicht auch alle sauber.
Über einen hilfreichen Rat wäre ich Sehr dankbar.
ich benötige mal dringend eure Hilfe.
Bei uns in der Firma haben wir folgenden Aufbau:
DrayteK Vigor 2962 Uplink Ethernet-> Cisco SX350 10Gbit SFP-> Cisco CBS350SFP und von hier aus aus per SFP auf diverse andere Switche zb. Cisco SG200 / SG220
leider tritt vermehrt auf das Unterbrechungen stattfinden zb zum Draytek siehe Bild.
beobachtet man Nagios einige Zeit brechen stellenweise auch die Switche weg und sind nach einer gewissen Zeit wieder da.
Was kann das sein.
Wir arbeiten natürlich auch mit Vlans diese funktionieren aus unserer Sicht auch alle sauber.
Über einen hilfreichen Rat wäre ich Sehr dankbar.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 32383335312
Url: https://administrator.de/forum/cisco-switche-verlieren-staendig-verbindung-untereinander-32383335312.html
Ausgedruckt am: 22.12.2024 um 13:12 Uhr
20 Kommentare
Neuester Kommentar
Die Switches sollten Logs haben die zeigen was passiert.
Ich tippe auf eine STP-Topologieänderung, aber das wird uns nur das Log verraten können.
Ich tippe auf eine STP-Topologieänderung, aber das wird uns nur das Log verraten können.
2
Hallo,
vielen Dank für die zahlreichen Info....du merkst schon, das da noch ein paar Angaben fehlen. Oder?
Was sagen die Logs in der Zeit? wurde am Spanning Tree rumgestellt?
Wer Routet?
Wie sehen die Links zwischen den Switches aus? single Link oder LAG?
"Verlierst" du nur den Ping, wenn geroutet wird oder auch im gleichen Subnetz? Bleiben die Links auf dem gleichen Switch zumindest online?
Gruß
vielen Dank für die zahlreichen Info....du merkst schon, das da noch ein paar Angaben fehlen. Oder?
Was sagen die Logs in der Zeit? wurde am Spanning Tree rumgestellt?
Wer Routet?
Wie sehen die Links zwischen den Switches aus? single Link oder LAG?
"Verlierst" du nur den Ping, wenn geroutet wird oder auch im gleichen Subnetz? Bleiben die Links auf dem gleichen Switch zumindest online?
Gruß
Da kann man Kollege @LordGurke nur zustimmen. Du hast vermutlich kein oder ein fehlerhaftes Spanning Tree Design realisiert was zu diesen Probleme führt.
Switchlogs sind die erste Anlaufstelle.
Leider sind auch die Informationen mehr als oberflächlich so das man nur raten und Schrotschuss Infos geben kann.
Checke auch alle deine SFP Optiken und Stecker. Insbesonder bei 10Gig die Kabellängen! OM2 Kabel können lediglich 90 Meter bei 10G (OM3=300m, OM4=440m). Oft sind es Überlängen bestimmt Kabel du ebenso ein Verhalten auslösen.
Switchlogs sind die erste Anlaufstelle.
Leider sind auch die Informationen mehr als oberflächlich so das man nur raten und Schrotschuss Infos geben kann.
- Generell auf allen Switches RSTP aktivieren.
- Wenn du einen Layer 3 Core hast und die Peripherie im Access rennt sollten der oder die Core Switches immer eine höhere Spanning Tree Priority haben! Das gilt auch für ein reines L2 Netz mit sternförmigem Design. Die Priority Werte müssen Vielfache von 4096 sein wie z.B. 8192. Kleinerer Wert bedeutet höhere Priority. Siehe dazu auch HIER und auch HIER.
Checke auch alle deine SFP Optiken und Stecker. Insbesonder bei 10Gig die Kabellängen! OM2 Kabel können lediglich 90 Meter bei 10G (OM3=300m, OM4=440m). Oft sind es Überlängen bestimmt Kabel du ebenso ein Verhalten auslösen.
Danke für die schnellen antworten.
es wurde nichts umgestellt es wurden lediglich in der Weihnachtspause mal alle Systeme runtergefahren und neu gestartet.
Sry für meine Unwissenheit aber Netzwerker bin ich jetzt noch kein Genie drin.
meint ihr diesen Log ?
es wurde nichts umgestellt es wurden lediglich in der Weihnachtspause mal alle Systeme runtergefahren und neu gestartet.
Sry für meine Unwissenheit aber Netzwerker bin ich jetzt noch kein Genie drin.
meint ihr diesen Log ?
Ja. Du kannst ja auch selber sehen das gerade der Link 11 hier massive Probleme hat, weil es dort immer wieder zu einem physischen Ausfall des Links kommt und das in permanenten Abständen. Sowas darf natürlich in einem stailen und sauber konfigurierten Netzwerk niemals der Fall sein, ganz besonders nicht auf Backbone Links! Hier musst du nach dem Grund suchen zu dem du oben ja schon diverse Tips bekommen hast.
Außerdem ist die Spanning Tree Priority zumindesten für die Core Switches falsch! Diese sollten zwingend auf einen höheren Wert z.B. 8192 gesetzt werden um die Root Switches (Core) fest und statisch vorzugeben und damit die Backbone Root Links.
Wie Kollege @tech-flare unten richtig sagt ist zudem bei einem der Screenshots das STP Setup falsch und korrespondiert NICHT zu den anderen Switches! Steht also zu befürchten das da noch mehr grobe Anfänger- und Flüchtigkeitsfehler im Setup stecken.
Man kann dir nur raten jemanden an die Hand zu nehmen der weiss was Spanning Tree ist und wie man es in einem Netzwerk wie deinem richtig und insbesondere mit korrekter Core Priority konfiguriert. Und...
Du musst herausfinden woher das Port Flapping an z.B. Port 11 kommt! Vermutlich ist nicht nur Port 11 davon betroffen?!
Das alle Switches zumindestens die aktuellste Firmware geflasht haben sollten, sollte ebenso klar sein.
Außerdem ist die Spanning Tree Priority zumindesten für die Core Switches falsch! Diese sollten zwingend auf einen höheren Wert z.B. 8192 gesetzt werden um die Root Switches (Core) fest und statisch vorzugeben und damit die Backbone Root Links.
Wie Kollege @tech-flare unten richtig sagt ist zudem bei einem der Screenshots das STP Setup falsch und korrespondiert NICHT zu den anderen Switches! Steht also zu befürchten das da noch mehr grobe Anfänger- und Flüchtigkeitsfehler im Setup stecken.
Man kann dir nur raten jemanden an die Hand zu nehmen der weiss was Spanning Tree ist und wie man es in einem Netzwerk wie deinem richtig und insbesondere mit korrekter Core Priority konfiguriert. Und...
Du musst herausfinden woher das Port Flapping an z.B. Port 11 kommt! Vermutlich ist nicht nur Port 11 davon betroffen?!
Das alle Switches zumindestens die aktuellste Firmware geflasht haben sollten, sollte ebenso klar sein.
Bild 3 hat eine andere Spanning Tree Einstellung, als Bild 1 und 2
Bei 615k Topology Change Counts verkneife ich mir die Frage nach den Zeitstempeln.
Ich denke ein vollständig deaktiviertes STP wäre besser als diese "Konfig"
Ich denke ein vollständig deaktiviertes STP wäre besser als diese "Konfig"
Damit hätte der TO dann keinerlei Loop Protection mehr. Das wäre ein großes Risiko. Gerade auch im Hinblick auf die o.a. schlampig konfigurierte Infrastruktur! ☹️
@aqui
Um die Fragen noch zu beantworten
Wir haben eine sterntopologie mit Single link.
Der sx350 Routet nicht .
Pung geht auch im gleichen subnetz verloren.
Auf allen switchen ist rstp aktiviert.
Port flapping kommt nur bei einzelnen Systemen vor wo möglicherweise 100m überschritten sind. Dies sind aber keine Trunk ports
Um die Fragen noch zu beantworten
Wir haben eine sterntopologie mit Single link.
Der sx350 Routet nicht .
Pung geht auch im gleichen subnetz verloren.
Auf allen switchen ist rstp aktiviert.
Port flapping kommt nur bei einzelnen Systemen vor wo möglicherweise 100m überschritten sind. Dies sind aber keine Trunk ports
Besteht eine Möglichkeit den changelog Zähler zurückzusetzen?
Auf allen switchen ist rstp aktiviert.
Mit entsprechender STP Priority auf dem Core?? 🤔 Das ist ein zwingendes Muss auf dem Core in einem korrekten Sterndesign um die Root Ports sicher zu definieren.Pung geht auch im gleichen subnetz verloren.
Pung??Wenn du Winblows Maschinen pingst hast du ja sicher auf dem Radar das in deren lokaler Firewall das ICMP Protokoll (Ping) deaktiviert ist! Ping mit Windows Maschinen scheitert also generell sofern man es nicht in der lokalen Firewall erlaubt:
https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
Nur das du das auf dem Radar hast wenn du lokal pingst...
Wenn es dennoch scheitert hast du ein anderes, gravierenderes Problem.
Alle Systeme hast du mit der aktuellsten Firmware geflasht?? Für die SGx50 Systeme ist Mitte Dez.23 eine neue Firmware mit diversen Fixes released worden.
@aqui
Wir haben bei unserem Coreswitch die priority auf 8192 geändert.
Alle Switche auf Classic STP gestellt und den Haken bei Spanning Tree State rausgenommen.
Im SX350 zb. wird der Root Port erkannt der zum SG350 SFP führt.
es treten aber immer mal wieder Aussetzer im Ping auf.
Unter dem Spanning Tree Topologiechange ist die Zeit auch nicht mehr so kurz wie vorher der letzte wechsel ist jetzt über eine Stunde her
Wir haben bei unserem Coreswitch die priority auf 8192 geändert.
Alle Switche auf Classic STP gestellt und den Haken bei Spanning Tree State rausgenommen.
Im SX350 zb. wird der Root Port erkannt der zum SG350 SFP führt.
es treten aber immer mal wieder Aussetzer im Ping auf.
Unter dem Spanning Tree Topologiechange ist die Zeit auch nicht mehr so kurz wie vorher der letzte wechsel ist jetzt über eine Stunde her
Und warum guckst du nicht ins Log der Switches?
Da steht der Grund für TC drin.
Aber die Pingverluste können noch andere Gründe haben.
Die Mac der IP, die Du pingst, liegt auf einem Port. Sind hinter dem Port noch mehr IPs nicht stabil erreichbar?
Da steht der Grund für TC drin.
Aber die Pingverluste können noch andere Gründe haben.
Die Mac der IP, die Du pingst, liegt auf einem Port. Sind hinter dem Port noch mehr IPs nicht stabil erreichbar?
Alle Switche auf Classic STP gestellt
Ein schwerer Fehler! Kein verantwortungsvoller Netzwerk Admin nutze heute noch das veraltete STP 802.1d sondern ausschliesslich nur noch das deutlich bessere RSTP, 802.1w. Das weiss eigentlich auch ein IT Laie.
Das solltest du also dringenst im Setup wieder korrigieren und zwar für ALLE Switches netzwerkweit!!
Es wäre vermutlich besser du nimmst dir jemanden an die Hand der netzwerktechnisch weiss was er tut?!
Hallo aqui
Danke für die Antwort.
Das RSTP Protokoll hat ja lt. deinem verlinkten Artikel lediglich Vorteile in Bezug auf die Möglichkeit bei redundanten Pfaden diese zu deaktivieren und im Bedarfsfall wieder zu aktivieren. Wir haben aber keine redundanten Pfade.
Also sollte doch grundsätzlich das STP Protokoll auch nutzbar sein? Es funktioniert jedenfalls aktuell damit besser und das war auch ziemlich sicher vor dem Neustart auf den Switchen überall aktiv.
Auf dem SX-350 können wir die aktuelle Konfig gerade nicht installieren, über den sind auch die ESXi mit dem Massenspeicher verbunden, wenn die Verbindung überraschend wegbricht, sind alle VMs hart runtergefahren. Steht aber auf dem Plan.
Und zu den Logs:
Auf dem SX-350 habe ich alle Logs mal gelöscht. Dann abgewartet, bis wieder die ersten Ping aussetzer im Netz waren. (PC via SG220 zum CBS350, dann zum SX350). Es war aber weder im Log vom SX350, noch vom CSB350 zu finden.
Weder bei RAM Memory noch Flash Memory.
Unter Administration - System Log - ist bei RAM alles aktiv von Emergency bis Debug, bei Flash Memory ist nur Emergency, Alert, Critical und Error aktiv.
Noch mal 2 generelle Fragen:
1. Die Einstellung mit Green Ethernet - 802.3 Energy Efficient Ethernet - sollte die aktiv sein (enable)? Oder lieber aus? Was hat das für Auswirkungen?
2. Die Einstellung "Smart Ports" steht standardmäßig wohl auf "Enable by Auto Voice WLAN". Ist das auch ok? Wir haben kein extra VLAN für VoIP. Die Telefone hängen genau wie die Clients im selben VLAN und teilweise sogar die Clients am zweiten Ethernetport
Danke für die Antwort.
Das RSTP Protokoll hat ja lt. deinem verlinkten Artikel lediglich Vorteile in Bezug auf die Möglichkeit bei redundanten Pfaden diese zu deaktivieren und im Bedarfsfall wieder zu aktivieren. Wir haben aber keine redundanten Pfade.
Also sollte doch grundsätzlich das STP Protokoll auch nutzbar sein? Es funktioniert jedenfalls aktuell damit besser und das war auch ziemlich sicher vor dem Neustart auf den Switchen überall aktiv.
Auf dem SX-350 können wir die aktuelle Konfig gerade nicht installieren, über den sind auch die ESXi mit dem Massenspeicher verbunden, wenn die Verbindung überraschend wegbricht, sind alle VMs hart runtergefahren. Steht aber auf dem Plan.
Und zu den Logs:
Auf dem SX-350 habe ich alle Logs mal gelöscht. Dann abgewartet, bis wieder die ersten Ping aussetzer im Netz waren. (PC via SG220 zum CBS350, dann zum SX350). Es war aber weder im Log vom SX350, noch vom CSB350 zu finden.
Weder bei RAM Memory noch Flash Memory.
Unter Administration - System Log - ist bei RAM alles aktiv von Emergency bis Debug, bei Flash Memory ist nur Emergency, Alert, Critical und Error aktiv.
Noch mal 2 generelle Fragen:
1. Die Einstellung mit Green Ethernet - 802.3 Energy Efficient Ethernet - sollte die aktiv sein (enable)? Oder lieber aus? Was hat das für Auswirkungen?
2. Die Einstellung "Smart Ports" steht standardmäßig wohl auf "Enable by Auto Voice WLAN". Ist das auch ok? Wir haben kein extra VLAN für VoIP. Die Telefone hängen genau wie die Clients im selben VLAN und teilweise sogar die Clients am zweiten Ethernetport
RSTP arbeitet nicht so rabiat und legt den gesamten Baum um. Außerdem ist RSTP schneller. Oft in 1-2 Sekunden fertig.
Bezüglich der Switches die das Storage erschließen schüttelt es mich und ich muss den Rat noch mal wiederholen: Hole dir dringend Hilfe! Dir fehlt sehr viel Basiswissen. Ganz offenkundig.
RSTP kann für die Pings verantwortlich sein, muss es aber nicht.
Der Pfad zu den MAC Adressen kann auch andere Instabilitäten aufweisen.
Bezüglich der Switches die das Storage erschließen schüttelt es mich und ich muss den Rat noch mal wiederholen: Hole dir dringend Hilfe! Dir fehlt sehr viel Basiswissen. Ganz offenkundig.
RSTP kann für die Pings verantwortlich sein, muss es aber nicht.
Der Pfad zu den MAC Adressen kann auch andere Instabilitäten aufweisen.
Wenn es das denn nun war bitte deinen Thread hier dann auch als erledigt schliessen!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?
@aqui vielen Dank für die zahlreichen Hilfestellungen. Letztendlich lag es an was ganz anderen aber von dir kamen wenigstens produktive Hilfestellungen . Dem Rest würd ich persönlich mal empfehlen nicht so großspurig aufzutreten…
Zitat von @Butzundweg:
@aqui vielen Dank für die zahlreichen Hilfestellungen. Letztendlich lag es an was ganz anderen aber von dir kamen wenigstens produktive Hilfestellungen . Dem Rest würd ich persönlich mal empfehlen nicht so großspurig aufzutreten…
@aqui vielen Dank für die zahlreichen Hilfestellungen. Letztendlich lag es an was ganz anderen aber von dir kamen wenigstens produktive Hilfestellungen . Dem Rest würd ich persönlich mal empfehlen nicht so großspurig aufzutreten…
Na da lehnt sich ja einer ziemlich weit aus dem Fenster.
Solche banalen Fragen stellen und dann nicht mal die Lösung präsentieren oder das Problem beim Namen nennen.
Aber was will man von einem Admin erwarten, der es nicht mal schafft seinen eigenen Infrastruktur auf ein einheitliches Spanning Tree Protkoll einzustellen - siehe [ Bild 3] - unabhänging davon, ob es das Problem war.
Cheers
1
