6
Spanning Tree mit Procurve 1800
Hallo zusammen.
Wir haben hier noch einige 1800er Procurves im Einsatz, die mit einer aktuellen Firmware zumindest nicht mehr ganz so dumm sind was Spanning Tree betrifft.
Jetzt habe ich ein kleines Test Setup erstellt mit einem 1800er und einem 2910al.
Auf dem 2910al habe ich MSTP aktiviert und in den default Einstellungen belassen, d.h. alle VLANs auf IST und keine weiteren Instances.
Grundsätzlich funktioniert das auch, Loops werden erkannt und Ports disabled. Nur in einem Fall nicht.
Fall 1 --> Loop wird erkannt:
Fall 2 --> Loop wird erkannt:
Fall 3 --> Loop wird nicht erkannt:
Fall 3 funktioniert auch mit einem einem anderen Switch nicht, bei dem STP deaktiviert ist, also gehe ich davon aus, dass es eigentlich nicht am 1800er liegt.
Jetzt zu meiner Frage:
Kann ich Fall 3 irgendwie abfangen, ohne die 1800er zu ersetzen?
Das der 1800er den Loop nicht erkennen kann ist mir klar, aber mir würde es auch reichen, wenn der 2910al die Verbindung zum 1800 kappt, so wie es bei Fall 2 passiert.
Vielleicht gibt es irgendeine MSTP Option oder ich müsste grundsätzlich eine andere Protokollversion wählen. Eine Art Storm Control, die mir den Port deaktiviert sobald ein Grenzwert an Broad-/Multicasts überschritten wird, gibt es bei 2910al leider nicht. Damit hätte man zwar das Problem nicht gelöst, aber die Auswirkungen eingeschränkt.
Wenn die Antwort lautet "Das geht nicht", dann ist das vollkommen ok. Die 1800er müssen dann einfach weg.
Vielen Dank
Wir haben hier noch einige 1800er Procurves im Einsatz, die mit einer aktuellen Firmware zumindest nicht mehr ganz so dumm sind was Spanning Tree betrifft.
Jetzt habe ich ein kleines Test Setup erstellt mit einem 1800er und einem 2910al.
Auf dem 2910al habe ich MSTP aktiviert und in den default Einstellungen belassen, d.h. alle VLANs auf IST und keine weiteren Instances.
Grundsätzlich funktioniert das auch, Loops werden erkannt und Ports disabled. Nur in einem Fall nicht.
Fall 1 --> Loop wird erkannt:
Fall 2 --> Loop wird erkannt:
Fall 3 --> Loop wird nicht erkannt:
Fall 3 funktioniert auch mit einem einem anderen Switch nicht, bei dem STP deaktiviert ist, also gehe ich davon aus, dass es eigentlich nicht am 1800er liegt.
Jetzt zu meiner Frage:
Kann ich Fall 3 irgendwie abfangen, ohne die 1800er zu ersetzen?
Das der 1800er den Loop nicht erkennen kann ist mir klar, aber mir würde es auch reichen, wenn der 2910al die Verbindung zum 1800 kappt, so wie es bei Fall 2 passiert.
Vielleicht gibt es irgendeine MSTP Option oder ich müsste grundsätzlich eine andere Protokollversion wählen. Eine Art Storm Control, die mir den Port deaktiviert sobald ein Grenzwert an Broad-/Multicasts überschritten wird, gibt es bei 2910al leider nicht. Damit hätte man zwar das Problem nicht gelöst, aber die Auswirkungen eingeschränkt.
Wenn die Antwort lautet "Das geht nicht", dann ist das vollkommen ok. Die 1800er müssen dann einfach weg.
Vielen Dank
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: 269876
Url: https://administrator.de/forum/spanning-tree-mit-procurve-1800-269876.html
Ausgedruckt am: 22.12.2024 um 21:12 Uhr
6 Kommentare
Neuester Kommentar
Arbeitet das VLAN 10 bei dir ein einer gemeinsamen MSTP Instance oder hast du separate Instances dafür genommen.
Der 1800 ist ein sehr doofer Swicth der nur rein Single Span supportet und kein MSTP. Zwar nutzt MSTP das RSTP Protokoll aber unterschiedliche Instances sind einem Single Span Verfahren natürlich unbekannt. Folglich sind diese also dann nur sehr bedingt kompatibel und du hast dann solche Probleme wie du sie oben siehst.
Die Szenarien 2 und 3 sind so oder so nicht komplett mit STP abzufangen, denn dafür benötigst du eine sog. Loop Protection Funktion um ganz sicher zu gehen. Die billigen Dummswitches haben das meist nicht.
STP kann nicht erkennen wenn eigene BPDU Frames am gleichen Port zurückkommen ! Solch ein Problem kommt sehr häufig vor wenn das kleine unmanaged Switches sind bei denen ein Loop gesteckt wird.
Damit sendet der Port dann ein eigens BPDU an sich selber. Das erkennt er nicht und somit looped der Port dann und flutet das ganze Netz.
Dagegen hilft dann nur die Loop Protection die den Port dann sofort in Error Disable nimmt.
OK bei dir mit aktiven STP Switches jetzt nicht primär das Theam aber trotzdem bleibt das Problem zwischen MSTP und Single Span Verfahren.
Der 1800 ist ein sehr doofer Swicth der nur rein Single Span supportet und kein MSTP. Zwar nutzt MSTP das RSTP Protokoll aber unterschiedliche Instances sind einem Single Span Verfahren natürlich unbekannt. Folglich sind diese also dann nur sehr bedingt kompatibel und du hast dann solche Probleme wie du sie oben siehst.
Die Szenarien 2 und 3 sind so oder so nicht komplett mit STP abzufangen, denn dafür benötigst du eine sog. Loop Protection Funktion um ganz sicher zu gehen. Die billigen Dummswitches haben das meist nicht.
STP kann nicht erkennen wenn eigene BPDU Frames am gleichen Port zurückkommen ! Solch ein Problem kommt sehr häufig vor wenn das kleine unmanaged Switches sind bei denen ein Loop gesteckt wird.
Damit sendet der Port dann ein eigens BPDU an sich selber. Das erkennt er nicht und somit looped der Port dann und flutet das ganze Netz.
Dagegen hilft dann nur die Loop Protection die den Port dann sofort in Error Disable nimmt.
OK bei dir mit aktiven STP Switches jetzt nicht primär das Theam aber trotzdem bleibt das Problem zwischen MSTP und Single Span Verfahren.
Danke für die Antwort.
Die Grafik war vielleicht etwas missverständlich. VLAN 10 war nur ein Beispiel, gleiches gilt für VLAN 20 oder jedes andere getaggte VLAN.
Ich habe keine Instances konfiguriert, das heißt alles auf der default Instance:
Wenn ich VLAN 1, also das Native VLAN des Trunks, am 1800er brücke, dann geht der Uplink Port auf "Blocking".
Wenn ich ein getaggtes VLAN brücke, dann passiert nichts. Das ist der Punkt den ich nicht so richtig verstehe.
Ich habe das so gedeutet, also würde STP die eigenen BPDUs erkennen, aber komischerweise nur auf dem untagged VLAN.
STP erkennt die eigenen BPDUs doch auch, wenn ich zwei Ports an einem Swich brücke der STP kann, oder funktioniert das anders?
Ich habe für den Uplink zum 1800er jetzt testweise Loop Protection aktiviert und das funktioniert für alle VLANs.
Das heißt es wäre vielleicht eine Alternative STP auf dem Uplink Ports zu den 1800ern zu deaktiveren, und dafür Loop Protection zu nutzen. Oder sollte Loop-Protection grundsätzlich zusätzlich zu STP genutzt werden?
Da der Uplink bei mir eigentlich ein LACP Trunk/Etherchannel ist muss man nur mit den Timern aufpassen, da sonst beim automatischen reaktivieren des Ports ein Loop erkannt wird, bevor LACP die Verbindung ausgehandelt hat. Das geht dann ewig so weiter.
Leider funktioniert Loop Protection anscheinend doch nur auf für das untagged VLAN und ist wohl eher für Access Ports gedacht (alles andere hätte mich irgendwie auch gewundert). Damit bringt es für mich leider keinen Vorteil, da dieser Fall auch mit STP funktioniert.
Danke für die Hilfe.
Die Grafik war vielleicht etwas missverständlich. VLAN 10 war nur ein Beispiel, gleiches gilt für VLAN 20 oder jedes andere getaggte VLAN.
Ich habe keine Instances konfiguriert, das heißt alles auf der default Instance:
Multiple Spanning Tree (MST) Information
STP Enabled : Yes
Force Version : MSTP-operation
IST Mapped VLANs : 1-4094
Switch MAC Address : 001635-b19f80
Switch Priority : 32768
Max Age : 20
Max Hops : 20
Forward Delay : 15
24 | 20000 64 Blocking | 001635-b19f80 2 Yes NoWenn ich ein getaggtes VLAN brücke, dann passiert nichts. Das ist der Punkt den ich nicht so richtig verstehe.
Ich habe das so gedeutet, also würde STP die eigenen BPDUs erkennen, aber komischerweise nur auf dem untagged VLAN.
STP erkennt die eigenen BPDUs doch auch, wenn ich zwei Ports an einem Swich brücke der STP kann, oder funktioniert das anders?
Das heißt es wäre vielleicht eine Alternative STP auf dem Uplink Ports zu den 1800ern zu deaktiveren, und dafür Loop Protection zu nutzen. Oder sollte Loop-Protection grundsätzlich zusätzlich zu STP genutzt werden?
Da der Uplink bei mir eigentlich ein LACP Trunk/Etherchannel ist muss man nur mit den Timern aufpassen, da sonst beim automatischen reaktivieren des Ports ein Loop erkannt wird, bevor LACP die Verbindung ausgehandelt hat. Das geht dann ewig so weiter.
Leider funktioniert Loop Protection anscheinend doch nur auf für das untagged VLAN und ist wohl eher für Access Ports gedacht (alles andere hätte mich irgendwie auch gewundert). Damit bringt es für mich leider keinen Vorteil, da dieser Fall auch mit STP funktioniert.
Danke für die Hilfe.
Wenn ich ein getaggtes VLAN brücke, dann passiert nichts. Das ist der Punkt den ich nicht so richtig verstehe.
Das ist auch etwas unklar.Also du hast einen Trunk, der beide Switches mit einem tagged Uplink verbindet und dann z.B. an diesem Switch 3 Ports untagged im VLAN 10 oder 20 die du dann mal mit einem kabel loopst, richtig ?
Wichtig ist hier das der Billigswitch im RSTP Modus arbeitet, denn MSTP basiert auf RSTP.
Das Billigteil kann ja nur ein Single Span, hat also nur einen STP Prozess global über alle VLANs, deshalb ist es zwingend das auch die MSTP Seite in einer einzigen Instance arbeiten muss.
Eigentlich muss dann so ein geloopter Port sofort in den Blocking State gehen. Je nachdem auf welcher Seite du die Root Bridge konfiguriert hast (STP priority!)
Sinnvollerweise sollte der MSTP Switch hier die Root Bridge sein indem du ihm die STP priority in der Instance mal auf 16384 setzt.
Anhand der STP Parameter solltest du dann am 1800 sehen das der den anderen Switch dann als Root Bridge sieht.
Das ist ein Indiz dafür das der STP bzw. RSTP sauber rennt und dann müssten diese Ports auch egal in welchem VLAN ins Blocking gehen.
Wenn HP da nicht mal wieder einen Bug im STP hat
Was die STP mäßig verzapfen ist totaler Schrott...jedenfalls auf den billigen ProCurve Modellen. Bei der zugekauften H3C Reihe ist es wohl geringfügig besser.
Das Problem ist, dass der 1800er in dem Sinn gar kein Spanning Tree kann, das heißt es gibt keine Konfigurationsmöglichkeiten und er versendet selbst keine BPDUs. Als die Switche rauskamen haben sie BPDUs nicht mal weitergeleitet. Seit einem Firmware Update können sie zumindest das.
Ich glaube die Nachfolgemodelle (1810; immer noch Billigteile) können dann auch am STP teilnehmen.
Das war etwas missverständlich formuliert. Mit "getagged" meinte ich VLANs die den Trunk Verbindung nutzen. Die geloopten Ports sind natürlich untagged auf den entsprechenden VLANs.
Ich habe folgende Konstellation:
Port 24 an beiden Switches: tagged 10+20; untagged 1
Fall 2 (von oben) --> 2 Ports im VLAN 1 (-->untagged 1) werden auf 1800 mit Kabel gebrückt --> Uplink Port auf 2910 geht auf Blocking
Fall 3 --> 2 Ports im VLAN 10 (oder 20 --> untagged) werden auf 1800 mit Kabel gebrückt --> Uplink bleibt auf Forwarding
Wenn ich das gleiche mit zwei Switchen mache, die Spanning Tree können, bei einem aber Spanning Tree deaktiviere, sehe ich das gleiche Verhalten.
Ein Loop des Trunk Native VLANs (auf dem stp disabled Switch) resultiert in einem Blocking State, ein Loop aller anderen VLANs hat keine Auswirkungen.
Vielleicht ist das schlicht das zu erwartende Verhalten bei einem Switch, der zwar VLANs kann aber nicht am STP teilnimmt.
Ich glaube die Nachfolgemodelle (1810; immer noch Billigteile) können dann auch am STP teilnehmen.
Das war etwas missverständlich formuliert. Mit "getagged" meinte ich VLANs die den Trunk Verbindung nutzen. Die geloopten Ports sind natürlich untagged auf den entsprechenden VLANs.
Ich habe folgende Konstellation:
Port 24 an beiden Switches: tagged 10+20; untagged 1
Fall 2 (von oben) --> 2 Ports im VLAN 1 (-->untagged 1) werden auf 1800 mit Kabel gebrückt --> Uplink Port auf 2910 geht auf Blocking
Fall 3 --> 2 Ports im VLAN 10 (oder 20 --> untagged) werden auf 1800 mit Kabel gebrückt --> Uplink bleibt auf Forwarding
Wenn ich das gleiche mit zwei Switchen mache, die Spanning Tree können, bei einem aber Spanning Tree deaktiviere, sehe ich das gleiche Verhalten.
Ein Loop des Trunk Native VLANs (auf dem stp disabled Switch) resultiert in einem Blocking State, ein Loop aller anderen VLANs hat keine Auswirkungen.
Vielleicht ist das schlicht das zu erwartende Verhalten bei einem Switch, der zwar VLANs kann aber nicht am STP teilnimmt.
das heißt es gibt keine Konfigurationsmöglichkeiten und er versendet selbst keine BPDUs.
OK, das ist dann natürlich tödlich. Damit kann er de facto KEIN STP und tunnelt bzw. flutet die BPUDUs nur. Das macht auch jeder 6 Euro Billigswitch vom Blödmarkt.Damit ist die Kiste dann vollständig unbrauchbar in einem STP Umfeld.
Sie MUSS aktiv STP machen sonst ist die Betrachtung deiner Szenarien sinnlos, klar. So gesehen ist das ganze Konstrukt dann wie ein unmanagebarer Switch der loopt und dagegen hilft eben nur die Loop Protection (Eigene BPDUs am gleichen Port zurück).
Aus Sicht von STP ist es ein unmanagebarer Switch, das stimmt. Mit dem Unterschied, dass der 6€ Switch keine VLANs kann.
Wenn sich der 1800er jetzt pro VLAN wie ein Billigswitch verhalten würden, dann wäre das temporär noch tolerierbar. Doppelte Verbindungen zwischen den Switchen werden auch erkannt und geblockt, nur eben Loops direkt auf dem 1800er nicht.
Loop Protection ist wie gesagt scheinbar für Access Ports gedacht und für diesen Anwendungsfall mit VLANs leider ungeeignet.
Scheinbar habe ich also keine Chance Loops auf den 1800ern zu verhindern (bzw. die Auswirkungen davon), wenn ich sie nicht als Baumarkt Switch mit nur einem VLAN nutzen will.
Danke für die Hilfe.
Wenn sich der 1800er jetzt pro VLAN wie ein Billigswitch verhalten würden, dann wäre das temporär noch tolerierbar. Doppelte Verbindungen zwischen den Switchen werden auch erkannt und geblockt, nur eben Loops direkt auf dem 1800er nicht.
Loop Protection ist wie gesagt scheinbar für Access Ports gedacht und für diesen Anwendungsfall mit VLANs leider ungeeignet.
Scheinbar habe ich also keine Chance Loops auf den 1800ern zu verhindern (bzw. die Auswirkungen davon), wenn ich sie nicht als Baumarkt Switch mit nur einem VLAN nutzen will.
Danke für die Hilfe.
