Liebes Forum,
Transit/Peering/Interconnect ist ein Thema das letztlich fuer alle ISP unabhaengig der Zugangstechnologie theoretisch relevant ist. I.d.R. ist der Zustand des Interconnects bei vielen ISPs befriedigend bis gut, so dass man da praktisch wenig Gedanken dran verschwenden muss. Aber nichts desto trotz ist das einer der Punkte in dem sich ISP unterscheiden und daher ist es hilfreich das selber fuer den eigenen ISP abschaetzen zu koennen.
Erst mal zur Terminologie, Peering bezeichnet i.d.R. eine (meist kostenneutrale) Verbindung zwischen zwei Autonomen System (AS, quasi die Baussteine des Internets, meist betreibt ein ISP ein eigenes AS) bei dem Pakete ausgetauscht werden die jeweils im Netz des anderen Terminieren. Transit hingegen bezeichnet eine (i.d.R. fuer den kleineren Partner kostenpflichtige) Verbindung zwischen 2 AS, bei denen einer der Partner nicht nur Pakete ins eigene Netz handelt, sondern auch generell Pakete in den Rest des Internets (oder bestimmte begrenzte Adressbereiche des Internets). (Das ist jetzt recht grob und damit im Detail inkorrekt, aber ich hoffe die generelle Idee wird verstanden). Die groesssten ISPs koennen quasi das ganze Internet ueber kostenneutrale Peerings errreichen (die sogenannten Tier-1 ISP) muesssen also nominell nirgendwo Transit einkaufen, bzw. die grossen T1-ISP verkaufen i.d.R. alle Transit (zusaetzlich gibt es noch andere grosse Transitanbieter wie Cogent die selber keine vollen T1-ISP sind).
Fuer Endkunden ist das erstmal egal welche wirtschaftlichen Beziehungen der eigene ISP aufbauen muss um Zugang zum ganzen Internet zu organisieren... fuer den ISP selber ist es relevant weil i.d.R. Transit teurer ist als Peerings aber zum Peering gehoeren immer zwei, d.h. man kann nur dann kostenneutral peeren wenn beide Seiten dazu bereit sind, und gerade die grossen T1-ISP verkaufen lieber Transit. Jetzt ist es so, dass die T1 zwingend kostenneutral miteinander Peeren (sonst erreichen sie nicht das ganze Internet), d.h. im Prinzip sind die Kunden eines T1 immer auch per Transit von den anderen T1 ISP erreichbar. Manche T1, die selber auch viele Endkunden haben (z.B. AT&T, ComCast, Deutsche Telekom) versuchen die grossen Inhalteanbieter dazu zu motivieren direkten Zugang beim T1 zu kaufen, statt dessen Netz per Transit zu erreichen. Damit das funktioniert und die Inhalteanbieter daran ein Interesse haben Zugang zu kaufen werdend dabei manchmal die Peerings zu den anderen T1-ISP absichtlich leicht unterdimensioniert, so dass es gerade zu den Spitzenlastzeiten zu erhoehtem Paketverlust und Latenz/Jitter kommt, so wie zu geringerem Durchsatz.
Wie kann man nun als Endnutzer selber nachsehen wie gut einen der eigene ISP mit dem Internet verbindet? Idealerweise misst man Durchsatz, Paketverlust, und Latenz zu allen anderen AS, aber das ist bei ca 90000 aktiven AS ein aussichtsloses Unterfangen, zudem enthalten nur wenige dieser AS Server die ein individueller Nutzer erreichen will. Und nicht alle AS sind gleich gut and den Rest des Internets angeschlossen. Man kann vom eigenen ISP schon erwarten, dass er keine Hindernisse aufbaut, aber fuer die Anbindung beliebiger Server in anderen AS ist er schwerlich verantwortlich.
Weil prinzipiell das ganze Internet per Transit von den grossen T1-ISP erreichbar ist, sollte es in erster Naeherung reichen zu ueberpruefen wie gut/schlecht man Servern die direkt un diesen T1 Netzen gehostet werden verbunden ist, bzw. welchen Durchsatz und welche Latenz man in der Primetime zu solchen System messen kann. Bei ca. 15 vollen T1 und ca. 15 "regionalen" T1 waeren das immer noch ca. 30 Messpunkte, was fuer eine schnelle Messung immer noch etwas aufwendig ist. (Auch weil man erst mal Messpunkte in diesen ~30 AS finden muss die zuverlaessige Daten liefern und die ebenso zuverlaessig nur ueber dieses AS erreicht werden koennen).
Um einen solchen Messpunkt zu nutzen sollte man idealerweise zur Primetime:
- den Durchsatz fuer einen grossen Datentransfer messen
- die idle Latenz zu diesem Messpunkt (d.h. ohne zusaetzliche Last)
- die working Latenz zu diesem Messpunkt (d.h. waehrend eines Kapazitaetstests der die Leitung auslastet)
- den Paketverlust messen
- den Netzwerkpfad in Vorwaerts-Richtung (zum Server) dokumentieren
- den Netzwerkpfad in Rueckwerts-Richtung (vom Server) dokumentieren (z.B. mittels Looking-Glass Server beim Messpunktbetreiber)
Dabei sind die Punkte 3, 4, und 6 besonders knifflig.
Da kaum ein Server im Internet echte Garantien zur bereit gestellten Kapazitaet macht, reicht es nicht aus eine solche Messung von einem ISP in Isolation zu machen, sondern man sollte (zu aehnlichen Zeiten gemachte) Messungen zum selben Messpunkt von verschiedenen ISP vergleichen.
Das war jetzt eher abstrakt, daher im Folge-Post mal eine Beispiel Messung und in Post 3 eine Liste mit einfachen Messungen (Durchsatz oder Latenz) die sich als nuetzlich erwiesen haben um ISP miteinander zu vergleichen.
Bezueglich 2/3, und 5 bieten sich MTR/Trippy als Messtools an, die messen die Latenz und den Vorwaertsnetzwerkpfad:
MTR
#IPv4:
mtr -ezb4 -o LSNBAWVJMXI example.com
#IPv6:
mtr -ezb6 -o LSNBAWVJMXI example.comTRIPPY
# Unter https://github.com/fujiapple852/trippy/releases zur aktuellen Release navigieren und unter Assets das passende Archiv fuer das eigene Endsystem (Windows, Macos, Linux) runterladen und lokal entpacken.
# Unter Windows CMD als Administrator starten, ins Verzeichnis mit der Datei trip.exe wechseln und folgendes aufrufen, die Firewall muss eventuell fuer Trippy geoeffnet werden.
trip --mode tui --icmp-extensions --dns-lookup-as-info --tui-address-mode both --tui-icmp-extension-mode all --tui-preserve-screen --dns-resolve-method cloudflare -4 --tui-custom-columns holsravbwdtKM --icmp --tos 181 example.com
# Linux/Macos
trip --mode tui --icmp-extensions --dns-lookup-as-info --tui-address-mode both --tui-icmp-extension-mode all --tui-preserve-screen --dns-resolve-method cloudflare -6 --tui-custom-columns holsravbwdtKM --icmp --tos 181 example.com
# Windows
trip --mode tui --icmp-extensions --dns-lookup-as-info --tui-address-mode both --tui-icmp-extension-mode all --tui-preserve-screen --dns-resolve-method cloudflare -6 example.com
# jeweils nach ca. 100 Messungen Trippy einfrieren (mit CTRL-f) und einen Screenshot machen und posten
