bintorosoft.com

Customer Edge Redundanz: Dual-Homing, Diverse Paths und Failure Handling

Red Snapper

Customer Edge Redundanz ist im Provider- und Enterprise-Connectivity-Umfeld der wichtigste Baustein, um Ausfälle am Netzrand abzufangen: Kabelschäden, Provider-Störungen, Wartungen, Stromprobleme im Gebäude oder Fehlkonfigurationen sollen nicht sofort zum Serviceausfall führen. Dabei reicht es nicht, „zwei Leitungen“ zu bestellen. Redundanz funktioniert nur dann zuverlässig, wenn Dual-Homing, diverse Pfade (Trassen-/Facility-Diversität) und Failure Handling als zusammenhängendes Topologie- und Betriebsmodell geplant werden. In der Praxis scheitern viele Designs an scheinbaren Details: beide Leitungen enden in derselben Straßenführung, beide Übergaben hängen am selben PoP, beide CEs teilen sich dieselbe Stromversorgung, oder das Routing failt zwar „technisch“, aber in einem unkontrollierten Muster (Flapping, asymmetrische Pfade, stateful Services brechen, MTU-Blackholes). Ein professionelles Design definiert daher zuerst die Failure Domains, dann die gewünschte Failover-Charakteristik (Active/Standby oder Active/Active), und erst danach das Protokoll- und Policy-Setup (Static/BGP/OSPF, Tracking, BFD, Communities). Dieser Artikel zeigt praxisnah, wie Sie Customer Edge Redundanz sauber planen: von Dual-Homing-Topologien über Pfaddiversität und SLA-Denken bis hin zu Failover-Tests und Observability, damit Redundanz auch im echten Störfall wirkt – nicht nur auf dem Papier.

Was bei Customer Edge Redundanz wirklich abgesichert werden muss

Bevor man über Topologien spricht, muss klar sein, welche Ausfälle realistisch sind. Viele Redundanzdesigns schützen nur gegen „eine Leitung kaputt“, scheitern aber bei gemeinsamen Risiken: gleiche Trasse, gleicher PoP, gleiche Stromphase, gleicher Gebäudeeintritt. Eine saubere Risikoanalyse ordnet Ausfälle in Failure Domains und priorisiert sie nach Eintrittswahrscheinlichkeit und Impact.

Leitprinzip: Redundanz muss Shared Risk vermeiden, nicht nur Links duplizieren

Ein zweiter Link ohne Diversität reduziert die Ausfallwahrscheinlichkeit oft viel weniger als erwartet. Der größte Hebel ist das Minimieren gemeinsamer Risiken (SRLG): unterschiedliche Trassen, unterschiedliche PoPs, unterschiedliche Strom-/Rack-Feeds.

Dual-Homing Grundmuster: Single-CE, Dual-CE, Single-Provider, Dual-Provider

Dual-Homing beschreibt, dass ein Kundennetz über zwei unabhängige Übergaben zum Provider (oder zu mehreren Providern) verbunden ist. Diese Übergaben können auf einem einzigen CE-Gerät enden oder auf zwei separaten CEs. Außerdem kann die Redundanz innerhalb eines Providers stattfinden (zwei PEs/PoPs) oder über zwei Provider hinweg. Jedes Muster hat einen anderen Betriebsaufwand und eine andere Resilienz.

Ein häufiger Irrtum: Dual-Link ist automatisch Dual-Homing

Wenn beide Links am selben PE oder im selben PoP enden, ist das eher Link-Redundanz als echtes Dual-Homing. Echte Dual-Homing-Resilienz entsteht erst, wenn auch die Provider-Seite divers ist.

Diverse Paths: Trassen-, Facility- und Geräte-Diversität richtig definieren

„Diverse Paths“ ist der wichtigste Begriff in Customer Edge Redundanz, weil er die Qualität der Redundanz bestimmt. Die Herausforderung: Diversität ist mehrschichtig. Zwei Leitungen können im Angebotstext „divers“ wirken, teilen aber trotzdem kritische Abschnitte. Daher sollten Diversitätsanforderungen konkret formuliert und vertraglich/technisch überprüfbar sein.

Praktische Daumenregel für Diversität

Wenn Sie nicht eindeutig benennen können, welcher Abschnitt nur einmal im Design vorkommt (Single Point), dann ist Diversität wahrscheinlich nicht wirklich geprüft. Gute Redundanzdesigns dokumentieren Shared-Risk-Segmente explizit.

Active/Standby vs. Active/Active: Entscheidung nach Risiko, State und Betrieb

Eine zentrale Designentscheidung ist, ob beide Pfade gleichzeitig genutzt werden (Active/Active) oder ob ein Pfad primär und der andere Backup ist (Active/Standby). Active/Active kann Kapazität besser nutzen und Failover weicher machen, ist aber empfindlicher gegenüber Asymmetrie und stateful Services (Firewalls, NAT, Session-Tracking). Active/Standby ist oft betrieblich „langweiliger“ und damit stabiler, besonders wenn Kunden-Apps oder Security-Gateways empfindlich auf Pfadwechsel reagieren.

Designregel: Stateful Services definieren die Grenze für Active/Active

Wenn am CE oder im Kundennetz stateful Firewalls, NAT oder IPSec-Tunnel hängen, ist Active/Active nur sinnvoll, wenn State-Synchronisation, Symmetrie oder klare Flow-Affinität gewährleistet sind. Sonst ist Active/Standby oft die bessere Wahl.

Routing-Optionen für Dual-Homing: Static, BGP und OSPF im Redundanzkontext

Redundanz wird nicht nur durch Topologie, sondern durch Failure Handling im Routing erreicht. In der Praxis sind drei Modelle verbreitet: Static mit Tracking, BGP als Standard für Policy und Multi-Site, und OSPF in bestimmten Enterprise-Integrationen. Entscheidend ist, dass das Protokoll zur Redundanzanforderung und zur Betriebsreife passt.

BGP als Provider-Standard

Für echte Dual-PoP- oder Dual-Provider-Redundanz ist BGP häufig der stabilste Standard, weil Pfadpräferenzen und Failover-Policies klar modellierbar sind und sich über Templates gut operationalisieren lassen.

Failure Handling: Detection, Convergence und kontrolliertes Umschalten

Die beste Topologie nützt wenig, wenn Fehlererkennung zu langsam oder zu aggressiv ist. Zu langsam bedeutet längere Unterbrechungen. Zu aggressiv führt zu Flapping und instabilen Übergängen. Gutes Failure Handling kombiniert zuverlässige Signale (Link Down, BFD, Tracking) mit Hysterese und klaren Failover-Regeln.

Ein wichtiges Konzept: „Hard Down“ vs. „Soft Failure“

Link-Down ist eindeutig. „Soft Failures“ (Congestion, Paketverlust, einseitige Störungen) sind schwerer. Tracking-Mechanismen sollten so gestaltet sein, dass sie echte Fehler erkennen, aber nicht bei kurzfristigen Peaks unnötig failovern.

Policy-Design: Präferenzen, Communities und kontrollierte Pfadwahl

Redundanz ist nicht nur „weg vom kaputten Link“, sondern auch „zur richtigen Alternative“. In Dual-Homing-Designs müssen Sie definieren, welche Pfade bevorzugt sind, welche nur Backup sind, und wie Traffic im Normalbetrieb verteilt wird. BGP-Policies (Local Preference, AS-Path, Communities) sind dafür das präziseste Werkzeug, insbesondere wenn Provider-seitig gesteuert werden soll.

Designregel: Policy muss auch im Störfall gültig bleiben

Viele Policies funktionieren im Normalbetrieb, brechen aber im Failover (z. B. weil Backup-Pfade andere MTU, andere Security Chains oder andere Exits haben). Deshalb muss Policy-Design immer mit Störfalltests gekoppelt werden.

Kapazität und QoS: N-1 ist Pflicht, sonst ist Redundanz nur „up“ aber nicht „gut“

Ein häufiger Redundanzfehler ist fehlende Störfallkapazität: Im Failover wird ein Link zwar erreicht, aber die Performance bricht ein. Das ist besonders kritisch für Echtzeitdienste, VPNs, VoIP, Produktionssysteme oder mobile Backhaul-ähnliche Profile. Deshalb braucht Customer Edge Redundanz eine N-1-Kapazitätsregel und QoS-Strategien, die kritische Klassen schützen.

Redundanz ohne Headroom erzeugt flache SLA-Verletzungen

Wenn Failover regelmäßig Congestion erzeugt, erleben Kunden das als „instabile Leitung“, obwohl die Architektur formal redundant ist. N-1 Headroom ist deshalb ein Servicequalitätskriterium.

MTU, Encapsulation und Statefulness: Die stillen Redundanzkiller

Viele Failover-Probleme entstehen nicht im Routing, sondern in Randbedingungen: der Backup-Pfad hat eine kleinere MTU, PMTUD/ICMP ist blockiert, oder der Traffic läuft im Failover durch eine andere Firewall-/NAT-Instanz ohne State. Diese Effekte sind besonders heimtückisch, weil sie selektiv wirken: Manche Anwendungen gehen, andere nicht.

Designregel: Backup-Pfad ist ein gleichwertiger Pfad, nicht „irgendwie da“

Ein Backup-Pfad muss dieselben grundlegenden technischen Eigenschaften erfüllen (MTU, Security Chains, QoS), sonst ist er im Incident eine Überraschung.

Tests und Runbooks: Redundanz ist nur echt, wenn sie geübt wird

Customer Edge Redundanz muss getestet werden – regelmäßig und strukturiert. Tests sollten nicht nur „Link ziehen“ sein, sondern auch Soft-Failure-Szenarien abdecken, Lastbedingungen berücksichtigen und klar definierte Erfolgskriterien haben. Ebenso wichtig sind Runbooks: Wer macht was bei welchem Alarm, wie wird Failback gesteuert, und wie wird nach einem Incident verifiziert, dass alles wieder im Normalzustand ist?

Ein operativer Erfolgsmesser

Wenn Ihr Team innerhalb weniger Minuten erklären kann, warum der Traffic gerade Pfad A oder Pfad B nutzt, und welche Failure Domain aktiv ist, dann ist das Redundanzdesign betrieblich reif.

Observability: Redundanz muss messbar sein, nicht nur konfiguriert

Ohne Telemetry wird Redundanz erst dann sichtbar, wenn Kunden betroffen sind. Gute Observability umfasst Pfad-KPIs (Latenz/Loss/Jitter), BGP/Session-Health, Interface/Optik-Health, Queue-Drops und Event-Korrelation. Wichtig ist, Normal- und Backup-Pfad getrennt zu messen.

Evidence-by-Design: SLA-Redundanz beweisen

Wenn Sie belegen können, dass Failoverzeiten, Drop-Spitzen und Pfadqualität innerhalb definierter Grenzen bleiben, wird Redundanz von „Marketing“ zu einem belastbaren Serviceversprechen.

Typische Fallstricke und wie man sie vermeidet

Praktische Leitlinien: Dual-Homing, Diverse Paths und Failure Handling sauber umsetzen

Exit mobile version