Wenn eine Leitung ausfällt, läuft es weiter.

Nur bedingt. Echte Redundanz braucht Vielfalt: unterschiedliche Provider und möglichst unterschiedliche Übertragungsmedien. Sonst trifft eine Störung im Provider-Netz oder an der Leitungstrasse beide Anschlüsse gleichzeitig.

Bei klassischer Dual-WAN-Redundanz sind eingehende Verbindungen an die öffentliche IP der jeweiligen Leitung gebunden. Fällt der Anschluss mit der statischen IP aus, sind Dienste auf dieser Adresse zunächst nicht erreichbar. Hat der zweite Festnetzanschluss ebenfalls eine feste öffentliche IP, kann man mit DNS-Failover oder einer zweiten Zieladresse arbeiten. Das ist bewährte Technik, aber es gibt Reconnect- und Umschaltzeiten. Ist der Zweitweg LTE/5G oder ein Anschluss hinter CGNAT, sind eingehende Verbindungen in einem klassischen Setup in der Regel nicht mehr erreichbar.

Für ausgehende Verbindungen kann die Umschaltung je nach Router, Erkennung und Verfahren schnell erfolgen, klassisches Dual-WAN liegt dabei aber eher im Sekundenbereich. Bestehende Sessions brechen häufig trotzdem ab, weil NAT, Quell-IP oder Providerpfad wechseln. In gerouteten Umgebungen mit IGP (OSPF oder IS-IS) lässt sich die lokale Reparatur über Fast Reroute und (TI-)LFA mit vorab berechneten Ersatzwegen in den Zielbereich von unter 50 Millisekunden bringen. Welche Umschaltzeiten realistisch sind, hängt vom Aufbau ab; die genauen Zeiten und Auswirkungen messen wir im Failover-Test.

Für eine einfache Backup-Leitung meistens nicht. Ein 5G- oder VDSL-Ersatzpfad wird in klassischen Setups über Dual-WAN, NAT, Policy-Based Routing und Failover-Tests genutzt, vor allem für ausgehenden Verkehr. BGP ist ein anderes Thema: Es lohnt sich, wenn eigene Prefixe über geeignete Provider- oder Transit-Anbindungen geroutet werden sollen. Bei LTE/5G mit CGNAT löst BGP die eingehende Erreichbarkeit nicht. Dafür braucht es ein anderes Konzept, zum Beispiel IP Access Flex.

MPLS wird klassisch als gemanagtes Provider-VPN (L3VPN) bezogen und ergibt ein sehr steuerbares WAN: Traffic Engineering legt Pfade gezielt fest, DiffServ-QoS priorisiert kritischen Verkehr, und MPLS-TE Fast Reroute schaltet im Fehlerfall auf vorab berechnete Ersatzpfade, im Carrier-Netz mit deterministischer Latenz und SLA. Dieselben Steuerungsprinzipien, also Traffic Engineering, Segmentierung und QoS, lassen sich auch als eigenes Overlay über normale Internet-Anschlüsse umsetzen, ohne Carrier-MPLS-Vertrag. Die Qualitätseigenschaften eines Carrier-Netzes, insbesondere deterministischer Jitter und SLA-gesicherte Latenz, erreicht ein Internet-Overlay dabei nicht. Ob sich das im Vergleich zum Carrier-VPN wirtschaftlich rechnet, hängt von vorhandenen Anschlüssen, Standortzahl und Anforderungen ab. Für einen einzelnen Standort mit einfachem Dual-WAN ist das meist überdimensioniert; interessant wird es bei mehreren Standorten, klaren internen Traffic-Anforderungen und kritischen Anwendungen.

Ja. Wir provozieren Leitungsausfälle gezielt und prüfen, ob die Umschaltung sauber und in der erwarteten Zeit funktioniert. Ein ungetesteter Failover ist nur eine Annahme.

Ja. Wenn Mobilfunk oder Satellit am Standort die bessere Bandbreite liefern, können sie als aktiver oder sogar primärer Pfad genutzt werden. Für ausgehenden Verkehr funktioniert das oft gut. Eingehende Dienste wie Client-VPN, Portfreigaben oder externe Zugriffe sind bei LTE/5G und vielen Starlink-Setups in klassischen Redundanzkonzepten jedoch meist nicht erreichbar, weil CGNAT, dynamische Adressen oder Providergrenzen im Weg stehen.

Wenn nicht nur ausgehender Internetzugang redundant sein soll, sondern auch feste öffentliche IPs, VPN-Ziele, Partnerzugänge oder geroutete Netze über verschiedene Access-Medien stabil erreichbar bleiben müssen. Besonders relevant ist das bei LTE/5G, Starlink, CGNAT oder dynamischen Provider-IPs.

Standortvernetzung beschreibt die Verbindung mehrerer Standorte und Netze. Redundante Anbindung fokussiert auf die Verfügbarkeit eines Standortes: Welche Access-Pfade existieren, was passiert bei Ausfall, welche IPs bleiben stabil und wie wird das getestet?