Uscita mtr con elevata perdita di pacchetti su un hop

Sto indagando su un reclamo per scarso rendimento da parte di un utente finale che accede a un sito che aiuto a mantenere.

Ho questi due output mtr per l'utente finale, il primo dal sito:

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

e il secondo dalla mia rete:

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

Come dovrei interpretare questi hop con perdita di pacchetti MASSIVE? Sono propenso a pensare che quei luppoli abbiano una sorta di instradamento asimmetrico in corso e uno dei percorsi è congestionato.

Ciò potrebbe causare problemi all'utente finale?

MTR utilizza ICMP, che spesso è limitato su Internet a causa di come può essere utilizzato in modo improprio per problemi creati (CPU elevata, larghezza di banda sprecata, DoS, ecc.).

Quando vedi un output come questo, generalmente questo è un segno che è in atto un limite di velocità per ICMP. Con una rapida ricerca sul Web ho trovato questa documentazione relativa all'uso di MTR. Sebbene non sia ufficiale, sembra decente (almeno con una scansione rapida) e fornisce esempi di alcuni problemi che potresti riscontrare usando MTR.

Come già scritto da @YLearn, la delimitazione dell'ICMP sul router con perdita di pacchetti potrebbe essere la causa, poiché la risposta alle richieste ICMP viene eseguita nella CPU mentre l'inoltro dei pacchetti viene di solito effettuato negli ASIC. Quindi questo non deve essere affatto un problema.

Un'ottima guida sull'interpretazione dell'output di traceroute (e MTR) è stata scritta da Richard Steenbergen alcuni anni fa. Ha fatto una bella presentazione al NANOG.

Premetto questo dicendo che sì, il routing che menzioni potrebbe farne parte. Sarebbe il percorso RITORNO al tuo host da quel luppolo che sta prendendo un percorso congestionato che gli altri non sono.

Il mio ragazzo pensa: se questo fosse un problema nel piano dati su quel particolare router, mi sarei aspettato di vedere la perdita di pacchetti per tutti gli hop dopo questo hop - ma non lo vedi.

Quando il TTL di un pacchetto raggiunge 0, spetta al piano di controllo sul router generare la risposta ICMP all'host di invio. La mia ipotesi è che la CPU del piano di controllo (nel momento in cui stavi eseguendo la traccia) su quel particolare router sia molto utilizzata e ti sta restituendo alcune risposte al di fuori del valore di timeout di MTR.