AW: Peering sowie DNS Probleme zu Hetzner

[#1]

Aufgrund der in letzter Zeit immer wieder zum Teil massiv auftretenden Probleme will ich mich hier mal wieder zu Wort melden...

Wir haben gerade in den Abendstunden immer wieder Probleme mit dem Peering zu Hetzner.

Unter anderem sind manche Webanwendungen die auf einem Hetzner Root liegen fast nicht mehr nutzbar.

Hierfür würde es zwar theoretisch die Option für den Double Paid Traffic geben, diese ist allerdings für Cloud Server nicht buchbar.

Im Hetzner Forum sammeln sich aktuell auch vermehrt Reports dazu.

Dass die Telekom sich hier immer noch weigert am DE-CIX vernünftig zu peeren ist mittlerweile echt inakzeptabel...

Ein weiteres Problem besteht aktuell mit den DNS-Servern der Telekom zu Hetzner.

Hier blockiert die Telekom aktiv die rekursiven DNS-Server von Hetzner.

Das löst bei vielen Kunden Zugriffsprobleme auf diverse bei Hetzner gehostete Websites sowie die Hetzner Seite selbst aus.

Hierzu folgender Post vom Hetzner Support:

Hetzner Support schrieb:

das Problem ist bekannt, es scheint so, als wuerden die autoritativen DNS der Telekom die Anfragen unserer rekursiven DNS blocken.

Wir haben die Telekom bereits kontaktiert um die Sperre aufzuheben, allerdings bisher noch keine Antwort erhalten. Wir wuerden Ihnen empfehlen, selbst ebenfalls die Telekom zu kontaktieren um eine moeglichst schnelle Freigabe zu erreichen.

Hier die zustaendigen autoritativen DNS der jew. Domains:

dip0.t-ipconnect.de:
DNS: dns01.btx.dtag.de.
Kontakt: support@t-ipnet.de

Die IPs unserer DNS die von den genannten DNS gesperrt wurden sind wie folgt (alle gleichermassen wichtig):

213.133.98.96
213.133.98.97
213.133.98.98
213.133.99.99
213.133.100.100
95.217.255.75
95.217.255.76
88.198.139.2
88.198.139.3
88.198.139.4
78.47.119.230
78.47.119.231
2a01:4f8:0:a111::add:9898
2a01:4f8:0:a102::add:9999
2a01:4f8:0:a0a1::add:1010
2a01:4f8:0:1::add:9896
2a01:4f8:0:1::add:9897
2a01:4f8:0:1::add:9898
2a01:4f8:0:1::add:9999
2a01:4f8:0:1::add:1010
2a01:4f9:0:a010::add:1a
2a01:4f9:0:a010::add:1b
2a01:4f8:0:a104::add:1ab
2a01:4f8:0:a104::add:1a
2a01:4f8:0:a104::add:1b
2a01:4f8:0:a104::add:1c
2a01:4f8:0:a0a1::add:1a
2a01:4f8:0:a0a1::add:1b


Leider haben wir bis zur Aufhebung der Sperre durch den Betreiber des aut. DNS keine Moeglichkeit Ihnen direkt zu helfen, die Aufhebung der Sperre liegt leider nicht in unserer Hand.

Sie koennen allerdings zwischenzeitlich alternative offene DNS Server wie z.B. 8.8.8.8 oder 1.1.1.1 in Ihrer /etc/resolv.conf verwenden um das Problem auf Ihrem Server zu umgehen.

[#2 · Accepted solution]

Nochmal ein kurzes Statusupdate hier.

Hetzner hat sich nun dazu entschlossen ab 01.04.2020 direkt mit der DTAG zu peeren.

Die Anbindung wird mit 2x 100 GBit/s erfolgen.

Damit kann der Thread eigentlich geschlossen werden, da sich das Thema ab dann erledigt hat.

[#3]

@gtt42 

Verwende doch einen anderen DNS Server

[#4]

Die Telekom peert entsprechend groß.
Jedoch muss das Peering bezahlt werden und das rechnet sich für Hetzner nicht mehr.
Es gehören immer zwei dazu.

Zum Thema Sperre.
Hetzner schießt ganz schön gegen die Telekom und stellt krasse Behauptungen auf.
Was hätte die Telekom davon, etwas gezielt zu sperren?
Nichts.
Es gibt hier ein Problem, wo erstmal geschaut werden muss, woran es liegt.

[#5]

@Mächschen 

Ich selbst verwende bereits einen alternativen DNS-Server. 

Das kann ich jedoch Kunden so nicht verkaufen.

Wenn es zum Teil bis zum initialen Aufbau einer Website mehrere Sekunden (teils bis zu ~45 Sekunden) dauert, klicken viele Leute schon wieder weg.

@Kugic 

Das mag sein, ich habe dies nun nur mal weitergetragen, damit es auch hier im Forum und damit für andere Telekom- und evtl. betroffene Hetzner Kunden sichtbar wird. 

[#6]

Ich kann mich hier nur anschließen... beim Speedtest von Hetzner (https://speed.hetzner.de/1GB.bin) erreiche ich gerade mal ca. 250 kB/s. Das läuft selbst mit meinem Handy übers Vodafone LTE-Netz schneller. Auch das Verbinden mit meinem Server über SSH dauert teilweise mehrere Sekunden und bei Sprachverbindungen treten öfter Paketverluste auf.
Für mich bleibt daher nur der Wechsel zu einem anderen ISP zuhause, der nicht doppelt abkassiert.

Mehr Infos dazu sind hier zu finden:
https://wiki.hetzner.de/index.php/Double_Paid_Traffic
Ich denke schon, dass sich das für Hetzner rechnen würde, nur wollen sie eben nicht auch noch die Kosten der Telekom tragen, die sich dafür lieber bezahlen lässt.

[#7]

---

@der_eismann  schrieb:
Ich kann mich hier nur anschließen... beim Speedtest von Hetzner (https://speed.hetzner.de/1GB.bin) erreiche ich gerade mal ca. 250 kB/s.

Gratulation, bei mir am Glasfaseranschluss sind es nur 80 KB/s. Ohne VPN ist hier Abends das halbe Internet kaputt.

Scheißverein!

[#8]

Hallo @der_eismann

zeigen Sie bitte einen Tracert o. ä vom Transportweg.

Gruß

Jürgen Wo.

[#9]

Hallo @Jürgen Wo.,

hier nun mal ein frischer MTR sowie ein kleiner netter Grafana Screenshot. Das Problem besteht aktuell wieder einmal massiv, bei Hetzner kommt kaum ein Package an.  Ziel ist dabei (damit es reproduzierbar ist) eine öffentlich erreichbare Hetzner Adresse: forum.hetzner.com. Es geht nur um IPv4, via IPv6 ist kein Loss feststellbar. 

MTR:

```
Host Loss% Snt Last Avg Best Wrst StDev
1. fritz.box 0.0% 146 3.0 19.2 1.2 800.5 95.6
2. 62.155.242.149 55.6% 145 6.1 8.1 5.6 37.0 3.9
3. m-ec3-i.m.de.net.dtag.de 55.6% 145 10.7 11.4 9.1 20.5 2.1
4. ae0-3320.muc10.core-backbone.com 55.6% 145 14.7 12.0 7.9 31.2 4.8
5. ae1-2014.nbg40.core-backbone.com 55.6% 145 14.3 16.3 14.0 19.5 0.8
6. core-backbone.hetzner.com 69.4% 145 14.3 17.4 14.3 19.2 1.3
7. core11.nbg1.hetzner.com 68.8% 145 58.8 18.6 15.5 58.8 6.2
8. ex9k2.dc1.nbg1.hetzner.com 68.8% 145 17.4 17.5 14.9 21.0 1.4
9. dediextern.your-server.de 70.1% 145 23.4 23.0 20.1 33.0 2.0
```

Grafana Screenshot ist angehangen aus dem Zeitraum 28.09.2019 14:32 Uhr bis 29.09.2019 14:34 Uhr.

Im übrigen gibt es momentan auch vereinzelt Package Loss zu Cloudflare, Youtube und co. Im Vergleich zum Loss zu Hetzner allerdings nicht der Rede wert.

Mit freundlichen Grüßen

Lukas Kämmerling

[#10]

Hallo @Jürgen Wo.,

ich kann nun auch den Rückweg liefern, allerdings kann ich den anderen Beitrag nicht mehr editieren. Deshalb nun so. Es steht der Host in Nürnberg. Folgender MTR:

 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 213-239-XXX-XXX.clients.your-ser  0.0%     9    0.3   0.5   0.3   0.6   0.1
 2. core11.nbg1.hetzner.com           0.0%     9    0.3   0.9   0.3   2.2   0.7
 3. juniper4.dc2.nbg1.hetzner.com     0.0%     9    0.4   0.6   0.3   1.2   0.3
 4. nug-b1-link.telia.net             0.0%     9    0.8   0.9   0.8   1.1   0.1
 5. ffm-bb3-link.telia.net            0.0%     9    3.6   3.7   3.6   3.8   0.1
 6. ffm-b1-link.telia.net             0.0%     9    3.7   6.0   3.6  17.5   4.7
 7. dtag-ic-319285-ffm-b1.c.telia.ne 33.3%     9    5.8   6.1   5.8   6.5   0.2
 8. 87.137.209.33                    57.1%     8   11.1  11.1  11.1  11.1   0.0
 9. pXXXXXXXX.dip0.t-ipconnect.de    25.0%     8   15.8  16.0  15.8  16.2   0.2

Anbei auch ein Screenshot von meinem Grafana. Auch hier liegt der Loss nur bei IPv4 vor und scheitert an dem DTAG <=> Telia Link.

Mit freundlichen Grüßen

Lukas Kämmerling

[#11]

Hey zusammen,

es tut mir leid, dass Ihr noch nichts von uns gehört habt.

@gtt42 Laut unseren Kollegen soll es bei Ihnen wieder funktionieren. Korrekt?

@Lukas_Kaemmerling Ich habe die Infos zu unserer Fachabteilung weitergeleitet.

Viele Grüße
Marita S.

[#12]

Hallo Frau S.,

wie haben Ihre Kollegen das festgestellt?

Vorgestern war leider die Verbindung wieder fast unbrauchbar. Explizit habe ich eine HTTPS Socket Connection zu meinem Hetzner Server genutzt. Je später abends es wurde, desto langsamer und instabiler wurde die Verbindung.

Ich kann gerne wenn das Problem das nächste Mal auftritt eine Diagnose für Sie durchführen.

Welche Daten würden Sie hierzu benötigen? Ich nutze einen Mac, es müsste also etwas sein das ich darauf ausführen kann.

Grüße

Alexander M.

[#13]

@gtt42
Laut dem Eintrag der Kollegen, haben die Kollegen mit Ihnen gesprochen und Sie haben gesagt, dass es wieder funktioniert.
Der Tracert wäre nicht schlecht

Viele Grüße
Marita S.

[#14]

@Marita S. 

Dass ich mit einem Kollegen gesprochen habe stimmt.

Ich habe ihm gesagt, dass ich keine DNS-Probleme habe, da ich ohnehin den Telekom DNS Server nicht verwende.

Ich habe ihm allerdings auch gesagt, dass ich hin und wieder Probleme habe.

Ich werde sobald mir das Problem das nächste mal auffällt einen Traceroute erzeugen und hier posten.

Ich bin allerdings jetzt erstmal eine Woche im Urlaub.

[#15]

Nun nach etwas längerer Zeit mal ein Update meiner Seite...

Gerade habe ich massive Probleme, mit meinem Server zu arbeiten.

Mein IPSec VPN schafft aktuell nicht mehr als 250 KB/s, normalerweise kann ich damit meine Leitung auslasten.

So ist nicht mal eine RDP Connection vernünftig möglich.

Ping zu hetzner.de bringt gerade 29 % Packet Loss:

Ping has started…

PING hetzner.de (78.47.166.55): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
64 bytes from 78.47.166.55: icmp_seq=2 ttl=55 time=42.665 ms
64 bytes from 78.47.166.55: icmp_seq=3 ttl=55 time=34.832 ms
64 bytes from 78.47.166.55: icmp_seq=4 ttl=55 time=20.990 ms
64 bytes from 78.47.166.55: icmp_seq=5 ttl=55 time=170.052 ms
64 bytes from 78.47.166.55: icmp_seq=6 ttl=55 time=25.221 ms
64 bytes from 78.47.166.55: icmp_seq=7 ttl=55 time=76.828 ms
Request timeout for icmp_seq 8
64 bytes from 78.47.166.55: icmp_seq=9 ttl=55 time=34.622 ms
64 bytes from 78.47.166.55: icmp_seq=10 ttl=55 time=22.749 ms
Request timeout for icmp_seq 11
64 bytes from 78.47.166.55: icmp_seq=12 ttl=55 time=24.064 ms
64 bytes from 78.47.166.55: icmp_seq=13 ttl=55 time=34.861 ms
64 bytes from 78.47.166.55: icmp_seq=14 ttl=55 time=519.130 ms
64 bytes from 78.47.166.55: icmp_seq=15 ttl=55 time=181.231 ms
64 bytes from 78.47.166.55: icmp_seq=16 ttl=55 time=93.969 ms
64 bytes from 78.47.166.55: icmp_seq=17 ttl=55 time=88.071 ms
64 bytes from 78.47.166.55: icmp_seq=18 ttl=55 time=20.843 ms
Request timeout for icmp_seq 19
64 bytes from 78.47.166.55: icmp_seq=20 ttl=55 time=81.043 ms
Request timeout for icmp_seq 21
64 bytes from 78.47.166.55: icmp_seq=22 ttl=55 time=178.426 ms
64 bytes from 78.47.166.55: icmp_seq=23 ttl=55 time=122.363 ms
64 bytes from 78.47.166.55: icmp_seq=24 ttl=55 time=24.863 ms
Request timeout for icmp_seq 25
64 bytes from 78.47.166.55: icmp_seq=26 ttl=55 time=219.741 ms
64 bytes from 78.47.166.55: icmp_seq=27 ttl=55 time=305.489 ms
64 bytes from 78.47.166.55: icmp_seq=28 ttl=55 time=20.758 ms
64 bytes from 78.47.166.55: icmp_seq=29 ttl=55 time=75.879 ms
64 bytes from 78.47.166.55: icmp_seq=30 ttl=55 time=181.761 ms
64 bytes from 78.47.166.55: icmp_seq=31 ttl=55 time=443.219 ms
Request timeout for icmp_seq 32
64 bytes from 78.47.166.55: icmp_seq=33 ttl=55 time=178.834 ms
64 bytes from 78.47.166.55: icmp_seq=34 ttl=55 time=52.919 ms
64 bytes from 78.47.166.55: icmp_seq=35 ttl=55 time=55.677 ms
64 bytes from 78.47.166.55: icmp_seq=36 ttl=55 time=85.652 ms
64 bytes from 78.47.166.55: icmp_seq=37 ttl=55 time=86.785 ms
Request timeout for icmp_seq 38
64 bytes from 78.47.166.55: icmp_seq=39 ttl=55 time=22.788 ms
64 bytes from 78.47.166.55: icmp_seq=40 ttl=55 time=30.722 ms
64 bytes from 78.47.166.55: icmp_seq=41 ttl=55 time=124.779 ms
64 bytes from 78.47.166.55: icmp_seq=42 ttl=55 time=152.466 ms
Request timeout for icmp_seq 43
64 bytes from 78.47.166.55: icmp_seq=44 ttl=55 time=20.858 ms
Request timeout for icmp_seq 45
64 bytes from 78.47.166.55: icmp_seq=46 ttl=55 time=20.223 ms
64 bytes from 78.47.166.55: icmp_seq=47 ttl=55 time=72.803 ms
64 bytes from 78.47.166.55: icmp_seq=48 ttl=55 time=21.150 ms
Request timeout for icmp_seq 49
Request timeout for icmp_seq 50
64 bytes from 78.47.166.55: icmp_seq=51 ttl=55 time=109.287 ms
64 bytes from 78.47.166.55: icmp_seq=52 ttl=55 time=27.325 ms
64 bytes from 78.47.166.55: icmp_seq=53 ttl=55 time=21.439 ms
64 bytes from 78.47.166.55: icmp_seq=54 ttl=55 time=20.717 ms
Request timeout for icmp_seq 55
Request timeout for icmp_seq 56
64 bytes from 78.47.166.55: icmp_seq=57 ttl=55 time=90.247 ms
64 bytes from 78.47.166.55: icmp_seq=58 ttl=55 time=20.657 ms
Request timeout for icmp_seq 59
Request timeout for icmp_seq 60
64 bytes from 78.47.166.55: icmp_seq=61 ttl=55 time=120.899 ms
Request timeout for icmp_seq 62
64 bytes from 78.47.166.55: icmp_seq=63 ttl=55 time=33.232 ms
Request timeout for icmp_seq 64
64 bytes from 78.47.166.55: icmp_seq=65 ttl=55 time=43.496 ms
64 bytes from 78.47.166.55: icmp_seq=66 ttl=55 time=28.081 ms
64 bytes from 78.47.166.55: icmp_seq=67 ttl=55 time=29.903 ms
64 bytes from 78.47.166.55: icmp_seq=68 ttl=55 time=21.090 ms
Request timeout for icmp_seq 69
64 bytes from 78.47.166.55: icmp_seq=70 ttl=55 time=20.635 ms
64 bytes from 78.47.166.55: icmp_seq=71 ttl=55 time=53.602 ms
Request timeout for icmp_seq 72
64 bytes from 78.47.166.55: icmp_seq=73 ttl=55 time=118.774 ms
Request timeout for icmp_seq 74
64 bytes from 78.47.166.55: icmp_seq=75 ttl=55 time=364.788 ms
64 bytes from 78.47.166.55: icmp_seq=76 ttl=55 time=39.731 ms
64 bytes from 78.47.166.55: icmp_seq=77 ttl=55 time=29.596 ms
64 bytes from 78.47.166.55: icmp_seq=78 ttl=55 time=74.193 ms
Request timeout for icmp_seq 79
64 bytes from 78.47.166.55: icmp_seq=80 ttl=55 time=123.119 ms
Request timeout for icmp_seq 81
64 bytes from 78.47.166.55: icmp_seq=82 ttl=55 time=401.595 ms
Request timeout for icmp_seq 83
64 bytes from 78.47.166.55: icmp_seq=84 ttl=55 time=201.064 ms
64 bytes from 78.47.166.55: icmp_seq=85 ttl=55 time=20.596 ms
64 bytes from 78.47.166.55: icmp_seq=86 ttl=55 time=127.530 ms
Request timeout for icmp_seq 87
Request timeout for icmp_seq 88
64 bytes from 78.47.166.55: icmp_seq=89 ttl=55 time=76.932 ms
64 bytes from 78.47.166.55: icmp_seq=90 ttl=55 time=378.288 ms
64 bytes from 78.47.166.55: icmp_seq=91 ttl=55 time=20.985 ms
64 bytes from 78.47.166.55: icmp_seq=92 ttl=55 time=103.950 ms
64 bytes from 78.47.166.55: icmp_seq=93 ttl=55 time=30.163 ms
64 bytes from 78.47.166.55: icmp_seq=94 ttl=55 time=43.676 ms
64 bytes from 78.47.166.55: icmp_seq=95 ttl=55 time=251.867 ms
64 bytes from 78.47.166.55: icmp_seq=96 ttl=55 time=329.752 ms
Request timeout for icmp_seq 97
64 bytes from 78.47.166.55: icmp_seq=98 ttl=55 time=20.879 ms

--- hetzner.de ping statistics ---
100 packets transmitted, 71 packets received, 29.0% packet loss
round-trip min/avg/max/stddev = 20.223/103.766/519.130/112.449 ms

Traceroute:

traceroute to hetzner.de (78.47.166.55), 64 hops max, 72 byte packets
 1  fritz.box (192.168.178.1)  1170.444 ms  1.814 ms  1.641 ms
 2  62.155.242.36 (62.155.242.36)  10.135 ms  10.387 ms  10.110 ms
 3  217.5.118.26 (217.5.118.26)  17.838 ms  17.109 ms  17.117 ms
 4  80.156.162.158 (80.156.162.158)  17.989 ms  17.322 ms  17.528 ms
 5  ae10-2021.fra20.core-backbone.com (80.255.14.6)  18.692 ms  18.451 ms  18.499 ms
 6  core-backbone.hetzner.com (80.255.15.122)  20.996 ms  20.790 ms  20.541 ms
 7  core11.nbg1.hetzner.com (213.239.224.233)  21.031 ms  20.808 ms  21.271 ms
 8  ex9k2.dc1.nbg1.hetzner.com (213.239.203.214)  21.219 ms  21.371 ms  22.370 ms
 9  dedihetznernew.your-server.de (78.47.166.55)  21.462 ms  21.620 ms  20.628 ms

[#16]

Hallo @gtt42,

wie sieht es aus? Kann es sein, dass es mittlerweile wieder läuft?

Grüße
Peter

[#17]

Hallo @Peter Hö., 

gestern Abend gegen 18 Uhr war es immer noch unbenutzbar.

Als ich vorgestern bei der Störungshotline angerufen und mein Problem geschildert hatte, wollte mir der Mitarbeiter einen kostenpflichtigen Techniker schicken, da das Problem ja an meinem Heimnetzwerk liege und definitiv ein Konfigurationsproblem auf meiner Seite wäre. Die Telekom hat laut ihm mit Peering und ihrem Netz nichts zu tun, eine Internetverbindung bestünde ja. 

So langsam bin ich es leid, von absolut inkompetenten Mitarbeitern irgendeinen Mist erzählt zu bekommen.

Wird sich dem Problem nun endlich angenommen?

Als ich hier das letzte Mal gepostet habe hatte ich am nächsten Tag eigenartigerweise einen Verbindungsabbruch zu Hetzner und ein paar Minuten später war die Verbindung einwandfrei. Das hat aber leider nur einen Tag angehalten...

[#18]

Hallo @gtt42

"traceroute to hetzner.de (78.47.166.55), 64 hops max, 72 byte packets
1 fritz.box (192.168.178.1) 1170.444 ms 1.814 ms 1.641 ms"

Der Wert an Hop 1, also Ihre Fritzbox mit 1170.444 ms ist in der Tat auffällig hoch. 1 - 3 ms sind hier normal. Bitte prüfen, ob dieser hohe Wert auch bei anderen tracerts auftritt. Dann wäre das Heimnetzwerk genauer prüfen.

Gruß

Jürgen Wo.

[#19]

@Jürgen Wo.,

das lag an meiner Firewall, dass ich da erst noch auf Allow drücken musste.

Der Hop zur FritzBox liegt im Regelfall bei ~2 ms.

[#20]

@gtt42

Jetzt funktioniert also wieder alles wie gewünscht?

Viele Grüße
Finn A.

[#21 · Accepted solution]

Nochmal ein kurzes Statusupdate hier.

Hetzner hat sich nun dazu entschlossen ab 01.04.2020 direkt mit der DTAG zu peeren.

Die Anbindung wird mit 2x 100 GBit/s erfolgen.

Damit kann der Thread eigentlich geschlossen werden, da sich das Thema ab dann erledigt hat.

[#22]

---

@gtt42  schrieb:

Nochmal ein kurzes Statusupdate hier.

Hetzner hat sich nun dazu entschlossen ab 01.04.2020 direkt mit der DTAG zu peeren.

Die Anbindung wird mit 2x 100 GBit/s erfolgen.

Damit kann der Thread eigentlich geschlossen werden, da sich das Thema ab dann erledigt hat.

---

Hast du da eine Quelle?
Finde ich auf jedenfall eine spannende Entwicklung.

[#23]

@Kugic 

in ihrem wiki schreibt Hetzner dass double paid ab 01.04.2020 obolet wird

https://wiki.hetzner.de/index.php/Double_Paid_Traffic#Besteht_ein_direktes_Peering_mit_der_Telekom.3...

Mal schauen ob es kein Aprilscherz ist

Tja, ist nun Hetzner eingeknickt oder die Telekom?

[#24]

---

@Kugic  schrieb:

---

---

Hast du da eine Quelle?
Finde ich auf jedenfall eine spannende Entwicklung.

---

Alle Hetzner-Kunden, die die Telekom-Option (Double-Paid-Traffic) gebucht hatten, haben eine Mail mit einer entsprechenden Erklärung bekommen. Da steht drin, dass Hetzner ab 1.4. direkt mit der DTAG peert. Bis April wird die Double-Paid-Traffic-Option nicht mehr berechnet, ab April fällt sie komplett weg.

Ich vermute stark, dass Hetzner hier letztendlich einknicken musste. Die Anbindung war in den letzten Wochen am Abend einfach so katastrophal schlecht, dass man so keine Produkte mehr verkaufen kann. Vielleicht haben sie sogar von der Telekom zur Abwechslung mal ein vernünftiges Angebot zu halbwegs marktüblichen Preisen bekommen, wer weiß? Das wird man offiziell vermutlich nie kommunizieren.

Insgesamt finde ich es allerdings äußerst armselig, dass man als Rechenzentrumsbetreiber nicht einfach Transit bei ein paar Carriern kaufen kann und dann Ruhe hat. Stattdessen kommen dann Drückervereine wie die Telekom und pochen auf ein direktes Peering unter Zahlung von ordentlich "Schutzgeld", damit die Daten auch vernünftig fließen. Wenn jeder Content-Provider individuell mit allen möglichen ISPs auf der Welt Peering-Verträge abschließen müsste, dann wäre doch aber das Internet völlig kaputt. Okay, das Telekom-Internet ist jetzt schon kaputt, aber zum Glück gibt's noch VPN, weil zumindest andere Carrier eine vernünftige Politik fahren.

Ohne Carrier und ohne Transit geht es nunmal nicht. Teure direkte Peerings sind für viele Dienste keine Dauerlösung, sondern nur ein "Hack", um um ein fundamentales Problem herumzuarbeiten. Dabei halte ich bezahlte direkte Peerings übrigens nichtmal für grundlegend schlecht. Für Dienste mit Anforderungen hinsichtlich geringer Latenz sind direkte Peerings und möglichst kurze Pfade natürlich wichtig, für "Hoster" wie Hetzner allerdings in der Theorie eher nicht (die Praxis sieht ja bekanntermaßen anders aus).

[#25]

Wo erpresst die Telekom denn?
Die Transitpartner steht es doch auch frei, sich entsprechende Kapazitäten einzuholen.

Es ist nun einmal eine Tatsache, das erheblich mehr Traffic ins Telekom Netz geht - als raus.
Daher ist ein kostenfreies Peering nicht möglich, da die Rechnung unausgeglichen ist.

[#26]

@Kugic 

Bei der entstellten Signatur erspare ich mir Diskussionen, was die BNetzA mit IP-Transit und Peering zu tun hat, weiß @direx wahrscheinlich selbst nicht.