Failover ohne DNS-Latenz: BGP Anycast für KRITIS-Plattformen

In herkömmlichen Hochverfügbarkeits-Szenarien ist DNS (Domain Name System) das Standardwerkzeug für den Failover. Fällt Standort A aus, wird der DNS-Eintrag auf die IP von Standort B umgebogen. Doch in der KRITIS-Welt, insbesondere bei der Steuerung von Strom- oder Gasnetzen, stößt dieser Ansatz an drei kritische Grenzen:

1. TTL-Verzögerung: DNS-Einträge werden weltweit gecacht. Selbst bei einer niedrigen “Time to Live” (TTL) dauert es Minuten bis Stunden, bis jeder Client die neue IP übernimmt.
2. Harte IP-Vorgaben: Viele Netzbetreiber nutzen starre Firewall-Regeln oder VPN-Tunnel, die auf eine feste IP-Adresse programmiert sind. Eine Änderung der IP am Zielort erfordert koordinierte manuelle Arbeit bei dutzenden Kunden gleichzeitig.
3. Client-Verhalten: Manche SCADA-Systeme oder IoT-Gateways cachen IP-Adressen dauerhaft (“Sticky DNS”) und bemerken eine Änderung erst nach einem manuellen Neustart.

Die Lösung für dieses Problem ist BGP Anycast. Hierbei wird die Umschaltung von der Applikationsebene direkt in das Fundament des Internets verschoben: das Routing.

1. Das Prinzip: Eine IP, viele Orte

Bei Anycast wird dieselbe IP-Adresse gleichzeitig von zwei oder mehr geografisch getrennten Rechenzentren in das Internet “bekannt gegeben” (announced). Das Border Gateway Protocol (BGP) sorgt dafür, dass der Traffic immer den kürzesten Weg zum nächsten gesunden Standort nimmt.

• Normalbetrieb: Ein Nutzer in Norddeutschland wird automatisch zum Rechenzentrum in Berlin geleitet, ein Nutzer im Süden nach Frankfurt - beide nutzen dieselbe IP.
• Der Failover-Moment: Fällt der Standort Frankfurt komplett aus (z. B. durch einen Glasfaser-Schnitt), zieht das System das BGP-Announcement für diesen Standort sofort zurück.
• Die Reaktion: Innerhalb von Sekunden “merkt” das globale Routing, dass Frankfurt nicht mehr erreichbar ist. Der gesamte Traffic fließt automatisch zum verbleibenden Standort in Berlin - ohne dass sich die IP-Adresse ändert und ohne dass ein DNS-Eintrag angefasst werden muss.

2. RTO unter 30 Sekunden: Umschalten auf Netzwerkebene

In unserem KRITIS-Projekt war die Zielvorgabe eine Wiederherstellungszeit (RTO) von unter 60 Sekunden. Mit DNS-basierten Lösungen war dies unmöglich zu garantieren. Durch den Einsatz von Anycast erreichten wir in Tests eine Umschaltzeit von unter 30 Sekunden.

Der entscheidende Vorteil: Für die Endgeräte der Kunden (die Netzsteuerungs-Gateways) sieht es lediglich so aus, als gäbe es eine kurze Netzwerkstörung (“Flapping”). Sobald die Route über BGP neu berechnet ist, läuft die Kommunikation über denselben VPN-Tunnel und dieselbe Firewall-Regel an den neuen Standort weiter.

3. Bring-Your-Own-IP (BYOIP) als strategischer Anker

Für KRITIS-Betreiber ist die Unabhängigkeit vom Provider essenziell. Durch BYOIP kann der Kunde seinen eigenen IP-Adressraum mitbringen.

• Provider-Unabhängigkeit: Man ist nicht an die IP-Bereiche eines spezifischen Rechenzentrums-Betreibers gebunden.
• Migrations-Sicherheit: Wenn die Plattform in Zukunft zu einem anderen Anbieter umzieht, bleiben die IP-Adressen identisch. Kunden müssen ihre Gateways niemals umkonfigurieren.

Fazit: Failover als unsichtbare Funktion des Netzwerks

Durch die Kombination aus BGP Anycast und einer Multi-Region-Plattform wird der Katastrophenfall zu einem rein technischen Ereignis, das keine menschliche Koordination erfordert. Die Plattform “verschwindet” nie aus dem Netz, sondern wechselt lediglich ihren physischen Standort im Hintergrund. Das ist die technologische Basis, um die strengen Verfügbarkeitsgarantien im KRITIS-Umfeld nicht nur zu versprechen, sondern im Ernstfall auch zu liefern.

FAQ

Benötigt Anycast eine spezielle Hardware beim Kunden? Nein. Die Komplexität liegt vollständig auf der Seite des Plattform-Betreibers und dessen Peering-Partnern. Der Kunde nutzt die IP-Adresse wie jede andere Adresse im Internet oder im dedizierten Weitverkehrsnetz.

Wie wird verhindert, dass Traffic zwischen den Regionen “hin- und herspringt” (Flapping)? Durch geschicktes BGP-Tuning (z. B. AS-Path Prepending) wird eine “bevorzugte” Route definiert. So bleibt der Traffic stabil an einem Standort, solange dieser gesund ist, und schwenkt erst bei einem echten Ausfall um.

Funktioniert Anycast auch mit VPN-Tunneln? Ja, aber es erfordert eine saubere Konfiguration der Tunnel-Endpunkte (Terminierung). In hochverfügbaren Umgebungen nutzen wir oft redundante Tunnel-Architekturen, die mit dem Anycast-Routing harmonieren.

Ist Anycast teurer als klassisches Load Balancing? Die Betriebskosten sind höher, da man eine engere Zusammenarbeit mit Netzwerk-Carrieren und meist eigenen IP-Space (AS-Nummer) benötigt. Für KRITIS-relevante Systeme ist dies jedoch oft die einzige Möglichkeit, die geforderten RTO-Zeiten zu erreichen.

Wie unterstützt ayedo bei der Implementierung von Anycast? Wir übernehmen die Architekturplanung des Netzwerks, unterstützen bei der Beantragung von IP-Präfixen (RIPE) und konfigurieren die BGP-Schnittstellen zwischen Ihren Kubernetes Clustern und den Upstream-Providern.