mtr Ausgabe mit hohem Paketverlust auf einem Sprung

Ich untersuche eine Beschwerde über schlechte Leistung eines Endbenutzers, der auf eine von mir unterstützte Website zugreift.

Ich habe diese zwei mtr-Ausgaben für den Endbenutzer, die erste von der Site:

                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 198.199.92.253                    0.0%   200    7.3   4.2   0.9  89.6   8.0
 2. 69.22.130.37                      0.0%   200    0.4   2.5   0.3  51.4   8.0
 3. 69.22.143.170                    42.5%   200    1.3   2.0   1.1  47.9   4.9
 4. 69.22.143.165                     0.0%   200    2.3   6.4   1.6  56.9   9.7
 5. 206.223.116.86                    0.0%   200    2.5   3.0   1.8  14.1   1.5
 6. 64.125.24.1                       0.0%   200    3.0   6.9   2.2  65.7   9.9
 7. 64.125.26.230                     0.0%   200   56.3  61.4  55.6 119.0  10.0
 8. 64.125.24.33                      0.5%   200   76.4  78.9  76.0 116.1   7.1
 9. 64.125.29.38                      0.0%   200   73.9  77.5  73.4 238.8  13.4
10. 64.125.31.181                     0.5%   200  160.0 159.4 156.2 181.4   4.3
11. 64.125.32.93                      0.0%   200  156.9 157.8 155.9 217.0   6.8
12. 62.253.174.190                    0.0%   200  166.0 166.5 165.6 172.8   1.2
13. 62.253.175.217                    0.0%   200  162.1 163.1 161.7 200.4   4.2
14. 213.105.159.194                   0.0%   200  163.8 165.0 163.4 241.2   8.3
15. 81.97.112.218                     0.0%   200  164.7 166.5 164.5 220.0   7.4
16. ???

und die zweite aus meinem Netzwerk:

                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 216.16.235.1                      0.0%   115    0.4   0.4   0.3   0.6   0.1
 2. 216.16.232.37                     0.0%   115    0.9   0.9   0.6  18.8   1.7
 3. 216.16.255.141                    0.0%   115    0.8   0.7   0.6   1.1   0.1
 4. 216.16.255.130                    0.0%   114    1.0   1.0   0.8   1.4   0.1
 5. 24.153.3.141                      0.0%   114    1.9   3.6   1.5   6.5   1.2
 6. 64.71.241.97                      0.0%   114    3.4   5.3   3.3   7.4   1.1
 7. ???
 8. 64.124.128.193                   34.5%   114   18.9  19.2  18.7  39.0   2.3
 9. 64.125.21.74                      0.0%   114   19.2  20.4  18.9  49.9   5.0
10. 64.125.29.38                      0.0%   114   19.3  23.1  19.2  48.3   7.6
11. 64.125.27.186                     0.9%   114  105.2 106.1 105.1 137.8   3.2
12. 64.125.32.93                      0.0%   114  106.3 107.1 106.1 163.3   5.8
13. 62.253.174.190                    0.0%   114  181.8 123.5 115.8 206.3  20.9
14. 62.253.175.217                    0.0%   114  113.8 114.8 113.6 144.3   4.2
15. 213.105.159.194                   0.0%   114  115.3 115.9 115.2 163.5   4.6
16. 81.97.112.218                     0.0%   114  113.3 114.4 113.2 140.7   4.5
17. ???

Wie soll ich diese Hops mit MASSIVEM Paketverlust interpretieren? Ich bin geneigt zu glauben, dass diese Hopfen eine Art asymmetrisches Routing haben und einer der Pfade überlastet ist.

Könnte dies zu Problemen für den Endbenutzer führen?

MTR verwendet ICMP, das im Internet häufig nur mit eingeschränkten Raten verwendet wird, da es für die Entstehung von Problemen (hohe CPU-Auslastung, verschwendete Bandbreite, DoS usw.) missbraucht werden kann.

Wenn Sie eine Ausgabe wie diese sehen, ist dies im Allgemeinen ein Zeichen dafür, dass eine Geschwindigkeitsbegrenzung für ICMP vorhanden ist. Mit einer schnellen Websuche fand ich diese Dokumentation zur Verwendung von MTR. Obwohl es nicht offiziell ist, sieht es anständig aus (zumindest mit einem schnellen Scan) und enthält Beispiele für einige Probleme, die Sie möglicherweise bei der Verwendung von MTR finden.

Wie @YLearn bereits geschrieben hat, könnte ICMP-Ratelimiting auf dem Router mit Paketverlust die Ursache sein, da die Beantwortung von ICMP-Anforderungen in der CPU erfolgt, während die Weiterleitung von Paketen normalerweise in den ASICs erfolgt. Das muss also kein Problem sein.

Ein sehr guter Leitfaden zur Interpretation der Traceroute- (und MTR-) Ausgabe wurde vor einigen Jahren von Richard Steenbergen verfasst. Er hat auf der NANOG einen schönen Vortrag darüber gehalten.

Ich gehe dem voran, indem ich sage, dass das erwähnte Routing ein Teil davon sein könnte. Es wäre die Route ZURÜCK zu Ihrem Host von diesem Hop, der einen überlasteten Pfad einnimmt, den die anderen nicht nehmen.

Mein Typ denkt: Wenn dies ein Problem in der Datenebene auf diesem bestimmten Router wäre, würde ich nach diesem Hop einen Paketverlust für alle Hops erwarten - aber das sehen Sie nicht.

Wenn die TTL eines Pakets 0 erreicht, muss die Steuerungsebene des Routers die ICMP-Antwort an den sendenden Host zurückgeben. Ich vermute, dass die CPU der Steuerebene (zu dem Zeitpunkt, als Sie den Trace durchgeführt haben) auf diesem bestimmten Router stark ausgelastet ist und einige Antworten außerhalb des Timeout-Werts von MTR an Sie zurückgesendet werden.