LINUX.ORG.RU
ФорумAdmin

mtr показывает завышенное значение потерь на промежуточных хопах


0

1

mtr показывает завышенное значение потерь на промежуточных хопах (20-30-50%) хотя если просто пинговаться об те же хопы то оказывается что 2-3% потери, не более. С чем может быть связано такое странное поведение mtr?

★★★★★

Последнее исправление: af5 (всего исправлений: 1)

у mtr выше rate(количество сообщений на единицу времени) - попробуй ping -i 0.1 -с 100 host

ryk
()

чаще шлет пакеты. а на промежуточных хопах наверняка настроена приоретизация трафика и icmp ratelimit.

Komintern ★★★★★
()
Ответ на: комментарий от ryk

Мысли конечно правильные, только дело не в этом
делал даже ping -i 0.05 -c 100 host
всего 1 % потерь...
а mtr ~30 показывает

посмотрел tcpdump'ом - от промежуточных хостов видит только «ICMP time exceeded in-transit» вместо реплеев... очень странно.

af5 ★★★★★
() автор топика
Ответ на: комментарий от sdio

sdio> Дык откуда им взяться если пакеты дропаются на промежуточных хопах?
Не дропаются. Но по данным mtr дропается 30%. Но и ожидаемых оставшихся 70% ICMP echo reply tcpdump не видит.

af5 ★★★★★
() автор топика
Ответ на: комментарий от af5

Более того, эта чуда утилита и ICMP реквестов оказывается кроме как к оконечному хопу не отсылает

af5 ★★★★★
() автор топика
Ответ на: комментарий от af5

Получается гетвэй видит что-то в типа-чужом пакете, на что отвечает по своему настроению с вероятностью 70%

af5 ★★★★★
() автор топика
Ответ на: комментарий от sdio

sdio> Вообще-то, в linux'e traceroute это UDP по-умолчанию. там нет вообще пакетов, нит tcp ни udp ни ICMP кроме упомянутых «ICMP time exceeded in-transit»

af5 ★★★★★
() автор топика
Ответ на: комментарий от af5

af5> Получается гетвэй видит что-то в типа-чужом пакете, на что отвечает по своему настроению с вероятностью 70%

А ты знаешь как работает traffic shaping?

sdio ★★★★★
()
Ответ на: комментарий от sdio

sdio> Да, АПВС?

Ну во-первых, по тому что там по умолчанию ни какого udp нет, а во-вторых, надеялся что кто-то кроме меня замечал в ней такие странности

af5 ★★★★★
() автор топика
Ответ на: комментарий от af5

Я замечал. На провайдерских хопах были/есть дропы от 10 до 50 %

sdio ★★★★★
()
Ответ на: комментарий от af5
                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. DD-WRT                            0.0%    43    1.1   1.1   1.1   1.3   0.1
 2. bzq-179-1.static.bezeqint.net     0.0%    43   19.1  19.0  18.3  22.1   0.6
 3. bzq-219-29.static.bezeqint.n      0.0%    43   19.1  20.5  18.6  59.5   6.5
 4. bzq-179-241.static.bezeqint.n     0.0%    43  122.8  42.7  18.5 212.0  50.4
 5. bzq-219-133.cablep.bezeqint.     14.0%    43  183.9 242.2 157.8 384.8  42.6
 6. bzq-219-162.cablep.bezeqint.      0.0%    43   19.3  21.5  19.0  52.0   6.6
 7. bzq-219-18.cablep.bezeqint.n      4.7%    43  119.6 170.8 119.6 222.9  23.8
 8. decix.naukanet.ru                 0.0%    43  138.4 140.9 136.4 175.3   9.7
 9. SFT.naukanet.ru                   0.0%    43  138.7 138.5 137.2 144.5   1.2
10. r0-ch2-1-1.k16.moscow.ccs.ru      0.0%    43  143.2 143.2 142.0 148.4   1.2
11. vlan415.cat5.m34.moscow.ccs.ru    0.0%    43  145.0 144.4 142.9 150.0   1.2
12. linux.org.ru                      0.0%    43  137.6 137.7 136.3 139.7   0.7

sdio ★★★★★
()
Ответ на: комментарий от sdio

sdio> Ну если знаешь, то почему удивляешься дропам?

Так потому что это нифига не дропы :) а какойто тупой глюк непонятно что мерящей софтины
По крайней мере ping -i 0.05 -c 100 midle_host не создаёт дропов

af5 ★★★★★
() автор топика
Ответ на: комментарий от af5

потому что пинговать надо не тот хост на котором дропы, а следующий.

// ВрИО К. О.

Pinkbyte ★★★★★
()
Ответ на: комментарий от sdio

sdio> То, что через него в данном (ping ... midle_host) случае трафик не проходит и он его не шейпит.
Допустим. Но:
Во-первых, если пинговать следующий хост, то потерь опять нет.
Во-вторых, последний хост в итоге доступен 100%, т.е. ICMP пакеты между нами не шейпятся.
Т.е. IMHO дело не в шейпере.

af5 ★★★★★
() автор топика
Ответ на: комментарий от sdio

и еще похоже, как я уже сказал выше, mtr не пингует промежуточные хосты. У нее какой-то другой способ...

af5 ★★★★★
() автор топика
Ответ на: комментарий от sdio

sdio> OMG, ты знаешь как работает traceroute? Подсказка в TTL
Не вижу как это объясняет псевдо-патери регистрируемые в mtr

af5 ★★★★★
() автор топика
Ответ на: комментарий от af5

а оно не факт что теряет именно там что ты пингуеш в итоге:) и еще про ассиметрию не забываем:)

вот к примеру тебе более интересная задачка:

1. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 2. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 3. 192.168.111.17 10.0% 10 948.9 765.0 382.5 1196. 311.2 4. 10.52.129.2 40.0% 10 845.7 970.7 596.0 1454. 308.9 5. 10.52.129.2 20.0% 10 781.0 898.3 497.2 1369. 277.2 6. 83.149.40.3 10.0% 10 656.2 818.9 432.4 1288. 265.9 7. 85.26.236.121 10.0% 10 532.0 813.0 349.2 1220. 289.5 8. linux.org.ru 11.1% 9 464.5 787.1 464.5 1182. 247.6

PING 10.52.129.2 (10.52.129.2) 56(84) bytes of data.

--- 10.52.129.2 ping statistics --- 100 packets transmitted, 0 received, 100% packet loss, time 5810ms

правда интересно? как это 4 и 5 хопы нарисовались и одинаковые да еще и не пигруются совсем? и псевдопотери аж 301% :) но я же тут печатаю тем не менее:)

так что вобщем то сначала лучше понять принцип работы а потом говорить что это псевдопотери и mtr не правильно работает.

GHhost
()
Ответ на: комментарий от GHhost

GHhost> так что вобщем то сначала лучше понять принцип работы
IMHO понять из этого можно всякое:
1) девелоперам - что используемый принцип работы не лучшим образом подходит для той статистики, которую отражает их программа (mtr)
2) мне - что mtr нельзя использоваться для оценки качества линков между маршрутизаторами. Но это я уже давно понял.

Один вопрос остался. Есть ли альтернатива mtr, которая честно пингует каждый роутер?

af5 ★★★★★
() автор топика
Ответ на: комментарий от af5

проблема в том, что относительно честно ты можешь увидеть потери только на последней миле - что после неё, тёмный лес

ryk
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.