Anycast-Routing

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

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 for 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 GeoDNS

Der Einsatzweck von Anycast ist es, eine Anfrage eines Clients an einen netzgeografisch „nahen“ Server zu leiten. Sicher gibt es Ansätze wie GeoDNS (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) 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 Netzwerkmap
    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
    GeoDNS 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

So tickt Anycast

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.

Stattdessen werden geografisch und von der Netzwerkanbindung günstig Server aufgestellt, die aber alle die gleichen IP-Adresse haben. Natürlich könnten Sie nun sagen, dass das doch nicht erlaubt ist, dass zwei oder mehr Systeme im Internet die gleichen IP-Adresse haben. Aber das haben wir bei Windows NLB auch schon gehabt, nur dass da die IP-Adresse gleich mehrere Server aber im gleichen Subnetz genutzt haben. Bei Anycast gibt es zu jeder AnyCast IP-Adresse auch das passende Subnetz, welches Router mit dem Internet verbunden ist. Natürlich geben diese Router auch das angeschlossene Subnetz über BGP im Internet bekannt. Dank BGP bekommt der Router in der Nähe des Clients im schlimmsten Fall einfach mehrere Route zum gleichen Subnetz. Über die Kosten/HopCount wird der Router die Pakete dann einfach zum nächsten Ziel leiten.

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, Tokenbasierte Anmeldungen etc.) von Vorteil, bei der ein anderer Server allein anhand der http-GET/POST-Daten die Antwort auch liefern kann.

Wer nutzt Anycast ?

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.

Service Traceroute zum Service

GoogleDNS 
(8.8.8.8/8.8.4.4)

Leider kann ich mit meinen beiden deutschen Zugängen aktuell nicht beweisen, dass die Google-DNS Server über Anycast Routing angeschlossen sind. Google dokumentiert das aber selbst auf

How does Google Public DNS know which data center to send me to? Google Public DNS uses anycast routing to direct all packets to the closest DNS server. For more information on anycast routing, see the Wikipedia entry (https://en.wikipedia.org/wiki/Anycast).
https://developers.google.com/speed/public-dns/faq?csw=1#countries

Passend dazu der Auszug aus der englischen Wikipedia:

Google Public DNS operates recursive name servers for public use at the two following IP addresses:[5] 8.8.8.8 and 8.8.4.4 for IPv4 service, as well as 2001:4860:4860::8888 and 2001:4860:4860::8844, for IPv6 access.[6] The addresses are mapped to the nearest operational server by anycast routing
Quelle: https://en.wikipedia.org/wiki/Google_Public_DNS 

  • Traceroute von O2DSL
C:\>racert 8.8.8.8
Routenverfolgung zu google-public-dns-a.google.com [8.8.8.8] über maximal 30 Abschnitte:

  1  16ms  21ms  16ms  fritz.box [192.168.178.1]
  2  57ms  39ms  39ms  loopback1.90.brun.0001-01.dus.de.net.telefonica.de [62.52.200.184]
  3  29ms  39ms  19ms  ae14-0.0001.dbrx.02.dus.de.net.telefonica.de [62.53.5.36]
  4  25ms  24ms  22ms  ae1-0.0001.corx.01.dus.de.net.telefonica.de [62.53.0.10]
  5  22ms  23ms  22ms  ae5-0.0001.corx.01.fra.de.net.telefonica.de [62.53.0.5]
  6  23ms  20ms  20ms  bundle-ether15.0001.dbrx.02.fra.de.net.telefonica.de [62.53.25.254]
  7  23ms  21ms  21ms  ae7-0.0001.prrx.13.fra.de.net.telefonica.de [62.53.2.57]
  8  21ms  21ms  21ms  de-cix.fra.google.com [80.81.193.108]
  9  21ms  21ms  21ms  108.170.251.193
 10  21ms  21ms  21ms  108.170.237.239
 11  29ms  27ms  28ms  google-public-dns-a.google.com [8.8.8.8]
  • Traceroute von Telekom DSL
C:\Users\fcarius>tracert 8.8.8.8
Routenverfolgung zu google-public-dns-a.google.com [8.8.8.8] über maximal 30 Abschnitte:

  1   3ms   2ms   1ms  fritz.box [192.168.178.1]
  2  10ms   9ms  11ms  87.186.225.45
  3  20ms  12ms  11ms  217.0.92.86
  4  11ms   9ms  11ms  pb-sa2-i.PB.DE.NET.DTAG.DE [62.154.107.113]
  5  17ms  17ms  16ms  217.5.116.90
  6  17ms  16ms  15ms  80.150.170.30
  7  16ms  16ms  16ms  108.170.251.193
  8  18ms  18ms  16ms  108.170.237.239
  9  17ms  16ms  17ms  google-public-dns-a.google.com [8.8.8.8]

Man sieht hier bei beiden Traceroute-Ausgaben, dass die letzten Hops gleich sind. Dies ist also kein Beweis. Wenn Sie aber etwas suchen, dann finden sie acuh Webbasierte Traceroute-Dienste aus der ganzen Welt. Hier mal ein Trace aus den USA:

Host                                        Loss    Sent   Recv  Best ms Avg ms  worst ms
tantale.home.fifi.org                       0%      1      1     0.47    0.47     0.47
173-228-89-1.dsl.static.fusionbroadband.com 0%      1      1    24.83   24.83    24.83
gig1-29.cr1.lsatca11.sonic.net              0%      1      1    24.60   24.60    24.60
???                                         100%    0      1     0.00    0.00     0.00
50.ae4.gw.pao1.sonic.net                    0%      1      1    21.83   21.83    21.83
152.ae4.gw.equinix-sj.sonic.net             0%      1      1    34.73   34.73    34.73
209.85.172.186                              0%      1      1    21.73   21.73    21.73
108.170.243.1                               0%      1      1    24.81   24.81    24.81
74.125.37.41                                0%      1      1    24.83   24.83    24.83
google-public-dns-a.google.com              0%      1      1    24.56   24.56    24.56

Der Router vor dem Ziel ist unterschiedlich und die Laufzeit der Pakete belegt quasi, dass der Client in Deutschland und der Client in den USA auf jeden Fall ihre

Skype for Business TURN
(13.107.8.20)

Etwas anders sieht es bei den Skype for Business TURN-Servern des Skype for Business Online Network Assessment Tool aus. Die hier verwendete Adresse ist wohl auch eine Anycast-Adresse. Die Wege sind hier am Ende auf jeden Fall unterschiedliche

  • 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.

Als Gegenprobe habe ich mal einen Tracert aus die msxfaq.de aus zwei Netzwerken gemacht. Schon anhand der Laufzeiten siehr man, dass die MSXFAQ nur in Deutschland liegt und nicht geografisch verteilt wird, so dass man mit GeoDNS Auflösungen oder Anycast-Routing etwas bewirken könnte.

Deutschland T-DSL USA

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]

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

Kleine Erfahrung am Rand: Ich wollte einfach eine VM in den verschiedenen Azure-Datacenter starten und von dort einen Traceroute machen. Das Ergebnis war aber ernüchternd:

Tracing route to 13.107.8.20 over a maximum of 30 hops

  1     *        *        *     Request timed out.
  2     *        *        *     Request timed out.
......
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14     1 ms     1 ms     1 ms  13.107.8.20

Microsoft blockiert ICMP zu und vom Internet komplett. Man kann wohl einen PING machen aber der ICMP-not reachable kommt nicht zurück und auch

"ICMP support in Azure is blocked externally but you can allow ICMP on firewall rules in the VM and ping between VMs in the same cloud service or virtual network. If you wish to ping between Azure VMs and on-prem machines; then you can setup Point to Point IPsec tunnels or a Site to Site VPN, enable ICMP on both ends and ensure gateway-device firewall (or software VPN gateway) rules allow ICMP traffic (and have necessary routing table entries"
Quelle: Ping and Tracert commands on Azure VM https://blogs.msdn.microsoft.com/gsamant/2015/02/16/ping-and-tracert-commands-on-azure-vm/

Weitere Links