sortie mtr avec perte de paquets élevée sur un saut

J'enquête sur une plainte pour mauvaise performance d'un utilisateur final accédant à un site que j'aide à maintenir.

J'ai ces deux sorties mtr pour l'utilisateur final, la première du 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. ???

et le second de mon réseau:

                                       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. ???

Comment dois-je interpréter ces sauts avec une perte de paquets MASSIVE? Je suis enclin à penser que ces sauts ont une sorte de routage asymétrique en cours et que l'un des chemins est encombré.

Cela pourrait-il poser problème à l'utilisateur final?

MTR utilise ICMP, dont le taux est souvent limité sur Internet en raison de la façon dont il peut être utilisé à mauvais escient pour créer des problèmes (CPU élevé, bande passante gaspillée, DoS, etc.).

Lorsque vous voyez une sortie comme celle-ci, cela signifie généralement que la limitation de débit pour ICMP est en place. Avec une recherche rapide sur le Web, j'ai trouvé cette documentation concernant l'utilisation de MTR. Bien qu'il ne soit pas officiel, il semble décent (au moins avec une analyse rapide) et fournit des exemples de certains problèmes que vous pouvez rencontrer en utilisant MTR.

Comme @YLearn l'a déjà écrit, la limitation des ratages ICMP sur le routeur avec la perte de paquets pourrait bien en être la cause, car la réponse aux demandes ICMP se fait dans le CPU tandis que le transfert des paquets se fait généralement dans les ASIC. Cela ne doit donc pas du tout être un problème.

Un très bon guide sur l'interprétation de la sortie traceroute (et MTR) a été écrit par Richard Steenbergen il y a quelques années. Il a fait une belle présentation à ce sujet au NANOG.

Je préfère ceci en disant que oui, le routage que vous mentionnez pourrait en faire partie. Ce serait la route de retour à votre hôte à partir de ce saut qui prend un chemin encombré que les autres ne sont pas.

Mon gars pense: si c'était un problème dans le plan de données sur ce routeur particulier, je m'attendrais à voir une perte de paquets pour tous les sauts après ce saut - mais vous ne voyez pas cela.

Lorsque le TTL d'un paquet atteint 0, il appartient au contrôle du plan sur le routeur de générer la réponse ICMP à l'hôte émetteur. Je suppose que le processeur du plan de contrôle (au moment où vous effectuiez la trace) sur ce routeur particulier est très utilisé et qu'il vous renvoie des réponses en dehors de la valeur de délai d'attente de MTR.