Salida mtr con alta pérdida de paquetes en un salto

Estoy investigando una queja de bajo rendimiento de un usuario final que accede a un sitio que ayudo a mantener.

Tengo estas dos salidas mtr para el usuario final, la primera del sitio:

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

y el segundo de mi red:

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

¿Cómo debo interpretar esos saltos con pérdida masiva de paquetes? Me inclino a pensar que esos saltos tienen algún tipo de enrutamiento asimétrico y uno de los caminos está congestionado.

¿Podría esto causar algún problema para el usuario final?

MTR usa ICMP, que a menudo tiene una tasa limitada en Internet debido a cómo se puede usar incorrectamente para crear problemas (CPU alta, ancho de banda desperdiciado, DoS, etc.).

Cuando ve un resultado como este, generalmente esto es una señal de que la limitación de velocidad para ICMP está en su lugar. Con una búsqueda rápida en la web encontré esta documentación sobre el uso de MTR. Si bien no es oficial, parece decente (al menos con un escaneo rápido) y proporciona ejemplos de algunos problemas que puede encontrar al usar MTR.

Como @YLearn ya escribió que la limitación de paquetes ICMP en el enrutador con paquete de paquetes podría ser la causa, porque responder a las solicitudes ICMP se realiza en la CPU, mientras que el reenvío de paquetes generalmente se realiza en los ASIC. Por lo tanto, esto no tiene por qué ser un problema en absoluto.

Hace unos años, Richard Steenbergen escribió una muy buena guía para interpretar el resultado de traceroute (y MTR). Hizo una buena presentación en NANOG.

Prefiero esto diciendo que sí, la ruta que mencionas podría ser parte de ella. Sería la ruta de regreso a su host desde ese salto que está tomando un camino congestionado que los otros no.

Mi chico piensa: si esto fuera un problema en el plano de datos en ese enrutador en particular, esperaría ver la pérdida de paquetes para todos los saltos después de este salto, pero no lo ves.

Cuando el TTL de un paquete llega a 0, depende del plano de control en el enrutador generar la respuesta ICMP de regreso al host emisor. Supongo que la CPU del plano de control (en el momento en que realizaba el rastreo) en ese enrutador particular es altamente utilizada y le envía algunas respuestas fuera del valor de tiempo de espera de MTR.