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
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
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 263678
Url: https://administrator.de/contentid/263678
Ausgedruckt am: 22.11.2024 um 00:11 Uhr
22 Kommentare
Neuester Kommentar
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 ?
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 ?
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 ?
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.
Die Modi bestimmen das RSTP Verhalten udn Recovery Time auf diesen Ports im Failover- oder Linkloss Fall.
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 "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.
Kannst du mir sagen was diese Meldung aussagt?
Nein, die ist so kryptisch da kann kein normaler Mensch was mit anfangen 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 ?
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
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 !
Ja, Bootmeldungen sind zu sehen, kurze Zeit ist auch die Konfiguration möglich, bis es irgendwann abbricht.
Das sieht nicht wirklich gut aus... 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.