почему может изменяться 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 при пинге
У меня всегда есть окно, открытое с помощью 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. Думаю данный материал, будет полезен как новичкам, так и продвинутым пользователям, особенно когда вы ищите причину неисправности в сети или сервисе, встречал много раз, что вы думаете, что вам отвечает один сервер, а на самом деле это другой, так как кто то, что то поменял и не задокументировал.
Значение ttl
Ранее я вам рассказывал про модель OSI, и там у сетевого пакета, есть такое значение TTL (Time To Life), если перевести, то это время жизни пакета. TTL это некий счетчик, который уменьшается на единицу, при прохождении сетевого пакета или как его еще называют, кадра через маршрутизатор, делается это для того, чтобы он, при невозможности найти пункт назначения, вечно не бегал по роутерам, создавая нагрузку и паразитный трафик.
Именно время жизни пакета (TTL) нам и поможет, определить кто там с другой стороны. У каждой операционной системы этот показатель свой, так например
- Cisco TTL > равен 255
- ttl windows > равен 128
- Unix ttl > равен 64
- Android и IOS Apple> 65
- Lumia > 130
Как видите у всех он разный, и давайте разбираться, для примера я пропингую коммутатор Cisco, для этого открываем командную строку Windows, у вас может и linux быть.
Как видите значение ttl тут 255, что и показывает, что отвечает вам IOS у устройства Cisco, как видите команда ping отлично узнала операционную систему хоста с другой стороны.
Попробуем пропинговать unix систему, у меня например в локальной сети шлюзом выступает Kerio Control, на linux версии. Пингуем.
Как видите тут значение ttl равно 64, что означает unix платформу, так могут отвечать различные D-link устройства и другие домашние роутеры.
Давайте еще проверим Windows платформы, например у меня есть Windows 8.1 в локальной сети, сделаем пинг. И видите, что оно равно 128, как я и говорил.
Вот вам. тогда загадка, пингуем Windows Server 2012 R2, на нем есть веб сайт relay.aetp.ru. Что вы видите, а то что значение ttl равно 120, но в Windows же 128 по умолчанию идет, не стыковка ��
Все дело в хопах, помните в определении я вам говорил, что значение ttl уменьшается на единицу при следующем шаге и проходе через маршрутизаторы, давайте произведем трассировку до данного адреса.
Как видите сетевой пакет проходит не один хо до нужного адреса, и на определенных этапах он теряет от ttl по единичке. Все теперь вы знаете как узнать ttl windows.
Как изменить ttl windows
Давайте рассмотрим ситуацию, что вам нужно изменить ttl windows, поверьте бывают такие ситуации в жизни, примером может быть компания Yota, с ее дурацкой политикой ограничений Yota на раздачу Wi-Fi. Представим ситуацию, что взяли себе оператора Yota на телефон и решили раздать Wifi на ноутбук, но вы даже не знали подводных камней. в плане фильтрации пакетов со стороны Yota. Она жестко режет скорость, и режет она посредством значения ttl, оно должно быть 64, а если у вас дополнительное устройство, то это лишний хоп и значит ttl меньше, вот для обхода этой подставы с раздачей Wifi на ноутбук от Yota, мы и изменим ttl. Менять ttl мы будем в Windows 10, но данные действия подойдут и для Windows 7 и 8.1.
В итоге у вас откроется редактор реестра Windows. Вам нужно перейти в ветку реестра
В разделе вам нужно создать значение, все зависит от разрядности Windows, если 32 битная, то создаем параметр DWORD (32 бита), если 64 битная, то QWORD (64 бита). Я создаю QWORD.
эта лишняя единица, как раз и пойдет на лишний скачок через ваш телефон с ноутбука и Yota ничего не увидит, как видите изменить ttl windows 10, очень просто.
Как изменить ttl Ubuntu, Debian
И так с Windows мы уже научились, менять ttl, но не у всех стоит именно он, есть люди с Ubuntu например, давайте учиться как обойти ограничение на раздачу интернета через телефон на компьютер с Ubuntu на борту, в случае, если ваш оператор Йота, вы должны сделать несколько простых вещей.
1) Нажать одновременно Ctrl+Alt+T. Так вы вызовете терминал.
2) Ввести первую команду:
3) Попросит ваш пароль, вводим, жмем Enter, далее жмем i — это введет редактор vi в режим редактирования.
4) Вводим сам скрипт фиксирования TTL Ubuntu на значении 65, если у вас Android или iOS (у них стандартный TTL=64), если вы обладатель Люмии, где стандартный TTL равен 128, вам вместо 65 нужно прописать 129. Все это по простейшей формуле, ttl на компе должен быть на 1 больше, чем ttl на телефоне, с которого вы раздаете. Теорию я вам рассказал, а теперь сам скрипт:
5) Далее, для окончания редактирования жмем Esc. Потом сохраняем файл, зажимая Shift+ZZ.
6) Теперь необходимо проставить скрипту права на запуск:
7) Теперь последнее, добавляем все это дело в автозапуск:
8) Нажимаем Enter. Все будет делаться автоматически и без вашего участия.
Как изменить ttl MacOS
Ну и конечно, нельзя обижать яблочников �� Для изменения ttl на mac делаем следующее
Идем в /Library/StartupItems. Открываем терминал и прописываем:
Создаем там папку (например, это будет yota). В терминале пишем: /Library/StartupItems> sudo mkdir yota
Идем туда. В терминал вставляем: /Library/StartupItems> cd yota/
4) Создаем там скрипт (он должен называться так же как и папка), который хотим выполнять.
Для создания скрипта в терминал вбиваем:
/Library/StartupItems/yota> sudo vim yota
И тут откроется редактор Vim! Сюда копируем сам скрипт:
# Скрипт смены ttl на Mac OS X:
И закрываем Vim с сохранением результата, вводим в виме (редакторе): yota
5) Создаем файл параметров StartupParameters.plist.
/Library/StartupItems/yota> sudo vim StartupParameters.plist
И тут опять откроется редактор Vim! Сюда копируем содержание файла параметров:
Самое главное, чтобы в строчке Provides было прописано то же имя, что и название скрипта и название папки:
И опять закрываем Vim с сохранением результата, для этого вводим: w! StartupParameters.plist
6) Выставляем права на выполнение нашему скрипту.
/Library/StartupItems/fuckingyota> sudo chmod 755 yota
7) в итоге получаем: /Library/StartupItems/yota> ll
9) А сейчас, мы не будем перезагружать комп, а просто стартанем скрипт, чтобы убедиться в его работоспособности:
/Library/StartupItems/yota> sudo SystemStarter start fyota
Резюмируя мы с вами рассмотрели какие значения ttl у каждой операционной системы, рассмотрели для чего они. Мы научились менять ttl на самых распространенных системах, если есть вопросы пишите их в комментариях.
forum.lissyara.su
В моей практике такого еще не было, суть в том, что с некоторых пор начал пропадать пинг до сервера
с 8.0-RELEASE FreeBSD. Сервер смотрит одним интерфейсом в локальную сеть и имеет ip 10.40.40.40.1 а вторым в инет.
Проблема появилась не так давно, до этого работал 3 месяца без сбоев.
Когда Я начинаю пинговать до сервака из локальной сети до интерфейса 10.40.40.1 до пинг имеет ttl 127 и нифига ничего не работает(апач, днс,фтп). Когда же Я самого сервера начинаю пинговать какой нить компьютер из сегмента локальной сети к примеру 10.40.40.4, то у пинга с домашнего компа до сервера с фряхой ttl меняется резко до 63 и всё начинает работать(апач, фтп,днс).
На рисунке видно как пингуется сервер, ttl 127-> начинаю пинговать до с фряхи до др. сервака и ttl поменялась, пинга пропала и ttl обратно поменялась на 127. Как будто интерфейс нужна какая то взбучка
Написал скрипт, чтобы он постояно пинговал какой нить другой сервер. Но не прокатывает всё равно.
Внутренняя сетевая была подключена в циску С2960 потерь на интерфейсе ничего нету. Подключил в другую циску, такая же муть приключается, т.е. не из за коммутаторов.
Может ли быть такое, что кто то из локальной сети себе ставит такой же IP ? И на моём сервере приключается такая же муть. Ядро не пере собирал, фаерволл не подключен.
Почему при пинге выдаёт высокий TTL?
Иногда такой TTL появляется при переводе устройства в Recovery mode.
Если роутер делает так самостоятельно, то лучше обновить прошивку до самой последней версии, сбросить к настройкам по-умолчанию и настроить заново.
Либо подключиться к консольному порту на плате роутера и напрямую смотреть логи в момент перехода в такое состояние.
Почему меняется ttl при пинге
Так всё-таки, почему устройство (в частности принтер) может отвечать на ping вот так:
Добавлю, что одновременно с TTL = 64 (63, если смотреть на шаг ниже) прилетает совсем другое поле Identification: (например 0x7f35 (32565)), когда в пакетах выше/ниже на ICMP reply с TTL = 255 (254 соответственно) Identification совсем не похож на этот (например — выше: 0x2113 (8467), ниже: 0x2114 (8468)).
Это кто-то вставляет такой пакет «не по порядку»? Кто? Принтер?
Рискну позвать эксперта
ValdikSS
У тебя нет конфликтов IP-адресов в сети? Похоже, что принтер и какое-то другое устройство используют один IP-адрес.
Спасибо. Простое и отличное объяснение было бы. Завтра попробую проверить.
Та сеть не совсем моя. Первый день на неё смотрю. Пытаюсь поженить «свою», переехавшую сеть со этой. На «моей» стороне шлюз по умолчанию и есть шлюз «туда». С той стороны — попросил человека прописать маршрут в эту сторону.
Получилось так, что с его стороны теперь все мои ресурсы нормально доступны, а мои люди через раз не могут печатать на тот принтер. То могут, то не могут. Полдня убил на это. По всем пирогам — должно работать. Но не работает. Вот эта странность с TTL, например, смущает.
Хотя. Наверное нет.
Тогда же ведь MAC-адреса должны же были бы быть разные в дампе, насколько я понимаю?
Но и в ответе TTL=255, и в ответе TTL=64
Но проверить вашу версию будет не лишним. Спасибо еще раз.
Тогда же ведь MAC-адреса должны же были бы быть разные в дампе, насколько я понимаю?
Если через шлюзы проходит — в дампе ты будешь видеть мак своего gw.
Я и снимаю дамп непосредственно на шлюзе.
KYOCERAD_7c:fb:26 (00:17:c8:7c:fb:26) — это проблемный принтер.
ZyxelCom_0c:e0:2d (10:7b:ef:0c:e0:2d) — это шлюз.
Тут вроде почти понятно.
UPD: Под «снимаю дамп» подразумевается ZyWALL -> Maintenance -> Diagnostics -> Packet Capture на веб-морде шлюза. Получившийся cap смотрю в Wireshark. Сам ping посылается из внутренней моей машины при этом (вот на ней — уже 254 и 63 соответственно, что тоже, в целом, понятно).
С той стороны — попросил человека прописать маршрут в эту сторону.
Каким образом? На шлюзе по умолчанию добавлен маршрут в твою подсеть или dhcp выдает статический маршрут?
В первом случае может ещё icmp redirect приходить.
О! Тоже отличное объяснение. Спасибо.
Да, добавили на том gw маршрут. DHCP там не трогали.
Рискну позвать эксперта ValdikSS
Касты не работают при редактировании сообщения.
Тоже склоняюсь к конфликту IP-адресов. Возможно, еще и MAC-адресов в придачу.
Это который Electromagnetic Interference? Спасибо, интересно, почитал немного. Первый раз слышу.
В общем так: совершенно точно эта Kyocera отвечает 255 ttl, когда находится в режиме энергосбережения. 64 ttl, когда находится в активном режиме.
Тупо ноутбук с VoidLinux проводом непосредственно к ней подключал и смотрел.
Отключили с человеком энергосберегающий режим для сетевой карты этого принтера — теперь она всегда отвечает 64.
Вроде у моих людей теперь стабильно работает. Тьфу-тьфу-тьфу.
Из оставшегося непонятным:
- почему же если её никак не трогать она сама может одним-двумя пакетами 64 делать вид что проснулась и тут же обратно 255 как-будто уснула?
- почему же в своей родной сети, без шлюза это никак не влияет на работу пользователей? Они и не знали про эту пляску ttl до вчерашнего дня.
Да и шут с ней. Люди счастливы, и чудненько.
bigbit , Tanger , ValdikSS спасибо за участие в мозговом штурме. )
С этим переездом офиса вся жопа в мыле. Новый шлюз, новый ISP, новые соседи по офису. Уж и не помню когда последний раз так потел четыре дня подряд на компутерах, а не на грядках ) Наконец-то всё устаканилось и можно свалить на дачу )
Что заставляет 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 в пинге?
TTL — что такое? Время жизни (TTL) — это механизм, используемый для ограничения продолжительности жизни данных в сети. Данные отбрасываются, если истекает заданное значение. Идея создания заключается в том, чтобы предотвратить распространение любого пакета данных на неопределенный срок.
Определение
Что такое TTL? Термин «время жизни» относится к количеству времени или «перескокам», когда пакет устанавливается в сети, прежде чем отбрасывается маршрутизатором. Технология также используется в других контекстах, включая кэширование CDN и кэширование DNS.
TTL является значением в пакете IP-протокола, который сообщает сетевому маршрутизатору, был ли пакет слишком длинным. В IPv6 поле в каждом пакете было переименовано. TTL устанавливается в восьмом двоичном разряде в заголовке пакета и используется для предотвращения бесконечного распространения пакетов в интернете или в другой сети. При пересылке IP-пакета маршрутизаторы должны уменьшать TTL по меньшей мере на один порядок. Если поле пакета достигло нуля, маршрутизатор, обнаруживающий его, отбрасывает пакет и отправляет сообщение ICMP (протокол управления через интернет) обратно на исходный узел.
Как работает технология?
Когда пакет информации создается и отправляется через интернет, существует риск того, что он будет продолжать переходить с маршрутизатора на маршрутизатор на неопределенный срок. Чтобы уменьшить эту возможность, пакеты создаются с истечением срока действия, называемым пределом времени жизни. Пакет TTL также может быть полезен при определении того, как долго он находился в обращении, и позволяет отправителю получать информацию о пути пакета через интернет.
Каждый пакет имеет место, где он хранит числовое значение, определяющее, насколько долго он должен продолжать перемещаться по сети. Каждый раз, когда маршрутизатор получает пакет, он вычитает одно значение из счета TTL и затем передает его в следующее место в сети. Если в любой момент счетчик TTL равен нулю после вычитания, маршрутизатор отбросит пакет и отправит сообщение ICMP обратно на исходный узел.
Техническое описание процесса
IP TTL устанавливается первоначально системой, отправляющей пакет. Его можно разместить в любое значение от 1 до 255. Разные операционные системы устанавливают разные значения по умолчанию. Каждый маршрутизатор, который получает пакет, вычитает не менее 1 из счета. Если счетчик остается больше 0, маршрутизатор перенаправляет пакет, в противном случае он отбрасывает его и отправляет сообщение управления интернет-протоколом (ICMP) обратно на исходный узел, что может вызвать повторную отправку.
Точка ограничения TTL/hop должна поддерживать непрерывный поток пакетов, застрявших в циклах маршрутизации (возможно, из-за некорректных таблиц с данными и засорения сетей). В облаках Multiprotocol Label Switching (MPLS) TTL копируется из IP TTL, когда IP-пакет входит в облако. При выходе значение MPLS TTL копируется в соответствующее поле до тех пор, пока оно меньше значения в поле.
Изменяем TTL
Утилиты ping и traceroute используют значение TTL, чтобы попытаться достичь заданного хост-компьютера или проследить маршрут до этого хоста. Traceroute отправляет поток пакетов с последовательно более высокими TTL, поэтому каждый будет отброшен в свою очередь следующим скачком (маршрутизатором) на пути до места назначения: первый пакет имеет TTL одного и отбрасывается первым маршрутизатором, второй — TTL из двух и отбрасывается следующим маршрутизатором. Время между отправкой пакета и получением ответного ICMP-сообщения используется для вычисления каждого последующего времени перемещения.
В многоадресной рассылке IP TTL управляет областью или диапазоном, в котором может быть перенаправлен пакет. Условно IP ограничивается:
- 0 — хостом;
- 1 — подсетью;
- 32 — сайтом;
- 64 — регионом;
- 128 — континентом;
- 255 — неограничен.
Кэширование TTL и DNS
Что такое TTL в контексте DNS? Значение сообщает локальным серверам, как долго запись должна храниться локально прежде, чем новая копия записи будет восстановлена из DNS. Хранилище записей известно, как DNS-кэш, а акт хранения записей называется кэшированием.
Термин «время жизни» также используется для описания времени, в течение которого запись DNS может быть возвращена из кэша. В этом контексте USB TTL представляет собой числовое значение, заданное в записи DNS на авторитетном DNS-сервере для домена, определяющее количество секунд, за которое сервер кэширования может предоставить свое значение для записи. Когда прошло нужное количество секунд с момента последнего обновления, кэширующий сервер снова выйдет на сервер и получит текущее (и, возможно, измененное) значение для записи. Характерные особенности процесса кеширования, где TTL:
- Является частью системы доменных имен.
- Устанавливается авторитетным сервером имен для каждой записи ресурса.
- Используется для целей кэширования. Например, значение TTL для www.dnsknowledge.com составляет 86400 секунд (24 часа). Чем выше TTL записи, тем дольше будет кэшироваться информация, и тем меньше потребуется запросов, которые клиент должен будет сделать, чтобы найти домен.
- Используется разрешающим сервером имен для ускорения решения путем локального кэширования результатов.
TTL — что такое и как это работает?
В HTTP время жизни отображает количество секунд, для которых может быть возвращен кэшированный веб-контент до запроса сервера. Значение по умолчанию определяется настройками на веб-сервере, но может быть переопределено тегами управления кэшем, которые определяют, какие типы серверов могут кэшировать данные.
Пакет является фундаментальной единицей информационного транспорта во всех современных компьютерных сетях и в других сетях связи. Маршрутизатор представляет собой электронное устройство или программное обеспечение сетевого уровня, которое соединяет локальные или глобальные сети и пересылает пакеты между ними.
Общие значения
Обычно значение составляет 86400 секунд, что составляет 24 часа. Это хорошая отправная точка для большинства записей. Однако вы можете установить более высокий TTL Patch для записей MX или CNAME, поскольку они будут меняться очень редко. Если ваш сервис имеет решающее значение, рекомендуется установить TTL на 1 час (3600 секунд).
Случаи применения
Помимо трассировки пакетов маршрутов через интернет, TTL используется в контексте кэширования информации за определенный период времени. Вместо того, чтобы измерять время в перелетах между маршрутизаторами, каждый из которых может занимать определенное количество часов, некоторые случаи использования сети работают более традиционным образом.
CDN обычно использует TTL PL, чтобы определить, как долго кэшированный контент должен обслуживаться с пограничного сервера CDN, прежде чем новая копия будет извлечена с исходного сервера. Правильно устанавливая время между загрузками сервера происхождения, CDN может обслуживать обновленный контент без непрерывного распространения запросов на исходное. Эта оптимизация позволяет CDN эффективно обслуживать контент ближе к пользователю, уменьшая требуемую пропускную способность от источника.
В контексте записи DNS TTL представляет собой числовое значение, определяющее, как долго сервер кэша DNS может обслуживать запись, прежде чем обратиться к авторитарному DNS-серверу и получить новую копию записи.
Почему при пинге выдаёт высокий TTL?
Иногда такой TTL появляется при переводе устройства в Recovery mode.
Если роутер делает так самостоятельно, то лучше обновить прошивку до самой последней версии, сбросить к настройкам по-умолчанию и настроить заново.
Либо подключиться к консольному порту на плате роутера и напрямую смотреть логи в момент перехода в такое состояние.