mtr вихід з великими втратами пакетів на одному стрибку

Я розслідую скаргу на низьку ефективність роботи кінцевого користувача, який відвідує сайт, який я допомагаю підтримувати.

У мене є ці два виходи mtr для кінцевого користувача, перший із сайту:

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

а друге з моєї мережі:

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

Як слід інтерпретувати ці хмелі з МАСИВНОЮ втратою пакетів? Я схильний думати, що у цих хмелів відбувається якась асиметрична маршрутизація, і один із шляхів перевантажений.

Чи може це спричинити якісь проблеми для кінцевого користувача?

MTR використовує ICMP, який часто обмежений в Інтернеті через те, як його можна неправомірно використовувати для створених проблем (високий процесор, витрачається пропускна здатність, DoS тощо).

Коли ви бачите такий вихід, як правило, це знак того, що для ICMP встановлено обмеження швидкості. Швидким веб-пошуком я знайшов цю документацію щодо використання MTR. Хоча це не офіційно, він виглядає пристойно (принаймні, при швидкому скануванні) і надає приклади деяких проблем, які можуть виявитись за допомогою MTR.

Як @YLearn вже писав, ратемітизація ICMP на маршрутизаторі з пакетною втратою може бути причиною, оскільки відповідь на запити ICMP виконується в процесорі, а пересилання пакетів зазвичай проводиться в ASIC. Тож це взагалі не повинно бути проблемою.

Дуже хороший посібник з інтерпретації результатів traceroute (і MTR) був написаний Річардом Стінбергеном кілька років тому. Він зробив приємну презентацію про це в NANOG.

Я передмовлю це, кажучи, що так, маршрутизація, яку ви згадуєте, може бути частиною цього. Це був би маршрут НАЗАД до вашого господаря з того хопу, який веде перевантаженим шляхом, який інші не мають.

Мій хлопець думає: якби це була проблема в площині даних на цьому конкретному маршрутизаторі, я б очікував, що після цього скаку буде втрата пакетів для всіх переходів - але ви цього не бачите.

Коли TTL пакету досягає 0, до управління площиною маршрутизатора доводиться генерувати відповідь ICMP назад до хоста, що відправляє. Я гадаю, що CPU площини управління (в той момент, коли ви виконували трасування) на цьому конкретному маршрутизаторі, використовується дуже сильно, і він надсилає вам деякі відповіді поза значенням MTR часу очікування.