Anycast-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
So tickt Anycast-DNS
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.
Wer nutzt Anycast-DNS?
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 |
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). 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
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]
C:\>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 |
Quad9 DNS Service |
Der Name ist Programm, mit dem Quad9 Mitte November 2017 an den Start gegangen ist. Das nicht gewinnorientierte Konsortium betreibt geografisch verteilt DNS-Services, die angeblich keine Daten protokollieren, wer welche Adresse auflöst. Quad9 is
a free, recursive, anycast
DNS platform that provides
end Users robust security
protections,
high-performance, and
privacy. Unter den folgenden IP-Adressen bietet Quad9 ähnlich wie Google DNS-Dienste an
Auf deren Webseite gabt es mal ein Bild der physikalischen Standorte. Alle Server sind unter 9.9.9. erreichbar
Beachten Sie aber bitte, dass die Verwendung die "Optimierung" von Microsoft bezüglich Office 365-Routing torpediert. Siehe dazu auch Office 365 DNS-Routing
|
OenDNS |
Gestartet als freier DNS-Server, der aber schon von Anfang ab die erhaltenen Daten auswertet und früher unbekannte Domains auf Werbeseiten geleitet hat, ist der Dienst mittlerweile von Cisco aufgekauft und kommerzialisiert worden. Die DNS-Dienste sind mit Anycast-IP-Adressen erreichen |
Skype or Business TURN |
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 Adressen.
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
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
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 |
Siehe Office 365 DNS Details |
Teams |
Siehe Office 365 DNS Details |
Als Gegenprobe habe ich mal einen Tracert aus die msxfaq.de aus zwei Netzwerken gemacht. Schon anhand der Laufzeiten sieht man, 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.
| 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/
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
- DNS Provider
- NLB
- Skype for Business Online Network Assessment Tool
- Office 365 DNS Details
- DoH - DNS over HTTPS
- Anycast
https://de.wikipedia.org/wiki/Anycast - Ping and Tracert commands on Azure VM
https://blogs.msdn.microsoft.com/gsamant/2015/02/16/ping-and-tracert-commands-on-azure-vm/ - Traceroute.org - Liste von Traceroute-Diensten,
die per Browser genutzt werden können.
http://www.traceroute.org - Anycast – Was ist das?
https://www.recast-it.com/themen/anycast/ - Anycast Domain Name Service
https://www.pch.net/services/dns_anycast
