Так в чем проблема то?

А проблема в том, что ни один маршрутизатор НЕ ОБЯЗАН отправлять ответные уведомления при обнулении TTL! Конечно, большинство хопов в сети такие уведомления высылают, однако не мало и таких, которые этого не делают. Кстати может сложится такая ситуация, когда конечный ресурс доступен и пингуется, а вот трассировка не показывает вообще ничего! Это конечно большая редкость, но все же случается.

Почему собственно маршрутизаторы никак не реагируют на окончание TTL и не высылают уведомления? Ну, как правило, самая частая причина - это банальный запрет на отправку таких уведомлений. Т.е админ просто настраивает роутер, так что на окончание TTL, тот никак не реагирует. Такой пакет отбрасывается, а вот ответы не высылаются. Вот собственно и все.

А причем тут WinMTR. А вот таки как раз и причем! Дело в том, что я предполагал в начале, что сия утилита, сделав трассировку один раз, затем просто пингует найденные хопы, измеряя потери по пингу. Возможно, время от времени, она еще и повторяет трассировку, чтобы узнать адреса хопов не ответивших по каким то причинам на первый цикл трассировки. Однако перехват трафика от WinMTR анализатором пакетов показал, что тулза совсем ничего не пингует, а просто повторяет трассировку циклически пока юзер не нажмет кнопку СТОП. Потери же пакетов на промежуточных маршрутизаторах она измеряет таким способом:

П = ((S — R) / S) * 100, где:

S — кол-во отправленных утилитой пакетов;

R — кол-во полученных от промежуточного хопа ICMP уведомлений (тип=11, код=0).

Другими словами WinMTR просто измеряет процент не пришедших от маршрутизатора уведомлений об окончании TTL относительно отправленных ею же пакетов на тестируемый ресурс. А так как мы только что выяснили не все промежуточные хопы горят желанием отправлять эти самые уведомления, то утилита считает, что имеется потеря пакетов, хотя на самом деле все пакеты достигли своих целей.

И еще раз: если какой-то хост не доступен для трассировки, то это не значит, что на нем есть какие-то реальные потери! И вот еще что: не отвечая на трассировку, хост вполне может отвечать на пинг. Запомните, пинг и трассировка маршрута это две большие разницы. И работают они по разным алгоритмам, а порой и даже по разным сетевым протоколам!. Это я к тому, что единственным верным критерием качества канала, является процент потерь на КОНЕЧНОМ хосте, а не на промежуточных маршрутизаторах. Хотя строго говоря, даже измерение потерь на конечном хосте не гарантирует 100%-го качественного тестирования, но это уже другая история...

Кстати, меня заинтересовало довольно странное поведение ретнетовского маршрутизатора. И вот почему. Если бы он всегда отвечал на трассировку, то это было хорошо. Если бы он не отвечал на трассировку ни когда, то это было бы не так хорошо, но выглядело бы логично. Я бы сделал вывод о запрете уведомлений. Но вся странность заключалась в том, то сей хоп все же отвечал на трассировку, но не всегда. Т.е время от времени он уведомления отправлял, но делал это крайне редко. Я предположил, что на нем настроена приоритизация подобных ответов. Другими словами, если роутер ничем важным не занят, то он конечно ответит. А уж если занят, то извините и извольте ответа не будет! А так как занят он всегда, то и отвечает он на трассировку лишь изредка. С этими то сомнениями, я сирый и убогий и обратился к своим старшим собратьям из RetnNet. Далее привожу свое весьма пространное письмо и их столь же лаконичный ответ:

			кому: ReTN

Здраствуйте!

Проконсультируйте пожалуйста по следующему вопросу.

В нашу техподдержку обратился пользователь нашей сети, утверждающий,

что на пограничном маршрутизаторе с вашей стороны 87.245.251.113 (Спб, Большая Морская-18) наблюдаются регулярные потери пакетов. При этом его не убеждает тот факт, что при больший "потерях" пакетов на пограничном маршрутизаторе, потерь на конечном тестируемом ресурсе нет (в случае нашего абонента этоwww.yandex.ru). В подтверждение своих слов он прислал скриншот с результатами работы утилиты WinMTR (прилагается во вложении). На скриншоте действительно видно, что процент "потерянных" пакетов довольно велик. Однако, мне известно, что WinMTR использует циклическую трассировку, многократно отправляя пакеты с увиличивающимся TTL на тестируемый хост. Потери же данная утилита измеряет просто подсчитывая процент ответов от того или иного хопа по протоколу ICMP (type=11), относительно к кол-ву отправленных ею пакетов. Конечно маршрутизатор не обязан отправлять ICMP-ответ об истечении TTL, и многие хосты поэтому просто недоступны для трассировки. Однако, маршрутизатор 87.245.251.113 периодически все-таки отвечает на трассировку, из чего можно сделать вывод, что правилами брандмауэра такие ответы не запрещены. Не могли бы вы разъяснить мне алгоритм по которому этот хост решает отвечать ему на пакет с нулевым TTL или нет. Я подозреваю, что он отвечает только если его ресурсы полностью свободны. Т.е приоритет для этой операции очень низкий. Буду очень вам признателен за объяснения. Поясню: сам я проблемы в этом не вижу и претензий к работе канала у меня нет. Ваш ответ мне важен лишь для того чтобы убедить пользователя в его неправоте.

Заранее благодарен.

Компания ООО "Телевест Инет", г. Тихвин, Лен. обл.

			кому: мне, ReTN

Здравствуйте.

Не обязательно "полностью" свободны, но в остальном именно так. Более того,
ICMP rate limit зашит в JunOS и изменению конфигом не поддается.

			кому: мне, ReTN

И на всякий случай: на форвардинге пакетов "загрузка" никак не отражается, так как
за форвардинг и ответы на ICMP отвечают разные модули, PFE и RE соответственно.
Последний спокойно перелопачивет миллионы пакетов в секунду.

В общем вот такие дела. Про работу WinMTR расписывать больше не буду. Как она работает видно из моего письма. Но если все же понадобится, то сделаю дополнение. Со скринами анализатора трафика. Там хорошо видно, что WinMTR не пингует ресурсы, а делает именно трассировку, повторяя ее много раз.

Дата добавления: 2015-09-02