Ein Kunde ruft an: Das Videostreaming sei seit Dienstag langsam. Ein Geschäftskunde schickt einen Screenshot mit 300 ms Ping. Von innen betrachtet ist in Ihrem Netz jede Grafik grün. Die Verschlechterung sitzt meist am Rand dessen, was Sie kontrollieren: ein gesättigter Peering-Port, ein Transitanbieter, der über einen anderen Internetknoten umleitet, oder das Ziel selbst. Sie müssen den Pfad so sehen, wie der Kunde ihn sieht, und so, wie er aus anderen Netzen aussieht, bevor Sie entscheiden, ob der Fehler bei Ihnen, bei Ihrem Upstream oder bei niemandem liegt.
Ein visuelles Traceroute von mehreren Standorten aus, Ihrer eigenen Region, einer anderen Region, einer Sonde im Netz eines Mitbewerbers, zeigt jeden Hop mit Latenz, Jitter, Verlust und ASN und markiert den Punkt, an dem der Verkehr Ihr AS verlässt. Geplante Traces liefern den Trend, bevor die Beschwerden eintreffen; die Vergleichsansicht zeigt den Pfad vor und nach einer Routing-Änderung; der Export liefert ein datiertes Dokument mit Hop-Daten, das Sie einem Transitanbieter oder Peer schicken, statt am Telefon zu streiten.
Peering- und Transitkanten über die Zeit beobachten
Planen Sie Traces von Falkenstein, Gravelines oder einer Globalping-Sonde in Ihrem Kundenstamm zu den Zielen, die Beschwerden erzeugen: große CDNs, Cloud-Regionen, beliebte Spielehoster, öffentliche Resolver. Legen Sie Alarme für Latenz, Paketverlust und Routenänderung an. Ein Routenänderungs-Alarm ist Ihr frühestes Signal, dass eine Session abgebrochen ist oder sich eine Policy im Upstream geändert hat. Lesen Sie den Hop, an dem Ihr ASN übergibt. Steigen Latenz und Jitter genau dort, zur Stoßzeit, jeden Abend am selben Hop, ist dieser Port gesättigt oder der Peer drosselt. Steigen sie zwei Hops später im Netz des Transitanbieters, liegt das Problem bei ihm, und der Export zeigt es. Vergleichen Sie einen Trace aus einer ruhigen Stunde nebeneinander mit einem aus der Stoßzeit, um das Ausmaß der Verschlechterung zu beziffern.
Eine Beschwerde in Minuten zu einem lokalisierten Fehler machen
Fragen Sie den Kunden nach Ziel und Uhrzeit. Tracen Sie das Ziel von der Quelle, die ihm am nächsten liegt, und von einer Sonde außerhalb Ihres Netzes. Drei Fälle. Beide Traces sind sauber: Das Problem liegt beim Kunden, im WLAN oder CPE, oder es ist intermittierend; bitten Sie ihn, sich zu melden, wenn es wieder auftritt. Ihr Trace ist schlecht und der Trace von außen zum selben Ziel ist sauber: Der Fehler liegt auf Ihrer Seite der Übergabe oder auf Ihrem Transitpfad; sehen Sie sich den Hop an, an dem die Verzögerung beginnt. Beide sind ab demselben Hop schlecht: Das Ziel oder dessen Provider ist beeinträchtigt, und das können Sie dem Kunden mit Belegen sagen. Verlust an einem mittleren Hop, der am Ziel verschwindet, ist ICMP-Drosselung und kein Eskalationsgrund.
Eine BGP-Änderung von außen validieren
Nach einer neuen Präfix-Ankündigung, einem Transitwechsel oder einem Prepend prüfen Sie die Ausbreitung mit dem BGP Viewer: welches Origin-ASN die Routenkollektoren sehen, über welche Upstreams und wie viele Kollektoren sie tragen. Tracen Sie dann eine Adresse innerhalb des Präfixes von Sonden in mehreren Ländern und vergleichen Sie: Eingehender Verkehr sollte über den Transit in Ihr AS gelangen, den Sie erwarten. Kommen Sonden einer Region Stunden später noch über den alten Pfad an, hat dieser Upstream nicht aktualisiert, oder ein Routenfilter hat Ihre Ankündigung verworfen. Heben Sie den Trace von vor der Änderung auf und vergleichen Sie ihn mit dem danach; der Vergleich nebeneinander zeigt den Hop, an dem sich die Pfade trennen. Asymmetrisches Routing, raus über einen Transit und rein über einen anderen, ist normal, sollte aber gewollt sein.
Einen Trace lesen: Verlust, der in einem Transit beginnt
Ein Lehrbeispiel, keine echte Messung. Von einer Sonde in Ihrem Netz zu einem Video-CDN liegen Hop 1 bis 3 in Ihrem AS bei 2 bis 4 ms mit 0 % Verlust. Hop 4 ist die Übergabe an Ihren Transitanbieter: 5 ms, 0 % Verlust. Hop 5, noch im ASN des Transits, zeigt 6 ms, aber 30 % Verlust, und Hop 6 bis 9 zeigen 28 bis 32 % Verlust. Der Verlust bleibt bis zum Ziel bestehen, ist also echt, und er beginnt im Netz des Transits, einen Hop hinter Ihrer Kante. Derselbe Trace von einer Globalping-Sonde bei einem anderen Anbieter zeigt 0 % Verlust: Das CDN ist gesund. Fazit: eine gestörte Leitung oder ein überlasteter Port im Transit. Der Export, mit Zeitstempeln und beiden Traces, geht an dessen NOC; ein geplanter Trace sagt Ihnen, wann es behoben ist.
Werkzeuge, die das Bild vervollständigen
BGP Viewer zeigt, wer ein Präfix originiert, seine Upstreams und wie viele Routenkollektoren es sehen: die erste Prüfung nach jeder Änderung an Ihren Ankündigungen. WHOIS und IP Reputation identifizieren ein Ziel oder eine Kundenadresse, wenn eine Beschwerde von Sperrung oder einer Blacklist spricht. DNS Lookup, mit dem Resolver Ihrer Wahl, bestätigt, dass ein CDN oder ein Anycast-Dienst Ihre Kunden zu einem nahen Knoten schickt. Ping über einen Zeitraum bestätigt Jitter auf einer Leitung, bevor Sie einen Trace öffnen, und Port Check prüft Filterung von außerhalb Ihres Netzes.
Häufige Fragen
- Kann ich aus Kundensicht tracen, ohne Zugriff auf dessen Gerät?
- Wählen Sie eine Quelle in der Nähe des Kunden: Falkenstein, Gravelines oder eine der Globalping-Sonden, von denen einige in Privatkunden- oder anderen Anbieternetzen stehen. Der Trace enthält nicht den Hop im Haus des Kunden, zeigt aber den Pfad von einem nahen Netz zum Ziel. Ist dieser Pfad sauber, während die Beschwerde weiter besteht, liegt das Problem sehr wahrscheinlich zwischen dem CPE des Kunden und Ihrem ersten Router.
- Wie funktioniert ein Alarm bei Routenänderung?
- Ein geplanter Trace läuft in dem Intervall, das Sie festlegen. Jeder Lauf hält die Abfolge der Hop-Adressen fest, und weicht sie vom vorherigen Lauf ab, wird ein Alarm verschickt, mit einer Abklingzeit, damit ein flatternder Pfad Sie nicht alle paar Minuten benachrichtigt. Kombinieren Sie ihn mit Schwellenwerten für Latenz und Verlust, um sowohl stille Umleitungen als auch schleichende Verschlechterungen zu erkennen, und öffnen Sie beide Traces nebeneinander, um zu sehen, wo sie sich trennen.
- Kann ich einem Transitanbieter nachweisen, dass der Fehler auf seiner Seite liegt?
- Sie können ihm einen datierten Trace aus Ihrem Netz und einen von einer externen Sonde zum selben Ziel vorlegen, die beide zeigen, dass Verlust oder Latenz in seinem ASN auftreten und bis zum Ende bestehen bleiben. Exportieren Sie als PDF oder JSON und hängen Sie es ans Ticket. Das ist ein Beleg auf Hop-Ebene mit ASN-Zuordnung, und genau den braucht sein NOC, um sich die richtige Leitung anzusehen, selbst wenn er die Schlussfolgerung bestreitet.