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.
- Last-Mile-Ausfall: Glasfaserbruch, Bauarbeiten, Muffe, Spleißfehler, beschädigtes Patchfeld.
- PoP-/Provider-Ausfall: Aggregationsrouter, Linecard, OLT/BNG/PE-Knoten, lokale Strom-/Klimaprobleme.
- Gebäude-/Campus-Risiken: Single Building Entry, internes Kabel, Brandschutzabschnitt, lokales Routing-Switching.
- CE-Risiken: Hardwaredefekt, PSU-Ausfall, Softwarebug, Konfigurationsfehler, Zertifikat/AAA-Abhängigkeiten.
- Operative Risiken: Wartung, Change-Fenster, Fehlbedienung, ungetestete Failover-Policies.
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.
- Single CE, Dual Links: Zwei Uplinks an einem Router/Firewall. Einfach, aber CE bleibt Single Point of Failure.
- Dual CE, Dual Links: Zwei CEs (z. B. Router/Firewalls) mit je einem Link. Höhere Resilienz, höherer Betriebsaufwand.
- Single Provider, Dual PoP: Beide Links zum selben Provider, aber in unterschiedliche PoPs/PEs. Gut für Betrieb, wenn echte PoP-Diversität vorhanden ist.
- Dual Provider: Zwei verschiedene Provider (idealerweise diverse Trassen/PoPs). Beste Resilienz, aber komplexere Policies und Koordination.
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.
- Trassen-Diversität: Unterschiedliche Straßenführung, unterschiedliche Kabelsysteme, minimale gemeinsame Strecke (SRLG).
- Building Entry Diversität: Zwei getrennte Gebäudeeintritte, unterschiedliche Steigwege, getrennte Brandabschnitte.
- PoP-/Facility-Diversität: Übergaben in zwei unterschiedliche PoPs oder sogar in zwei unterschiedliche Rechenzentren.
- Geräte-Diversität: Unterschiedliche Linecards/Chassis/Router, getrennte Stromfeeds, getrennte Ports und Cross-Connects.
- Carrier-Diversität: Zwei Provider oder zwei unabhängige Carrier-Netze, wenn das Risiko es erfordert.
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.
- Active/Standby Vorteile: deterministisches Verhalten, weniger Asymmetrierisiko, einfacheres Troubleshooting.
- Active/Standby Nachteile: Backup-Kapazität wird im Normalbetrieb weniger genutzt; Peak-Failover muss N-1 tragen.
- Active/Active Vorteile: bessere Kapazitätsausnutzung, potenziell geringere Failover-Spitzenlast.
- Active/Active Nachteile: höhere Policy-Komplexität, Risiko von Reordering, stateful Pfade müssen sauber geplant werden.
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.
- Static + Tracking: Geeignet bei wenigen Präfixen und klarer Primär/Backup-Logik; Failover hängt an verlässlichem Link-/Path-Tracking.
- BGP Dual-Homing: Sehr flexibel, klare Policies, gute Skalierung; erfordert Route Hygiene (Filter, Max-Prefix, Communities).
- OSPF Dual-Homing: Möglich, aber Redistribution und Domänengrenzen sind fehleranfällig; nur mit strikten Leitplanken.
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.
- Fehlererkennung: Link State, BFD (wo sinnvoll), IP SLA/Tracking für „Upstream reachable“ statt nur „Interface up“.
- Konvergenz: BGP Timer/Policies oder statische Umschaltung; Ziel ist reproduzierbares Verhalten.
- Hysterese: Hold-down-Timer oder Dampening, um Flapping zu vermeiden.
- Failback-Regeln: Zurückschalten ist oft riskanter als Umschalten; klare Kriterien verhindern Ping-Pong.
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.
- Primär/Backup Präferenz: Klar definierte Priorität pro Link/PoP/Provider.
- Traffic Engineering: Optional Active/Active mit kontrollierter Lastverteilung, ohne stateful Brüche.
- Route Hygiene: Prefix-Filter, Max-Prefix, Default-deny, um Leaks und Fehlkonfigurationen zu begrenzen.
- Blackhole-Patterns: Für DDoS-Szenarien oder harte Mitigation, ohne das gesamte Redundanzmodell zu zerstören.
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.
- N-1 Dimensionierung: Der verbleibende Pfad muss die kritische Last tragen können (mindestens für definierte Serviceklassen).
- QoS-Profile: Marking, Queuing und Policing so planen, dass Failover nicht zum unkontrollierten Drop führt.
- ECMP/Hashing: Bei Active/Active Hotspots vermeiden; Member-Visibility ist wichtig.
- Peak-Tests: Failover unter Last testen, nicht nur im Leerlauf.
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.
- MTU-Profile: End-to-end konsistent, inklusive Overhead (QinQ, PPPoE, MPLS/SR, IPsec).
- PMTUD-Strategie: ICMP kontrolliert erlauben oder MSS-Clamping gezielt einsetzen.
- Stateful Devices: Symmetrie sicherstellen oder State-Synchronisation planen.
- Asymmetrie erkennen: Monitoring für Pfadwechsel und Reordering, bevor Kunden es melden.
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?
- Geplante Failover-Tests: Link Down, PE Down, PoP Isolation, Provider-Wartung – jeweils mit Messkriterien.
- Failover unter Last: Realistische Peaks simulieren oder in geeigneten Zeitfenstern messen.
- Failback-Prozeduren: Rückschalten kontrolliert, mit Hold-down und Verifikation, um Ping-Pong zu vermeiden.
- Dokumentation: Shared Risks, Übergabepunkte, Policy-Logik und Kontaktketten transparent halten.
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.
- Pfadqualität: Latenz/Loss/Jitter pro Pfad, Trendanalyse und Anomalie-Erkennung.
- Routing-KPIs: BGP-Session-Status, Prefix-Counts, Flap-Events, Failoverzeiten.
- Link-KPIs: Optikwerte, CRC/Errors, Microbursts, LAG-Member-Auslastung.
- Service-KPIs: Applikationsnahe Checks (z. B. DNS/HTTP) aus Kundensicht, um Soft Failures zu erkennen.
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
- „Diverse“ Links mit Shared Trasse: Lösung: SRLG explizit prüfen, diverse Building Entries und PoPs verlangen.
- CE als Single Point of Failure: Lösung: Dual-CE oder zumindest duale PSU/Stacking/HA-Design.
- Flapping durch aggressive Timer: Lösung: Hysterese, konservatives Tracking, klare Failback-Kriterien.
- Backup-Pfad ohne Headroom: Lösung: N-1 Kapazität und QoS-Profile, Failover unter Last testen.
- MTU/State bricht im Failover: Lösung: MTU-Profile, PMTUD-Strategie, stateful Symmetrie oder State-Sync.
- Policy-Wildwuchs: Lösung: Standardprofile, BGP-Communities/Templates, Changes versionieren.
Praktische Leitlinien: Dual-Homing, Diverse Paths und Failure Handling sauber umsetzen
- Failure Domains definieren: Last Mile, Building Entry, PoP, Provider, CE, Betrieb – und Prioritäten festlegen.
- Diversität konkretisieren: Trassen- und Facility-Diversität, getrennte PoPs, getrennte Cross-Connects und Stromfeeds.
- Topologie passend wählen: Single CE/Dual Links für „basic“, Dual CE/Dual PoP oder Dual Provider für „high availability“.
- Active/Standby als Default: Besonders bei stateful Services; Active/Active nur mit Symmetrie- und Hashing-Disziplin.
- Routing-Mechanik standardisieren: Static+Tracking für klein, BGP für Wachstum/Policy, OSPF nur mit strikten Grenzen.
- Guardrails verpflichtend: Max-Prefix, Default-deny, Rate-Limits, Logging/Audit für Änderungen.
- N-1 und QoS planen: Backup muss kritische Last tragen; QoS schützt wichtige Klassen im Failover.
- MTU und State prüfen: Backup-Pfad technisch gleichwertig machen, PMTUD sicherstellen, stateful Pfade stabil halten.
- Tests & Runbooks etablieren: Regelmäßige Failover-/Failback-Tests, klare Erfolgskriterien, dokumentierte Prozeduren.
- Observability ausbauen: Pfadqualität, Routing-Events, Link-/Queue-Drops und Service-Checks pro Pfad messen.
