Time to live exceeded ping ошибка

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

В этой статье я расскажу вам, о секретах использования сетевых утилиты командной строки ping, traceroute и whois.

Сетевые утилиты командной строки

Начнем с самой популярной, о которой знает каждый админ.

Сетевая утилита ping

Команда
ping example.com известна каждому, даже далекому от сетей человеку. Она отправляет удаленному хосту пакеты ICMP echo, на которые, по идее, он должен ответить таким же пакетом.

РЕКОМЕНДУЕМ:
Автоматизация настройки адресов в IPv6

Однако этот протокол не просто так называется Internet Message Control Protocol. Его функции далеко не только диагностические, а диагностические функции куда шире, чем «ответил — не ответил».

Возможности ping

Зачастую, если хост назначения недостижим, от ping действительно можно получить только
request timeout и ничего больше. Если успешный ответ всегда исходит от самого хоста назначения, то сообщения об ошибках доставки — от промежуточных маршрутизаторов. По стандарту промежуточные маршрутизаторы могут, но не обязаны уведомлять отправителя. Часто и не уведомляют — по соображениям производительности, и обвинить их не в чем.

Но уж если тебе пришел ответ от промежуточного маршрутизатора, он обычно информативен. К примеру, ответ
destination host unreachable должен отправляться только тогда, когда хост находится в одной локальной сети с маршрутизатором и не отвечает. Самый простой способ увидеть эту ошибку — пингануть заведомо несуществующий адрес в своей же сети: к примеру, если твоя сеть 192.168.0.0/24 и хоста 192.168.0.200 в ней нет, выполнить
ping 192.168.0.200.

Такой ответ может прийти только от последнего маршрутизатора на пути к хосту.

А вот
network unreachable говорит об отсутствии маршрута к указанной сети у одного из хостов на пути. Эта ошибка может возникнуть в любом месте пути, поэтому нужно обратить внимание на отправителя.

Чаще всего эта проблема у тебя самого: слетели настройки маршрутов или хост не получил маршрут от сервера DHCP. Но такой ответ может прийти и от промежуточного маршрутизатора:

Если ты видишь такую картину, что-то серьезно пошло не так. Если хост достижим из других сетей, вполне возможно, что у провайдера проблема с настройками BGP. Я как минимум один раз сталкивался с тем, что крупный провайдер ошибочно фильтровал маршруты из сети, которую он считал зарезервированной для использования в будущем, хотя на тот момент IANA уже полгода как передала ее RIPE NCC и многие люди получили адреса из нее.

Если не хочешь быть как тот провайдер, можно воспользоваться автоматически обновляемыми списками несуществующих адресов вроде Cymru Bogon Reference

Ошибки семейства
destination host/net prohibited означают, что пакет был отброшен правилом межсетевого экрана. Впрочем, никто не обязывает отвечать отправителю именно так или вообще отвечать. К примеру, в Linux правила вида
iptables —j REJECT по умолчанию выдают
destination port unreachable, если явно не указать
—reject—with, причем указать можно любой тип, даже
icmp—net—unreachable.

Но это все о простом
ping без опций. Некоторые проблемы лучше всего выявляются дополнительными опциями.

Определение проблемы с MTU

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

Распространенная причина таких проблем — некорректно настроена сеть назначения, из-за чего пакеты перестают проходить через туннель. Поскольку MTU (Maximum Transmission Unit — максимальный размер пакета) для туннелей меньше, чем стандартный для интернета размер 1500, правильная работа соединений требует работающего path MTU discovery. Увы, работает он не всегда, и самый простой способ его сломать — запретить протокол ICMP, «чтобы не пинговал кто попало».

Такие патологические случаи среди сетевых админов встречаются редко, но именно сломанный
PMTU discovery, увы, распространен.

Выявить эту проблему можно, указав размер пакета опцией
—s:
ping —s1300 www.example.com. Если стандартный пинг с размером пакета в 64 байта проходит, но с какого-то размера пакета (например,
—s 1450) пинг внезапно перестает работать, то поздравляю, ты нашел проблему. Пиши админу, чтобы включил MSS clamping, или включай сам, если ты и есть админ.

Поиск глубокой инспекции пакетов

Многие решения для DPI не смотрят так уж глубоко, а просто ищут фиксированные строки в пакетах. В некоторых случаях определить наличие такого DPI на пути можно с помощью одного ping. В Linux для этого есть опция
—pattern. Один недостаток — сомнительную строку придется вручную кодировать в hex, но, если установить генератор пакетов нет никакой возможности, может пригодиться.

TTL exceeded

Еще одна ошибка, которую на практике можно увидеть только с дополнительной опцией, —
Time to live exceeded. Поле Time To Live у пакетов IPv4 (Hop Limit в IPv6) ограничено значением 255, но интернет — «тесная сеть», и средний путь не достигает и одной десятой максимальной длины. Изначальная цель этого механизма — предотвратить бесконечную пересылку пакетов по кругу при возникновении петли маршрутизации, но современные протоколы исключают петли. Тем не менее никто не мешает указать TTL заведомо короче ожидаемой длины пути:

Сетевая утилита traceroute

Именно по принципу, описанному выше, и работает команда
traceroute: отправляет пакеты сначала с TTL = 1, затем TTL = 2 и так далее и ждет ответов TTL exceeded от каждого промежуточного хоста.

На первый взгляд traceroute представляется таким же простым инструментом, как ping. На самом деле из его вывода тоже можно извлечь больше данных, чем кажется. В то же время там можно увидеть проблему, которой не существует в реальности, а реальные проблемы могут никак не отображаться.

Задержки

Как обычная команда traceroute, так и инструменты вроде MTR весьма популярны для поиска «узких мест» в сети. MTR показывает статистику задержек для каждого хоста на пути.

Однако интерпретация этих данных не так очевидна. Предположим, ты видишь на первом хосте задержку в 20 миллисекунд, а на втором — 950. Не спеши радоваться, что нашел узкое место, и ругать админов той сети. Задержки выдачи ICMP TTL exceeded могут не иметь ничего общего с задержками передачи пакетов.

В нашем сценарии 950 миллисекунд — это именно время, которое прошло от отправки пакета до получения ответа ICMP. Сколько ушло времени на передачу тестового пакета — неизвестно. Сколько ушло на доставку ответа — тоже. Сколько прошло времени между получением пакета и отправкой ответа?

РЕКОМЕНДУЕМ:
Трюки настройки сети в Linux

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

Поэтому сам по себе всплеск задержек в выводе traceroute или MTR ничего не означает. Вот если все задержки на последующих хостах больше 950 миллисекунд, тогда уже есть повод ругаться с админами.

Асимметричные пути, балансировка, MPLS

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

Если сеть провайдера A подключена к сетям B и C каналами с одинаковой пропускной способностью и качеством, будет вполне естественно распределить исходящий трафик по этим каналам. Однако даже если админы провайдера А предпочитают отправлять большую часть трафика через сеть B, над входящим трафиком у них нет почти никакого контроля. Можно искусственно «ухудшить» анонсы маршрутов в сети C, но и в этом случае нет гарантии, что клиенты сети B проводят ту же политику. Вполне возможно, что они как раз предпочитают сеть C.

Предположим, что сеть C на самом деле плохая. Увидим ли мы это в traceroute? Очевидно, нет, поскольку истечение TTL всегда случается на прямом пути, а не на обратном. Никакого способа увидеть полный граф сети не существует.

Еще более интересной ситуацию делает MPLS. Поскольку кадры MPLS инкапсулируют пакеты IP целиком и для сетей на концах LSP он выглядит как прямое физическое соединение, огромная часть внутренней структуры транзитной сети оказывается невидимой.

Эта ситуация делает отладку сложнее не только для пользователей, но и для самих провайдеров, поэтому иногда используют MPLS ICMP tunneling, который позволяет генерировать корректные ответы. Однако, поскольку отправителем пакетов IP выступает последний маршрутизатор в логическом соединении MPLS (до него никакой обработки IP не делается), это будет выглядеть как множество хостов с нулевой задержкой между ними.

Сетевая утилита whois

Предположим, ты нашел проблемную сеть с помощью ping или traceroute или увидел адреса злоумышленников в логах. Как теперь найти, с кем ругаться? Здесь тебе на помощь придет whois.

Чаще всего команду whois используют для получения информации о доменах (
whois example.com). На самом деле в базах данных RIR (Regional Internet Registries — RIPE NCC, ARIN…) существует куда больше типов объектов.

Каждый выделенный ресурс, будь то номер автономной системы или адрес сети, имеет в базе данных свою запись, из которой можно узнать его принадлежность.

К примеру, ты хочешь пожаловаться, что авторы «Хакера» учат молодежь плохому. Можно отрезолвить xakep.ru и выполнить
whois 178.248.232.27. Но ты подозреваешь, что информация о самом адресе не совпадает с информацией о сети хостера. Не страшно, whois понимает и адреса сетей:

Здесь нам сразу показывают abuse contact, но, если его вдруг нет, всегда можно копать дальше и смотреть whois про любое поле. Например,
whois ORG—LA267—RIPE. По правилам, у каждой организации есть abuse contact.

Оттуда же можно извлечь информацию об автономных системах. Просто допиши
AS перед номером. Например, кому принадлежит автономная система 6939?

Как поступать с людьми, которые шлют тебе спам и брутфорсят твои сервисы, — решать тебе, но во многих случаях написать письмо хостеру на abuse contact не будет лишним. Большинству хостеров и провайдеров нарушители закона и порядка ни к чему, так что, если у тебя есть доказательства, вероятность, что сервер нарушителя заблокируют, ненулевая.

Looking glass

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

Они доступны через веб-интерфейс, но иногда и через Telnet/SSH.

Увы, общего способа его найти не существует, и на сайтах провайдеров эти адреса чаще всего не пишут. Тем не менее сам термин настолько стандартный, что запрос $provider looking glass в любой поисковой системе приведет тебя к цели. Например,
https://duckduckgo.com/?q=rostelecom+looking+glass приводит нас к
http://lg.ip.rt.ru.

РЕКОМЕНДУЕМ:
Настройка отказоустойчивой сети в Linux с keepalived

Большинство из них позволяют выполнить ping и traceroute, а самые полные предоставляют еще и информацию о маршрутах BGP и возможность выбора маршрутизаторов из разных регионов.

Заключение

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

(1 оценок, среднее: 5,00 из 5)

Загрузка…

As a network administrator, I occasionally hear the question, “What does it mean when I get an error message that says “Time to Live exceeded”?” People often ask this question when they are having connectivity problems. This error message may appear while using the ping or traceroute command to diagnose one of these problems..

TL;DR

“Time to Live exceeded” is an error message indicating that a data packet has traveled through too many routers on the way to its destination, and has been discarded. This can be caused by temporary ISP problems, misconfigured routers, or an offline destination host.

TTL: A background on IP networks

In an IP packet, the Time to Live (TTL) field is a crucial but sometimes misunderstood topic. It details the most hops a packet is permitted to complete before being rejected. The TTL field is used to ensure that packets are delivered to their intended locations without using excessive amounts of network resources and to prevent packets from circling indefinitely in a network.

The TTL value in the Internet Protocol (IP) is a field in the header of an IP packet that indicates how many hops a packet can make before being rejected. A packet is given a certain TTL value when it is sent, which is often a low number like 64 or 128. The TTL value is decreased by one each time a packet travels through a router. The router discards the packet and notifies the sender that the “Time to Live” limit has been reached when the TTL value drops to zero.

What does the error message “Time to Live exceeded” actually mean?

Generally speaking, it denotes that a data packet was unable to reach its destination within the allowed number of hops. This error most frequently occurs because the BGP routing protocol used by the internet contains inaccurate information about how to reach a particular target network. In this case, it’s likely that router A believes router B is the best router to send the packet to in order to get it closer to the destination, while router B believes router A is the ideal router to send the packet to. This is known as a routing loop. This frequently occurs when the host or destination network is unavailable. In this situation, it is impossible to get to the desired location, and occasionally internet service providers will mistakenly transmit traffic back and forth to one another in the mistaken belief that the other network can still get there.

What to do about it?

The BGP internet routing system may take some time to update in order to reflect the most effective path to a specific network. As a result, transient “routing loops” like the ones mentioned above might happen even when no action is required to fix them; they will go away in a few seconds or minutes. If the issue continues after this, remedial action might be required.

As a result, if you encounter this error notice, there may be an issue with the network or the destination host. You would have to investigate the issue if you were in charge of the destination network. Otherwise, if the issue has persisted for longer than a few minutes, it is recommended to do a MTR test, report the findings to your internet service provider, and request that they fix the issue.

Anyone who uses networks, whether they are network engineers, system administrators, or just regular users of the internet for work, can benefit from understanding the TTL field and how it functions. Understanding this idea and knowing how to address TTL field-related problems will help you make sure that your data gets to where it needs to go and that your network functions properly.

Do You Love Servers?

We do! As a dedicated server hosting company, IOFLOOD is aware of the need of dependable networking. We can assist if you require a dependable connection and a dedicated server. Our team of skilled network engineers is committed to offering premium hosting services and making sure that your data gets to where it needs to go.

Please feel free to contact us at sales[@]ioflood.com if you have any questions regarding our hosting services or networking, or visit our available servers at https://ioflood.com to see what’s available. We are dedicated to offering our clients the finest service possible and are always happy to assist.

About Author

gabe