MTR kombiniert Traceroute und Ping zu einem einzigen laufenden Test. Es findet jeden Hop auf dem Pfad vom deutschen Probe zu Ihrem Ziel und misst kontinuierlich Latenz und Paketverlust an jedem Schritt. Das macht es deutlich nützlicher als ein einfacher Ping oder Traceroute für die Diagnose, wo genau auf dem Pfad ein Problem auftritt.

Von Deutschland aus passieren die meisten Routen zu europäischen Zielen Frankfurt-basierte Transit-Provider, bevor sie ihr Ziel erreichen. Hops durch DE-CIX-Interconnects fügen typischerweise 1–3 ms hinzu. Wenn Sie einen großen Latenzsprung bei einem bestimmten Hop sehen – sagen wir von 8 ms auf 45 ms – ist dieser Hop entweder geografisch weit entfernt, überlastet oder ICMP-deprioritisierend (was wie Latenz aussehen kann, aber Anwendungstraffic möglicherweise nicht betrifft). Verlust an einem Zwischenhop, der bei nachfolgenden Hops verschwindet, ist fast immer ICMP-Rate-Limiting und kein echter Paketverlust.

MTR von mehreren deutschen Knoten ist besonders nützlich für die Verfolgung Carrier-spezifischer Routing-Unterschiede. Deutsche Telekom, Hetzner und OVH nehmen zum selben Ziel oft unterschiedliche physische Pfade. Wenn ein Carrier zu Ihrem Server hohe Latenz zeigt, während andere das nicht tun, können Sie den abzweigenden Hop in der MTR-Ausgabe identifizieren und bestimmen, ob das Problem der Transit-Wahl des Carriers, einem Peering-Streit oder der Überlastung auf einem bestimmten Link liegt. Dieses Maß an Pfaddetail ist aus Ping oder TCP-Checks allein nicht sichtbar.

Frankfurt ist das Gravitationszentrum des europäischen Internettraffics. DE-CIX Frankfurt ist der nach Spitzendurchsatz meistgenutzte Internet Exchange der Welt und überschreitet während der Spitzenstunden routinemäßig 20 Tbit/s. Er verbindet über 1.000 Netze – darunter große Carrier, Cloud-Provider, CDNs und Content-Netzwerke – über direktes Peering. Deshalb haben in Frankfurt gehostete Server tendenziell ungewöhnlich niedrige Latenz zu Zielen quer durch Europa, ohne über Zwischenstädte transitieren zu müssen.

Frankfurt beherbergt auch mehrere parallel betriebene IXPs. KleyReX und LocIX bedienen Netze, die kleinere, community-orientierte Peering-Fabrics bevorzugen. ECIX ist in Frankfurt neben Standorten in Hamburg und Düsseldorf präsent. Jeder dieser Exchanges gibt Netzwerkbetreibern zusätzliche Peering-Optionen jenseits von DE-CIX, was die Pfadvielfalt und Resilienz auf der Frankfurter Interconnect-Ebene erhöht.

Außerhalb Frankfurts betreibt DE-CIX regionale Exchanges in Hamburg, München und Berlin. BCIX (Berlin Commercial Internet Exchange) bedient das Berliner Carrier-Ökosystem unabhängig. Diese regionalen IXPs sind wichtig, weil nicht der gesamte deutsche Traffic über Frankfurt routet – ISPs, die Norddeutschland bedienen, bevorzugen oft Hamburger Peering, und bayerische Provider peeren häufig in München, statt Traffic zuerst nach Frankfurt zu senden.

Über Frankfurt hinaus verteilt sich deutsche Hosting-Infrastruktur auf Nürnberg, Berlin, München, Hamburg und Düsseldorf. Hetzner (AS24940) betreibt zwei der größten Rechenzentren Europas in Nürnberg und Falkenstein. Deutsche Telekom (AS3320) betreibt das nationale Backbone quer durch alle Großstädte. OVH (AS16276) hält Kapazität in Frankfurt und Limburg. Kleinere, aber gut angebundene Anbieter wie GHOSTnet (AS12586), Lumaserv (AS200303) und Packets-Decreaser (AS214243) sorgen für Vielfalt auf Frankfurter Ebene. Der deutsche Hosting-Markt ist einer der wettbewerbsfähigsten in Europa, was bedeutet, dass zwischen den meisten Stadtpaaren mehrere redundante Pfade existieren.

Unsere Probe-Knoten innerhalb Deutschlands laufen auf mehreren dieser Anbieter und Städte. Die Multi-ISP-Abdeckung bedeutet, dass ein Ergebnis auf einem Knoten das Routing eines Carriers widerspiegelt – nicht das des gesamten Landes. Ein Check über alle deutschen Knoten zusammen gibt Ihnen ein realistisches Bild davon, was verschiedene Nutzersegmente in Deutschland tatsächlich sehen, sowohl auf Frankfurt-zentrierten als auch auf regionalen Routing-Pfaden.