die dann natürlich NICHT möglichst nah am Kunden liegen
Ausser halt, dass das fuer DG, Easybell, O2, Vodafone so nicht stimmt... wir wissen nur, dass es bei der Telekom zu diesem Problem kommt... waere nicht nahe am Kunden Business Idee von Cloudflare, dann waere zu erwarten, dass alle deutschen ISPs aus den USA mit free cloudflare versorgt wuerden...
Woher die Idee kommt, kann man schon daran erkennen, dass der Peer AS6453 nicht nur Standorte in New York hat, sondern auch in Deutschland, wovon man sich ja hier https://lg.as6453.net/bin/lg.cgi problemlos überzeugen kann.
Wenn die Telekom den Verkehr also am Ende der Welt übergibt, dann mit Absicht.
Denn verfolgt man dort von Frankfurt aus den Weg zu telekom.de (80.158.67.40), gibt es selbstverständlich eine direkte Übergabe nach München. Diese stehen Kunden mit Netzbremse der Telekom nur schlicht nicht zur Verfügung. Der Webserver der Telekom hat also einen vollständigen Zugang zum Internet, Telekom-Kunden mit Magenta-Tarif jedoch nicht.
Hi,
so, nun ist es passiert: ich bin bei meiner normalen Internetnutzung auf ein vermeintliches Peering-Problem am Telekomanschluss gestoßen:
iterm2.com scheint ebenfalls über die USA (NYC) geroutet zu werden. Ebenfalls Cloudflare-free? Wie kann ich das verifizieren?
Jedenfalls kein Update zur Primetime möglich, mit VPN sind die 32 MB direkt auf der Platte.
traceroute to iterm2.com (188.114.97.3), 30 hops max, 60 byte packets
1 fritz.box 0.839 ms 0.603 ms 0.749 ms
2 xyz.dip0.t-ipconnect.de 3.153 ms 4.904 ms 5.083 ms
3 nyc-sb6-i.NYC.US.NET.DTAG.DE (62.154.5.202) 97.455 ms 97.325 ms 97.839 ms
4 nyc-sb6-i.NYC.US.NET.DTAG.DE (62.154.5.202) 97.709 ms 97.577 ms 98.102 ms
5 80.156.160.213 (80.156.160.213) 91.557 ms 91.567 ms 91.437 ms
6 if-ae-0-2.tcore3.njy-newark.as6453.net (216.6.90.14) 101.114 ms 96.403 ms 97.432 ms
7 66.198.70.2 (66.198.70.2) 95.016 ms 93.252 ms 94.980 ms
8 162.158.61.221 (162.158.61.221) 97.416 ms 162.158.61.105 (162.158.61.105) 95.707 ms *
9 188.114.97.3 (188.114.97.3) 95.385 ms 94.698 ms 95.476 ms
In der Tat, Ladezeit Telekom Glasfaser unendlich, 1&1 DSL eine Sekunde.
Schade, dass der hartnäckige User mbo77 das nicht mitbekommen kann.
Hier zwar auch newyork, aber der Donwload selbst ist instant, schräg dass das selbst unter Telekomkunden scheinbar nochmal variiert: wget und im Browser direkt bei mir beides instant.
Bei mir jetzt auch kein Problem mehr. Zack, Download fertig.
so, nun ist es passiert: ich bin bei meiner normalen Internetnutzung auf ein vermeintliches Peering-Problem am Telekomanschluss gestoßen:
iterm2.com scheint ebenfalls über die USA (NYC) geroutet zu werden. Ebenfalls Cloudflare-free? Wie kann ich das verifizieren?
Jedenfalls kein Update zur Primetime möglich, mit VPN sind die 32 MB direkt auf der Platte.
das, und wenig spaeter das:
Bei mir jetzt auch kein Problem mehr. Zack, Download fertig.
Also Engpaesse die primaer in der Primetime spuerbar sind, ist genau die Symptome die als Konsequenz einer temporaeren Ueberlast zu erwarten sind. Passiert das nur einmal oder nur fuer ein paar Tage in folge, ist das kein grosser Akt, ISPs brauchen halt etwas Zeit um geaenderten Nutzungsprofilen zu folgen. Wenn so ein Zustand allerdings relativ zuverlaessig immer/oft in der Primetime auftritt, dann ist das ein Indiz fuer unterdimensionierte Uebergaben auf dem Netzwerkpfad, und damit z.B. auch fuer vorsaetzliches Unterpeering.
Also Engpaesse die primaer in der Primetime spuerbar sind, ist genau die Symptome die als Konsequenz einer temporaeren Ueberlast zu erwarten sind
Ich glaube, das trifft hier nicht zu. Vielmehr sieht es nach Unterschieden IPv4/IPv6 aus.
curl -6 -o /dev/null https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.271-1/virtio-win-0.1.271.iso
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 692M 0 780k 0 0 61842 0 3:15:47 0:00:12 3:15:35 38834curl -4 -o /dev/null https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.271-1/virtio-win-0.1.271.iso
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
32 692M 32 227M 0 0 4063k 0 0:02:54 0:00:57 0:01:57 6829kBei mir jetzt auch kein Problem mehr. Zack, Download fertig.
Also genau der Effekt, den ich bei dem hier vor ein paar Tagen geposteten Test hatte. Erster Versuch läuft sich zu Tode und bricht mit Timeout ab, zweiter Versuch läuft dann problemlos durch.
Bei mir war das beides per IPv4 gleiche Quell- und gleiche Zieladresse, also nichts mit IPv4 und IPv6 unterschiedlich.
Was treibt die Telekom da?
iterm2.com scheint ebenfalls über die USA (NYC) geroutet zu werden. Ebenfalls Cloudflare-free? Wie kann ich das verifizieren?
Natürlich ist das ebenfalls AS13335.
Und das ist alles, was der geneigte Telekom-Kunde wissen muss:
1. Das halbe Internet ist AS13335 (also der für Endkunden interessante Teil, das Militär mag andere Netze interessant finden). Dort sind 56.260.166 Domains gehostet.
2. Der Traffic in dieses Internet wird von der Telekom an AS6453 (Tata Communications) in New York übergeben, obwohl es Standorte in Deutschland gibt und die Telekom direkte Peerings mit AS6453 in Deutschland hat.
AS6453 kann natürlich auch AS13335 in Deutschland direkt erreichen:
iterm2.com:
traceroute to 188.114.97.3 (188.114.97.3), 30 hops max, 52 byte packets
1 if-be-7-2.ecore1.f2c-frankfurt.as6453.net (195.219.61.4) 1.272 ms 0.947 ms 0.693 ms
2 195.219.148.122 (195.219.148.122) 22.227 ms 2.492 ms 1.368 ms
3 162.158.84.169 (162.158.84.169) [AS 13335] 0.907 ms 162.158.84.111 (162.158.84.111) [AS 13335] 15.773 ms 162.158.84.169 (162.158.84.169) [AS 13335] 1.610 ms
4 188.114.97.3 (188.114.97.3) [AS 13335] 0.847 ms 1.641 ms 2.317 msUnd genauso natürlich die Telekom:
telekom.de:
traceroute to 80.158.67.40 (80.158.67.40), 30 hops max, 52 byte packets
1 if-ae-12-2.tcore2.fnm-frankfurt.as6453.net (195.219.87.1) 1.731 ms 2.760 ms 1.775 ms
MPLS Label=97374 CoS=0 TTL=1 S=1
2 if-ae-35-12.tcore1.fr0-frankfurt.as6453.net (195.219.50.238) 14.757 ms if-ae-35-10.tcore1.fr0-frankfurt.as6453.net (195.219.50.210) 1.348 ms 1.398 ms
MPLS Label=650 CoS=0 TTL=1 S=1
3 m-eb13-i.M.DE.NET.DTAG.DE (217.5.69.66) [AS 3320] 7.643 ms 7.321 ms 7.530 msEs liegt also nicht am Peer AS6453 (Tata Communications). Die sind hevorragend vernetzt. Der Verkehr der Telekom-Kunden für AS13335 wird nur von der Telekom explizit durch ein Transatlantikkabel geschoben, und das dieses dann eben manchmal überlastet. Der Verkehr der Vodafone-Kunden, O2-Kunden und DG-Kunden eben nicht.
Der Weg durch das Transatlantikkabel befindet sich innerhalb des Telekom-Netzes (AS3320). Deshalb ist es sinnvoll, nicht bei der Telekom Kunde zu werden.
Bei mir ging es auch nicht beim dritten Versuch, auch nicht im Mobilfunk und auch nicht bei ADSL.
Hier mal zur illustration ein RIPE Atlas Traceroute gegen dietpi.com fuer jeweils 10 zufaellig gewaehlte Nodes der 4 grossen Massenmarkt-ISPs:
Telekom (AS3320)
Vodafone (AS3209)
1&1 (AS8881)
O2 (AS6805)
Man sieht sehr schoen bei welchem ISP die szenische Route ueber die Ostkueste der USA gewaehlt wurde...
Mal etwas Interessantes, noch ein RIPE Atlas Test mit 50 AS3320 (Deutsche Telekom) probes gegen nordee.de
Hier die Uebersicht:
Der erste Hop sieht gaanz anders aus, Telekom, aber "normale"Latenz zu Nordee? Was ist denn da los?
Und hier die Aufloesung: Probe 54378 lief wohl gerade ueber ein VPN (vermutlich bei ip-projects.de gehostet)... 
und damit wurde der Umweg ueber New Jersey eingespart...
Das ist jetzt kein wirklich neuer Datenpunkt, aber das mit dem zufaellig "mitgefangenen VPN" finde ich ganz illustrativ.
Wusste ich es doch, das sind die wahren Hintergründe deines immer wieder propagierten Hasses auf die Telekom. So entlarvt man sich schließlich selbst..
Kriminell (wie DLMttH schrieb) ist in der Tat zum jetzigen Zeitpunkt keine begruendete Bewertung (das laesst sich erst sagen wenn ein Gericht entsprechend geurteilt hat). Aber das aendert nichts daran, dass es die Geschaeftspolitik der Telekom ist ihre zahlenden Endkunden als Druckmittel zu verwenden (was noch OK waere) und diese Endkunden auch vorsaetzlich ungenuegend mit dem ganzen Rest des Internets zu verbinden (warum sollten Inhalteanbieter ansonsten den vergleichsweise sehr teuren "Transit" bei der Telekom einkaufen?). Und das ist IMHO nicht OK, zumindest nicht solange es in der Macht der Telekom liegt das zu aendern, und so weit wir wissen sind zumindest die anderen T1-ISP bereit ihre kostenneutralen Peerings mit der Telekom zeitnah zu erweitern wenn es regelmaessig zu zu hoher Last kommt.
P.S.: Ich habe das mal hier in einen der passenderen Threads gepackt, hat ja mit Verlegung in MFH nichts zu tun.
