Output mtr dengan paket loss tinggi dalam satu hop


16

Saya sedang menyelidiki keluhan tentang kinerja buruk dari pengguna akhir yang mengakses situs yang saya bantu pertahankan.

Saya memiliki dua output mtr ini kepada pengguna akhir, yang pertama dari situs:

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

dan yang kedua dari jaringan saya:

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

Bagaimana saya harus menafsirkan hop-hop itu dengan paket loss besar? Saya cenderung berpikir bahwa hop memiliki semacam routing asimetris yang sedang terjadi dan salah satu jalurnya macet.

Bisakah ini menyebabkan masalah bagi pengguna akhir?

Jawaban:


15

MTR menggunakan ICMP, yang sering dinilai terbatas di internet karena dapat disalahgunakan untuk masalah yang dibuat (CPU tinggi, bandwidth terbuang, DoS, dll).

Ketika Anda melihat output seperti ini, umumnya ini adalah tanda bahwa pembatasan tingkat untuk ICMP sudah ada. Dengan pencarian web cepat saya menemukan dokumentasi ini tentang penggunaan MTR. Meskipun tidak resmi, terlihat layak (setidaknya dengan pemindaian cepat) dan memberikan contoh beberapa masalah yang Anda temukan menggunakan MTR.


14

Seperti @YLearn sudah menulis ICMP ratelimiting pada router dengan packetloss mungkin menjadi penyebabnya, karena membalas permintaan ICMP dilakukan di CPU sementara penerusan paket biasanya dilakukan di ASIC. Jadi ini tidak perlu menjadi masalah sama sekali.

Panduan yang sangat bagus untuk menafsirkan output traceroute (dan MTR) ditulis oleh Richard Steenbergen beberapa tahun yang lalu. Dia melakukan presentasi yang bagus di NANOG.


1

Saya akan mengawali ini dengan mengatakan bahwa ya, rute yang Anda sebutkan bisa menjadi bagian darinya. Ini akan menjadi rute KEMBALI ke host Anda dari lompatan yang mengambil jalan yang macet dan yang lainnya tidak.

Orang saya berpikir: jika ini merupakan masalah pada bidang data pada router tertentu, saya akan berharap melihat paket loss untuk semua hop setelah hop ini - tetapi Anda tidak melihat itu.

Ketika TTL suatu paket mencapai 0, terserah untuk mengendalikan pesawat pada router untuk menghasilkan respons ICMP kembali ke host pengirim. Dugaan saya adalah bahwa control plane CPU (pada titik waktu Anda melakukan penelusuran) pada router tertentu sangat dimanfaatkan, dan mengirimkan beberapa respons kembali kepada Anda di luar nilai batas waktu MTR.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.