Главная страница » Превышен срок жизни ttl при передаче пакета что это

Превышен срок жизни ttl при передаче пакета что это

  • автор:

Что значит — Превышел срок жизни (TTL) при передаче пакета

Пчму так? И почему это может происходить.. подскажите пожалуйста..

Партнерская программа EFSOL Oblako

Максимальный TTL — 255
Я сделал пинг с ключём — i
ping myadress.com -i 255

Ответ был тот же..

Джамп.. а расскажи пожалуйста про Кольцо.. как оно может возникнуть?

Вот давай я тебе попробую описать ихнуюю сеть.. сеть провайдера..

Она имеет адресс — 10.128.89.x
И вот.. на 9тиэтажке.. стоит свитч провайдера..
Затем на этом же доме Провайдер поставил ВайФай антену — с адрессом — 10.128.89.20

И затем уже у клиента на крыше котеджа.. с адрессом — 10.128.89.21

Вот.. и от второй антены идёт провод.. к моему роутеру..

Мне кажется что-то с антенами они намудрили. не так настроили мб..
А может и роутер кривой..

Компьютерная безграмотность. Локальная сеть часть 2. ⁠ ⁠

Судя по комментариям, статья «зашла». Значит продолжаем.

Дискламер. Для специалистов — не ругайтесь, я специально стараюсь упростить информацию, чтобы подать ее языком, понятным сантехнику и трактористу. Некоторые вещи теряются, недосказываются. Иначе просто не хватит места и статья получится скучной.

0. Дополню по комментариям из первой части.

Витая пара это аналоговая среда. По ней передается цифровая информация в виде прямоугольных импульсов. Чем выше скорость, тем больше передаваемый сигнал начинает походить на синусоиду. Фронты нарастания и спада сигнала никуда не делись. Чем лучше качество оборудования, тем меньше шансов неправильно перевести синусоиду в прямоугольник. Меньше помех, меньше отказов.

Почему пара витая? Полезная информация это разница потенциалов между проводниками. В случае телефонной «лапши» электропомеха со стороны наводит в одном проводнике ЭДС выше, чем в другом. В случае витой пары наводки одинаковы и помеха нам не так страшна.

Экранирование. В обычном патч-корде 4 пары. 2 для передачи сигнала, 2 не используются (про PoE помню). Не используются — заземлены — экранируют помехи. Не так, как внешний экран, но тоже весьма заметно.

Почему иногда экранированная пара хуже? Возьмем пример. Точка заземления — устройство — витая пара — устройство — точка заземления. Большая кольцевая антенна. Второй точки заземления может не быть, тогда помеха пойдет по экрану витой пары с наводками на линии данных. Экран витой пары должен быть заземлен с одной стороны. Не с двух! Выбор стороны зависит от конкретной ситуации. Обычно это середина. Устройство — патч-панель с землей — устройство. Если мы соединяем два здания — к выбору заземления нужно подходить после исследования качества заземления в обоих зданиях и уровней помех.

1. TTL и MTU. Расшифровка — Time-to-Live и Maximal Transferred Unit. Время жизни пакета и его максимальный размер. Поехали разбираться.

Компьютерная безграмотность. Локальная сеть часть 2. Локальная сеть, Роутер, Ликбез, Длиннопост

10.0.0.1 — мой домашний роутер, 192.168.2.1 — рабочий роутер. Между ними VPN. 192.168.2.190 — компьютер на работе. ya.ru — сайт яндекса.

Для начала рассмотрим TTL. Изначально мой пакет пинга получил 64 очка здоровья. Проходя каждый узел сети он теряет по 1 очку здоровья. Иногда узел может поменять TTL пакета, на примере рабочий роутер резко взбодрил мой пакет и выдал ему еще 64 очка здоровья. Итого 62+64 = 126. В случае Яндекса пакет прошел 18 узлов и потерял 18 очков здоровья. Зачем это нужно? Ну самое простое — заблудившиеся пакеты не должны забивать сеть. Пакет долго гуляет по сети, теряет очки здоровья, умирает. Мы получаем потерю пакета — узел недоступен. Бывает, что поковыряв настройки роутера можно достучаться до далеких узлов. Поднимаем TTL и упираемся в MTU.

Каждый пакет, пересылаемый через Интернет, помимо полезной информации содержит некоторые служебные поля. Адрес назначения, адрес источника. Представьте, что это письмо в конверте. Вы подписали конверт, отнесли на почту. Письмо весит 50 грамм, конверт 1 грамм. Итого 51 грамм. По тарифам почты это письмо, бандероль это все что выше 100 грамм. Окей, мы прошли, у нас меньше. Почта нашего района пакует наше письмо в конверт, адрес назначения — сортировочный узел города. Адрес отправителя — почта района. Вес 52 грамма. Почта города так же пакует в конвертик и отправляет на почту страны. 53 грамма. Потом международная сортировка, транзитные страны, таможни. Если наше письмо в итоге стало тяжелее 100 грамм — все, это бандероль. Не пролезло. Уничтожается. Пакет потерян. Вот так странно работает интернет. Значение MTU обычно 1400-1500 байт, что означает передаваемый разом пакет в 1024 байта.

Но можно же порезать пакет пополам? Можно. Но не всегда. Защищенные протоколы SSL (https), VPN, потоковое вещание не допускают фрагментацию пакетов.

Чем это грозит обычному пользователю? Сайт mysite.com работает по http, но не работает по https. Или https://mysite.com работает у Пети, но не работает у Васи, который сидит за соседним столом.

Вкратце. Чем на пути нашего конверта меньше транзитных узлов, тем быстрее и надежнее работает интернет. Пример:

Обмен пакетами с taobao.cn [140.205.220.96] с 32 байтами данных:

Превышен интервал ожидания для запроса.

Превышен интервал ожидания для запроса.

Превышен интервал ожидания для запроса.

Ответ от 140.205.220.96: число байт=32 время=375мс TTL=87

Статистика Ping для 140.205.220.96:

Пакетов: отправлено = 4, получено = 1, потеряно = 3

Приблизительное время приема-передачи в мс:

Минимальное = 375мсек, Максимальное = 375 мсек, Среднее = 375 мсек

Сайт далеко, часть пакетов пошла по длинному пути и не дошла. Один нашел путь покороче и прошел.

2. Роутер и «главный коммутатор». Вот не хотел я на модель OSI уходить. Ну вообще никак. Но походу придется. Для начала разберем обычный роутер. Он состоит из 4х функциональных частей (иногда 5ти и более).

Первое — собстна роутер. Процессор и микропрограммное обеспечение функциональности NAT, DHCP и DNS. Эта часть имеет один вход и один выход. На вход подаем интернет, на выход подключаем внутреннюю сеть.

Второй блок — коммутатор. У него несколько входов. Все равнозначны. И немного мозгов, если это честный коммутатор (switch), а не галимый тройник (hub). Мозги нужны, чтобы запомнить на каком входе какой адрес клиента. Или адреса. От роутера приходит пакет, свич смотрит его заголовок и выпихивает пакет сразу в нужный выход. Хаб так не умеет, он выпихнет пакет всем, а вы там сами разбирайтесь ваше это или нет.

Третий блок это WiFi. Пакет до клиента шифруется, устанавливается связь с клиентом на уровне радиоканала, пакет уходит. Тут свой процессор, свое ПО, свои заморочки.

Четвертый блок это веб-морда, samba и веб-приложения. В роутер можно воткнуть флешку, ее будут видеть все компьютеры. Роутер может качать торренты. Роутер может гнать музыку широковещалкой. Роутер может поднимать VPN.

Почему я называю коммутатор главным? Возьмем простейшую сеть. Роутер — 2 коммутатора в 2х комнатах — 10 клиентов (по 5 в комнате). Компьютеры не общаются между собой (обзор сети отключен). Все пакеты идут только через роутер наружу. Каждый коммутатор в комнате хранит 5 адресов своих клиентов и адрес роутера. Роутер в свою очередь хранит у себя все компьютеры. Тоесть априори требует больше памяти и ресурсов. Если адрес компьютера не найден в таблице роутинга — отправляется широковещательный запрос, это мешает другим клиентам и отнимает время.

В случае домашнего и SOHO оборудования пластиковая коробочка и блок питания делают невыгодным делать все эти устройства отдельно. Делают роутеры все-в-одном. С процессором роутинга, вайфаем, веб-службами, серверами samba, torrent, печати, преферансом и профурсетками. Клиент уже сам если ему нужно что-то там выключит. В случае серьезной сети это все собирается из отдельных железок. Так проще собирать, настраивать, резервировать и обслуживать.

3. Еще не вскипели? Тогда пара слов про VPN. Сначала вопрос — зачем это мне? Работа такая, ага.

У меня есть домашний роутер. Два канал интернета. Есть несколько «рабочих» роутеров по всему городу. Конторы, которые я обслуживаю. Рабочие роутеры подключаются к моему домашнему по основному или резервному каналу. Итого я имею дома логическую сеть из нескольких сегментов. Не вставая с удобного кресла я могу по внутренней сети получить доступ к любом компьютеру/принтеру любой конторы. Если мне нужен цветной принтер формата A0 — вот он. Напечатал, позвонил, бумажку отложили, приехал, забрал. У меня один склад дистрибутивов. Из любой конторы я могу в него залезть и взять что надо. Если у кого-то сломался комп (нужно переставлять систему) — до выезда из дома на компьютер соседа заливается нужное ПО. Приехал, поставил систему, поставил ПО, вуаля.

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

Для простого пользователя VPN это собственный уютный мирок, которой доступен везде. Помимо этого VPN решает некоторые другие проблемы, как то блокировка сайтов в России (а я не в России, я виртуально уже в Финляндии, хехе).

Более подробный рассказ про VPN невозможен без краткого введения в проблемы безопасности. Поэтому я оставлю это до следующего раза. Если будет интересно.

Превышен срок жизни ttl при передаче пакета что это

Что такое ping и для чего он нужен. Ping – эта такая утилита для проверки работоспособности сети. Принцип ее работы в общих чертах заключается в посылке узлу эхо-запроса и ожидании от него эхо-ответа.

Каждый узел сети Интернет должен уметь принимать эхо-запросы и возвращать эхо-ответы, разумеется, если он подсоединен к сети и работает.

Отсутствие эхо-ответа от сервера обозначает: либо сервер "висит", либо имеется неустранимое повреждение сети на участке клиент-сервер, обойти в "обход", которое невозможно.

Это свойство делает ping удобным инструментом проверки работоспособности узла и целостности соединения. Впрочем, отрицательный результат работы ping не всегда свидетельствует о наличии какой-либо проблемы (см. "Почему ping не проходит, а сайт сервера нормально работает и открывается?").

Где я могу достать ping? В штатный комплект поставки Windows входит консольная версия утилиты ping, вполне удовлетворяющая запросы непритязательного пользователя. Ping в графическом исполнении можно обнаружить в составе практически любого пакета сетевых утилит (NetInfo, CyberKit и т.д.).

Комплект разработчика Windows-приложений (SDK), входящий, в частности, в поставку компилятора Microsoft Visual Studio, содержит исходные тексты программы ping с достаточно подробными комментариями, что легко позволяет адаптировать ее к собственным нуждам и перекроить под собственный вкус.

Каково назначение ключей утилиты ping?Несмотря на свою простоту, утилита ping из штатной поставки Windows принимает достаточно большое количество ключей командной строки, более чем поверхностно описанных в прилагаемой документации. Неудивительно, что многие возможности ping ускользают не только от начинающих, но и от умудренных жизнью пользователей!

Ключ -w используется для задания интервала ожидания эхо-ответа в миллисекундах (по умолчанию 20 секунд). Если отклик от сервера не будет получен в течение указанного времени, утилита ping сообщит "Превышен интервал ожидания для запроса", намекая на неработоспособность сервера или повреждение сети. На загруженных каналах медленных провайдеров ответ может прийти и через 30, и даже через 60 секунд, поэтому интервал ожидания приходится увеличивать, например, так:

Ключ -n задает количество отправляемых эхо-запросов (по умолчанию 4). Увеличение количества запросов бывает необходимо для контроля надежности и устойчивости работы сервера. Чем выше качество канала, тем меньше разброс по времени ответов.

Ключ –t заставляет утилиту ping посылать запросы в бесконечном цикле до ее прерывания нажатием комбинации клавиш . Внимание: не прерывает процесс, а выводит текущую статистику! Этот ключ очень удобен для ожидания момента пробуждения некстати зависшего сервера: запустил ping www.hover-server.fu –t и жди появления сообщения "Host Alive" или что-то в этом роде.

Ключ –l> задает размер дейтаграммы без учета длины заголовка (28 байт), посылаемой в эхо-запросе. Допустимыми являются значения от 0 до 65.500, включительно. По умолчанию размер дейтаграммы составляет 32 байта. Манипулируя этим значением, можно выяснить зависимость: скорость доставки – размер дейтаграммы. Если размер дейтаграммы превысит некоторую критическую величину (определяемую каждым промежуточным узлом самостоятельно), дейтаграмма разрезается на несколько пакетов подходящего размера, каждый из которых добирается до конечной точки маршрута самостоятельно, а на узле назначения они вновь собираются в исходную дейтаграмму.

Ключ –f устанавливает на дейтаграмме специальную пометку, запрещающую ее разрезание (то есть, говоря техническим языком, фрагментацию). Если хотя бы один из промежуточных узлов не может обрабатывать пакеты таких размеров, он прибивает дейтаграмму и посылает отправителю уведомление, объясняя причину смерти тем, что требуется фрагментация, но установлена пометка, ее запрещающая. Впрочем, некоторые узлы не посылают такого уведомления, молчаливо отправляя пакет на тот свет или же разрезают дейтаграмму вопреки запрету (впрочем, последнее встречается редко). Вкупе с ключом –l, задающим длину дейтаграммы, запрет фрагментации ключом –f, позволяет определить максимальный размер нефрагментируемых пакетов.

Ключ –i задает время жизни (сокращенно TTL – Time To Live) пакета посылаемых дейтаграмм, измеряемое количеством узлов, которые может посетить пакет (по умолчанию 128). Каждый промежуточный узел уменьшает значение TTL на единицу и, когда оно достигает нуля, пакет уничтожается с посылкой отправителю соответствующего уведомления. Это обстоятельство позволяет отслеживать маршрут путешествия пакетов, используя ping вместо утилиты tracert, что будет нелишним в тех ситуациях, когда tracert нет под рукой.

Для контроля выясним маршрут к некоторому узлу с помощью tracert, входящей в штатную поставку Windows:

Трассировка маршрута к aport.ru [194.67.18.8] с максимальным числом прыжков 30:

А теперь вызовем ping, задав значение TTL равное одному. Первый же маршрутизатор, уменьшив его на единицу, обнаружит, что оно равно нулю, и пошлет нам соответствующее уведомление. Итак…

И в самом деле, получен ответ от узла 195.151.210.36, – первого маршрутизатора в цепочке, как это видно по протоколу работы tracert. Теперь увеличим значение TTL до двух и повторим процедуру:

Действительно, теперь найден второй маршрутизатор в цепочке! Увеличиваем значение TTL еще на единицу…

В самом деле, этот прием работает! Правда, уж очень утомительно перебирать пакеты вручную. Но работу легко оптимизировать командным файлом 1 следующего содержания: FOR /L (%%I) IN (1,1,30) DO ping %1 –i %%I вызываемым с аргументом – доменным именем или IP-адресом трассируемого узла, и он самостоятельно начнет перебирать все значения TTL от 1 до 30.

Ключ –v задает значения поля типа службы (TOS – Type Of Service). Тип сервиса с помощью некоторых абстрактных параметров указывает предпочтительный вид обслуживания – минимальная задержка, максимальная пропускная способность, максимальная надежность, минимальные издержки на пересылку или обычная, неприоритетная, пересылка. Предпочтение может быть отдано только одному типу приоритета, – нельзя одновременно требовать молниеносной скорости пересылки пакета вкупе с соломоновой надежностью его доставки. Выбирайте уж что-то одно!

Тип сервиса задается одним из следующих десятичных чисел (См. таблицу 1). Как легко увидеть, каждому значению соответствует свой бит:

Таблица 1. Допустимые типы сервиса в поле TOS

Код сервиса Пояснение
2 — минимальные издержки на пересылку
4 — максимальная надежность доставки
8 — максимальная пропускная способность
16 — минимальная задержка

Не все маршрутизаторы анализируют поле TOS, многие из них его напрочь игнорируют, что и подтверждает следующий эксперимент:

Независимо от типа сервиса, время отклика всегда составляло 130 мс, и быстроты пересылки при TOS, равном 16, не наблюдалось. А вот пример сети, поддерживающей TOS:

Наибольшая задержка наблюдалась при TOS, равном 2 (минимальные издержки на пересылку), а наименьшая – при TOS, равном 16 (минимальная задержка), и чуть менее быстрыми оказались посылки с TOS, равном 8.

Какую пользу из этого можно извлечь? А вот какую – прикладные программы могут манипулировать полем TOS по своему усмотрению, выбирая значение, соответствующее специфике своей работы. Например, telnet-клиенты, ICQ и чаты очень чувствительны к задержкам, ftp клиентам задержки не страшны, – была бы хорошей пропускная способность, и т.д. Разумеется, если промежуточные узлы игнорируют содержимое поля TOS, никакого выигрыша не получается и высокоприоритетные пакеты (например, от ICQ) обрабатываются с той же скоростью, что и пакеты, скажем, от почтового сервера, не критичные к скорости доставки. Использование ping с ключом –v позволяет выяснить, поддерживается ли TOS на данном маршруте и, если имеется несколько альтернативных маршрутов, выбрать из них наиболее подходящий2.

Ключ –r заставляет промежуточные узлы записывать в заголовок отправляемых эхо-запросов свои IP-адреса. Не все маршртузаторы поддерживают такую возможность, но очень многие. Ping, вызванная с ключом –r, позволяет отслеживать маршрут пересылки пакетов и могла бы полностью заменить собой утилиту tracert, если бы не ограничения, налагаемые размером IP-заголовка на максимальное количество запоминаемых адресов – их умещается всего девять, и более длинные пути отслеживать этим способом невозможно.

Ключ –s похож на ключ –r, но заставляет промежуточные узлы вносить в заголовок не свои адреса, а временную метку (или "штамп времени" в плохом русском переводе). По общепринятым соглашениям временная метка представляет собой четырехбайтовое поле, содержащее число миллисекунд, истекших с начала полуночи всеобщего скоординированного времени, однако на практике это соглашение мало кто соблюдает, и многие маршрутизаторы заполняют это поле всякой отсебятиной, интерпретируемой только одним им известным способом.

На количество запоминаемых временных меток наложены те же самые ограничения, что и на количество запоминаемых IP-адресов, за одним небольшим исключением – временная метка, вставленная неизвестно каким маршрутизатором, бесполезна (разве что маршрут путешествия пакетов заведомо не меняется с течением времени и может быть предварительно выявлен трассировкой). По умолчанию утилита ping автоматически запоминает IP-адреса узлов при записи временных меток, таких пар в заголовок пакета может вместиться только четыре.

Временная метка выгодно отличается тем, что позволяет вычислять точную скорость пересылки пакета, поскольку содержит в себе не общий интервал задержки (от пересылки в оба конца), а время пересылки на заданный узел. По непонятным причинам штатная (да и большинство остальных) реализация утилиты ping не позволяет задавать запись временной метки для произвольного узла в цепочке (хотя, в принципе, это возможно), чем полностью обесценивает ключ –s — ну право же, редкий сервер отделен от клиента менее чем четырьмя промежуточными узлами!

Пример вызова ping с ключом –s приведен ниже. Обратите внимание на временную метку: похоже, она представляет собой ни что иное, как случайное число.

Ключ -j задает список узлов для свободной маршрутизации от клиента и аналогичен одноименному ключу утилиты tracert.

Ключ -k похож на ключ -j, но задает список узлов для жесткой маршрутизации, т.е. пакет передается из рук в руки строго по перечню перечисленных узлов, и ни один их них не может позволить себе воспользоваться услугами "собственного" маршрутизатора для передачи пакета следующему узлу. Если узел не может передать пакет напрямую, он уничтожает его и посылает отправителю соответствующее уведомление: дескать, такая маршрутизация от источника невозможна. Существует очень мало причин, требующих применения свободной, а тем более жесткой маршрутизации. Все это пережиток старых времен, современные сети самостоятельно решают проблемы маршрутизации пакетов, и пытаться помочь им, право, не стоит – они и без того справляются со своей задачей слишком хорошо.

Ключ -a задает определение имен узлов по их IP-адресам. Так, во всяком случае, сказано в документации. Смысл этого неясен: такое определение и без того происходит автоматически независимо от наличия (отсутствия) ключа "-a".

Почему ping не проходит, а сайт сервера нормально работает и открывается? Бывает, ping к некоторому серверу упорно не проходит, какая бы задержка ни была выбрана, но все сервисы (будь то почта или web) работают нормально. Почему? Все объясняется очень просто – администратор сервера защитил его межсетевым экраном, блокирующим либо эхо-запросы, либо эхо-отклики, либо и те, и другие вместе. А может запрет эхо-откликов наложен на сам узел.

Все эти меры предосторожности объясняются тем, что эхо-посылки имеют более высокий приоритет по сравнению с обычными пакетами (иначе бы эха век не дождаться), и злоумышленники могут перегрузить сервер, направив на него штурм эхо-запросов. "Упасть", правда, сервер не упадет, но вот общая производительность несколько снизится. Хуже, если направить шторм эхо-запросов от имени жертвы, выходящей в Интернет по модему: на нее обрушится сокрушительная лавина эхо-ответов от быстродействующего сервера (хорошо, если одного), плотно забивающая канал…

Вот поэтому-то для заблаговременного предотвращения возможности атаки, эхо-посылки и запрещаются, делая работу ping невозможной, но все службы сервера продолжают, как ни в чем не бывало, работать!

Почему могут теряеться пакеты при малом ttl?

Есть керио на одном физическом порту LAN настроен ip 192.168.1.252/24, а так же дополнительный адрес 10.11.0.1/16. DHCP выдаёт ip адреса из сети 192.168.1.0/24.
Есть компьютер, который получил адрес по DHCP.
С компьютера отлично пингуется шлюз 192.168.1.252 и другой комп 10.11.0.2. Потерь нет, задержка 1мс.

А вот если выполнять команду tracert начинаются чудеса.

так же при выполнении пинга

Вот меня мучает вопрос: что-тут вообще может происходить?

  • Вопрос задан более трёх лет назад
  • 2723 просмотра

Оценить 1 комментарий

  • Facebook
  • Вконтакте
  • Twitter

А как вы хотите с TTL=1 дойти до хоста за шлюзом? Шлюз декрементит TTL до 0 и дальше пакет не пойдёт т.к. время его жизни истекло. TTL определяет максимальное количество хостов МЕЖДУ source и destination хостами.

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

krimtsev

ну так это логично.

-i 1 знаете за что отвечает? время жизни пакета TTL (Time to live)

так же почитайте тут

  • Facebook
  • Вконтакте
  • Twitter

Я этот параметр не просто так вводил, а для локализации проблемы.
При истечении времени жизни, узел должен ответить «Превышен срок жизни (TTL) при передаче пакета.», , а он в 39% случаев не отвечает.

Читайте пожалуйста внимательнее вопрос.

  • Facebook
  • Вконтакте
  • Twitter

«Еще для тестирования попробуйте так:
ping 192.168.0.252 -t»
неа. в вопросе описал, что в этом случае ни потер, ни задержек нет
Если бы керио был бы занят и дропал пакеты, то эти признаки были бы и в других ситуациях.

«А может он таким образом борется с DOS атаками по ICMP. Посмотрите настройки керио в этом направлении.» самое разумное объяснение, но в логах атак про это ни слова. да и странный какой-то способ блокировки. через раз

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

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