Revoke: Per VLAN Spanning Tree? STP mit Cisco-Switches und Lancom-Router

ecox · Beitrag von **ecox** » 10 Sep 2018, 18:21

Hallo zusammen,

nehmen wir mal an, wir haben zwei unkonfigurierte Cisco-Switches, diese haben an Port Gi0/48 eine Verbindung zu ETH-1 und ETH-2 (beide auf LAN-1). Die Switches selber sind an Gi0/47 untereinander verbunden (InterSwitching). Ok, im default sprechen die Ciscos ja so oder so STP, am LANCOM ist STP default deaktiviert.

STP am Lancom aus:
Man sieht im "show spanning-tree" am Cisco, das der Gi0/48 am Switch 1 auf Forwarding steht und im Designated. An Port 0/47 am Switch sieht man die Rolle "Root", ok, springen wir nun auf Switch 2, sehen wir das der Port Gi0/48 blocked und im AlternateState ist. Somit gibt es ein Port der im Forwarding zum Lancom steht. Die RootBridge selber ist jedoch der zweite Switch.

STP am Lancom an:
Verkabelung bleibt wie oben. Ich gebe dem LANCOM mit aktiviertem STP eine höhere Priorität (aus RSTP Zeiten habe ich gelernt, in 4096er Schritten), also bekommt er diese auch.

So, bootet man nun alles durch, habe ich das selbe Verhalten an den CiscoSwitches wie vorher, der Cisco wird definitiv nicht die RootBridge, muss er aber werden...
Im SpgTre Trace sehe ich nur, das er BPDUs empfängt aber keine sendet (das finde ich schon sehr seltsam, auch im Ethernet-Trace sehe ich keine Layer-2 Pakete raus fliegen, wie sollen also auch die Cisco-Switches was von der Prio des LANCOMs mitbekommen, wenn er sie gar nicht sendet).

Ich sitze an der Sache nun schon gut 1 1/2 AT und ich werde noch verrückt. Wieso wird der LANCOM nicht RootBridge und wieso sind in der Log-Table zu sehen das er aber zu dieser gesetzt wird "ls stat/lan-bri/span/log-tab". Im Monitor sehe ich auch das LAN-1 im Status "Disabled" ist, alles so seltsam. Ich verzweifle noch, erschwerend kommt dann im Endszenario noch hinzu das wir noch PerVLAN STP machen müssen, oh man

...

Über eine schnelle Antwort und Expertisen würde ich mich freuen, ich brauche eine Lösung am besten schon gestern, ach was sage ich, vor vor vorgestern.

Grüße ausm Osten!

ecox

alf29 · Beitrag von **alf29** » 10 Sep 2018, 18:51

Moin,

Verkabelung bleibt wie oben. Ich gebe dem LANCOM mit aktiviertem STP eine höhere Priorität (aus RSTP Zeiten habe ich gelernt, in 4096er Schritten), also bekommt er diese auch.

So, bootet man nun alles durch, habe ich das selbe Verhalten an den CiscoSwitches wie vorher, der Cisco wird definitiv nicht die RootBridge, muss er aber werden...

Nur zur Sicherheit gefragt: Mit "höhere Prio" meinst Du einen numerisch höheren Wert, d.h. das LANCOM hat die *niedrigere* Priorität bei der Wahl zur Root-Bridge?

So, bootet man nun alles durch, habe ich das selbe Verhalten an den CiscoSwitches wie vorher, der Cisco wird definitiv nicht die RootBridge, muss er aber werden...
Im SpgTre Trace sehe ich nur, das er BPDUs empfängt aber keine sendet (das finde ich schon sehr seltsam, auch im Ethernet-Trace sehe ich keine Layer-2 Pakete raus fliegen, wie sollen also auch die Cisco-Switches was von der Prio des LANCOMs mitbekommen, wenn er sie gar nicht sendet).

Wer ist jetzt "er"? Der Cisco oder das LANCOM? Also solange der STP-Algorithmus Pakete von der "anderen Seite" mit einer höheren bridge-Prio (also einem numerisch kleinerem Wert) empfängt, solange sendet er auf diesem Port auch keine eigenen Pakete. Das würde er nur tun, wenn er meint, daß er selber die höhere Prio hat.

Du hast nicht irgendwo auf dem Cisco diese Downstream-Protection (oder wie die auch immer hieß) eingeschaltet, die dafür sorgt, daß der Cisco einen Port abschaltet, sobald er STP-Pakete auf selbigem empfängt? Die ist eigentlich für Endgeräte-Ports gedacht, wo keine STP-Pakete kommen dürfen, aber ich habe schon Admins erlebt, die darüber eine bestimmte Topologie erzwingen wollten...

Wieso wird der LANCOM nicht RootBridge und wieso sind in der Log-Table zu sehen das er aber zu dieser gesetzt wird "ls stat/lan-bri/span/log-tab".

Also wenn der Spanning-Tree-Algorithmus losläuft und noch nichts weiß von anderen Bridges, dann erklärt sich das Gerät erstmal initial zur Root-Bridge. So ist der Algorithmus definiert. Ich weiß nicht mehr auswendig, ob es da auch Log-Meldungen gab, wenn die Auswahl der Root-Bridge sich ändert, aber das würdest Du ja auch im Spanning-Tree-Status sehen.

Im Monitor sehe ich auch das LAN-1 im Status "Disabled" ist, alles so seltsam.

Welchen Status meinst Du? Den Status dieses Ports bzgl. Spanning Tree? "Disabled" hieße dann schlicht, daß der Port keinen Link hat (z.B. weil auf dem Cisco diese Downstream-Protection zugeschlagen hat).

Ich verzweifle noch, erschwerend kommt dann im Endszenario noch hinzu das wir noch PerVLAN STP machen müssen, oh man ...

Mir MSTP habe ich keine Erfahrung, das LCOS unterstützt maximal RSTP. Wie so etwas zusammenspielt, weiß ich nicht.

Über eine schnelle Antwort und Expertisen würde ich mich freuen, ich brauche eine Lösung am besten schon gestern, ach was sage ich, vor vor vorgestern.

Dafür daß bei Dir die Hütte brennt kann hier erstmal keiner was. Und wenn die Infos dann noch so mehrdeutig und bruchstückhaft sind, daß ich noch nicht einmal wüßte, was ich genau nachbauen soll, dann wird's auch nicht einfacher...

Viele Grüße

Alfred

Dr.Einstein · Beitrag von **Dr.Einstein** » 10 Sep 2018, 19:06

Hi ecox,

ecox hat geschrieben: 10 Sep 2018, 18:21 Ich gebe dem LANCOM mit aktiviertem STP eine höhere Priorität (aus RSTP Zeiten habe ich gelernt, in 4096er Schritten), also bekommt er diese auch.

du weißt, dass bei STP einere "höhere Prio" eine "niedrigere Zahl" bedeutet?

Gruß Dr.Einstein

ecox · Beitrag von **ecox** » 10 Sep 2018, 20:13

Servus,

@alf, hoffe es ist so ein wenig klarer

Visio_2.png

@dr. einstein, jo, das ist mir bewusst

soviel ist aus dem ccna r&s hängen geblieben

darum schrieb ich ja oben, durch RSTP ist mir noch hängen geblieben das man dort immer in 4096er Schritten die Prio erhöhen muss auf Grund von irgendwelchen Bytes die sich da verschieben oder so.

Grüße
ecox

alf29 · Beitrag von **alf29** » 10 Sep 2018, 22:51

n'Abend,

@alf, hoffe es ist so ein wenig klarer

Ja, einigermaßen. Laß mich zusammenfassen: Sobald Du STP am LANCOM einschaltest, müßte es ja anfangen, STP-PDUs in Richtung der Ciscos zu schicken, das tut es lt. Ethernet-Trace aber nicht. Korrekt? Dann zeige doch bitte mal den Inhalt des Untermenüs "Status/LAN-Bridge/Spanning-Tree" und der Tabelle "Status/LAN-Bridge/Spanning-Tree/RSTP-Port-Table". Von letzterer dürften die Zeilen für LAN-1 und LAN-2 reichen. Ich gehe davon aus, daß Du ETH-1 an LAN-1 und ETH-2 an LAN-2 gebunden hast?

Viele Grüße

Alfred

ecox · Beitrag von **ecox** » 10 Sep 2018, 23:01

Hey Alf,

den Output der Tabellen kann ich morgen herreichen. Wenn du schon so die Frage nach ETH-1 (LAN-1) ETH-2 (LAN-2) stellst, gehe ich davon aus das so konfiguiert werden "muss"? Weil wenn ja, so habe ich es nicht, ETH-1 und 2 sind auf LAN-1 gebridged. Das paradoxe ist, das hatte ich ganz am Anfang im Sinn, hab es aber irgendwie verworfen.

Liegt es daran das es nicht funktioniert weil er den LANCOM nur als 1 PORT sieht und nicht als zwei? Weil nur eine MAC-Adresse ankommt? Versteh ich das so halbwegs richtig

?

Grüße
ecox

alf29 · Beitrag von **alf29** » 10 Sep 2018, 23:53

Moin,

also was passiert, wenn Du ETH-1 und ETH-2 beide an LAN-1 bindest kann ich Dir nicht sagen. Das habe ich nie ausprobiert und es macht auch keinen Sinn. Der Spanning Tree arbeitet auf der Ebene der LAN-x und er soll ja einzelne Ports ein- und ausschalten können. Das geht nur, wenn die ETH-x an separate LAN-x gebunden sind. Die LAN-x kannst Du dann wieder in eine Bridge-Gruppe stecken und das ARF-Netz an diese Bridge-Gruppe binden. Wenn ETH-1 und ETH-2 an LAN-1 hängen, dann wird der Hardware-Switch im LANCOM weiter transparent zwischen den beiden switchen und das wird - vermutlich - für die Ciscos so aussehen, als wären ihre GIO/48 immer miteinander verbunden. So als ob Du in der Mitte einen Dreiport-Hub hättest, an dem alle drei Geräte dran hängen.

Viele Grüße

Alfred

ecox · Beitrag von **ecox** » 11 Sep 2018, 09:05

Hallo Alf,

auch ein ETH-1(LAN-1) und ETH-2(LAN-2) bringt keinen Erfolg. Der Cisco ist stur der Meinung, er ist und bleibt die Root-bridge. Ich habe nun nochmal ein LANCOM Switch zur Hand genommen, alle Geräte wieder resetet.

Am LANCOM Router nur STP aktiviert und mal einen LANCOM Switch drangehängt und diesem eine niedrigere Prio als dem Router gegeben, nix, es passiert einfach nichts! Ich glaube immer noch das der LANCOM keine BPDUs senden kann/will, denn sonst würden die anderen ja mal was von ihm mitbekommen...

Es ist zum Haare raufen, könnt ihr das mit Cisco Switches in eurer Umgebung nachstellen?

Auch finde ich nicht sehr vertrauenerweckend, das in der 9.24 STP nicht drin ist und in der 10.12 dann wieder da ist, in der 9.10 ist es auch mal wieder zu sehen usw usw...

Grüße
ecox

alf29 · Beitrag von **alf29** » 11 Sep 2018, 10:29

Moin,

auch ein ETH-1(LAN-1) und ETH-2(LAN-2) bringt keinen Erfolg. Der Cisco ist stur der Meinung, er ist und bleibt die Root-bridge. Ich habe nun nochmal ein LANCOM Switch zur Hand genommen, alle Geräte wieder resetet.

Tja und keine Tabellen/Menüauszüge und keine Traces. Was soll ich sagen...

Es ist zum Haare raufen, könnt ihr das mit Cisco Switches in eurer Umgebung nachstellen?

Also ich hab selber schon genug um die Ohren nach meinem Urlaub. Wenn Du irgendjemand anders dazu hier bewegen willst, wirst Du ein Ticket beim Support aufmachen müssen.

Auch finde ich nicht sehr vertrauenerweckend, das in der 9.24 STP nicht drin ist und in der 10.12 dann wieder da ist, in der 9.10 ist es auch mal wieder zu sehen usw usw...

Mir ist kein Fall bekannt, wo wir aus irgendeinem Gerät STP mit einem LCOS-Update wieder herausgenommen hätten. Hast Du Dir das wirklich im LCOS-Menübaum angeschaut oder nur im LANconfig? Im LANconfig werden Features auch schon mal "vergessen" nachzutragen...

Viele Grüße

Alfred

ecox · Beitrag von **ecox** » 11 Sep 2018, 18:58

Servus alf,

ich habe es nun doch zum laufen gebracht, ein Wunder! Eigentlich habe ich hier nur ein kleines Detail von dir vergessen. Ich habe die Schnittstellen in der Port-Tabelle nicht gebridged -.- ich habe jetzt alle Netze die über den Switch reinkommen auch auf BRG-X gesetzt. Ist dies an sich notwendig? Oder reicht es schon aus einfach in der Port-Tabelle die Ports zu bridgen?

Es ist jetzt jedenfalls so, das der LANCOM die Root-bridge ist, das suggerieren mir auch alle Switches im Netz (Ciscos). Erster Schritt ist geschafft. Nun habe ich alle VLANs die vorher nur auf LAN-1 liefen auch mit ins LAN-2 aufgenommen, danach brechen alle drei VPN Tunnel ins RZ zusammen

ein Problem gelöst, kommen die nächsten, business as usual

.

Danke für die Tipps Alf, ohne dich hätte ich da wohl noch ne Woche rum gesucht, leider fehlt mir die Zeit mich nur auf dieses Thema zu fokussieren, aktuell fliegt mir auch noch sooo viel BGP Kram um die Ohren das ich langsam nicht mehr weiß wo oben und unten ist

Bzgl. Traces und Log-Einträge, die hätten nichts gebracht da sie einfach nichts ausgesagt haben

hätte auch nur in einem Trace gestanden "HEY HONK, du hast die Schnittstellen nicht gebridged"

vllt. kann man ja dieses Szenario mit in die KB bei euch aufnehmen, selbstverständlich ist die Konfiguration aufjeden fall nicht...nun schon ^^

Grüße
ecox

alf29 · Beitrag von **alf29** » 12 Sep 2018, 14:24

Moin,

Eigentlich habe ich hier nur ein kleines Detail von dir vergessen. Ich habe die Schnittstellen in der Port-Tabelle nicht gebridged -.- ich habe jetzt alle Netze die über den Switch reinkommen auch auf BRG-X gesetzt. Ist dies an sich notwendig? Oder reicht es schon aus einfach in der Port-Tabelle die Ports zu bridgen?

Du meinst, Du hattest für LAN-1 und LAN-2 die Bridge-Gruppe auf 'none' gesetzt? Das bedeutet seit der 10.12 nicht nur, daß auf diesen Ports nicht mehr gebridget wird, sondern die LAN-Bridge sich mit allen ihren Funktionen von diesen Ports zurückzieht. Die Ports sind quasi mehr oder weniger direkt mit dem Router verbunden, und auch der Spanning Tree macht mit ihnen nichts mehr. Hintergrund war, daß mit der 10.12 alle LANCOMs die LAN-Bridge bekommen haben, und die Forderung war, daß sich das nicht auf die Performance auswirken darf. In früheren Versionen hat die LAN-Bridge immer ein wenig Overhead verursacht, wenn sie als Feature im LCOS enthalten war, auch wenn man sie gar nicht benutzt hat.

Daß Du bei Dir die LAN-x als "disabled" in der STP-Porttabelle gesehen hast, ist dann kein Wunder. Der STP ist Teil der LAN-Bridge-Funktionalität, und auch der läßt von einem Port die Finger, wenn die Bridge-Gruppe auf 'none' steht. Wozu sollte er auch damit etwas machen, denn STP ist ja dazu da, Schleifen beim L2-Forwarding aufzubrechen. Wenn aber gar nicht auf Layer 2 weitergeleitet wird...

Nun habe ich alle VLANs die vorher nur auf LAN-1 liefen auch mit ins LAN-2 aufgenommen, danach brechen alle drei VPN Tunnel ins RZ zusammen ein Problem gelöst, kommen die nächsten, business as usual .

Yup. SNAFU....

Viele Grüße

Alfred

ecox · Beitrag von **ecox** » 14 Sep 2018, 19:03

So, da bin ich wieder, nächstes Problem was mich mehrere Stunden gekostet hat.
Der LANCOM bietet Classic STP und Rapid STP an, feine Sache.

Die Cisco-Switches sprechnen nur mst, pvst und rapid-pvst. Nun ist es so das auf dem LANCOM und logischer weise auf den Switches VLANs laufen.
Ich habe es nun zum laufen gebracht das der LANCOM die Root-bridge ist, aber das ist sie laut Output vom Cisco nur im VLAN0001, im vlan 515,516 und 517 ist sie es nicht, dort bleibt der Switch die Root-bridge.

Ich habe natürlich enorm viel rum probiert, wie immer halt

aber ich habe es nicht zum laufen gebracht. Es ist nun so das Per VLAN Spanning Tree sich an STP anlehnt aber eine Erweiterung von Cisco ist, somit Cisco-proprietär ist.

Es gibt jetzt hier zwei Sachen die ich nicht verstehe, es existiert im ganzen Konstrukt kein VLAN0001, es ist zwar in der VLAN-database im Switch, aber nicht im LANCOM, dort gibt es kein VLAN1.

Wo kommt die VLAN ID 1 vom LANCOM her, die den LANCOM im VLAN1 für den Switch zur Root-bridge macht

Spricht der LANCOM Router überhaupt Per VLAN Spanning Tree? Auswählen kann man es jedenfalls nicht, aber man weiß ja nie...eine andere Lösung wäre auch noch MST aber das kann er halt auch nicht...

Mach ich irgendwo was falsch?

Verkabelung ist gerade nur Labor-mäßig. Aber vom ETH-1 geht ein Kabel zu Gi0/1 am Switch. Das Switch interface ist im Trunk-modus und erlaubt alle VLANs (dot1q). LAN-1 (ETH-1) hat die VLAN-ID 515 zugewiesen, Trunk und PVID ist 515, andere VLANS erlauben.

Stelle ich auf Hybrid um, kommen Fehlermeldungen auf dem Cisco "PVID_Inc" usw...

Grüße
ecox

Koppelfeld · Beitrag von **Koppelfeld** » 15 Sep 2018, 09:17

PVST war eine ziemlich coole Idee von Cisco -- haben die sich aber offensichtlich schützen lassen.

Wenn überhaupt *STP, dann MSTP. Einfacher Hintergrund: VLANs spannen neue Netzwerke auf, welche im Netzwerkdiagramm logischerweise auch separat gezeichnet werden müssen. Denn der Graph kann für jedes VLAN unterschiedlich sein. Sonst bräuchte man keine VLAN s.

MSTP hast Du bei LANCOM aber noch nicht.

Letztlich bleiben m.E. Zwei Szenarien für STP:
- LACP
- redundante Switches

Sehr viele Kunden wünschen sich redundante Switches, aber z.B. die 54xx-Serie von HP bietet redundante Netzteile, redundante Backplanes und sogar redundante Management-Module.
Da kann man dann auf STP getrost verzichten.

Die Idee ist gut, die Praxis gruselig.

ecox · Beitrag von **ecox** » 15 Sep 2018, 14:21

Hallo,

@Koppelfeld.
Gut, wenn du mir hier bestätigst das der LANCOM CPE kein MSTP spricht, kann ich die ganze Sache abblasen. Der Kunde kommt im Endeffekt eh mit zwei Switches, zwei Aruba-Switches -.- (glaube die wurden von HP geschluckt), jeweils an ETH-1 und ETH-2 (wie oben in der Zeichnung).

Dann stell ich STP am LANCOM aus und er reicht die BPDUs einfach durch, dann merken die Switches schon wer Root ist und wann aussteigt so das der zweite Root-bridge wird sodass dann über die Querverbindung weiter gearbeitet werden kann.

LACP haben wir direkt angeboten, aber irgendwie scheint der Kunde ein STP Fetisch zu haben

Grüße
ecox

alf29 · Beitrag von **alf29** » 15 Sep 2018, 22:17

Moin,

Ich meine, ich hatte bereits oben geschrieben, daß das LCOS maximal RSTP unterstützt. Inwieweit MSTP zu RSTP "aufwärtskompatibel" ist, weiß ich nicht. AFAIK bedeutet MSTP aber nur, daß pro VLAN ein anderer Tree ausgerechnet werden kann, um redundante Verbindungen besser zu nutzen (da kann ich mich aber auch irren). Ob Du das in Deinem Aufbau brauchst, weiß ich nicht, es scheint mir aber nicht nötig, denn durchsatzmäßig kann man am LANCCOM da nichts gewinnen. Alle Ethernet-Ports des 1783 hängen an einem internen Switch, und der hängt über einen GE-Port an der CPU.

Sehr viele Kunden wünschen sich redundante Switches, aber z.B. die 54xx-Serie von HP bietet redundante Netzteile, redundante Backplanes und sogar redundante Management-Module.
Da kann man dann auf STP getrost verzichten.

Ich hatte mal mit einem Kunden zu tun, der ein Container-Terminal vernetzt hat, da ist der Ausfall einzelner Leitungen und ein "vollvermaschter" Aufbau der Switches schon ein Thema. YMMV.

MSTP hast Du bei LANCOM aber noch nicht.

Ja, das liegt auf dem großen Stapel von Dingen, die man eigentlich mal machen müßte...

Letztlich bleiben m.E. Zwei Szenarien für STP:
- LACP

Geht prinzipiell auf einem 178x, ist aber witzlos, weil's keinen Durchsatzgewinn bringt. Beide Ports an einem Switch, der wiederum...siehe oben.

Viele Grüße

Alfred

LANCOM-Forum.de