MGN - Microsoft Global Network

Auf dieser Seite versuche ich all die Daten zu sammeln, die ich aus verschiedenen Quellen und einzelnen Messungen zusammen getragen habe. Weiter unten versuche ich eine Liste der Zugangsprovider und ihrer "Entfernung" zu Office 365 zu ermitteln. Wenn sie Lücken in der Tabelle finden, dann sind sie gerne aufgerufen mit ihre Daten zu melden.

Was ist das MGN ?

Microsoft betreibt nach meinem Wissen eines der größten weltweit umspannenden Netzwerk neben dem Internet. Angeblich kann nur noch Google mit einem vergleichbaren privaten Netzwerk mithalten und dieses Netz soll um vieles größer sein, als namhafte Provider aktuell unterhalten. Dieses Netzwerk hat weltweit verschiedene Zugangspunkte, um möglichst nahe beim Kunden zu sein. Eine aktuelle Karte finden Sie auf https://azure.microsoft.com/en-us/documentation/articles/expressroute-locations. Hier ist ein Schnappschuss von Anfang 2016:

Innerhalb dieses Netzwerk wird laut verschiedener Quellen jeder Traffic per QoS kontrolliert, d.h. Prioritäten als auch Bandbreitenobergrenzen kommen zum Einsatz, um z.B. zeitkritische VoIP-Pakete mit minimaler Verzögerung durch zuleiten, während Outlook/MAPI-Traffic dann etwas warten muss. Die Liste der Peering-Locations sind hier aber nur für Express-Route sichtbar. Es gibt noch einige weitere Zugangspunkte, die auch immer weiter ausgebaut werden. Die folgenden Zahlen habe ich aus verschiedenen Quellen gesammelt, die allesamt öffentlich sind. Ob sie aber stimmen, kann ich daher auch nicht garantieren. Ich denke dass der reale Ausbau des MGN täglich größer wird

Das sind schon beeindruckende Zahlen und zeigen die Ernsthaftigkeit, mit der Microsoft an seiner Cloud Strategie arbeitet.

Der "Zugang" zum MGN

AuAuch wenn Microsoft selbst nur sehr wenig öffentlich macht, so lassen sich einige Punkte einfach technisch nicht verbergen. So ist "outlook.office365.com" ein zentraler DNS-Name, der von allen Outlook-Clients genutzt wird. Auch der Zugriffe per "Webmail" erfolgt erst einmal über diese Adressen. Es ist nun aber so, dass dieser Name nicht auf eine IP-Adresse auflöst, sondern auf mehrere IP-Adressen, um die Last zu verteilen. Hinzu kommt aber noch, dass ihr Client je nach geografischem Standort und sogar Provider eine "passende" IP-Adresse auflöst.

Es ist eines der Ziele von Microsoft, dass ein Client möglichst schnell auf dem "öffentlichen Internet" in das MGN überwechselt. Auf dem öffentlichen Internet gibt es nämlich keine Bandbreiten-Garantien und auch die Laufzeit ist nicht immer vorhersehbar. Das kann nur innerhalb des MGN erfolgen.

Wenn Sie auch noch das letzte Stück von ihrem Firmennetzwerk zur Cloud "sichern" wollen, dann ist Express Route die Lösung. Ein Provider schaltet ihnen eine Leitung durch sein WAN bis zu Microsoft mit einer garantierten Bandbreite und optional noch QoS, um darin dann noch die einzelnnen Dienste zu priorisieren.

DNS nach Provider

Sie können ganz einfach mit einem NSLOOKUP die IP-Adressen ermitteln. Allerdings fragt dabei natürlich ihr Client ihren Provider, der dann bei Microsoft anfragt. Über die Quell-IP-Adresse des DNS-Servers kann Microsoft die besten IP-Adressen für den Client Zugriff ausliefern. p>

Daher ist es auch so wichtig, dass ihr Client eben nicht z.B. den Google-DNS-Server (8.8.8.8/8.8.4.4) oder andere fremde DNS-Server nutzen. Nur wenn Sie die von ihrem Provider angebotenen DNS-Server nutzen, kann Office 365 ihnen auch den passenden Zugangspunkt nennen. Das gilt übrigens auch für Standorte, die einen lokalen Ausgang ins Internet haben aber vielleicht aufgrund von Firmenrichtlinien dennoch eine zentrale Namensauflösung nutzen.

Es gibt offene DNS-Server im Internet (z.B. über http://www.ungefiltert-surfen.de/ abrufbar) Sie können mit einem passenden Einsatz von NSLOOKUP daher auch die IP-Adressen erhalten, die z.B. jemand in Südafrika, Süd Amerika oder anderen Staaten erhalten dürfte. Ich habe das exemplarisch einmal gemacht: (Stand 18. Feb 2016 ohne IPv6 Adressen)

Region

Brasilien

United Kingdom

Deutschland

Taiwan

DNS-Server

152.250.250.178

109.204.97.30

Telekom

118.143.233.5

Name

outlook-namsouth2.office365.com

outlook-emeawest2.office365.com

outlook-emeaeast2.office365.com

outlook-apaccentral.office365.com

IPv4

40.96.0.98
132.245.245.178
132.245.16.242
132.245.15.210
132.245.68.130
132.245.53.2
132.245.245.194
132.245.58.146

40.101.1.82
132.245.212.98
132.245.27.34
132.245.77.18
132.245.195.162
132.245.226.50
132.245.226.34
132.245.228.2
132.245.176.66
132.245.55.178

40.101.0.2
132.245.67.82
134.170.68.82
132.245.34.34
132.245.61.226
132.245.35.98
132.245.51.50
132.245.74.114
132.245.229.178
132.245.76.226

40.96.1.210
40.96.2.114
40.96.13.146
40.100.0.210
132.245.69.50
132.245.41.114
132.245.43.98
132.245.254.242

Abhängig vom genutzten DNS-Server werden unterschiedliche Namen ausgeliefert, die mit entsprechend unterschiedlichen IP-Adressen hinterlegt sind. Die Anwender in England laufen also eher in Irland auf "emeawest2" auf, während zumindest die Kunden eines Telekom-DSL-Anschlusses bei "emeaeast2" auflaufen, was vermutlich bei Amsterdam ist. Sie können gerne ihre eigenen Untersuchungen anstellen. Nutzen Sie doch einfach den DNS-Server ihres Providers.

BGP und AS8075

Damit das alles funktioniert, ist das "Microsoft Global Network" natürlich an vielen Stellen mit dem Internet über verschiedene Peerings "verbunden". Die IP-Netzwerke von Microsoft werden dabei über das "Border Gateway Protokoll (BGP)" mit den Peering-Punkten ausgetauscht. auch diese Informationen sind öffentlich. So können Sie über das RIPE sehr gut erkennen, wie weit verschiedene Standorte "entfernt" sind.

Das RIPE (Quelle: https://stat.ripe.net/AS8075#tabId=at-a-glance) ist hier eine sehr gute Startadressen, um mehr über Provider und deren Netzwerke zu erfahren.

Analyse mit TraceRT über den Teich

Die Prüfung einer Gegenstellt per PING und TRACERT ist keine ausreichend zuverlässige Methode, um Bandbreitenprobleme oder die Erreichbarkeit und Performance von Diensten zu überprüfen. Dazu müssten Sie schon die Dienste selbst ansprechen und die Antwortzeit ermitteln. Aber auch ein einfacher Tracert kann schon interessante Einblicke in eine Verbindung geben. Hier zwei Traces

Trace Beschreibung

Routenverfolgung zu 132.245.0.83 über maximal
1    1 ms   1 ms   1 ms fritz.box [192.168.178.1]
2    9 ms   9 ms   8 ms 87.186.225.45
3   12 ms   3 ms  12 ms 217.0.92.82
4   24 ms  23 ms  23 ms f-ed1-i.F.DE.NET.DTAG.DE [62.154.14.110]
5   15 ms  16 ms  16 ms 87.128.238.186
6   16 ms  16 ms  16 ms ae12-0.fra-96cbe-1a.ntwk.msn.net [104.44.228.0]
7   26 ms  27 ms  26 ms ae14-0.pra-96cbe-1a.ntwk.msn.net [198.206.164.5]
8   27 ms  26 ms  26 ms ae4-0.pra-96cbe-1b.ntwk.msn.net [104.44.226.47]
9  103 ms 104 ms 105 ms ae3-0.was02-96cbe-1c.ntwk.msn.net [104.44.227.114]
10 109 ms 103 ms 108 ms 7-0.ibr01.was02.ntwk.msn.net [104.44.4.235]
11 105 ms 104 ms 104 ms ae62-0.bl2-96c-1a.ntwk.msn.net [104.44.8.171]
12      *      *      * Zeitüberschreitung der Anforderung.

Telekom DSL

Dies ist ein Trace von einem Telekom DSL-Anschluss auf einen Skype for Business Edge Server in den USA. Die IP-Adresse des Ziels habe ich erhalten, weil ich mit einem anderen MVP-Kollegen per Skype for Business gesprochen habe und in meinem Ressourcen Monitor eben diese IP-Adresse als Ziel gesehen habe. Diese Chance habe ich genutzt um direkt einmal den Weg durch das MGN zu protokollieren.

Wenn wir mal den ersten Hop der FritzBox ignorieren, dann dauert es nur die Stationen 2-5, bis mein Paket in Frankfurt an einem Übergang in das Microsoft Netzwerk ist.

Dann scheinen die Pakete von Frankfurt und vermutlich Prag an der Position 9 über den Teich zu laufen. WAS02 könnte für Washington stehen und die plötzliche Zunahme der Laufzeit von 27ms auf 103ms ist einfach der Entfernung geschuldet. Dann geht es wieder schnell zwei Stationen weiter bis zum Ziel.

Der Edge-Server ist anscheinend nicht per ICMP "anpingbar".

Die Telekom hat also anscheinend ein privates Peering mit Microsoft in Frankfurt.

Tracing route to 132.245.0.83 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms home.local [192.168.0.1]
2 10 ms 17 ms 12 ms ip5886dc86.dynamic.kabel-deutschland.de [88.134.220.134]
3 14 ms 13 ms 12 ms ip5886c217.dynamic.kabel-deutschland.de [88.134.194.23]
4 21 ms 16 ms 18 ms ip5886cbe5.dynamic.kabel-deutschland.de [88.134.203.229]
5 26 ms 28 ms 23 ms ip5886ca9b.dynamic.kabel-deutschland.de [88.134.202.155]
6 31 ms 33 ms 36 ms msft-decix-01-fra.ntwk.msn.net [80.81.194.52]
7 29 ms 33 ms 33 ms ae12-0.fra-96cbe-1b.ntwk.msn.net [104.44.228.1]
8 115 ms 113 ms 112 ms be-3-0.ibr02.ams.ntwk.msn.net [104.44.5.16]
9 111 ms 113 ms 112 ms be-2-0.ibr02.amb.ntwk.msn.net [104.44.4.219]
10 118 ms 110 ms 111 ms be-1-0.ibr01.amb.ntwk.msn.net [104.44.4.213]
11 110 ms 112 ms 112 ms be-5-0.ibr01.lts.ntwk.msn.net [104.44.4.233]
12 33 ms 38 ms 37 ms ae62-0.lts-96cbe-1b.ntwk.msn.net [104.44.9.151]
13 37 ms 39 ms 39 ms ae22-0.lon04-96cbe-1b.ntwk.msn.net [104.44.225.174]
14 110 ms 112 ms 112 ms 104.44.5.28
15 112 ms 109 ms 114 ms be-1-0.ibr01.nyc04.ntwk.msn.net [104.44.4.50]
16 112 ms 108 ms 113 ms be-3-0.ibr01.was02.ntwk.msn.net [104.44.4.34]
17 110 ms 118 ms 108 ms ae62-0.bl2-96c-1a.ntwk.msn.net [104.44.8.171]
18 * * * Zeitüberschreitung der Anforderung.

Kabel Deutschland

Ganz anders sieht der Trace von einem Kabelanschluss von Kabel-Deutschland aus. Die IP-Adresse kann zum AS31334 zugeordnet werden, was mittlerweile Vodafone ist "https://www.peeringdb.com/net/997"

Die ersten vier Hops sind alle bei Kabel Deutschland und die Namen lassen vermuten, dass hier vielleicht ein NAT dabei ist. Ich könnte mir vorstellen dass diese Anschluss gar keine richtige eigene IPv4 Adresse hat, sondern per Enterprise-NAT arbeitet. das würde auch mit der Beobachtung übereinstimmen, dass meine Audio-Daten zur Gegenstelle eben nicht den direkten Weg zu dessen Router gefunden haben sondern wir den Edge-Server in den USA als TURN-Relay in diese Richtung verwendet haben.

Wenn ich den Namen "msft-decix-01-fra" richtig deute, dann werden die Daten über ein öffentliches Peering (DECIX). Über das AS31334 ist schnell zu sehen, dass es drei Verbindungen mit 100G, 200G und noch mal 200G gibt. Da es "noch" kein direktes peer gibt, sind wohl zumindest die Kabel Deutschland Kunden auf das Decix angewiesen und balgen sich um die Bandbreite mit anderen Diensten.

Interessant ist hier aber, dass die Verbindung bei Microsoft auf dem System 104.44.228.0 aufläuft und von da an einen ganz anderen Weg durch das MGN nimmt. Als wenn die Pakete über Amsterdam, London, New York und erst dann nach Washington laufen. Das sind ganze 5 Hops mehr.

Nicht erklären kann ich mir aktuell, warum Hop 12/13 so kurze Laufzeiten melden.

Tracing route to 132.245.0.83 over a maximum of 30 hops
  1  <1 ms  <1 ms  <1 ms  gateintern.netatwork.de [192.168.100.5]
  2  <1 ms  <1 ms  <1 ms  gate.netatwork.de [80.66.20.17]
  3   1 ms   2 ms   1 ms  80.228.21.26
  4   1 ms   1 ms   1 ms  adsl-110-073.ewetel.net [212.6.110.73]
  5   2 ms   2 ms   2 ms  212.6.114.81
  6   3 ms   3 ms   3 ms  212.6.114.77
  7   3 ms   3 ms   3 ms  bbrt.hb-1-ge-7-0-7.ewe-ip-backbone.de [212.6.114.113]
  8   6 ms   6 ms   7 ms  bbrt.han-0-ge-7-0-3.ewe-ip-backbone.de [212.6.114.213]
  9  23 ms  23 ms  23 ms  80.228.90.89 (EWE Transfer net)
 10  23 ms  23 ms  23 ms  igblmdistc7504.uk.msft.net [195.66.224.140]
 11  23 ms  23 ms  23 ms  ae7-0.lon04-96cbe-1b.ntwk.msn.net [104.44.225.170]
 12  97 ms  98 ms  98 ms  104.44.5.28
 13 100 ms 100 ms 100 ms  be-4-0.ibr02.was05.ntwk.msn.net [104.44.4.28]
 14  98 ms  98 ms 101 ms  ae71-0.bl2-96c-1b.ntwk.msn.net [104.44.8.173]
 15     *       *      *  Request timed out.

Eggenet

Hier einmal eine ganz andere Anbindung, die auf den ersten Blick schlimmer aussieht, als sie ist. Die ersten beiden Hops sind die eigenen Systeme um dann 7 Hops erst durch das eigene WAN von EWE zu laufen. Allerdings sind die Latenzzeiten super niedrig.

Von Hamburg scheint es dann über ein EWE-Transfernetz auch wieder direkt zu Microsoft zu gehen. Allerdings läuft die Leitung durch die Nordsee nach England und dann mit einer Zwischen nach Washington.

Wenn ich den Test gegen outlook.office365.com mache, dann ist wieder zu sehen, dass die Pakete via London zurück nach Amsterdam laufen. Hier bleiben wir aber immer noch unter 60ms. Der kleine Umweg fällt nicht sonderlich auf.

Ohne ein komplettes Bild des MGN aber sind solche Auswertungen doch wieder nur der Blick mit einer Taschenlampe in einem großen Wald. So lassen sich nur Momentaufnahmen einer ganz kleinen Teilmenge ermitteln. Es ist schon erstaunlich, dass von drei ganz unterschiedlichen Providern mit unterschiedlichen Zwischenstationen eine Laufzeit von ca. 100-110ms bis nach Washington erreicht wird. Allerdings ist für VoIP das schon am Rande einer "guten" Verbindung. Wenn es zu Überlastsituationen kommt, dann kann sich das schnell auf die Sprache auswirken.

Tracert zu outlook.office365.com

Als zweiten Test nutze ich natürlich einen Tracert zum Namen "outlook.office365.com". Da dieser Name auf sehr viele IP-Adressen aufgelöst wird und in den Datacentern mehrere Systeme die Last verteilen, ist es hier wichtiger den DNS-Namen zu erkennen und nicht auf die letze IP-Adresse des Tracert zu achten. Leider ist outlook.office365.com nicht immer per ICMP erreichbar, so dass tracert am Ende ins leere läuft.

Trace Beschreibung

Routenverfolgung zu outlook-emeacenter.office365.com [132.245.48.34]
über maximal 30 Hops:
 
 1  <1 ms  <1 ms  <1 ms  fritz.box [192.168.52.1]
 2  10 ms  13 ms  15 ms  10.99.88.1
 3  21 ms  15 ms  12 ms  172.30.5.37
 4  16 ms  19 ms  19 ms  84.116.190.69
 5  30 ms  25 ms  23 ms  84.116.190.9
 6  23 ms  24 ms  22 ms  84.116.190.2
 7  19 ms  25 ms  24 ms  de-fra01b-rc1-ae0-0.aorta.net [84.116.134.5]
 8  29 ms  27 ms  30 ms  de-fra03b-ri1-ae10-0.aorta.net [84.116.132.178]
 9  25 ms  23 ms  28 ms  213.46.179.162.aorta.net [213.46.179.162]
10   *     32 ms  39 ms  ae12-0.fra-96cbe-1b.ntwk.msn.net [104.44.228.1]
11  43 ms  38 ms  36 ms  ae11-0.gru-96cbe-1b.ntwk.msn.net [198.206.164.1]
12  35 ms  38 ms  32 ms  ae8-0.vie-96cbe-1b.ntwk.msn.net [104.44.227.29]
13   *      *      *     Zeitüberschreitung der Anforderung.
14   *      *      *     Zeitüberschreitung der Anforderung.
15   *      *      *     Zeitüberschreitung der Anforderung.
16   *      *      *     Zeitüberschreitung der Anforderung.
17  39 ms  33 ms  39 ms  132.245.48.34

Unitymedia (BW)

Daniel Wydler war so freundlich mit einen Tracert von seinem Unitymedia Anschluss zu überlassen. Leider hat Unitymedia keine Reverse-DNS Einträge für ihre Router, so dass man auch hier nur vermuten kann, wo diese stehen.

Erst der mit bislang unbekannte Carrier "aorta.net" mit der IP-Adresse 84.116.134.5 verweist in Realität auf "Liberty Global", die aber das komplett 84.116.0.0-84.116.207.255 haben. Das passt aber, da Liberty Global im Jahre 2009 Unitymedia übernommen hat.

Unity-Media Kunden nutzen also ihren Provider bis zum Übergabepunkt zu Microsoft, der vermutlich in Frankfurt steht.

  1    <1 ms    <1 ms    <1 ms  LAN
  2     1 ms     1 ms     1 ms  Firewall
  3    26 ms    22 ms    27 ms  80.150.x.x
  4    21 ms    22 ms    22 ms  217.239.52.150
  5    22 ms    22 ms    22 ms  87.128.238.186
  6   108 ms   109 ms   109 ms  be-3-0.ibr02.ams.ntwk.msn.net [104.44.5.16]
  7   128 ms   115 ms   114 ms  be-2-0.ibr02.amb.ntwk.msn.net [104.44.4.219]
  8   114 ms   113 ms   110 ms  be-1-0.ibr01.amb.ntwk.msn.net [104.44.4.213]
  9   111 ms   113 ms   109 ms  be-5-0.ibr01.lts.ntwk.msn.net [104.44.4.233]
10   114 ms   113 ms   147 ms  be-1-0.ibr02.lts.ntwk.msn.net [104.44.4.220]
11   112 ms   114 ms   113 ms  be-3-0.ibr02.dub30.ntwk.msn.net [104.44.5.4]
12   109 ms   108 ms   109 ms  ae11-0.db5-96cbe-1b.ntwk.msn.net [104.44.9.9]
13     *        *        *     Zeitüberschreitung der Anforderung.
14     *        *        *     Zeitüberschreitung der Anforderung.
15     *        *        *     Zeitüberschreitung der Anforderung.
16     *        *        *     Zeitüberschreitung der Anforderung.
17   113 ms   114 ms   115 ms  132.245.51.50

Telekom Company Connect

Eine ebenfalls in Baden Württemberg stehende Firmenanbindung ist schon nach 4 Hops im Microsoft Netzwerk. Leider hat die Telekom ihre Router nicht per Reverse-DNS auflösbar gemacht. alle drei Adressen sind aber Netzwerke der Telekom.

Anscheinend routet die Telekom aber im Amsterdam den Verkehr in das Microsoft Netzwerk. Die IP-Adresse 104.44.5.16 gehört auf jeden fall schon zum AS8075 aber ist nicht geografisch verortet.

Interessant ist hier der Sprung der Laufzeit auf über 100ms. Man könnte das als Anzeigen eines "Engpass" werten denn ich denke nicht, dass die Verbindung hier über den Teich geht.

Es wäre natürlich schon interessant, welche Standortcodes hinter AMB, LTS, GRU stehen. VIE könnte Vienna (Wien), "fra" dürfte Frankfurt und ams = Amsterdam sein. Aber es ist schon interessant zu sehen, dass ein Privatanwender am UnityMedia-Anschluss deutlich geringere Laufzeiten hat als ein Company Connect Anschluss. Solche Messungen sollten wir aber nicht überbewerten, da es nur Momentaufnahmen sind und daher nicht als repräsentativ gelten dürfen. Es wäre aber dennoch mal an der Zeit, wenn die Provider neben den Hochglanzprospekten auch technisch eine beschreiben dazu stellen würden.

Wer mit wem am Beispiel von outlook.office365.com

Es ist nicht einfach, die aktuellen Anbindungen von Microsoft an die Provider und entsprechende Peerings und deren Bandbreite zu ermitteln. Einen Bandbreitentest mit ICMP-Pings kann man eh nicht für Voll nehmen. Aber es lassen sich schon die ein oder anderen Rückschlüsse darauf ableiten. Vielleicht helfen Sie mir, die folgende Tabelle zu erweitern. Die Spalten bedeuten.

  • Provider
    Ihr lokaler Zugangsprovider, der den Internet Zugang bereit stellt. Interessant ist die Firma aber auch die Zugangsart. Die Telekom z:B. hat ja durchaus neben dem DSL auch andere Angebote. Hier interessiert die IP-Adresse des DNS-Servers, der ihnen die Antworten liefert. Das ist für Privatanwender nicht einfach diese Daten zu erhalten, da hier der DSL-Router in der Regel als DNS-Proxy agiert. Sie sehen also nur die "FritzBox" als DNS-Server. Wer Zugriff auf den Router hat, kann hier vielleicht erkennen, welche externen IP-Adressen und DNS-Server dieser Router gerade nutzt.
  • Die IP-Adresse von outlook.office365.com erhalten sie am einfachsten über einen TRACERT auf diese Adresse. So sehen Sie zum einen die IP-Adresse und zugleich auch die Anzahl der Hops und die Latenzzeit.

  • Der HOP-Count
    Dies ist ein Maß für die Entfernung. Je mehr Hops zu nehmen sind, desto langsamer wird die Übertragung (Latenzzeit) und desto eher könnte eine Teilstrecker überlastet sein. Home-DSL-Anschlüsse können den einen Hop im internen LAN einfach mitzählen. Firmen hingegen, bei denen die Pakete schon intern mehrere Stationen überwinden, sollten erst ab der Firewall zählen um vergleichbare Zahlen zu liefern. Für die internen Wege kann Office 365 ja nichts.
  • Laufzeit in ms könnte eine Teilstrecker überlastet sein.
  • Laufzeit in ms
    Die Daten sind so mit einem ICMP-Pink auch nur Näherungswerte, da QoS-Priorisierung eher auf MAPI und RTP angewendet werden und ICMP mit Default-Prioritäten übertragen werden dürfte.

Die gleiche Messreihe könnte ich nun natürlich noch für Skype for Business Edge-Server, das Admin-Portal und viele andere Dienste erstellen. Es ist aber anzunehmen, dass die Werte hier vergleichbar sind, da Microsoft wohl in jedem Datacenter die entsprechenden Server bereithält.

Provider DNS-Server IP-Adresse Hopcount Laufzeit

Telekom DSL

217.237.149.142 / 217.237.150.205

132.245.229.178

10

50ms

Kabel Deutschland

unbekannt

132.245.229.178

18

50ms

EWE Firmen ASDL

212.6.108.140 / 212.6.108.141

132.245.229.178

15

60ms

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Weitere Links