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.
Beachten Sie dazu auch die Seite Express Way
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 2017:
Quelle
https://azure.microsoft.com/de-de/blog/how-microsoft-builds-its-fast-and-reliable-global-network/
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
- Angeblich über 100 "Sites"
- Über 6000 Peerings.
Einen Teil davon könne Sie auf www.peeringdb.com z.B. einsehen - Angeblich allein 800.000km eigene
Glasfaser in den USA
Quelle: http://download.microsoft.com/download/8/2/9/8297F7C7-AE81-4E99-B1DB-D65A01F7A8EF/Microsoft_Cloud_Infrastructure_Datacenter_and_Network_Fact_Sheet.pdf - 149 IPv4 Subnetze mit insgesamt
20.184.320 IPs
Quelle: https://stat.ripe.net/AS8075#tabId=at-a-glance - 10 IPv6 Bereiche mit 8.589.324 /48s Subnetzen
Das sind schon beeindruckende Zahlen und zeigen die Ernsthaftigkeit, mit der Microsoft an seiner Cloud Strategie arbeitet.
- How Microsoft builds its fast and
reliable global network
https://azure.microsoft.com/de-de/blog/how-microsoft-builds-its-fast-and-reliable-global-network/
BRK3029 - Demystifying internet
connectivity to Skype for Business Online and Microsoft
Teams
https://myignite.microsoft.com/sessions/53245
Vortrag von Martin Rinas auf der Ignite 2017
Der "Zugang" zum MGN
Auch 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 ExpressRoute 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 einzelnen 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 |
40.101.1.82 |
40.101.0.2 |
40.96.1.210 |
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 verschiedene Traces.
Achten Sie darauf, wie schnell ihre Paket am ersten Microsoft Knoten ist
| 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 DSLDies 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 |
Kabel DeutschlandGanz 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.
|
EggenetHier 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 ConnectEine 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.
- Latenz im Netzwerk
- Verizon veröffentlich ihre
Latenzstatistik
http://www.verizonenterprise.com/about/network/latency/
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
- Office 365 Netzwerkziele
- ExpressRoute
- Latenz im Netzwerk
-
How Microsoft builds its fast and reliable
global network
https://azure.microsoft.com/de-de/blog/how-microsoft-builds-its-fast-and-reliable-global-network/ - Microsoft Cloud Infrastructure
Datacenter and Network Fact Sheet
http://download.microsoft.com/download/8/2/9/8297F7C7-AE81-4E99-B1DB-D65A01F7A8EF/Microsoft_Cloud_Infrastructure_Datacenter_and_Network_Fact_Sheet.pdf - Office 365: Client connectivity
https://support.office.com/en-us/article/Client-connectivity-4232abcf-4ae5-43aa-bfa1-9a078a99c78b?ui=en-US&rs=en-US&ad=US - DNS geolocation for Office 365,
connecting you to your nearest Datacenter
for the fastest connectivity
https://blogs.technet.microsoft.com/onthewire/2014/06/27/dns-geolocation-for-office-365-connecting-you-to-your-nearest-datacenter-for-the-fastest-connectivity/ - Datenbank mit Provider peerings
www.peeringdb.com - DNS-Server im Internet
http://www.ungefiltert-surfen.de/
