Redundante L2-Strecken: Wie vermeide ich Schleifen zwischen Standorten?
Zwei L2-Strecken schaffen erst mit einem klaren Redundanzmodell Ausfallsicherheit. So planen Sie STP, Split Horizon, EVPN, Failover und Abnahme.
Zwei Layer-2-Verbindungen zwischen denselben Standorten sind nicht automatisch redundant. Wenn beide dieselben VLANs gleichzeitig weiterleiten und dadurch ein geschlossener Pfad entsteht, können Ethernet-Frames im Kreis laufen, vervielfältigt werden und MAC-Tabellen ständig umschreiben. Ausfallsicherheit entsteht erst durch ein festgelegtes Betriebsmodell: genau ein aktiver Pfad, ein korrekt gebündelter logischer Link oder ein abgestimmtes Multihoming-Verfahren mit eigener Schleifenvermeidung.
Warum eine L2-Schleife nicht von selbst endet
Ein Ethernet-Frame besitzt keinen IP-Hop-Limit- oder TTL-Mechanismus, der ihn nach mehreren Umläufen verwirft. Broadcasts, Multicasts und Frames zu noch unbekannten Ziel-MAC-Adressen werden innerhalb einer Broadcast-Domain auf mehrere Ports geflutet. Gelangt eine Kopie über einen zweiten Weg zurück, kann sie erneut vervielfältigt werden. Cisco beschreibt als typische Folgen doppelte Nachrichten, wechselndes MAC-Lernen und eine instabile Topologie. Spanning Tree verhindert das, indem es für einen redundanten Pfad einen Port in einen nicht weiterleitenden Zustand versetzt.
Cisco: Spanning Tree und schleifenfreie redundante Pfade
| Beobachtung | Mögliche Ursache | Nützlicher Nachweis |
|---|---|---|
| Broadcast- oder Unknown-Unicast-Rate steigt stark | Frames werden über einen geschlossenen Pfad wiederholt repliziert | Zähler je VLAN und Port sowie Paketmitschnitt mit Zeitstempeln |
| Eine MAC-Adresse wechselt schnell zwischen Ports | Dasselbe Quell-Frame erreicht den Switch abwechselnd über zwei Wege | MAC-Move-Protokoll und Weiterleitungstabelle beider Enden |
| CPU-Last und Paketverlust steigen gleichzeitig | Kontroll- und Datenebene werden durch vervielfältigten Verkehr belastet | Geräteauslastung, Drops, Paketrate und Topologieänderungen auf einer Zeitachse |
Zuerst das Redundanzmodell festlegen
Vor der Bestellung muss feststehen, wer den aktiven Pfad auswählt und welche Komponente eine Schleife verhindert. Die Antwort darf nicht aus zwei unabhängig konfigurierten Enden entstehen. Betreiber, beide Kundenswitches und gegebenenfalls ein Overlay müssen dasselbe Modell verwenden. Ein zweiter Link, der im Fehlerfall manuell aktiviert wird, hat andere Anforderungen als ein All-Active-Design.
| Modell | Normalzustand | Zwingend zu klären |
|---|---|---|
| Single-Active | Ein Pfad leitet weiter, der zweite wartet | Erkennung, Umschaltkriterium, Haltezeit und kontrollierte Rückkehr |
| Spanning Tree | STP blockiert einen redundanten Port oder VLAN-Pfad | BPDU-Transport, Root-Platzierung, STP-Variante und VLAN-Zuordnung |
| Logisches Link-Bündel | Mehrere Mitglieder bilden einen gemeinsam gesteuerten Link | Endpunkte, LACP-Verhalten, Mindestanzahl aktiver Mitglieder und Fehlerdomänen |
| EVPN-Multihoming | Single-Active oder All-Active mit verteiltem Kontrollverfahren | End-to-End-Unterstützung, ESI, DF-Wahl, Split Horizon und MAC-Mobility |
Layer 3 ist oft die einfachere Redundanzgrenze
Wenn Anwendungen keine gemeinsame Broadcast-Domain benötigen, können geroutete Übergaben mit einem Routingprotokoll den Ausfallbereich verkleinern. Ein VLAN sollte nicht nur deshalb über Standorte gespannt werden, weil zwei Leitungen vorhanden sind.
Spanning Tree funktioniert nur mit einer bekannten BPDU-Grenze
STP kann kundenseitig einen der beiden Wege blockieren. Dafür müssen die Switches die benötigten Bridge Protocol Data Units zuverlässig austauschen und dieselbe logische Topologie sehen. Ein L2-Dienst kann BPDUs transparent transportieren, filtern oder selbst terminieren; das darf nicht angenommen werden, sondern gehört in die Leistungsbeschreibung. Ebenso müssen Root Bridge, Pfadkosten, RSTP- oder MSTP-Verhalten und die Zuordnung von VLANs zu Instanzen dokumentiert sein.
- Auf jedem Standort festlegen, welcher Switch Root oder bevorzugter Root sein soll.
- Für jedes transportierte VLAN wissen, welcher Port im stabilen Zustand weiterleitet und welcher blockiert.
- Klären, ob der Dienst BPDUs, Link-OAM und andere Kontrollprotokolle transparent transportiert.
- Schutzfunktionen wie BPDU Guard, Root Guard oder Loop Guard nur mit passender Portrolle einsetzen.
- Einseitige Fehler einplanen: Ein Link kann Frames noch senden, aber Kontrollpakete in Gegenrichtung verlieren.
Betreiber- und Kundenschleifen sind zwei verschiedene Ebenen
Ein Provider kann seine eigene L2-VPN-Topologie mit Split Horizon schleifenfrei halten. RFC 4762 beschreibt für VPLS, dass Broadcast, unbekannter Unicast und Multicast geflutet werden, Frames aber nicht von einem Pseudowire auf einen anderen Pseudowire desselben vollständigen Meshes weitergereicht werden dürfen. Diese Regel schützt das Provider-Mesh. Sie beweist nicht, dass eine Schleife aus zwei Kundenswitches, Querverbindungen oder falsch gekoppelten VLANs ebenfalls verhindert wird.
RFC 4762: Flooding und Split Horizon in VPLS
Illustratives Szenario: VLAN 120 über zwei Strecken
Das folgende Beispiel verwendet ausschließlich Dokumentationswerte: Standort A und Standort B verbinden VLAN 120 über Strecke Rot und Strecke Blau. An beiden Standorten existiert zusätzlich eine interne Verbindung zwischen den beteiligten Switches. Es handelt sich nicht um eine reale AS51202-Topologie, kein bestätigtes Redundanzverfahren und keine Produktzusage.
| Zustand | Unsichere Wirkung | Kontrolliertes Verhalten |
|---|---|---|
| Beide Strecken verfügbar | Beide Ports leiten VLAN 120 ohne gemeinsame Logik weiter | Ein Port blockiert oder ein abgestimmtes All-Active-Verfahren verhindert Rückführung |
| Strecke Rot fällt aus | Manuelle Änderungen an beiden Enden erfolgen in unterschiedlicher Reihenfolge | Das definierte Verfahren aktiviert Blau erst nach eindeutiger Fehlererkennung |
| Rot kehrt zurück | Beide Pfade leiten während einer unkoordinierten Rückkehr gleichzeitig | Hold-down, Synchronisation und Rückkehrregel verhindern einen transienten Doppelpfad |
Die Rückkehr ist genauso wichtig wie der Ausfall. Viele Fehler entstehen nicht beim Trennen eines Kabels, sondern wenn ein Pfad wieder erscheint, Endpunkte zu unterschiedlichen Zeitpunkten konvergieren und MAC-Einträge noch den alten Weg zeigen.
Zwei Leitungen sind nicht automatisch ein LACP-Bündel
Ein Link Aggregation Group kann mehrere physische Mitglieder als einen logischen Link behandeln. Das funktioniert jedoch nur, wenn die gegenüberliegenden Systeme und die Transportarchitektur genau dieses Bündel gemeinsam unterstützen. Zwei voneinander unabhängige Carrier-Dienste lassen sich nicht allein durch identische LACP-Konfiguration an den Kundenswitches sicher zusammenfassen. Auch Mindestanzahl aktiver Mitglieder, Hash-Verteilung, MTU, VLAN-Liste und Verhalten bei einem einseitigen Mitgliederausfall müssen übereinstimmen.
EVPN-Multihoming braucht mehr als zwei aktive Ports
EVPN kann MAC-Erreichbarkeit über BGP verteilen und ein Ethernet-Segment an mehrere Provider Edges anbinden. RFC 7432 definiert dafür unter anderem Ethernet Segment Identifier, Auto-Discovery, Designated-Forwarder-Wahl und Split-Horizon-Verfahren. Der Designated Forwarder steuert bei mehrzieligem Verkehr, welcher Knoten in ein multihomed Segment weiterleitet. Das Modell muss auf allen beteiligten Systemen konsistent eingerichtet sein; zwei Ports mit demselben VLAN bilden noch kein EVPN-Multihoming.
RFC 7432: EVPN-Multihoming und Designated Forwarder
RFC 9746 präzisiert zwei Split-Horizon-Verfahren für EVPN-Multihoming: ein ESI-Label-basiertes Verfahren und Local Bias. Beide sollen verhindern, dass ein Frame an dasselbe multihomed Kundensegment zurückgesendet wird, aus dem er stammt. Welche Methode passt, hängt unter anderem von der Tunnelart ab. Deshalb gehören Kapselung, Betriebsmodus und Interoperabilität in die Planung; „EVPN“ allein ist keine vollständige Redundanzbeschreibung.
RFC 9746: Split-Horizon-Verfahren für EVPN-Multihoming
Flooding und MAC-Lernen messbar machen
Auch ohne Schleife gehört BUM-Verkehr zum L2-Betrieb: Broadcast, Unknown Unicast und Multicast. RFC 7348 beschreibt für VXLAN, wie unbekannte Ziele und Broadcasts repliziert werden und wie die Zuordnung von Quell-MAC zu Tunnelendpunkt gelernt wird. Ein ungewöhnlich hoher Unknown-Unicast-Anteil kann auf fehlendes oder instabiles Lernen hinweisen. Eine reine Bandbreitenkurve reicht nicht; benötigt werden Werte je VLAN, Richtung und Knoten.
RFC 7348: MAC-Lernen und BUM-Verkehr in VXLAN
- Broadcast, Multicast und Unknown Unicast getrennt nach Paketrate und Datenrate beobachten.
- MAC-Moves mit alter Schnittstelle, neuer Schnittstelle, VLAN und Zeitstempel protokollieren.
- STP-Topologieänderungen, Root-Wechsel und Portrollen mit Linkereignissen korrelieren.
- Drops, Fehlerzähler und CPU-Last an beiden Standortenden gemeinsam auswerten.
- Alarme auf die normale Umgebung abstimmen; eine einzelne ARP-Spitze ist noch kein Schleifennachweis.
Abnahme muss Ausfall und Rückkehr prüfen
- 1Kabelbild, VLANs, Portrollen, Kontrollprotokolle und erwarteten Normalzustand in einem gemeinsamen Diagramm festhalten.
- 2Im stabilen Zustand für jedes VLAN aktiven und blockierten Pfad beziehungsweise DF-Rolle dokumentieren.
- 3Jede Strecke einzeln trennen und Erkennungszeit, Umschaltung, Paketverlust, MAC-Moves und Anwendungsauswirkung messen.
- 4Einen einseitigen Fehler testen, bei dem nur eine Richtung oder nur Kontrollverkehr beeinträchtigt ist.
- 5Die Strecke kontrolliert zurückbringen und prüfen, ob Hold-down, Synchronisation und MAC-Lernen ohne Doppelweiterleitung funktionieren.
- 6Mit legitimem Broadcast-, Multicast- und Unicast-Testverkehr prüfen, dass Zähler und Alarme die erwarteten Pfade zeigen.
Welche Angaben in eine L2-Anfrage gehören
Nennen Sie beide exakten Übergabepunkte, Bandbreite, Porttyp, MTU, VLANs und gewünschtes Tagging. Beschreiben Sie die Kundenswitches, interne Querverbindungen und das gewünschte Modell: Single-Active, kundenseitiges STP, ein abgestimmtes Bündel oder Multihoming. Fragen Sie ausdrücklich nach dem Umgang mit BPDUs und anderen Kontrollprotokollen, MAC-Limits, BUM-Verkehr, Fehlererkennung und Wartungsfällen. Für eine AS51202-Anfrage wird anschließend geprüft, welche Übergabe und Redundanzoption an den gewünschten Standorten tatsächlich verfügbar und vertraglich festzuhalten ist.