bintorosoft.com

STP vs. MLAG: Wenn Topologien kollidieren

Red Snapper

STP vs. MLAG ist eine der klassischen „Topologie-Kollisionen“ im Rechenzentrum und im Campus – und gleichzeitig eine der häufigsten Ursachen für schwer erklärbare Layer-2-Störungen. Spanning Tree Protocol (STP) existiert, um Loops in redundanten Layer-2-Topologien zu verhindern. MLAG (Multi-Chassis Link Aggregation) – je nach Hersteller vPC, MC-LAG, VLT, IRF, StackWise Virtual oder ähnlich genannt – existiert, um Redundanz und aktive/aktive Uplinks zu ermöglichen, ohne dass STP diese Links blockiert. Genau an dieser Schnittstelle passieren Incidents: Eine Topologie „denkt“ in STP-Logik (Root Bridge, Port Roles, Blocking), die andere „denkt“ in MLAG-Logik (Peer-Link, Split-Brain-Schutz, Consistency Checks, orphan ports). Wenn beide Logiken gleichzeitig auf denselben Traffic wirken, entstehen Fehlerbilder, die wie Zufall wirken: MAC-Flapping, TCN Storms, intermittierende Blackholes, scheinbar willkürlich suspendierte Ports oder massive Flooding-Spitzen. In der Praxis ist nicht STP „schlecht“ und auch nicht MLAG „magisch“ – das Problem ist fast immer ein Design- oder Betriebsbruch: falsches Root Placement, unklare STP-Domänen, Peer-Link trägt nicht alle VLANs, inkonsistente Trunk-Parameter oder Guard-Features, die im falschen Segment aktiv sind. Dieser Artikel zeigt, wie STP und MLAG zusammenspielen sollten, wo sie typischerweise kollidieren und wie Sie die häufigsten Fehlerbilder im Troubleshooting schnell eingrenzen, beweisen und nachhaltig fixen.

Die beiden Denkmodelle: Warum STP und MLAG überhaupt kollidieren

Um STP vs. MLAG sauber zu verstehen, hilft ein kurzer Perspektivwechsel: Beide Technologien lösen „Loop vs. Redundanz“, aber auf unterschiedlichen Ebenen.

Die Kollision entsteht, wenn STP in der Praxis doch auf Pfade trifft, die MLAG als „intern konsistent“ betrachtet – oder wenn MLAG intern inkonsistent ist und STP dann Symptome zeigt. Grundsätzliches zu STP (inkl. RSTP) finden Sie als Einstieg bei IEEE 802.1D und 802.1Q, z. B. über die IEEE-Übersichtsseiten IEEE 802.1D und IEEE 802.1Q.

Wo STP endet und MLAG beginnt: Das wichtigste Architekturprinzip

Ein stabiles Design setzt eine klare Grenze: STP muss wissen, „wo“ seine Domain ist, und MLAG muss wissen, „welche Links“ es aktiv/aktiv führen darf. In vielen Umgebungen entstehen Probleme, weil diese Grenze unklar ist – etwa wenn der Peer-Link als „normales Trunk“ behandelt wird, Guard-Features auf den falschen Ports aktiv sind oder Root Bridge Platzierung dem Zufall überlassen wird.

Root Placement: Der häufigste Auslöser für STP-MLAG-Chaos

Wenn STP die „falsche“ Root Bridge wählt, kann eine ansonsten korrekt aufgebaute MLAG-Topologie plötzlich suboptimal oder instabil werden. In MLAG-Designs erwarten Teams oft, dass beide Peers „gleichwertig“ sind. STP ist das egal: Es wählt die Root Bridge nach Bridge Priority und MAC. Das führt zu drei typischen Fehlern:

In der Praxis sollte Root Placement absichtlich geplant werden: Root auf dem Paar, das als L2-Aggregationspunkt gedacht ist, mit klarer Primary/Secondary-Priorität. Herstellerleitfäden, z. B. Cisco STP Design/Config Docs, sind hilfreich, um Root-Priority und Guard-Mechaniken konsistent zu setzen.

Peer-Link als versteckter Transit: Wenn STP-Design den Peer-Link „missbraucht“

Der Peer-Link ist das Herz der MLAG-Domäne. Er transportiert State-Synchronisation und oft auch Datenverkehr (z. B. für Traffic zu MACs, die auf dem anderen Peer gelernt wurden). In einem idealen MLAG-Design ist der Peer-Link kein dauerhafter Transit für „normalen“ Ost-West-Traffic zwischen Access-Segments. Genau das passiert aber, wenn STP blockt oder Root Placement ungünstig ist: Dann fließt plötzlich großer Datenverkehr über den Peer-Link, er congestet, Drops entstehen, und die MLAG-Logik wird instabil.

Split-Brain trifft STP: Wenn Schutzmechanismen plötzlich Topologie verändern

MLAG/vPC hat Split-Brain-Schutzmechanismen: Wenn Peer-Link oder Keepalive ausfallen, müssen Systeme entscheiden, wie sie Loops vermeiden. Viele Implementierungen reagieren, indem sie bestimmte Ports suspendieren oder den Forwarding-State ändern. Für STP sieht das aus wie „plötzliche Topologieänderung“ – und STP reagiert mit Reconvergence, TCNs und (je nach Mode) kurzen Unterbrechungen.

Wichtig: Wenn MLAG Schutzmechanismen Ports herunternehmen, ist das oft nicht „der Fehler“, sondern die Reaktion auf Inkonsistenz. Troubleshooting sollte dann zuerst Peer-Link/Keepalive/Consistency prüfen – nicht STP „tunen“.

Consistency Checks vs. STP Guard Features: Doppelte Schutzlogik mit Nebenwirkungen

Viele Netze nutzen STP Guard Features (BPDU Guard, Root Guard, Loop Guard) und parallel MLAG Consistency Checks. Beide schützen, aber sie schützen unterschiedliche Annahmen. Wenn sie falsch kombiniert werden, entsteht Over-Protection: Ports werden deaktiviert, obwohl kein echter Loop existiert.

Best Practice: Guard Features gezielt einsetzen (Edge vs. Uplink), Consistency Checks ernst nehmen (sie sind meist korrekt), und alle Schutzmechaniken mit einer klaren „Port-Rollen“-Dokumentation verbinden.

VLAN- und Trunk-Fallen: Wenn nur ein VLAN „kaputt“ ist

Ein besonders typisches STP-vs-MLAG-Fehlerbild ist VLAN-spezifisch: Ein VLAN funktioniert, ein anderes nicht; oder nur ein Service in einem VLAN zeigt Drops. Ursache ist häufig, dass Peer-Link oder Downstream-vPC nicht alle VLANs identisch trägt. STP kann dann je VLAN anders blocken, MAC-Learning wird inkonsistent, und Traffic wird geflutet oder gedroppt.

Intermittierende Blackholes: Hashing, Peer-Link-Drops und „nur manche Flows“

Wenn STP und MLAG kollidieren, sehen Teams häufig intermittierende Fehler: nicht „alles down“, sondern einzelne Sessions hängen. Das ist häufig die Kombination aus Hashing (LACP/ECMP) und einem degradierten Teilpfad (ein Peer-Link-Member hat Errors, ein Uplink ist geblockt, Congestion trifft nur bestimmte Queues).

Beweisführung im Troubleshooting: Welche Daten zuerst, welche zuletzt?

STP vs. MLAG Incidents eskalieren häufig, weil Teams zu früh „große“ Änderungen machen. Besser ist eine klare Beweisreihenfolge, die Ursache und Wirkung trennt.

Toolchain: Praktische Werkzeuge, die in STP-MLAG Incidents wirklich helfen

Die effektivste Toolchain ist klein, aber präzise. Wichtig ist, dass Sie an beiden Peers symmetrisch prüfen, weil Inkonsistenz das Problem oft erst erzeugt.

Design-Regeln, die STP-MLAG-Kollisionen langfristig vermeiden

Die nachhaltigsten Fixes sind fast immer Design- und Betriebsregeln, nicht „ein einzelnes Kommando“. Wenn STP und MLAG kollidieren, liegt häufig ein strukturelles Problem vor.

Für vPC/MLAG-spezifische Betriebsdetails sind Herstellerleitfäden oft die beste Praxisquelle, z. B. Cisco vPC Troubleshooting/Support Docs oder Arista MLAG Dokumentation.

Runbook-Baustein: STP vs. MLAG in 15 Minuten eingrenzen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Lieferumfang:

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.

 

Exit mobile version