Telia Peering

Spacefish1337_0-1609956312303.png

Könnte die Telekom mal über ihren Schatten springen und ihre restriktive Peeringpolitik mal aufgeben, damit wir nicht Innerdeutch 180ms+ Pingzeiten und Paketverluste haben?


Hier ein Telia Peering in Frankfurt.. Wir sind im Büro bei der Telekom Kunde und daheim bei Easybell. Die Verbindung auf die Server im Büro läuft über dieses Telia Peering in FFM und ist extrem langsam (190ms+ und Paketverluste).. 

In letzter Konsequenz würde ich dann halt den Telekom Anschluss im Büro kündigen und zu einem Provider mit besseren Peerings gehen.. 

Das letzte Jahr über X Probleme mit dem Peering DTAG <-> AWS und Google und jetzt das.. Grund ist die Peeringpolitik der Telekom, andere Provider einigen sich ja auch!

die 190 ms entstehen nicht innerdeutsche , ist über den Atlantik, vermutlich gleich 2x

 

ausserdem entstehen sie nicht durchs peering sondern IM Telia Net

Das peering ist zwischen HOP 6 und 7

 

Ne das geht nicht über den Atlantik. Das ist einfach das Telekom <-> Telia Peering welches total überlastet ist, da nahezu aller Traffic zu AWS u.s.w. da drüber fließt, da die DTAG sich nicht mit Amazon einig wird was ein Peering agreement angeht..

 

So wie mit vielen anderen Anbietern auch nicht, deswegen läuft ja alles über dieses Telia Peering. Siehe die 20 anderen Threads hier im Forum.

@Spacefish1337 

sieht du nicht das die Latenz zwischen HOP 5 und 6 im Telianetz liegen?

Das ist doch offensichtlich, oder wie erklärst du dir "telia.net" als Domainname. Wie soll da das peering zu der Telekom liegen?

zwischen Hop 5 und 6 liegt das MPLS Netz von Telia und ich wette, dass das über den Atlantik geht.

Man muss die Dinger nicht nur posten, sondern auch lesen können

 

Und das eine Paket wurde auch bei Telia verloren, wobei die Anzahl Pakete viel zu klein ist um da eine Aussage zu treffen.

Doch ich sehe dass das im Telia Netz ist,

 

aber es liegt daran, dass einfach extrem viel Traffic über diesen Telia Knoten zur / von der Telekom läuft.


Telia wird hier als Transitnetz misbraucht, da sich eben Telekom und die Inhaltsanbieter wie Amazon nicht einigen und der ganze AWS Traffic genau diese Route zu macht. Der Telia Knoten heißt nicht ohne Grund "dtag***"

 

Warum sollte Telia das in FFM ausbauen? Die haben ja nichts davon, die sind nur gerade zwischen die Fronten geraten.

Telekom soll einfach mal über ihren Schatten springen und direkt mit den anderen Anbietern Peeren. Man muss nicht auf beiden Seiten kassieren.

Ich als Firma erwarte von meinem ISP, dass er halbwegs sinnvolle Peering mit anderen ISPs und Inhaltanbietern eingeht und eben nicht auf beiden Seiten kassiert. Dafür zahle ich ja schon für meinen lokalen Anschluss! Andere ISPs wie Ecotel, Versatel, Orange und wie sie alle heißen, kriegen das ja auch hin. Als Kunde gehe ich dann halt zu einem dieser Anbieter in letzter Konsequenz.

@Spacefish1337 

Sorry, du hast echt keine Ahnung von dem was du schreibst.

Telia ist zwischen die Fronten geraten - rofl.

Telia ist einer der größten Tier-1 Anbieter der Welt und kein Opfer.

Es gibt durchaus Kapazitätsproblem und Meinungsverschiedenheit zwischen Talia und DTAG, keine Frage,

aber das hier der Traffic über USA gerouted wird hat alleine Telia zu verantworten.  

Das was du hier als Beweis aufführst ist halt keiner dafür.

 

Die Telekom will ausdrücklich direkt zu den andern Anbietern peering und ist jederzeit bereit dies auch zu tun.

Wie sie das zu youtube und vielen anderen ja auch tut.

 

 

Telekom hilft Team
Hallo @Spacefish1337,

wir sind aktuell am Thema dran. Zu diesem Thema haben wir seit einiger Zeit einen Beitrag https://telekomhilft.telekom.de/t5/Telefonie-Internet/Peeringprobleme-Probleme-bei-Datenuebertragung... zusammengestellt. Vielleicht erläutert dieser alles ein wenig. Bitte noch um etwas Geduld.

Grüße
Erdogan T.

Hallo in die Runde,

 

soeben haben wir Neuigkeiten aus der entsprechenden Fachabteilung erhalten.

 

Es gibt keine Engpässe in Richtung Amazon. Unsere mit Amazon vereinbarten Schnittstellen sind für den Datenverkehr ausreichend ausgestattet. Amazon ist das bekannt. Warum Amazon seinen Datenverkehr von der Ostküste darüber hinaus auch über andere Verkehrswege verschickt, können wir nicht sagen oder kommentieren. Es handelt sich hierbei um die souveräne Entscheidung eines eigenständigen Unternehmens. Für weitere Fragen zu diesem Thema wendet euch bitte an den Anbieter.

 

Grüße
Erdogan T.

Auch zur Oracle Cloud AS31898 (https://www.peeringdb.com/net/1905) scheint die Telekom über Telia zu gehen. Abends ist die Verbindung regelmäßig unterirdisch; 5-10 zufällige Beispiel-Server im AS31898 haben dann Ping-Zeiten von >100ms. Was ist denn der richtige Weg um das bei der Telekom zu platzieren? 

Telekom hilft Team
hi @jmuichler,

im verlinkten Beitrag von meinem Kollegen ist soweit alles genannt worden:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Peeringprobleme-Probleme-bei-Datenuebertragung...

Viele Grüße
Oliver I.

Hallo Oliver I.,

 

so wirklich hilft das nicht: Ich verstehe grundsätzlich wie BGP, Routing, Peering,... funktioniert. Wir versuchen das Thema jetzt einerseits vom "Inhalteanbieter" als auch von unserem Großkunden-AP bei der Telekom voranzutreiben, jede weitere Hilfe / Ansprechpartner bei der Telekom selbst wären aber hilfreich. Das absurde ist: Telia behandelt Traffic zu verschiedenen Telekom-Subnetzen (die technisch am selben Endpunkt enden und zum selben AS gehören) unterschiedlich: wir haben konsistent 5ms Latenz vs. 20-100ms Latenz in dem wir einfach nur von einer anderen IP-Adress/Adressraum innerhalb desselben Telekom-Netzes starten (bei konstanter Route).

 

Gruß

@jmichler  Es ist sehr schwer zu sagen welche Route benutzt wird. Denn die hin- und Rückrichtung kann über eine andere Route laufen! Prinzipiell sieht man von der Sendeseite nur die Hin-route wenn man traceroute aufruft.
Traceroute funktioniert ja prinzipiell so:

Es gibt an TCP / UDP / ICMP Paketen einen Header "TTL" Time To Live. Das ist in wirklichkeit keine Zeit sondern eine maximale Anzahl an "Hops" über die das Paket weitergeleitet wird. Jeder der das Paket entgegen nimmt und weiterleitet reduziert das TTL Feld um den Wert 1.. Sprich bei einer TTL von 60 hat das Paket nach dem ersten Router noch 59 danach 58 u.s.w. Die Funktion ist dafür da, dass das Paket, sollte eine Routingschleife auftreten nicht ewig im Kreis geroutet wird, sondern irgendwann verworfen wird, wenn die TTL 0 ist.
Der Router der das Paket verwirft sendet dann eine Information an den ursprünglichen Absender, dass das Paket verworfen wurde (macht nicht Jeder) und zwar in form eines ICMP Pakets.

Traceroute funktioniert nun so, dass es die TTL der Pakete einfach direkt auf 1, 2, 3, 4 u.s.w. setzt und einfach schaut wer die Nachrichten schickt, dass das Paket verworfen wurde.. 

Da das verwerfen dann aber natürlich immer auf dem Pfad Absender -> Empfänger liegt, sieht man nur diese Richtung der Route.

 

Möchte man die andere Seite sehen muss man das von der fremden IP her machen.. Oft unterscheiden sich die Routen!

 

Man muss auch beachten, dass manche Router auch "transparent" sind, sprich sie reduzieren die TTL nicht und oder schicken keine Information, falls das Paket verworfen wurde.. 

Es gibt auch Load Balancing auf dem Layer darunter (port trunking) u.s.w. das ist dann auf dem IP-Layer überhaupt nicht zu sehen..

Beispiel: Zwischen Telia und Telekom gibt es 20 Links im entsprechenden Übergabepunkt, welchen dieser 20 Links ein Paket nimmt ist nicht zufall sondern hängt von der IP ab, dann kann es auch sein, dass einige dieser Links überlastet sind, andere aber nicht. Das sieht man aber nicht im Traceroute, da das komplett transparent für IP ist.

 

Am Ende sehen das nur die Provider auf ihrem Netzwerkequipment von außen ist es reine Spekulation / man sieht oft nur an welchem Exchange die Daten übergeben werden, aber nicht wie das konkrete Setup dort ist.

 

Da spielt leider viel Politik zwischen den Providern mit rein..  Manchmal wird sowas halt auch mit voller Absicht etwas ungünstig konfiguriert, da man z.B. als ISP Inhalteanbieter "erpressen" möchte o.Ä... Damit möchte ich nicht implizieren, dass die Telekom das im vorliegenden Fall macht.