Anycast IP und Routing

Jeder Administrator mit TCP/IP-Kenntnissen kann mit Unicast, Multicast und Broadcast etwas anfangen. Aber wie funktioniert Anycast und wozu ist es gut?

Anycast-Routing eignet sich eigentlich nur für UDP-basierte Pakete wie z.B. DNS-Anfragen.

Die verschiedenen IP-Adressen

Wenn Sie die drei bekannten Klassen betrachten, dann hat jede ihren Einsatzbereich:

  • Unicast - Die persönliche IP-Adresse
    Ein System hat eine IP-Adresse, die sonst nirgendwo im LAN/WAN verwendet wird und unter der er erreichbar ist, Die Adressen bewegen sich zwischen 0.0.0.0 und 223.255.255.255
  • Multicast - 1:n
    Diese Adressen von 224.0.0.0-247.255.255.255 gehören nicht einem Zielsystem sondern mehrere Clients können auf diese Adresse hören. Sie teilen dazu den Routern per IGMP (Internet Group Messaging Protocol) mit, dass Sie diesen Kanal hören wollen. Sie eigenen sich ideal für Streaming von Daten an viele Clients. die damit nur einmal pro Subnetz verteilt werden müssten. Leider nutzen viele Systeme diese Option nicht, da man z.B. im Internet sich dann ja eine Nummer "reservieren" müsste. Im LAN hingegen ist das ein durchaus nützliches Verfahren um Daten an viele Clients parallel zu verteilen. Denken Sie mal neben Audio/Video auch an die Softwareverteilung.
  • Broadcast 255.255.255.255 oder x.x.x.255
    Ein Subnetz-Broadcast oder ein globaler Broadcast erlaubt es die Clients in einem Subnetz oder sogar alle, sofern Router und Firewalls das nicht unterbinden, mit Daten zu versehen. Broadcasts sind oft auch "Suchpakete", z.B. für Namensauflösung (NetBIOS vor den Zeiten von WINS und DNS, UPNP etc.)

Diese drei Klassen gibt es übrigens auch eine ebene tiefer auf dem MAC-Level. Auch hier hat jedes System eine eindeutige MAC-Adresse und neben der Broadcastadresse FF:FF:FF:FF:FF:FF gibt es auch noch Multicast-Adressen, wie diese z.B.: von Windows-NLB genutzt werden. Darauf werde ich hier aber nicht weiter eingehen.

Es gibt keine gesonderten "Anycast-Adressen", sondern die für Anycast-Routing verwendete Adressen sind ganz normale Unicast-Adressen. Der Unterschied ist das Routing zu diesen Subnetzen mit den Adressen. Dazu gleich etwas mehr.

Grenzen von Geo-DNS

Der Einsatzweck von Anycast ist es, eine Anfrage eines Clients an einen netzgeografisch „nahen“ Server zu leiten. Sicher gibt es Ansätze wie Geo-DNS (https://www.msxfaq.de/konzepte/pinpointdns.htm), bei denen ein DNS-Server sich die IP-Adresse des Clients betrachtet und aus dem Subnetz den nächsten Server ermittelt und dessen IP-Adresse auf die DNS-Abfrage ausliefert. Dieses Verfahren ist aber ineffektiv und mit Einschränkungen verbunden

  • Falscher Client
    So ist es essentiell, dass der Client auch seinen Provider-DNS fragt, der sich dann über die DNS-Server bis zum Ziel per „REFER“ durchfragt. Wenn der Client aber einen DNS-Server wie z.B. Google (8.8.8.8/8.8.8.4) oder Quad9 (9.9.9.9/2620:fe::fe mit DNSSEC oder 9.9.9.10/2620:fe::10) ohne DNSSEC) fragen, dann kann es sein, dass das Ziel eine falsche Adresse ausliefert. Wenn ich z.B. am Telekom-DSL Anschluss nach outlook.office365.com frage, aber statt meines Routers und dem DSL-DNS-Servers lieber Google oder einen anderen DNS-Server frage, dann bekomme ich eventuell eine ungünstigen IP-Adresse zurück
  • Unvollständige Netzwerk-Map
    Selbst wenn ich den richtigen DNS-Frage und das Ziel dann meine IP-Adresse oder die meines Provider-DNS sieht, dann muss er immer noch um die „Leitwege“ und deren aktuellem Status wissen. Solche Daten können unstimmig sein und ich lande vielleicht nicht beim „nächsten“ Server
  • DNS Cache
    Wenn ich als Client eine Antwort bekommen habe, dann merke ich mir die im Cache, selbst wenn danach das Zielsystem oder die Leitung dahin ausgefallen sein sollte. Ich „schwenke“ nicht und der Anbieter muss irgendwie die IP-Adresse woanders wieder online stellen.
  • Es müssen Namen sein
    Geo-DNS geht natürlich auch nur, wenn der Client einen DNS-Namen abfragt und nicht direkt eine IP-Adressen ansprechen will, wie dies z.B. beim TURN/STUN-Server einer VoIP Lösung meist der Fall ist

Insofern sind intelligente DNS-Antworten, die abhängig vom Standort des Clients den naheliegenden funktionstüchtigen Server ausliefern zwar nett, aber nicht immer ausreichend

Routing von Anycast IP-Adressen

Anycast geht einen anderen Weg, bei dem die IP-Adresse das Ziel ist. Es ist egal ob der Client die IP-Adresse irgendwie selbst über ein Provisioning-Protokoll bekommt oder doch per DNS auflöst. Er bekommt aber auf jeden Fall die eine weltweit gleiche IP-Adresse. Nun wird niemand alle Anfragen von Clients in ein zentrales Datacenter routen. Die Abhängigkeit von diesem einen Ort oder Server ist ebenso wenig gewünscht wie die Laufzeit der Pakete um die halbe Welt. Ein paar Bilder helfen bei der Erklärung:

Schritt Bild

Wir fangen erst einmal einfach an. Ein Client unten ist mit dem Internet verbunden. Der Client hat natürlich seinen "Router" als Default Gateway. Der Router aber hat über das interne Provider Netzwerk gelernt, über welchen Weg es zum angeforderten Ziel (hier 8.8.8.8) kommt. Nehmen wir an, dass der Client und der >Service beim gleichen Provider hängen.

Natürlich hat ein Provider nicht nur genau einen Weg. Die meisten Provider haben natürlich redundante Verbindungen. Insofern ist auch das innere Bild in der Regel etwas komplexer. Der Zugangsrouter kenn nun zwei Wege zum Ziel, die entweder über Router 3 oder Router 4 gehen, wobei hier beide Male die Kosten gleich sind.

Fällt ein Weg aus, so kann der Router 1 dynamisch den Verkehr über den anderen Weg routen.

Nun nehmen wir an, dass der Anbieter dies Dienstes seinerseits auch eine Redundanz derart eingerichtet hat, dass er über mehrere Provider geht. Sein Subnetz (hier 8.8.8.0/24) ist also Provider-unabhängig. Die beiden Router des Anbieters speisen als den Weg zum Netz über die beiden Router 2 (beim Provider 1) und Router 5 (beim Provider 2) ein. Diese Routen werden im Verbund der Provider und vorhandener Peerings ausgetauscht, so dass der Router 4 nun zwei Wege zum gleichen Ziel kennt:

Fällt also der Link beim einen Provider aus, kann mit dem entsprechendem Peering der Weg nun auch über den anderen Provider führen. Die Router entscheiden einfach anhand der Kosten.

So ist das Internet sehr tolerant in Bezug auf den Ausfall von Teilstrecken.

Diese Bild ist nun das erste Mal, dass Sie stutzig machen sollte. Es gibt nämlich zwei Server, die beide die gleiche IP-Adresse haben und z.B. in verschiedenen Rechenzentren und Standorten stehen. Eigentlich ist diese Konfiguration so ja nicht erlaubt, da IP-Adressen im Internet "eindeutig" sein müssen.

Hier ist aber genau das Absicht aber an den Leitwegen hat sich erst einmal nichts geändert. Der Client als auch "das Internet" kennt immer noch die beiden Wege und je nach Verfügbarkeit der Leitung werden Pakete auch zu einem der Server geroutet.

Bei gleichen Kosten könnte es sogar sein, dass ein Paket links und das andere Paket nach rechts geroutet wird. Damit sollten Sie auch verstanden haben, dass diese Art der Anbindung sich eigentlich nur für "connectionless" - Dienste eignet. Also Dienste die z.B. auf UDP aufsetzen und jedes Paket in sich komplett und vollständig ist. Es sollten also nicht mehrere Pakete als Gruppe immer zum gleichen Server gehen müssen.

Interessant wird das ganze Bild nun, wenn es zwei Clients an unterschiedlichen Standorten aus ihrer Sicht den gleichen Server ansprechen. Hier sind zwei Clients, die beide mit der 8.8.8. sprechen wollen und das Paket an "ihren Router" senden. Sie sehen aber anhand der Leitwege, dass der linke Client über Router 1 zuerst zum Router 2 und damit zum linken Service gelenkt wird.

Für den rechte Client hingegen ist der rechte Service "näher", d.h. er geht über den Router 4 oder 7 zu dem rechten Service.

Nun stellen sie sich vor, dass die Server zwar beide immer die gleiche Antwort liefern aber netztechnisch auf unterschiedlichen Kontinenten stehen.

Wenn nun noch die "langen Leitungen" über die Ozeane "teuer" sind, dann können Sie sich selbst ausmalen, zu welchen Service der Client geht.

Er wird ganz automatisch immer bei dem Service landen, der "nahe" zu dem Netzwerkstandort des Clients ist. 

Wir haben also über Anycast-Routing einen einfachen aber effektiven Automatismus, die Pakete eines Clients immer zu dem Service zu senden, der hinsichtlich IP-Routing den kürzesten Weg hat und zudem noch verfügbar ist. Das Internet routet Pakete anhand von Leitwegen über Router weiter. Die Router "lernen" den Weg zu einem Ziel über Routingprotokolle wie BGP und nicht nur aus Überlegungen zur Ausfallsicherheit gibt es meist mehrere Wege zum gleichen Ziel. Es ist damit aber völlig "normal", dass ein Router mehrere Wege zum gleichen Subnetz erhält und eben den Weg nutzt, der verfügbar und günstig ist. Wenn nun z.B. ein großer Provider an mehreren Standorten einfach das gleiche Subnetz betreibt und dieses per BGP auch bekannt gibt, dann überschneiden sich diese Meldungen natürlich und der Router mehrt sich einfach den kürzesten Weg.

Der Router kann gar nicht erkennen, dass die beiden Wege nun nicht zum genau gleichen Zielsystem laufen sondern absichtlich zu unterschiedlichen Servern gehen, die aber für den Client alle den gleichen Datenbestand haben. Das ist natürlich Voraussetzung für Anycast. Alle Server müssen auf die Anfrage des Clients mit der gleichen Antwort reagieren. Das ist für DNS-Anfragen natürlich einfach, da es hier keine "Session" oder Anmeldung gibt. Auf eine Anfrage kommt eine Antwort und die Transaktion ist damit abgeschlossen.

Alle anderen Dienste, die z.B. eine Anmeldung erfordern, sollten nach der Initialen Anmeldung z.B. mit Tokens und Cookies arbeiten, damit ein Client beim Wechsel zu einem anderen Server dennoch seine Session weiter behalten kann. Exchange 21013/2016 Server sollten das z.B. können, da der Frontend-Service anhand eines HTTP-Headers die Anfrage immer zum Backend-Server weiter gibt.

Damit das natürlich sinnvoll funktioniert, muss jeder Server exakt die gleichen Daten liefern können und im Idealfall auch damit umgehen, dass ein Client aufgrund veränderter BGP-Routen auch zu einem anderen Server geroutet wird. In so einer Situation ist ein „sitzungsloses“ Protokolle (z.B. REST, token-basierte Anmeldungen etc.) von Vorteil, bei der ein anderer Server allein anhand der http-GET/POST-Daten die Antwort auch liefern kann.

Auswertung Anycast-IP?

Anycast-IP-Adressen unterscheiden sich nicht von normalen Unicast-IP-Addressen. Sie sehen also einer Adresse erst einmal nicht an, ob es mehrere Server an verschiedenen Standorten gibt. Aber es gibt Hinweise, mit denen Sie solchen Adressen auf die Schliche kommen können. Der Schlüssel dazu sind mehrere Clients, die überunterschiedliche Internetprovider an verschiedenen Standorten im Internet verbunden sind. Wobei wir hier schon von „großräumigen“ Abmessungen sprechen, d.h. zwei Clients in Deutschland oder sogar Europa werden vermutlich schnell beim gleichen Endpunkt landen. Dazu sind die Bandbreiten und Laufzeiten so gering. Interessant wird es beim Wechsel der Kontinente. Wenn ein Anbieter wirklich mehrere Server mit der gleichen IP-Adresse in der Welt verteilt hat, dann sollte ein Tracert mit dem Fokus auf die vorletzte Zeile hoffentlich den Router ausgeben, der das Paket dann an den Server weiter leitet. Wenn sich hier dann unterschiede zeigen, dürfte das als sehr starker Hinweis auf Anycast-IP-Adressen zu deuten sein. Eine Garantie ist es aber nicht.

DNS-Server sind natürlich ideale Kandidaten für Anycast-IP-Adressen, um dem Client immer zum Server zu routen, der aus Sicht des Netzwerks am "nächste" und damit am schnellsten ist

Nur weil der DNS-Server auf für den Client kurzem Weg erreichbar ist und schnell antwortet, ist das keine Garantie, dass die Antwort "korrekt" ist. Sie mag zwar einen erreichbaren Server liefern aber der Dienstanbieter hat die Anfrage vom DNS-Server und nicht von ihrem Client oder Provider bekommen. Es kann also eine weniger optimale Antwort sein

Das kann dann wieder der Dienstanbieter dadurch heilen, indem der Dienst selbst per Anycast-IP erreichbar ist. Damit lieferten alle DNS-Server einfach immer die gleiche IP-Adresse, egal wo sie stehen. So können wir diese Dienste dann auch einfach ermitteln. Wir fragen verschiedene DNS-Server in der Welt und schauen uns die IP-Adressen an.

Wenn ein Dienst aus verschiedenen Orten immer die gleiche IP-Adresse liefert, dann nutzt der Anbieter entweder Anycast-IP mit vielen verteilten Servern oder es gibt wirklich nur einen Server an einem Standort. Wir müssen also dann immer noch die Laufzeit messen. Die MSXFAQ wird z.B. ohne Anycast nur in Europa gehostet. Egal wo sie sind, bekommen Sie immer die gleiche IP-Adresse zum Server. Die Abrufgeschwindigkeit ist aus Asien oder USA dann natürlich langsamer. Um dies zu zeigen, habe ich einen Tracert auf die msxfaq.de aus zwei Netzwerken gemacht. Schon anhand der Laufzeiten sehen Sie, dass die MSXFAQ nur in Deutschland liegt und nicht geografisch verteilt wird, so dass man mit Geo-DNS Auflösungen oder Anycast-Routing etwas bewirken könnte.

Standort Traceroute

Deutschland T-DSL

 
Routenverfolgung zu www.msxfaq.de [217.160.0.234] über maximal 30 Abschnitte:
  1   3ms   1ms   2ms  fritz.box [192.168.178.1]
  2  10ms   9ms  17ms  87.186.225.45
  3  15ms  12ms  12ms  217.0.92.86
  4  10ms   9ms   9ms  pb-sb2-i.PB.DE.NET.DTAG.DE [62.154.107.117]
  5  18ms  16ms  16ms  f-ee5-i.F.DE.NET.DTAG.DE [62.154.14.238]
  6  19ms  24ms  62ms  80.157.204.170
  7  22ms  29ms  21ms  ae-11.bb-c.bs.kae.de.oneandone.net [212.227.120.18]
  8  23ms  20ms  21ms  217-160-0-234.elastic-ssl.ui-r.com [217.160.0.234]

USA

 
http://www.fifi.org/services/traceroute?hostname=www.msxfaq.de&nprobes=1&resolved=yes&submit=Traceroute 

tantale.home.fifi.org                          0%    1    1    0.43    0.43    0.43
173-228-89-1.dsl.static.fusionbroadband.com    0%    1    1   21.87   21.87   21.87
gig1-29.cr1.lsatca11.sonic.net                 0%    1    1   21.85   21.85   21.85
???                                          100%    0    1    0.00    0.00    0.00
50.ae4.gw.pao1.sonic.net                       0%    1    1   21.82   21.82   21.82
palo-b22-link.telia.net                        0%    1    1   21.84   21.84   21.84
nyk-bb4-link.telia.net                         0%    1    1   96.81   96.81   96.81
prs-bb4-link.telia.net                         0%    1    1  167.83  167.83  167.83
prs-b7-link.telia.net                          0%    1    1  171.91  171.91  171.91
1o1internet-ic-309320-prs-b7.c.telia.net       0%    1    1  172.33  172.33  172.33
ae-8-0.bb-a.bap.rhr.de.oneandone.net           0%    1    1  182.15  182.15  182.15
217-160-0-234.elastic-ssl.ui-r.com             0%    1    1  181.75  181.75  181.75

Die über 180ms am Ende sind ein deutliches Zeichen, dass hier eine große Stecke zu überwinden ist.

Wer nutzt Anycast-IP?

Für ein paar Gegenstellen habe ich die Erreichbarkeit und Auflösung geprüft.

Service Traceroute zum Service

DNS-Server

 Auf der Seite Anycast DNS habe ich die Details zu öffentlichen DNS-Servern wie GoogleDNS, Quad, Cloudflare, OpenDNS und NextDNS beschrieben.

Skype or Business TURN
(13.107.8.20)

Die Skype for Business TURN-Servern des Skype for Business Online Network Assessment Tool sind wohl Anycast-IP-Adressen. Die Wege sind hier am Ende auf jeden Fall unterschiedliche Adressen.

  • Traceroute von O2DSL
C:\>tracert 13.107.8.20

Routenverfolgung zu 13.107.8.20 über maximal 30 Abschnitte

  1   4ms   3ms   3ms  fritz.box [192.168.178.1]
  2  28ms  20ms  19ms  loopback1.90.brun.0001-01.dus.de.net.telefonica.de [62.52.200.184]
  3  19ms  18ms  19ms  ae14-0.0002.dbrx.02.dus.de.net.telefonica.de [62.53.5.38]
  4  22ms  22ms  24ms  ae3-0.0001.corx.01.dus.de.net.telefonica.de [62.53.0.12]
  5  22ms  22ms  21ms  ae5-0.0001.corx.01.fra.de.net.telefonica.de [62.53.0.5]
  6  24ms  23ms  23ms  bundle-ether15.0001.dbrx.02.fra.de.net.telefonica.de [62.53.25.254]
  7  23ms  24ms  23ms  ae5-0.0001.prrx.11.fra.de.net.telefonica.de [62.53.19.144]
  8  24ms  23ms  23ms  microsoft.fra.ecix.net [62.69.146.70]
  9  28ms  30ms  27ms  be-72-0.ibr02.fra30.ntwk.msn.net [104.44.10.0]
 10  29ms  30ms  27ms  be-5-0.ibr02.ams.ntwk.msn.net [104.44.5.17]
 11  29ms  28ms  29ms  be-1-0.ibr01.ams.ntwk.msn.net [104.44.4.215]
 12  27ms  25ms  27ms  13.107.8.20
  • Traceroute von Telekom DSL
C:\>tracert 13.107.8.20
Routenverfolgung zu 13.107.8.20 über maximal 30 Abschnitte

  1   3ms   2ms   1ms  fritz.box [192.168.178.1]
  2  10ms  13ms   9ms  87.186.225.45
  3  13ms  12ms  13ms  217.0.92.86
  4  10ms   9ms  12ms  pb-sb2-i.PB.DE.NET.DTAG.DE [62.154.107.45]
  5  17ms  16ms  16ms  217.239.45.98
  6  17ms  17ms  16ms  80.157.131.138
  7  19ms  27ms  18ms  tor3.fra.msedge.net [104.44.80.143]
  8   *     *     *    Zeitüberschreitung der Anforderung.
  9  31ms  16ms  34ms  13.107.8.20
  • Traceroue USA via http://www.fifi.org/services/traceroute?hostname=13.107.8.20&nprobes=1&resolved=yes&submit=Traceroute
Host                                          Loss  Recv  Send  Best(ms)  Avg(ms) worst(ms)
tantale.home.fifi.org                           0%   1     1     0.46     0.46    0.46
173-228-89-1.dsl.static.fusionbroadband.com     0%   1     1    21.60    21.60   21.60
gig1-29.cr1.lsatca11.sonic.net                  0%   1     1    25.63    25.63   25.63
???                                           100%   0     1     0.00     0.00    0.00
50.ae4.gw.pao1.sonic.net                        0%   1     1    20.76    20.76   20.76
152.ae4.gw.equinix-sj.sonic.net                 0%   1     1    21.57    21.57   21.57
8075.microsoft.com                              0%   1     1    21.92    21.92   21.92
be-87-0.ibr01.by2.ntwk.msn.net                  0%   1     1    25.80    25.80   25.80
ae80-0.pao-96cbe-1b.ntwk.msn.net                0%   1     1    22.27    22.27   22.27
tor3.pao.msedge.net                             0%   1     1    25.84    25.84   25.84
???                                           100%   0     1     0.00     0.00    0.00
13.107.8.20                                     0%   1     1    22.51    22.51   22.51

Auch wenn der vorletzte Hop nicht sichtbar ist, so ist der davor liegende Microsoft Router unterschiedlich und geografisch codiert. (FRA = Frankfurt) und die Laufzeiten zeigen auch, dass aus den USA der Verkehr auch in den USA terminiert wird.

SharePoint

Sharepoint verweist bei Zugriffen auf die Adresse "<tennatname>.onmicrosoft.com" auf eine AnycastIP-Adresse

Siehe Office 365 DNS Details

Teams

Auch der Zugriff auf "https://teams.microsoft.com" löst weltweit auf die gleiche IP-Adresse auf. Das gilt aber nicht für die TURN-Server Hier kommt GeoOP zumEinsatz.

Siehe Office 365 DNS Details

Anycast und UDP-Steams bzw. TCP-Connections

Ganz am Anfang habe ich geschrieben, dass Anycast eigentlich nur für UDP geeignet ist. Genauer sogar nur für Dienste, bei denen relativ wenige Pakete den Weg zu einem Server unterwegs sind und auch die Antwort nach dem letzten Paket abgeschlossen ist. Es kann bei Anycast ja nicht verhindert werden, dass während einer Übertragung sich Routen im Verbundnetzwerk ändern und die Pakete nun einen "besseren" Weg zu der IP-Adresse nehmen. Das kann aber bei Anycast natürlich bedeuten, dass die Pakete nun an ein komplett anderes System gehen, welches nur die gleiche IP-Adresse hat. Eine "Affinität" zu einem Host ist nicht gegeben. Daher ist es mit kurzen UDP-Anfragen zwar kein Problem aber eine TCP-Session würde dann natürlich abbrechen.

Daher habe ich Anycast bislang eben auch nur bei Google DNS-Services und dem Skype for Business Network Assessment Tool gefunden. Bei beiden ist die Kommunikation zeitlich auf wenige DNS-Pakete oder eine kurze Zeitdauer (RTP over UDP) beschränkt und vor allem "Stateless".

Die Nutzung für DNS-Anfragen ist natürlich aber genial, da der DNS-Server ja bevorzugt die TCP-Services ausliefern kann, die "neben" dem DNS-Server in der gleichen Region stehen. Wenn der Client auf dem Weg zum DNS-Server schon in diesem RZ landet, dann ist die eindeutige IP für einen TCP-Service im gleichen RZ mit hoher Wahrscheinlichkeit auch die beste Wahl für den Client.

Anycast und Skalierung

Das optimierte Routing von Client zu netztechnisch nächsten Server haben wir nun erklärt. Aber die Arbeit für den Anbieter geht noch weiter. Es kommen beim Eingang nun Pakete an diese eine besondere IP-Adresse an und natürlich kann der Provider genau einen Server dafür aufstellen. Aber Verfügbarkeit und Lastteilung sind auch hier hiergefordert und irgendwann ist auch der schnellste Server an seiner Lastgrenze, selbst wenn ein sehr schneller Loadbalancer davor geschaltet wird. Aber auch dann ist es mit IP-Routing möglich, einfach mehrere Server hinter einer IP-Adresse zu verbergen. Natürlich dürfen diese nicht im gleichen Subnetz stehen. Das ist mit NLB zwar technisch möglich aber dann würden alle Server weiterhin alle Pakete bekommen. Aber was hindert mich daran, meinen Routern auch intern mehrere Wege zu dem anscheinend gleichen Server zu geben.

Ich muss meine Server hinter weiteren Netzwerken verstecken, damit die Router die Pakete entsprechend "stateful" weiterleiten.

Weitere Links