← Zurück zur Übersicht
Routing

Anycast

Routing zum nächsten Knoten

AnycastRoutingDNSCDNDDoS-SchutzBGPLatenz

Anycast weist mehreren Servern weltweit dieselbe IP-Adresse zu. Das Routing-Protokoll (BGP) leitet Anfragen automatisch zum nächstgelegenen Server. Ein Nutzer in Europa erreicht einen europäischen Server, ein Nutzer in Asien den asiatischen — mit derselben IP. Genutzt von Cloudflare, Google und jedem großen DNS-Anbieter.

Anycast – gleiche IP, nächster ServerInternetBGP-Routing→ nearestServer EU1.1.1.1FrankfurtServer US1.1.1.1New YorkServer APAC1.1.1.1SingaporeServer AU1.1.1.1SydneyCloudflare 1.1.1.1 · Google 8.8.8.8 · Root-DNS

Entstehung und Beteiligte

Anycast wurde 1993 von Chris Partridge, Trevor Mendez und Walter Milliken in RFC 1546 beschrieben. Die Idee nutzt dieselbe IP-Adresse an mehreren Orten; das Routing liefert Pakete zu einer topologisch günstigen Instanz.

Welches Problem sollte gelöst werden?

Globale Dienste sollten kurze Wege, Lastverteilung und Ausfallsicherheit erhalten, ohne dass Clients einen speziellen Server auswählen müssen. Besonders DNS-Rootserver profitierten von geografisch verteilten Instanzen.

Technische Hürden und Lösungen

Routing entscheidet nicht nach Serverlast und kann Wege während einer Sitzung ändern. Zustandsbehaftete Anwendungen benötigen stabile Zuordnung oder externen Zustand. Fehlerhafte BGP-Ankündigungen können Verkehr weitreichend umleiten.

Standardisierung und Einordnung

Routingverfahren beantworten die Frage, über welchen nächsten Knoten ein Paket sein Ziel erreicht. Ihre Entwicklung ist eng mit dem Wachstum des Internets und großer Unternehmensnetze verbunden. Die schwierigsten Probleme sind Schleifen, langsame Konvergenz, unvollständige Informationen und die Skalierung großer Tabellen. Kein Algorithmus kennt das gesamte reale Netz in Echtzeit; Router arbeiten mit ausgetauschten Zuständen, Regeln und Metriken.

Technik im praktischen Betrieb

Im Betrieb müssen Steuerungsebene und tatsächliche Weiterleitung getrennt geprüft werden. Eine Route kann im Protokoll gelernt, durch eine Richtlinie verworfen oder wegen eines anderen Präfixes nie verwendet werden. Nach Änderungen sind Nachbarschaft, Datenbank, Routingtabelle, Forwarding-Tabelle und Rückweg zu kontrollieren. Schnelle Konvergenz ist nicht automatisch stabil: zu aggressive Timer können kurze Lastspitzen als Leitungsfehler interpretieren. Zusammenfassungen und Filter reduzieren Größe, können aber Detailinformation verbergen.

Warum das Thema heute noch relevant ist

Die Relevanz dieser Verfahren wächst mit der Abhängigkeit von Netzen. Schon eine kleine fehlerhafte Ankündigung kann heute Rechenzentren, Cloudregionen oder Teile des Internets betreffen. Historisch gewachsene Vertrauensmodelle werden deshalb durch Filter, Authentifizierung, RPKI, Telemetrie und Automatisierung ergänzt. Trotzdem bleibt menschliche Kontrolle notwendig: Ein formal gültiger Weg kann geschäftlich oder sicherheitstechnisch falsch sein, und ein schneller Ersatzpfad kann andere Leitungen überlasten.

Daten und Meilensteine

  • 1993: RFC 1546 beschreibt IP Anycast.
  • Mehrere Standorte kündigen dasselbe Präfix an.
  • DNS, CDN und DDoS-Abwehr nutzen Anycast häufig.
  • Anycast ist keine Garantie für geografisch den nächsten Server.

Was ist Anycast?

Anycast ist eine Routing-Methode, bei der dieselbe IP-Adresse an mehreren geografisch verteilten Standorten gleichzeitig angekündigt wird. Das Routing-Protokoll (typisch BGP) leitet jede Anfrage automatisch zum topologisch nächsten Knoten — basierend auf BGP-Metriken, nicht auf geographischer Entfernung.

Das bekannteste Anycast-Beispiel: Cloudflares DNS-Resolver 1.1.1.1. Diese IP-Adresse ist an über 300 Standorten weltweit aktiv. Ein Nutzer in München wird zu einem Frankfurter PoP geroutet, einer in Tokio zum nächsten asiatischen PoP — beide nutzen dieselbe IP.

Wie Anycast mit BGP funktioniert

Jeder Anycast-Standort kündigt das Anycast-Prefix (z.B. 1.1.1.1/32 oder ein /24) via BGP an. Das Internet-Routing wählt automatisch den kürzesten/besten BGP-Pfad (AS-Path-Länge, MED, Local-Preference, etc.).

Bei einem Ausfall eines Anycast-Knotens: BGP zieht das Prefix zurück, Traffic fließt automatisch zum nächsten verfügbaren Knoten. Kein manuelles Failover, keine Konfigurationsänderung — BGP convergiert in Sekunden bis Minuten.

  • Kein DNS-TTL-Problem wie bei geografischem DNS-Steering
  • Keine Sticky-Sessions-Probleme bei kurzlebigen UDP-Flows
  • Kein State-Sharing zwischen Anycast-Knoten nötig (für DNS/NTP ideal)
  • Für TCP-Sessions: Verbindung muss vollständig von einem Knoten bedient werden (State)

Anwendungsfälle

Anycast ist überall dort optimal, wo Anfragen zustandslos sind (kurz, idempotent) und niedrige Latenz wichtig ist:

DNS: Die 13 Root-DNS-Server nutzen Anycast — tatsächlich sind es hunderte physische Server. Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9.

NTP: pool.ntp.org ist Anycast-basiert. Zeit-Anfragen sind zustandslos, Anycast leitet zur niedrigst-latenten Quelle.

DDoS-Abwehr: Cloudflare, Akamai, Fastly nutzen Anycast um DDoS-Angriffe auf hunderte PoPs zu verteilen — der Angriff wird absorbiert statt einen einzigen Server zu überlasten.

CDN: Edge-Nodes von CDNs sind Anycast-adressiert.

Anycast vs. Unicast, Multicast, Broadcast

Die vier Adressierungsarten im Überblick:

Unicast: Eine IP → ein Empfänger. Standard-Internet-Kommunikation. Multicast: Eine IP → Gruppe von Empfängern (die sich angemeldet haben). Für Video-Streaming, Routing-Protokolle. Broadcast: Eine IP → alle im Segment. Nur Layer 2, kein Internet-Broadcasting. Anycast: Eine IP → nächster von vielen Empfängern. Automatisches geografisches Load-Balancing.

Anyone-Unicast ist in IPv6 explizit standardisiert (RFC 4291). In IPv4 gibt es keinen formalen Anycast-Standard, aber die Praxis ist seit den 1990ern verbreitet.