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.
- STP: baut einen loopfreien Baum (Tree) über eine Layer-2-Domäne. Redundanz bleibt vorhanden, aber einzelne Pfade werden blockiert, um Loops zu verhindern. Das ist robust, aber kann aktive/aktive Uplinks verhindern.
- MLAG: lässt zwei physische Switches als einen logischen LAG-Partner erscheinen. Aus Sicht des Downstream-Geräts (z. B. Server oder Access-Switch) gibt es keine „zwei parallelen Links“, sondern einen Aggregat-Link. Dadurch soll STP idealerweise gar nicht erst in die Lage kommen, die Redundanz zu blockieren.
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.
- STP-Domain sauber definieren: Welche Switches gehören in dieselbe STP-Domain? Welche VLANs laufen wirklich L2-end-to-end?
- MLAG-Domain sauber definieren: Welche beiden Peers bilden eine Domäne? Wie ist der Peer-Link aufgebaut? Gibt es einen separaten Keepalive-Pfad?
- Übergangspunkte kennen: Uplinks zu anderen L2-Domänen, Übergänge zu L3 (SVIs, Anycast GW), sowie „orphan ports“ (Ports ohne MLAG-Bundle).
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:
- Root sitzt nicht dort, wo der optimale Pfad ist: Traffic nimmt unnötige Umwege, Peer-Link wird zum Transit, Congestion entsteht.
- Root wechselt (Root Flap): Bei Instabilität oder Konfigdrift kann die Root Bridge wechseln, was TCNs und L2-Churn auslöst.
- Per-VLAN Inkonsistenz: In PVST-/MST-Umgebungen kann Root pro VLAN/Instance unterschiedlich sein; das kann MLAG unerwartet belasten, wenn VLANs unterschiedlich blocken.
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.
- Symptom: Peer-Link utilization hoch, queue drops steigen, Latenzspitzen und sporadische Timeouts.
- Typische Ursache: ein Uplink ist durch STP geblockt, sodass Traffic „über den Peer“ ausweicht.
- Nachweis: STP Port Roles zeigen Blocking auf einem erwarteten Uplink; gleichzeitig steigen Peer-Link Counters.
- Fix: Root Placement korrigieren, STP-Design überdenken (z. B. L3 näher an Edge), Peer-Link VLAN/MTU korrekt und ausreichend dimensionieren.
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.
- Symptom: plötzliche TCN Storms, MAC-Flapping, Ports gehen in err-disable/suspend, danach wieder hoch.
- Typische Ursache: Peer-Link instabil (LACP member flaps), Keepalive-Pfad packet loss, oder Consistency Violations führen zu Schutzaktionen.
- Nachweis: MLAG-Status zeigt Role/Peer-Probleme im gleichen Zeitfenster wie STP TCNs und MAC-Flaps.
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.
- BPDU Guard auf falschen Ports: Wenn auf einem Port BPDUs „legitim“ auftauchen (z. B. Uplink), kann BPDU Guard den Port err-disable setzen.
- Root Guard gegen geplante Root Placement: Root Guard kann verhindern, dass ein geplanter Root-Weg funktioniert und erzeugt unerwartetes Blocking.
- Loop Guard in MLAG-Szenarien: Bei einseitig fehlenden BPDUs (z. B. durch Peer-Link-Probleme) kann Loop Guard Ports blocken und so Blackholes erzeugen.
- Consistency Checks suspendieren vPC/MLAG: VLAN/Trunk/MTU-Mismatches führen zu suspendierten Port-Channels, was STP-Topologie kippt.
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.
- Symptom: nur VLAN X betroffen, ARP/ND wirkt „random“, MAC-Flapping für Hosts in einem Segment.
- Nachweis: Allowed VLANs unterscheiden sich zwischen Peer-Link und Downstream-vPC; STP Instance/VLAN zeigt unterschiedliche Port Roles.
- Fix: VLAN-Liste vereinheitlichen (Peer-Link und vPC), native VLAN konsistent, Tagging-Fallen eliminieren.
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).
- Symptom: p95/p99 Latenz schlecht, aber p50 ok; sporadische TCP Retransmissions; einzelne Clients betroffen.
- Nachweis: per-member Counter im LAG zeigen Errors/Drops nur auf einem Member; Peer-Link Queue-Drops korrelieren mit STP Blocking.
- Fix: degradiertes Member isolieren, Peer-Link dimensionieren, Root Placement und Blocking-Pfade korrigieren.
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.
- Zeitfenster festlegen: Wann begann der Impact, wie lange dauerte er, gab es wiederkehrende Zyklen?
- MLAG Domänenhealth prüfen: Peer adjacency, Role/Primary, Peer-Link operational, Keepalive stabil, Consistency Status.
- STP Topologie prüfen: Root Bridge pro Instance/VLAN, Port Roles (Forwarding/Blocking), TCN Rate, Topology Change Ursachen.
- Peer-Link Datenpfad prüfen: VLANs operational, MTU konsistent, LACP member state, errors/discards/drops.
- Erst danach mitigieren: gezielt und mit minimalem Blast Radius (z. B. ein VLAN/Port-Channel, nicht die ganze Domain).
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.
- Domänenstatus-Ausgaben: Rolle, Peer-Link/Keepalive, suspended Ports, Consistency Violations.
- STP Status: Root, Port Roles, TCN Zähler, BPDU Empfang/Sendeverhalten, Guard-Triggered Events.
- Interface Counter: Errors/Discards/Drops auf Peer-Link und Uplinks; Referenzbegriffe in RFC 2863.
- Flow Telemetry: um zu sehen, ob Traffic unerwartet über Peer-Link läuft oder ob Hotspots existieren; IPFIX-Grundlage: RFC 7011.
- Gezielte Captures: wenn nötig, BPDUs und Control-Traffic sichtbar machen (z. B. auf einem Mirror-Port). Für Analyse: Wireshark Dokumentation.
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.
- Root Placement ist Absicht: Root und Secondary Root klar definieren, pro STP-Instance/VLAN konsistent.
- Peer-Link ist kritisch: ausreichend Bandbreite, redundante Member, MTU konsistent, alle benötigten VLANs operational.
- VLAN-Scope minimieren: L2-Domänen klein halten, L3 näher an die Edge bringen (reduziert STP-Bedeutung).
- Guard Features rollenbasiert: Edge-Ports streng, Uplinks bewusst; keine pauschalen Defaults ohne Ausnahmeplan.
- Config Drift verhindern: Automatisierung mit Consistency-Checks, aber auch mit Pre-Checks (VLAN/MTU/LACP), bevor Änderungen live gehen.
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
- Minute 0–3: Scope bestimmen: Welche VLANs/Segmente betroffen? Welche vPC/MLAG-Port-Channels? Tritt MAC-Flapping oder Flooding auf?
- Minute 3–6: MLAG Health prüfen: Peer-Link operational? Keepalive stabil? Role/Primary konsistent? Gibt es suspend/consistency violations?
- Minute 6–9: STP prüfen: Root Bridge korrekt? Port Roles wie erwartet? TCN Rate hoch? Guard Features ausgelöst?
- Minute 9–12: Peer-Link Datenpfad prüfen: Allowed VLANs/Native VLAN/MTU, LACP member state, errors/discards/drops. Prüfen, ob Traffic unerwartet über Peer-Link geht.
- Minute 12–15: Mitigation gezielt: Inkonsistenz beheben (VLAN/MTU/Tagging), degradiertes Member isolieren, Root Placement korrigieren. Danach verifizieren: TCNs sinken, MAC-Flapping stoppt, suspend wird aufgehoben, Traffic stabilisiert.
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:
-
Netzwerkdesign & Topologie-Planung
-
Router- & Switch-Konfiguration (Cisco IOS)
-
VLAN, Inter-VLAN Routing
-
OSPF, RIP, EIGRP (Grundlagen & Implementierung)
-
NAT, ACL, DHCP, DNS-Konfiguration
-
Troubleshooting & Netzwerkoptimierung
-
Packet Tracer Projektentwicklung & Dokumentation
-
CCNA Lern- & Praxisunterstützung
Lieferumfang:
-
Konfigurationsdateien
-
Packet-Tracer-Dateien (.pkt)
-
Netzwerkdokumentation
-
Schritt-für-Schritt-Erklärungen (auf Wunsch)
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.
