clemens-der-vierte
Goto Top

Problem im lokalen Netzwerk - Teilausfall

Hallo @all,
seit kurzer Zeit bestehen in dem von mir zu verwaltenden Netzwerk (für mich) nicht nachvollziehbare Probleme.

Ist-Zustand:
Netgear Switche (2x Backbone, Etagenswitche sind redundant an beide angeschlossen), STP ist aktiv (802.1w), Segmentierung in VLANs.

Problembeschreibung:
Einige der Etagenswitche können nicht mehr gemanged werden (kein Zugriff, per Telnet, Seriell, Web). Das Switching funktioniert jedoch. Teilweise fallen einzelne Ports an verschiedenen Switchen aus, dies sieht dann so aus, dass am Client ein Netzwerkkabel erkannt wird, aber keine IP-Adresse bezogen werden kann.
Ein Neustart wurde schon durchgeführt, das Problem das kein Managemant möglich ist besteht jedoch wieder.

Es wurden keine Grundlegenden Änderungen am Netzwerk vorgenommen, außer ein Switch der gegen ein neueres Modell getauscht wurde (defekt).


Habt ihr eine Idee woher diese Probleme kommen? Ideen wie ich die Ursache einkreisen / finden kann?

Vielen Danke bereits im Vorraus!

Gruß
Clemens

Content-ID: 263678

Url: https://administrator.de/forum/problem-im-lokalen-netzwerk-teilausfall-263678.html

Ausgedruckt am: 22.12.2024 um 13:12 Uhr

runasservice
runasservice 17.02.2015 um 11:57:43 Uhr
Goto Top
Hallo,

Neustart wurde schon durchgeführt

Alle Switche neu gestartet, bzw. kurz ausser Betrieb genommen?
clemens-der-vierte
clemens-der-vierte 17.02.2015 aktualisiert um 12:24:09 Uhr
Goto Top
Ja, es wurden alle Switche Neugestartet (kurz stromfrei geschalten)
Dani
Dani 17.02.2015 um 12:53:29 Uhr
Goto Top
Hallo Clemens,
ich würde mal an einem Switch hinlaufen, per Konsole drauf und mir das Logfile anschauen. Da wird normalerweise schön mitgeschrieben was passierte. Spontan würde ich auf STP-Fehler tippen.


Gruß,
Dani
clemens-der-vierte
clemens-der-vierte 17.02.2015 aktualisiert um 16:10:03 Uhr
Goto Top
Hallo,

@Dani:
per Konsole drauf... - ist leider bei einigen nicht möglich. Beim Versuch der Verbindung bleibt das Fenster leer (normal erscheint sofort der Login).
Aber dies betrifft nicht alle Switche. Aus einem den ich (noch) verwalten kann habe ich folgende Meldungen aus dem Log:

#show logging buffered

Buffered (In-Memory) Logging : enabled
Buffered Logging Wrapping Behavior : On
Buffered Log Count : 706

<5> JAN 01 00:00:41 x.x.x.x-1 TRAPMGR[46004164]: traputil.c(663) 706 %% Cold Start: Unit: 0
<6> JAN 01 00:00:41 x.x.x.x-1 UNKN[44377052]: dot1s_sm.c(1286) 705 %% Discarding BPDU:Cannot process BPDU on port(23) until migration timer expires
<5> JAN 01 00:00:41 x.x.x.x-1 TRAPMGR[54353512]: traputil.c(663) 704 %% Link Up: Unit: 1 Slot: 0 Port: 21
<6> JAN 01 00:00:40 x.x.x.x-1 UNKN[44377052]: dot1s_sm.c(1286) 703 %% Discarding BPDU:Cannot process BPDU on port(23) until migration timer expires
<5> JAN 01 00:00:40 x.x.x.x-1 TRAPMGR[44377052]: traputil.c(663) 702 %% Spanning Tree Topology Change Initiated: 0, port Number: 23, Unit: 1
<5> JAN 01 00:00:40 x.x.x.x-1 TRAPMGR[44377052]: traputil.c(663) 701 %% Spanning Tree Topology Change: 0, Unit: 1
<6> JAN 01 00:00:35 x.x.x.x-1 UNKN[44377052]: dot1s_sm.c(1351) 691 %% dot1sPrxMachine(): Rcvd BPDU in Discard State on port 23
<6> JAN 01 00:00:33 x.x.x.x-1 UNKN[44377052]: dot1s_sm.c(1351) 685 %% dot1sPrxMachine(): Rcvd BPDU in Discard State on port 23
<6> JAN 01 00:00:24 x.x.x.x-1 UNKN[52434072]: dtl_pdu_landd.c(186) 659 %% invalid usp 1.0.23
<6> JAN 01 00:00:23 x.x.x.x-1 UNKN[52434072]: dtl_pdu_landd.c(186) 658 %% invalid usp 1.0.20
<6> JAN 01 00:00:23 x.x.x.x-1 UNKN[52434072]: dtl_pdu_landd.c(186) 657 %% invalid usp 1.0.20

Kann mir einer bei der Interpretation helfen?

Außerdem gibt es weitere Auffälligkeiten:
- die LED eines Ports am Switch leuchtet, obwohl kein Kabel angeschlossen ist. Der Port funktioniert aber ohne Probleme
- die "System Up Time" steht bei einigen Geräten bei 15min.


Gruß Clemens
aqui
aqui 17.02.2015 um 16:27:33 Uhr
Goto Top
STP ist aktiv (802.1w)
Das ist aber kein STP sondern RSTP !!
  • Hast du Switches im Netz die KEIN RSTP sprechen oder sprechen können
  • Ist das durchgängig auf ALLEN Switches aktiv ?
  • Wenn ja hast du für den Root Switch und den Backup Root Switch im RSTP Pfad die entsprechenden Priorities vergeben ??
  • Sind die NetGear Gurken ALLE auf dem akrtuellsten Firmware Release Stand ?
Du hast de facto ein Spanning Tree Problem im Netz ! Vermutlich duch eine falsche oder fehlerhafte RSTP Konfiguration ?!
runasservice
runasservice 17.02.2015 um 16:36:24 Uhr
Goto Top
Hallo,

Rcvd BPDU in Discard State on port 23
Cannot process BPDU on port(23) until migration timer expires

sieht aus fie ein STP-Problem? Hast Du den neuen Switch aus richtig konfiguriert? Wie oft kommt die Meldung:

Rcvd BPDU in Discard State on port 23
clemens-der-vierte
clemens-der-vierte 17.02.2015 um 16:49:45 Uhr
Goto Top
- RSTP ist auf allen Switches aktiviert. Es sind aber neben den Etagenswitchen noch kleine Switche z.b. in Meetingräumen vorhanden (nicht managebare 8 Port Switche u.ä.) - diese sind aber auch nicht neu)

- Auf dem Root und Backup Switch sind die Prioritäten entsprechend vergeben (Root: niedrigste, Backup etwas höher, Etagenswitche Standard (32T) belassen)
- Firmware ist auf dem aktuellsten Stand - allerdings haben die Geräte auch schon einige Jahre auf dem Buckel
clemens-der-vierte
clemens-der-vierte 17.02.2015 um 17:02:21 Uhr
Goto Top
Hallo runasservice,
der neue Switch ist genau wie die alten Konfiguriert (VLAN, Ports, RSTP...)
Die o.g. Meldung erschien 6x im Log, immer auf Port 23 (Uplink).

Gruß
runasservice
runasservice 17.02.2015 um 17:05:16 Uhr
Goto Top
Hallo,

ein Rückbau schon probiert? Den euen Switch wieder ausschalten, alle anderen Geräte ein Reset. Dein Netz müsste dann wieder, bis auf den neuen Switch laufen. So kann Du sicher auschliessen das der neue Switch die Ursache ist.
aqui
aqui 17.02.2015 um 19:49:35 Uhr
Goto Top
Hast du die RSTP Prio Modulo 4096 eingestellt also mit 4096er Steps dazwischen ? Das solltest du zwingend machen und niemals die 0 verwenden, denn damit können die Billigheimer wie NetGear nicht umgehen !
Hast du Loop Guard bzw. Protection am Laufen ? (Sofern die NG Gurken sowas überhaupt supporten ?!)
Hoffentlich, denn wenn dir jemand auf den Miniswitches ein Loop steckt hast du genau den Spass den du siehst ?
Wäre eine Option.... Man müsste aber mal genau die Logs auswerten wo diese Topo Changes im RSTP genau stattfinden und was sie auslöst.
Hast du im RSTP Setup Edge und Point to Point Ports sauber gesetzt ?
clemens-der-vierte
clemens-der-vierte 18.02.2015 aktualisiert um 10:44:38 Uhr
Goto Top
Hallo,

@runasservice: Ein Rückbau ist nicht einfach so möglich, da ja einige Arbeitsplätze da dran hängen.

@aqui:
Die Bridge Prios sind in 4096er Schritten vergeben ("0" nicht vergeben).
Bitt korrigiere mich wenn es nicht stimmt, "BPDU Guard" ist nicht gleich "Loop Guard".
Die älteren Switche die hauptsächlich eingesetzt werden haben, soweit ich es gesehen habe, keine derartige Funktion. Der eine ausgetauschte (Modell M4100-26G) hat die Funktion "BPDU Guard", diese ist aber deaktiviert.

Was meinst du genau mit "Setup Edge und Point to Point Ports sauber gesetzt"? Kannst du bitte noch mal erläutern welche Option du meinst?

Wie würdest du vorgehen um den Fehler zu lokalisieren?

Gruß,
Clemens

Nachtrag:
Die Logeinträge ( Discarding BPDU und Spanning Tree Topology Change ) sind 2 Tage - also zuletzt nicht wieder aufgetreten.
Noch eine Frage: Wie kann es sein das häufig "Link Up" / "Link Down" Meldungen erscheinen? Dies betrifft verschiedene Ports, die Meldungen sind aber auch ~2Tage alt.
aqui
Lösung aqui 18.02.2015, aktualisiert am 20.03.2015 um 08:13:43 Uhr
Goto Top
Ja richtig ! BPDU Guard und Loop Guard sind zwei unterschiedliche Features !
Der eine filtert und blockt BPDU Frames auf Endgeräteports, damit keiner mit einer falsch konfigurierten Bridge Prio deinen Spanning Tree aus dem Tritt bringt.
Loop Guard blockt eigene BPDUs wenn die am gleichen Port auftauchen.
Letzteres ist die Funktion die vor Loops an diesen unmanged Billigswitches schützt.
haben, soweit ich es gesehen habe, keine derartige Funktion.
War zu befürchten bei Billigheimer NG face-sad
"Setup Edge und Point to Point Ports sauber gesetzt"?
Im RSTP kann man Ports diesen Modus fest zuweisen. P2P Ports sind in der regel immer Uplink Ports und Edge Ports sind Endgeräte Ports.
Die Modi bestimmen das RSTP Verhalten udn Recovery Time auf diesen Ports im Failover- oder Linkloss Fall.
clemens-der-vierte
clemens-der-vierte 18.02.2015 aktualisiert um 12:20:13 Uhr
Goto Top
Vielen Dank für die Erläuterung!

Konfiguriert habe ich diese Einstellungen nicht, aber soweit ich es gesehen habe stehen die Einstellungen deiner Erläuterung entsprechend richtig auf meinen Switchen. Ich vermute, dass hier die automatische Erkennung diese Einstellung getroffen hat.
Auf dem neuen Switch ist die Option "Auto Edge" aktiviert. Bei den "alten" kann ich diese Option aber nicht sehen. UND: das neue Modell M4100-26G hat eine "Loop Guard" Funktion (die aber aktuell noch diabled ist).

Ist es denn existenziell das Edge und Point to Point Ports konfiguriert sind? (Zumal es mit dieser Einstellung (automatik) etliche Jahre ohne Probleme lief).
aqui
aqui 19.02.2015 um 09:06:59 Uhr
Goto Top
Nein, das ist eher kosmetisch und nicht zwingend. Es hat lediglich Einfluss auf die RSTP Konvergenz Zeiten im Netz und ursächlich auch mit deinem Problem nichts zu tun.
Kannst du in deinen Spanning Tree Logs irgendwelche zyklischen Topology Changes sehen ?
clemens-der-vierte
clemens-der-vierte 20.02.2015 um 14:32:37 Uhr
Goto Top
Topologie Changes sind bisher keine wieder aufgetreten. Diese Meldungen würde ich zeitlich mit dem Neustart der Switche (am vergangenen Sonntag) einordnen. Von daher würde ich davon ausgehen, dass diese durch das Neustarten der Switche (nacheinander) ausgelöst wurden.

Auf dem Backbone Switch habe ich allerdings einige Tage später noch folgende Meldung:
<6> JAN 04 21:24:17 x.x.x.x-1 NIM[114970352]: nim_intf_map_api.c(378) 478 %% nimGetUnitSlotPort: internal interface number 0 out of range

Diese Meldung ist zweimal vorhanden (einmal Montag, einmal Mittwoch). Kannst du mir sagen was diese Meldung aussagt?

Allgemein gibt es aktuell keine Störungen mehr im Netzwerk (bisher auch keine ausgefallenen Ports o.ä.). Zwei Fehler sind allerdings immer noch vorhanden:
- Einige Switche sind nicht mangebar (Telnet, Web, Console)
- bei einigen Switchen steht die "Uptime" (häufig bei ca. 30min)

Gruß Clemens
aqui
aqui 20.02.2015 um 18:48:52 Uhr
Goto Top
Kannst du mir sagen was diese Meldung aussagt?
Nein, die ist so kryptisch da kann kein normaler Mensch was mit anfangen face-sad
Frage ist was mit internal interface gemeint ist ?? Mamagement ??
Da kann wohl wirklich nur der Hersteller weiterhelfen. Solltest du mal an dessen Hotline posten !

Bei den nicht managebaren Switches kann es sein das du das Default VLAN ggf. nicht oder fehlerhaft auf den tagged Uplinks überträgst.
Die meisten Hersteller fahren in einem dualen Modsu das das Default VLAN immer untagged ist. Das muss aber nicht bei allen so sein.
Hier musst du also sicherstellen das das Default VLAN richtig mit übertragen wird, denn das Management Interface steckt ja immer im Default VLAN.
Ansonsten bleibt ja nur eine Fehlkonfiguration bei IP Maske oder Gateway ?!
Das Uptime Ding ist wohl eher ein Bug ?!! Sind alle Switches auf dem aktuellsten Firmware Stand ?
clemens-der-vierte
clemens-der-vierte 23.02.2015 aktualisiert um 17:06:12 Uhr
Goto Top
Das die Switche nicht managebar sind, denke ich, hängt nicht an irgendwelchen VLAN Konfigurationen, da sich diese Switche ja auch per Console nicht ansprechen lassen. Das mit der Uptime sehe ich genauso... aber wodurch tritt dies plötzlich auf??? Kann dies der eine neue (neues Modell) Switch auslösen??

Eventuell werde ich demnächst doch noch mal diesen außer Betrieb nehmen, einen der jetzigen Problemkinder neustarten und schauen ob es wieder auftritt.
Firmware ist auf allen Switchen auf dem aktuellen Stand.

Und noch zwei Fragen an die Profis:
1. Wann ist es sinnvoll MSTP anstatt von RSTP einzusetzen?
2. Was muss ich beachten bei der Aktivierung der Loop Guard Funktionalität?
aqui
Lösung aqui 23.02.2015, aktualisiert am 20.03.2015 um 08:14:28 Uhr
Goto Top
da sich diese Switche ja auch per Console nicht ansprechen lassen.
Du meinst nichtmal mit serielle Konsole direkt am Switch klappt das ??
Stimmt Baudrate, Bit und Flow Controll Setting an deinem terminal Programm (PuTTY oder TeraTerm) ?

Wennd as wirklich der Fall sein sollte gibt es nur 2 mögliche Fehler:
1.) Im Setup ist der Konsol Zugriff aus Sicherheitsgründen deaktiviert worden
2.) Der Switch ist defekt
Ersteres kannst du einzig nur über einen Factory Reset beheben, denn die Konsole ist immer der allerletzte Zugriff wenn man sich den Ast abgesägt hat auf dem man sitzt. Ist die deaktiviert hilft einzig nur der Werkseinstellung Reset.
diesen außer Betrieb nehmen, einen der jetzigen Problemkinder neustarten
Wäre dann der richtige Schritt aber immer mit dem Factory Reset !!

Zu deinen Fragen:
1.) Wenn du kannst solltest du immer PVRSTP einsetzen wenn du mehrere VLANs fährst. Das wäre immer der beste Weg. Wenn du allerdings billige Switches hast die keinen Art von PVSTP supporten dann bleibt dir nur MSTP.
Simples Single Span Verfahren in einem VLAN Umfeld mit einer zentralen Instanz birgt immer den gravierenden Nachteil das wenn in einem VLAN es rumpelt es immer in allen VLANs rumpelt und es zu Einschränkungen oder Ausfällen kommt.
In einem PVSTP Design ist das dann einzig nur auf ein VLAN limitiert und in den anderen passiert nichts.
MSTP ist so ein bischen was von jedem, da es nur mit einem Grouping von VLANs funktioniert. Ist aber immer noch die bessere Wahl als ein Single Span Verfahren, was STP Steinzeit ist.

2.) Gar nix. Einfach einschalten und gut iss.
Was man machen sollte ist wenn Loop Guard zuschlägt versetzt es den betreffenden Port in den sog. Error Disable Mode, schaltet ihn also physisch ab. Der bleibt solange bestehen bevor du als Netzwerk Admin den Port im Setup wieder aktivierst.
Das ist etwas nervig in großen Netzen, da du immer manuell Hand anlegen musst.
Es macht hier sinn einen Recoery Timer zu setzen auf z.B. 3 oder 5 Minuten, dann versucht der Switch selber den Port wieder zu aktivieren. Ist immer noch ein Loop da geht er wieder für 5 Minuten runter.
Das ist sinnvoller als manuelle Intervention durch den Admin face-wink
clemens-der-vierte
clemens-der-vierte 19.03.2015 um 17:36:01 Uhr
Goto Top
So, nachdem nun ein bisschen "Beobachtungszeit" vergangen ist, möchte ich nochmal ein Statusupdate geben:
  • Das neue Modell der Etagenswitche wurden gegen ein Baugleiches Modell getauscht (d.h. alle Etagenswitche sind nun wieder gleich alt)
-> Der Fehler das etliche Switche sich nicht konfigurieren lassen (weder per Telnet noch per Konsole am Gerät [Terminal Settings sind korrekt]) ist noch immer da. (der neu eingesetzte Switch zeigt das Problem nicht).
-> Hier vermute ich das ein Factory Reset und Neukonfiguration der Etagenswitche das Problem behebt.

  • Allerdings gibt es aktuell noch ein weiteres Problem:
Der zweite (Backup) Coreswitch ist aktuell abgeschalten. Sobald er ins Netz kommt steht "alles". Es ist keine Kommunikation mehr möglich. Diesen habe ich auch bereits nach Factory Reset neu konfiguriert, Problem besteht weiterhin.
-> An dieser Stelle wurde aber entschieden, dass neue Hardware beschafft wird. Dazu möchte ich gern eure Anregungen, dazu öffne ich aber, der Übersichtlichkeit halber, eine neue Frage.


Ich sehe es an dieser Stelle als gelöst an und DANKE allen für die Hilfe und Fachkundigen Auskünfte) !!

VG Clemens
aqui
aqui 19.03.2015 um 19:20:36 Uhr
Goto Top
weder per Telnet noch per Konsole am Gerät [Terminal Settings sind korrekt])
Wenn du diese Geräte mit angeschlossener Konsole bootest kannst du dann deren Bootmeldung sehen ?
Wenn nicht und auch nicht nach einem harten Factory Reset dann sind die de facto Geräte defekt !
Hier vermute ich das ein Factory Reset und Neukonfiguration der Etagenswitche das Problem behebt.
Ja, vermutlich. Und dann auch gleich einen Firmware Update auf die allerneueste Firmware machen bei diesen Switches, unbedingt.
Sobald er ins Netz kommt steht "alles".
Das ist völlig normal, denn wenn du RSTP machst gibt es eine Topology Recalculation bei der alle Ports erstmal in den Blocking Mode gehen.
Das sollte aber allerspätestens nach 5 Minuten verschwunden sein und eine sauber RSTP Topology errchnet sein.
(show spanning-tree detail Kommando !)
An dieser Stelle wurde aber entschieden, dass neue Hardware beschafft wird.
OK, damit sind dann alle weiteren Forschungen ja obsolet...
Hoffentlich dann die richtige HW und keinen HP Müll !
clemens-der-vierte
clemens-der-vierte 20.03.2015 um 08:12:49 Uhr
Goto Top
Zitat von @aqui:

> weder per Telnet noch per Konsole am Gerät [Terminal Settings sind korrekt])
Wenn du diese Geräte mit angeschlossener Konsole bootest kannst du dann deren Bootmeldung sehen ?
Ja, Bootmeldungen sind zu sehen, kurze Zeit ist auch die Konfiguration möglich, bis es irgendwann abbricht.

Ja, vermutlich. Und dann auch gleich einen Firmware Update auf die allerneueste Firmware machen bei diesen Switches, unbedingt.
Firmware gibt es leider keine aktuellere face-sad

> Sobald er ins Netz kommt steht "alles".
Das ist völlig normal, denn wenn du RSTP machst gibt es eine Topology Recalculation bei der alle Ports erstmal in den
Blocking Mode gehen.
Das sollte aber allerspätestens nach 5 Minuten verschwunden sein und eine sauber RSTP Topology errchnet sein.
(show spanning-tree detail Kommando !)
Das ist richtig, aber auch nach >7min hat sich daran nichts geändert.
aqui
Lösung aqui 20.03.2015, aktualisiert am 04.06.2015 um 17:34:07 Uhr
Goto Top
Ja, Bootmeldungen sind zu sehen, kurze Zeit ist auch die Konfiguration möglich, bis es irgendwann abbricht.
Das sieht nicht wirklich gut aus... face-sad
Wenn es die aktuelle Firmware ist musst du von einem Defekt ausgehen...
Das ist richtig, aber auch nach >7min hat sich daran nichts geändert.
Ohh oh... da ist dann aber noch mehr defekt bei den Kisten. Das darf niemals so sein. Auch ein völlig unkonfigurierter Spanning Tree kommt wieder auf die Füsse.
Aber ok, wenns eh was Neues gibt, und hoffentlich kein HP, dann bloß schnell weg mit dem alten Müll.