Когда я пинг в последние три прыжка пути трассировки к facebook.com из моего местоположения, все пакеты эхо-ответа ICMP, которые я получаю, имеют TTL соответственно 58, 57 и 56. Речь идет о 6-м, 7-м и 8-м перелетах с моей машины.
С другой стороны, TTL сообщений ICMP об истечении времени для пакетов, срок действия которых истекает на этих трех переходах, имеют все разумные значения: 246, 248, 249.
Сейчас Обратный путь вполне может быть не таким, как прямой путь и это может быть не то же самое для сообщений ICMP разных типов.
Но откуда могла взяться такая разница? 200 прыжков цикл по пути? Или генерируются пакеты эхо-ответа ICMP с низким TTL (намного ниже 255: такое вообще бывает?)?
Как предложил пользователь kwaio, значение TTL по умолчанию (или обычное) для использования при генерации Эхо-запрос ICMP и эхо-ответ пакеты 64.
В моем случае первые маршрутизаторы на выбранном мной пути ответили эхо-ответом с TTL = 255 (у источника), а последние - с TTL = 64.
Вместо этого оказывается, что Превышено время ICMP сообщения были созданы во всех случаях с TTL 255.
Покопавшись, я обнаружил, что разные поставщики и разные ОС используют разные начальные TTL для разных протоколов: binbert.com/blog/2009/12/default-time-to-live-ttl-values
Интересным следствием этого является то, что вы можете идентифицировать производителя данного маршрутизатора, допустив истечение срока действия пакета на нем и послав ему эхо-запрос. Подробнее здесь: Отпечатки на основе TTL и MPLS и полная статья: «Отпечаток сети: подписи маршрутизатора на основе TTL».