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

http://www.cap-design.ru/ksptp/5_3_2.htm

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

А вообще вот : http://tinyurl.com/ooxk35

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

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

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

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

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

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

Да.

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

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

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

Читать до просветления: http://www.linux.org.ru/jump-message.jsp?msgid=3757568&cid=3757601

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

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

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

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

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

>Читать до просветления: http://www.linux.org.ru/jump-message.jsp?msgid=3757568&cid=3757601

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

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

serji@localhost:~$ ping 195.94.224.3
PING 195.94.224.3 (195.94.224.3) 56(84) bytes of data.
64 bytes from 195.94.224.3: icmp_seq=1 ttl=59 time=6.52 ms
64 bytes from 195.94.224.3: icmp_seq=2 ttl=59 time=10.6 ms
64 bytes from 195.94.224.3: icmp_seq=3 ttl=59 time=5.33 ms
64 bytes from 195.94.224.3: icmp_seq=4 ttl=59 time=5.23 ms
^C
--- 195.94.224.3 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 5.233/6.938/10.658/2.207 ms

serji@localhost:~$ tracepath 195.94.224.3
 1:  192.168.20.135 (192.168.20.135)                        0.168ms pmtu 1500
 1:  192.168.20.129 (192.168.20.129)                        6.372ms
 1:  192.168.20.129 (192.168.20.129)                        6.368ms
 2:  77.108.96.169 (77.108.96.169)                          8.627ms
 3:  62.117.100.166 (62.117.100.166)                       10.822ms
 4:  dul-iki.comcor.ru (62.117.100.194)                     9.900ms
 5:  62.117.100.154 (62.117.100.154)                       11.505ms asymm  3
 6:  77.108.101.154 (77.108.101.154)                       11.899ms asymm  4
 7:  switch.westcall.ru (195.94.226.33)                    10.812ms asymm  5
 8:  ns2.westcall.ru (195.94.224.3)                        10.923ms reached
     
           Resume: pmtu 1500 hops 8 back 59

ttl=59

Resume: pmtu 1500 hops 8 back 59

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

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

нет, не препод

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

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

> есть предположение что 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 не уменьшается).

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

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

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 никак не может выполнится

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

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

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

tcpdump -n -v 'icmp'

или

tcpdump -n -v -X 'icmp'

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

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

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

DrLivsy

>Есть такое понятие, 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. все последующие пинги аналогичные

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>препод сёдня соизволил дать ответ на вопрос

возраст препода огласите

молодой, лет под 30. не больше