☰

Traceroute: Manchmal reagieren Router nicht und der Benutzer sieht Timeouts

tag-icon • tag-icon linux timeout rate-limiting icmp traceroute
Traceroute: Manchmal reagieren Router nicht und der Benutzer sieht Timeouts

Ich bin Administrator eines kleinen Netzwerks und untersuche ein Problem, über das sich meine Benutzer beschweren. Der Grund für ihre Beschwerden ist traceroute: Manchmal reagieren Router entlang des Pfads einfach nicht auf tracerouteTests und Benutzer sehen Timeouts (diese *s anstelle von RTT).

Das Netzwerk besteht aus einigen Linux-Routern, die über Ethernet/drahtlos verbunden sind. Linux-Router zu 99 % im Leerlauf, Verbindungsauslastung 20 Mbit/s, 2000 Pakete/s. Drahtlos ist absolut stabil. PING zu allen Routern entlang des Pfads beträgt 10 ms, natürlich mit einigen Abweichungen. Flood-PING zu jedem dieser Hosts läuft minutenlang ohne Paketverlust (und ich meine, 0 Pakete verloren). Herunterladen einiger großer Dateien über das Netzwerk: durchschnittlich 10,2 MB/s.

Das Beispielrichtig traceroutesieht aus wie das:

# traceroute -nI 10.0.0.2
traceroute to 10.0.0.2 (10.0.0.2), 30 hops max, 60 byte packets
 1  192.168.0.1  3.919 ms  3.866 ms  4.117 ms
 2  10.41.13.1  4.149 ms  6.714 ms  6.707 ms
 3  10.41.1.11  8.475 ms  8.468 ms  8.705 ms
 4  10.0.0.2  8.697 ms  9.428 ms  9.707 ms

Derproblematisch traceroutes sehen so aus:

# traceroute -nI 10.0.0.2
traceroute to 10.0.0.2 (10.0.0.2), 30 hops max, 60 byte packets
 1  192.168.0.1  3.190 ms  3.140 ms  3.128 ms
 2  10.41.13.1  3.119 ms  3.113 ms *
 3  10.41.1.11  3.697 ms *  3.683 ms
 4  10.0.0.2  4.531 ms  4.524 ms  5.171 ms
# traceroute -nI 10.0.0.2
traceroute to 10.0.0.2 (10.0.0.2), 30 hops max, 60 byte packets
 1  192.168.0.1  3.471 ms  3.405 ms  3.388 ms
 2  10.41.13.1  3.372 ms  3.359 ms  3.350 ms
 3  10.41.1.11  5.039 ms * *
 4  10.0.0.2  5.105 ms  5.484 ms  5.473 ms

Ich habe ein bisschen nachgeforscht tcpdumpund herausgefunden, dass traceroutees so funktioniert:

  1. Zuerst werden eine Reihe von ICMP-Anfragen mit TTL von 1, 2, 3, 4, 5, 6 gesendet. Jeder TTL wird dreimal gesendet. Das sind 18 Pakete :)
  2. Es wird einige Zeit auf alle Antworten gewartet ( Time Exceeded).
  3. Wenn alle Antworten zurückgegeben werden, werden die Ergebnisse angezeigt.
  4. ..oder warten Sie auf ein Timeout und zeigen Sie die Ergebnisse mit fehlenden Antworten an, die mit Sternchen markiert sind.

Die Ursache für die Zeitüberschreitungen liegt darin, dass die Router alle drei entsprechenden Anfragen erhalten, aber manchmal nicht antworten und keine „ICMP-Zeit überschritten“ senden.

Ich vermute, dass es einige Einstellungen gibt, die dieses Verhalten am Router festlegen. Nämlichicmp_ratelimit,icmp_ratemask,icmp_msgs_per_secUndicmp_msgs_burst. Alles irgendwie beschriebenbei kernel.org docs. Und hier ist der Punkt, an dem ich gescheitert bin. Ich habe keine Werte für diese Variablen gefunden, damit es tracerouteimmer funktioniert.

Ich habe versucht, dies auf allen Routern einzustellen:

  • icmp_ratelimiteingestellt auf 0(nichts einschränken)
  • icmp_msgs_per_seceingestellt auf 10000(sollte hoch genug sein)
  • icmp_msgs_bursteingestellt auf 5000(hoch genug)

Es hat mir nicht geholfen, ich sehe das gleiche Verhalten, zufällige Timeouts. Ich habe nicht mit herumgespielt icmp_ratemask, weil ich nicht ganz verstehe, wie ich Time Exceeded's von der Begrenzung ausschließen kann.

Also zum Schluss noch Fragen:

  1. Wenn Sie mit dieser Art von Problemen vertraut sind traceroute, wie haben Sie sie gelöst?
  2. Wenn Sie mit den oben genannten Kerneleinstellungen vertraut sind, welche Werte sind „gut genug“?
  3. Was ist die richtige Änderungsmethode, um die Nachrichtenanzahl icmp_ratemasknicht zu begrenzen und einen reibungslosen Ablauf zu gewährleisten?Time Exceededtraceroute
  4. Und zusätzlich: Gibt es Sicherheitsverstöße, wenn ich diese (oder verwandte) Einstellungen ändere? Ich möchte weder Opfer eines DoS-Angriffs werden, noch für irgendjemanden die Quelle eines DDoS-Angriffs sein.

Antwort1

Im Rahmen der Richtlinien der Kontrollebene werden ICMP-Sonden auf Hops meist ignoriert. Ich würde eine dedizierte Smokeping-Instanz vor Ort vorschlagen, wenn Sie ausführlichere historische Daten in Bezug auf Metriken und Trends haben möchten.

verwandte Informationen