Почему меняется ttl при пинге
Перейти к содержимому

Почему меняется ttl при пинге

Что заставляет TTL изменяться во время пинга?

У меня всегда есть окно, открытое с помощью ping -t 8.8.8.8 .

Много раз мой TTL меняется через некоторое время, и это вызывает отключение и повторное подключение приложений и игр. Например, мой TTL равен 117 за один час, и без объяснения он меняется на 121. Когда это меняется, мои приложения и игры отключаются и подключаются автоматически.

Это так раздражает, и никто из техников службы поддержки не может объяснить, что происходит.

Пока я не автономен, кто-нибудь может объяснить мне, что происходит с этими изменениями TTL ?!

У меня Windows 10.

1 ответ 1

Связь через Интернет осуществляется путем отправки множества небольших пакетов информации. Каждый пакет перемещается от его источника к месту назначения устройствами, которые называются маршрутизаторами. Маршрутизаторы соединяют множество различных небольших сетей, составляющих общедоступный Интернет.

Когда пакет проходит через маршрутизатор, маршрутизатор уменьшает поле TTL (Time To Live) пакета. Это сделано для двух целей:

Он обеспечивает механизм, позволяющий узнать, сколько маршрутизаторов (то есть прыжков) прошел пакет

Это предотвращает передачу пакетов в бесконечном цикле в случае ошибки конфигурации сети. Когда TTL достигает нуля, маршрутизаторы отбрасывают пакет.

Команда ‘ping’ показывает вам полученный TTL после того, как он уже прошел это уменьшение. Обычно отправитель указывает TTL 128 (или 64), поэтому, если вы получаете его с TTL 117, это означает, что он прошел через 11 маршрутизаторов (128-117).

Может кто-нибудь объяснить мне, что происходит с изменениями TTL ?!

Маршрутизаторы в Интернете обычно имеют несколько подключений к другим маршрутизаторам. Часто маршрутизаторы имеют несколько соединений, которые могут быть использованы для доставки вашего пакета. Задача маршрутизаторов — выбрать лучший. Из-за изменяющихся условий в сети маршрутизатор может не всегда выбирать один и тот же маршрут каждый раз для ваших пакетов. Когда это происходит, ваш пакет может в конечном итоге пройти путь, который включает в себя другое количество маршрутизаторов. Вот почему вы видите другой TTL. Это совершенно нормально. Тот факт, что существует множество маршрутов между пунктами назначения, действительно является одной из причин, по которым Интернет настолько устойчив.

мой TTL составляет 117 в течение 1 часа, и в одно мгновение без подсказки он меняется на 121, и с этим изменением мои приложения и игры отключаются и переподключаются.

В этом случае изменение вашего TTL является не причиной вашей проблемы, а скорее симптомом. Что бы ни вызывало вашу временную потерю подключения к Интернету, это также приводит к тому, что ваши пакеты выбирают другой маршрут к месту назначения. Если TTL изменяется для всех ваших пакетов, это говорит о том, что проблема очень близка вам, либо в вашей локальной сети, либо в сети вашего провайдера.

почему может изменяться TTL?

если сделать ping 194.х.х.х (веб-сервер нашего корпуса), то получается такое:

Обмен пакетами с 194.х.х.х по 32 байт:

Ответ от 194.х.х.х: число байт=32 время=1мс TTL=63
Ответ от 194.х.х.х: число байт=32 время<1мс TTL=63
Ответ от 194.х.х.х: число байт=32 время<1мс TTL=64
Ответ от 194.х.х.х: число байт=32 время<1мс TTL=64

при этом в таблицу arp того компа, с которого пинг пускаешь, добавляется запись для 194.х.х.х (после первого же пинга)

посмотреть на 194.х.х.х разумеется нельзя, кто нас туда пустит. тем не менее надо что то ответить, почему первые 2 пинга возвращаются с ТТЛ=63?

буду благодарен за идеи

Re: почему может изменяться TTL?

Re: почему может изменяться TTL?

Поле Время жизни (Time to Live = TTL) занимает один байт и означает предельный срок, в течение которого пакет может перемещаться по сети. Время жизни данного пакета измеряется в секундах и задается источником передачи. На маршрутизаторах и в других узлах сети по истечении каждой секунды из текущего времени жизни вычитается единица; единица вычитается и в том случае, когда время задержки меньше секунды. Поскольку современные маршрутизаторы редко обрабатывают пакет дольше, чем за одну секунду, то время жизни можно считать равным максимальному числу узлов, которые разрешено пройти данному пакету до того, как он достигнет места назначения. Если параметр времени жизни станет нулевым до того, как пакет достигнет получателя, этот пакет будет уничтожен. Время жизни можно рассматривать как часовой механизм самоуничтожения. Значение этого поля изменяется при обработке заголовка IP-пакета.

Re: почему может изменяться TTL?

Re: почему может изменяться TTL?

Я точно не уверен. Но может он сначала попытался выйти через какой-то маршрутизатор. Маршрутеризатор понял что пакет надо вернуть обратно в локальную сеть, в которой находится пингуемый компьютер. А после этого твой компьютер догадался, что можно направлять пинги напрямую в обход маршрутеризатора.

Соответстенно там где пакет проходил через один лишний узел TTL меньше на 1

Re: почему может изменяться TTL?

e000xf000h, а вы вопрос мой вообще читали? что такое ТТЛ я вроде как не спрашивал, благо и сам знаю. я спрашивал почему он меняется, и всегда одинаково — первые 2 пинга возвращаются с ТТЛ=63, все следующие — 64. если остановить пинг и минут через 10 опять попробовать — опять первые 2 будут 63, следующие — 64

Re: почему может изменяться TTL?

А известна топология сети? Мне кажется трудно ответить на вопрос о том какие должны быть TTL и почему не зная топологии.

Re: почему может изменяться TTL?

очевидно же: там где-то венда. это баги, да.

Re: почему может изменяться TTL?

>вы вопрос мой вообще читали?

>я спрашивал почему он меняется

Ты спросил, я тебе ответил, что-то не так?

Re: почему может изменяться TTL?

>первые 2 пинга возвращаются с ТТЛ=63, все следующие

Re: почему может изменяться TTL?

согласно этой логике дело в задержке

Re: почему может изменяться TTL?

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

Re: почему может изменяться TTL?

>А известна топология сети? Мне кажется трудно ответить на вопрос о том какие должны быть TTL и почему не зная топологии.

в том то и проблема 🙁 мне тоже трудно ответить на этот вопрос, ничего не зная о сети. экстрасенсорными способностями к сожалению не отличаюсь. но преподу пофиг, упёрся и чё хочешь то и делай

есть предположение что 10.64.255.254 и 194.х.х.х это одна и та же машина, причём оба эти интерфейса смотрят в одну сеть (буквально в один свич воткнуты). однако хз чем это предположение может помочь

ты хочешь сказать что первые 2 пакета там стабильно по секунде ждут непонятно чего? не смешно

Re: почему может изменяться TTL?

Да нету там нигде задержки больше 1с. Посмотрите время ответа пингов — 1мс.

Re: почему может изменяться TTL?

Re: почему может изменяться TTL?

Resume: pmtu 1500 hops 8 back 59

Re: почему может изменяться TTL?

e000xf000h, ты(вы?) случаем не мой препод? 🙂 лаконичность у вас схожа

Re: почему может изменяться TTL?

>ты(вы?) случаем не мой препод?

>лаконичность у вас схожа

Спасибо, я не специально.

Re: почему может изменяться TTL?

> есть предположение что 10.64.255.254 и 194.х.х.х это одна и та же машина, причём оба эти интерфейса смотрят в одну сеть (буквально в один свич воткнуты). однако хз чем это предположение может помочь

Ну как раз это предположение помочь может. Рутер при таком раскладе по идее пошлёт редирект (http://en.wikipedia.org/wiki/ICMP_Redirect_Message) хосту.

До того как хост получит его, пакеты идут через 10.64.255.254 (+1 хоп, TTL-=1). После получения редиректа, пакеты перенаправляются на 194. напрямую, минуя 10.64.255.254 (лишнего хопа нет, TTL не уменьшается).

Re: почему может изменяться TTL?

логично, я оже об этом пдумал, но где тогда редирект-сообщение?

Re: почему может изменяться TTL?

спс за ответ, но я не совсем понимаю как оно работает в моём случае
вот сценарий:

The ICMP Redirect message is only sent in the following situation:

1. Host A is sending a packet to Host B. Host A’s default IP router is router R1. Because Host B is a remote host, Host A forwards the packet destined for Host B to its default router R1.
2. R1 checks its routing table and finds that the next hop for the route to the network for Host B is router R2.
3. If Host A and R2 are on the same network that is also directly attached to R1, an ICMP Redirect message is sent to Host A informing it that R2 is the better route when sending to Host B.
4. Router R1 then forwards the IP datagram to R2.
5. Host A adds a host route to its routing table for Host B’s IP address with router R2’s IP address as the forwarding address. Subsequent datagrams from Host A to Host B are forwarded by means of router R2.

пункт 3 — If Host A and R2 are on the same network — в моём случае мой комп находится в сети 10.64.0.0/16, а R2 (который в моём случае является и Host B, 194.х.х.х) — в другой сети. и соответственно пункт 5 никак не может выполнится

Re: почему может изменяться TTL?

Есть такое понятие, shared medium, когда на одном к примеру эзернет сегменте сидят несколько различных ip подсеток. Вот, почитай, в принципе вроде здесь http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_I. как раз твой случай описан.

Re: почему может изменяться TTL?

так это проверить можно только tcpdump’ом, до пинга оно не доходит

Re: почему может изменяться TTL?

а пробовал tcpdump глядеть что по интерфейсу при пинге проходит? нужно нечто вроде

tcpdump -n -v ‘icmp’

tcpdump -n -v -X ‘icmp’

и глядеть содержимое. опять же traceroute до узла полезно сделать.

Re: почему может изменяться TTL?

tcpdump не канает. админских прав на машины нет, а к 194.х.х.х вообще доступа нет

traceroute идёт за 2 хопа, 10.64.255.254 и потом 194.х.х.х

>Есть такое понятие, shared medium, когда на одном к примеру эзернет сегменте сидят несколько различных ip подсеток. Вот, почитай, в принципе вроде здесь http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_I. как раз твой случай описан.

очень похоже на мой случай. как я понимаю, дело происходит таким макаром: есть А (мой комп, 10.64.0.1 к примеру), Б (мой шлюз, 10.64.255.254, который знает где 194.х.х.х), В (194.х.х.х, у него в качестве маршрута на 10.64.0.0/16 прописан Б). все 3 компа включены в один свич

когда А посылает первый пинг на В(194.х.х.х), он идёт к Б(10.64.255.254), который соображает что А и В находятся в shared media, и говорит А чтоб тот говорил с В напрямую. при этом, допустим, он SNAT-ит этот пинг и пересылает его на В. В отвечает через Б, ТТЛ=63

А посылает АРП запрос, узнаёт мак В. и посылает второй пинг уже напрямую В. В отвечает через Б (поскольку 10.64.0.0/16 у него в роутах прописана на Б), Б аналогично соображает что А и В находятся в shared media, и отсылает В редирект. второй пинг проходит с ТТЛ=63

А посылает третий пинг, напрямую В. к этому времени В уже тоже узнал мак А и отвечает напрямую, ТТЛ=64. все последующие пинги аналогичные

похоже на правду?

Re: почему может изменяться TTL?

Вроде так. За исключением того, что Б не SNAT-ит ничего, он просто форвардит пакет по таблице на В. И сообщение-редирект по идее приходит только на A. Почему это проходит спустя 2 пинга — хз.

Re: почему может изменяться TTL?

>Вроде так. За исключением того, что Б не SNAT-ит ничего, он просто форвардит пакет по таблице на В. И сообщение-редирект по идее приходит только на A. Почему это проходит спустя 2 пинга — хз.

я для этого и написал что он снатит. если б он просто форвардил, то по идее только один пинг был 63. а если снат, то вроде как раз 2

хотя нафиг снат когда прописаны роуты — загадка конечно. но у нас в универе всё можно ожидать, вполне может быть что так и есть

Re: почему может изменяться TTL?

в общем про SNAT я тупанул, ночью дело было. понятно что снат он не будет редиректить, иначе глупость может получиться

вопрос теперь стоит ребром — почему именно в начале именно 2 ТТЛа по 63?

если ставить его пинговать, скажем, на полчасика, то каждые минут 10 проскакивает один ТТЛ=63, т.е. чётко вписывается в теорию про ICMP REDIRECT. но в самом начале 2 ТТЛа по 63, и вопрос именно про них. куда нить ещё ткнёте?

Re: почему может изменяться TTL?

доброго времени суток. отпишусь таки, на всякий пожарный

препод сёдня соизволил дать ответ на вопрос, заданный в начале топика. привожу ответ дословно (в меру своей памяти):

"ТТЛ изменяется из-за того, что в сети находится реальный ИП. Первый пакет он пытается вытолкнуть наружу, но потом раздупляется что он находится в одной сети с ним, и шлёт напрямую. А почему 2 раза? А потому что винда так работает с ARP кешем, и не успевает до второго пинга. А если сеть будет сильно загружена, то тогда второй пинг будет 64"

короче бред редкостный. особенно порадовал ещё один его изыск на тему, почему винда отсылает пакеты с ТТЛ=128, а линух — с ТТЛ=64: "а линух принимает 128, а что такое 128 он не знает, он знает 64, вот и посылает"

почему _на самом деле_ 2 первых пинга возвращаются с ТТЛ=63, я так и не разобрался. ересь про то что винда что то там не успевает легко опровергается двумя одиночными пингами с разрывом секунд 10 (оба приходят с ТТЛ=63). да и собсно причём тут винда, если это ответные пинги с 194.х.х.х? ))

ноут свой я к сети подключал, снифером смотрел. действительно, первые 2 пинга возвращаются от шлюза, с маком шлюза, следующие пакеты — с маком от 194.х.х.х. шлюз действительно высылает ICMP_REDIRECT, правда я так и не уловил закономерности — иногда он приходил через 2 пинга, иногда через 3

в любом случае, спс всем за участие. особенно спасибо за статью про ICMP_REDIRECT, я про него не знал ) терь осталось повторить вышенаписанный бред преподу на консультации и получить допуск

Почему при пинге выдаёт высокий TTL?

Energoblock

Иногда такой TTL появляется при переводе устройства в Recovery mode.
Если роутер делает так самостоятельно, то лучше обновить прошивку до самой последней версии, сбросить к настройкам по-умолчанию и настроить заново.

Либо подключиться к консольному порту на плате роутера и напрямую смотреть логи в момент перехода в такое состояние.

Почему меняется ttl при пинге

Reply from 17.254.0.91: Bytes=32 time=70ms TTL=46

One ICMP echo request packet is sent every second to www.apple.com. When the ping program gets an echo reply back from the remote host (www.apple.com), it prints out the response, giving several pieces of information:

IP address of where the Echo Reply came from (usually this should be the IP address of www.apple.com)
Number of bytes of data sent
Round trip time it took for a packet to go to and from the remote host
Time-to-live (TTL) field
Every packet that gets sent out has a TTL field which is set to a relatively high number (ping packets get a TTL of 255). As the packet travels over the network, the TTL field gets decreased by one for each node, server, or router it passes through. When the TTL drops to 0, the packet is discarded by the router. The main purpose of this is so that a packet doesn't live forever on the network and will eventually die when it is deemed "lost." If the TTL field varies in successive pings, it could indicate that the successive reply packets are going via different routes. This could indicate that certain network routes may be experiencing problems. Packets are being sent along different paths (and not the same path each time) trying to find the quickest alternative route.

The time field is an indication of the round-trip time to get a packet to the remote host. The reply is measured in milliseconds. In general, it's best if round-trip times are under 200 milliseconds. The time it takes a packet to reach its destination is called latency. If there is a large variance in the round-trip times, the network may be experiencing problems.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *