Time to live exceeded ping error
Every packet of data that is sent out includes a TTL value within the IP packet header. This refers to the number of hops data can go through before it is discarded. Based on network traffic between hosts, it is possible to predict what OS is running on a system. Every operating system has its own unique way to implement the TCP/IP stack. A very simple but effective passive method is to inspect the initial time-to-live (TTL) in the IP header:
“Time to live exceeded” this ICMP ping error is due to the time to live (TTL) field reaching a zero value or there is a timeout for the reassembly of segments. As a solution, I will recommend increasing the TTL (Time To Live) value (the highest is 255).
Solution
For example, run traceroute to ipaddress 8.8.8.8 (Google’s publc DNS server). And find number of hops to the destination.
[root@server ~]# traceroute 8.8.8.8 (in linux distro) C:\>tracert 8.8.8.8 (in Windows OS)
For me its 6 hops to 8.8.8.8. So a minimum TTL value of 6 is required to reach icmp packets to 8.8.8.8 and get ping replay. And cannot ping to 8.8.8.8 with a TTL value of 5 or less.
Ping Results with different TTL values:
[root@server ~]# ping 8.8.8.8 -t 5 (-t 5 is for custom TTL value of 5) PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. From 192.168.1.1 icmp_seq=1 Time to live exceeded From 192.168.1.1 icmp_seq=2 Time to live exceeded From 192.168.1.1 icmp_seq=3 Time to live exceeded From 192.168.1.1 icmp_seq=4 Time to live exceeded
# ping 8.8.8.8 -t 6 (-t 6 is for custom TTL value of 6) PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_req=1 ttl=55 time=48.9 ms 64 bytes from 8.8.8.8: icmp_req=2 ttl=55 time=49.5 ms 64 bytes from 8.8.8.8: icmp_req=3 ttl=55 time=50.4 ms 64 bytes from 8.8.8.8: icmp_req=4 ttl=55 time=49.4 ms
Time to live exceeded, result after pinging the gateway from host in one subnet
I got a server with XenServer 6.0.2 and this server has 3 nic with 3 different ip addresses, because I am using 3 different subnet The first 2 card are working and from the first 2 subnet I have access to internet, the third one is the problem. Basically the hosts in the last subnet can ping each and other but I if try to ping the gateway I got
Destination Host Unreachable
and is not finished here. Trying to ping the gateway outside the subnet I got
PING 87.117.221.17 (87.117.221.17) 56(84) bytes of data. From 87.117.211.46 icmp_seq=1 Time to live exceeded What does it means? I saw the configuration of each host in the 3rd subnet and the nic interfaces is setup to use the 3rd card. Every host in the 3rd subnet has in the /etc/network/interfaces the right ip addresss for the gateway. Any thoughts?
Time to live exceeded что такое
Часовой пояс: UTC + 3 часа
Wireshark и Time To Live Exceeded In Transit — DGS-3610
Заголовок сообщения: Wireshark и Time To Live Exceeded In Transit — DGS-3610
Добавлено: Ср сен 28, 2011 10:17
Добрый день! Помогите. Для выявления проблемы использовал wireshark. Пациенты DGS-3610 (ядро сети) и соединенный по лацпу стек из 3-x DGS-3627G и 1-го DGS-3650. Имеем проблему описанную в шапке. Сидит абонент имеет например ип 172.28.8.222 и свой мас адрес. У него работают локальный ресурсы я его вижу на ядре сети sh arp | include 172.28.8.222. Его пингую без проблем. Но есть проблема сервер который тоже воткнут в DGS-3610 — 172.28.200.5 не пингуется от этого абонента. А остальные пингуют его с этой же сети. Проблема проявляется у некоторых. Снифер от проблемных показывает Time To Live Exceeded In Transit. Прочел описание этой проблемы здесь http://ust-pro.ru/Soobshhenija_tipa_Tim . index.html . Получается что когда пакет начинает прилетать к устройству абонента TTL = 0??
Снял пока маршрут на эту машину чтобы пользователи бежали через другие машины.
P.S. С этим столкнулся когда 1 день назад поставили в стек из DGS-3627G 2 юнит на замен сгоревшему 2 юниту. В стек был воткнут по меди Traffic inspector сервер. И картина была та же самая часть абонентов не пинговала Traffic inspector на Traffic inspector была arp запись этого компьютера но пинги не приходили ни со стороны сервера ни со стороны абонента а остальная сеть была для них доступна. Перенесли линки сервера на 3610 все заработало. Я сейчас с настройками абонента (ип и мак) мой линк в стеке не пингую 172.28.200.5. Ставлю другой ип из этой сети и все работает. Втыкаю линк в 3610 с настройками ипа и мака абонента и все начинает работать. Втыкаю в стек не работает. Wireshark показывает когда мой линк в стеке —Time To Live Exceeded In Transit. Очиститил таблицу FDB результата не дало. Перезагружу в обед его.
Дайте совета что это за явление. Впервые столкнулся с этим. Да и вот
-
DGS-3627G Gigabit Ethernet Switch
Command Line Interface
Firmware: Build 2.84.B18
Copyright(C) 2010 D-Link Corporation. All rights reserved.
DGS-3627G:admin#show switch
Command: show switch
Заголовок сообщения: Re: Wireshark и Time To Live Exceeded In Transit — DGS-3610
Добавлено: Ср сен 28, 2011 12:03
Никаких идей?
Заголовок сообщения: Re: Wireshark и Time To Live Exceeded In Transit — DGS-3610
Добавлено: Ср сен 28, 2011 13:27
TTL Exceeded означает, что у Вас какие-то проблемы с маршрутизацией и получается L3 петля.
Попробуйте запустить traceroute и посмотреть в каком именно месте возникает петля.
Заголовок сообщения: Re: Wireshark и Time To Live Exceeded In Transit — DGS-3610
Добавлено: Ср сен 28, 2011 14:06
Да Александр мы недавно запустили OSPF. Прокомментируйте где ошибка. Связка такая Сервера — 3610- 3627G и далее оборудование. Вот кусок с DGS-3610
Скрытый текст: показать
router ospf 1111
router-id 172.16.16.1
log-adj-changes detail
network 172.16.16.0 0.0.0.31 area 1
network 172.20.0.0 0.0.0.255 area 0
network 172.20.1.0 0.0.0.255 area 0
network 172.20.2.0 0.0.0.255 area 0
network 172.20.3.0 0.0.0.255 area 0
network 172.20.4.0 0.0.0.255 area 0
network 172.20.5.0 0.0.0.255 area 0
network 172.20.6.0 0.0.0.255 area 0
network 172.20.7.0 0.0.0.255 area 0
network 172.20.8.0 0.0.0.255 area 0
network 172.20.9.0 0.0.0.255 area 0
network 172.20.10.0 0.0.0.255 area 0
network 172.20.251.0 0.0.0.255 area 0
network 172.20.254.0 0.0.0.255 area 0
network 172.28.1.0 0.0.0.255 area 0
network 172.28.2.0 0.0.0.255 area 0
network 172.28.3.0 0.0.0.255 area 0
network 172.28.4.0 0.0.0.255 area 0
network 172.28.5.0 0.0.0.255 area 0
network 172.28.6.0 0.0.0.255 area 0
network 172.28.7.0 0.0.0.255 area 0
network 172.28.8.0 0.0.0.255 area 0
network 172.28.9.0 0.0.0.255 area 0
network 172.28.10.0 0.0.0.255 area 0
network 172.28.11.0 0.0.0.255 area 0
network 172.28.12.0 0.0.0.255 area 0
network 172.28.13.0 0.0.0.255 area 0
network 172.28.14.0 0.0.0.255 area 0
network 172.28.15.0 0.0.0.255 area 0
network 172.28.16.0 0.0.0.255 area 0
network 172.28.28.0 0.0.0.255 area 0
network 172.28.100.0 0.0.0.255 area 0
network 172.28.200.0 0.0.0.255 area 0
!
!
!
ip route 0.0.0.0 0.0.0.0 172.28.200.6
ip route 0.0.0.0 0.0.0.0 172.28.200.7
ip route 0.0.0.0 0.0.0.0 172.28.200.5
К 3610 подключен 3627G
Вот с него выводы
Скрытый текст: показать
DGS-3627G:admin#show ospf all
Command: show ospf all
Interface Name: System IP Address: 172.16.16.2/27 (Link Up)
Network Medium Type: BROADCAST Metric: 1
Area ID: 0.0.0.1 Administrative State: Enabled
Priority: 1 DR State: OTHER
DR Address: 172.16.16.8 Backup DR Address: 172.16.16.9
Hello Interval: 10 Dead Interval: 40
Transmit Delay: 1 Retransmit Time: 5
Authentication: None
Interface Name: For_Access IP Address: 172.16.20.1/23 (Link Up)
Network Medium Type: BROADCAST Metric: 1
Area ID: 0.0.0.1 Administrative State: Enabled
Priority: 1 DR State: DR
DR Address: 172.16.20.1 Backup DR Address: None
Hello Interval: 10 Dead Interval: 40
Transmit Delay: 1 Retransmit Time: 5
Authentication: None
Total Entries : 2
DGS-3627G:admin#show ospf neighbor
Command: show ospf neighbor
IP Address of Router ID of Neighbor Neighbor
Neighbor Neighbor Priority State
————— ————— ——— ————-
172.16.16.1 172.16.16.1 1 2-Way
172.16.16.3 172.16.16.3 1 2-Way
172.16.16.4 172.16.16.4 1 2-Way
172.16.16.5 172.16.16.5 1 2-Way
172.16.16.6 172.16.16.6 1 2-Way
172.16.16.7 172.16.16.7 1 2-Way
172.16.16.8 172.16.16.8 1 Full
172.16.16.9 172.16.16.9 1 Full
Total Entries : 8
DGS-3627G:admin#show iproute
Command: show iproute
IP Address/Netmask Gateway Interface Cost Protocol
—————— ————— ———— ——— ———
0.0.0.0/0 172.16.16.1 System 1 Default
172.16.16.0/27 0.0.0.0 System 1 Local
172.16.20.0/23 0.0.0.0 For_Access 1 Local
172.20.0.0/24 172.16.16.1 System 2 OSPF
172.20.1.0/24 172.16.16.1 System 2 OSPF
172.20.2.0/24 172.16.16.1 System 2 OSPF
172.20.3.0/24 172.16.16.1 System 2 OSPF
172.20.4.0/24 172.16.16.1 System 2 OSPF
172.20.5.0/24 172.16.16.1 System 2 OSPF
172.20.6.0/24 172.16.16.1 System 2 OSPF
172.20.7.0/24 172.16.16.1 System 2 OSPF
172.20.8.0/24 172.16.16.1 System 2 OSPF
172.20.9.0/24 172.16.16.1 System 2 OSPF
172.20.10.0/24 172.16.16.1 System 2 OSPF
172.20.251.0/24 172.16.16.1 System 2 OSPF
172.20.254.0/24 172.16.16.1 System 2 OSPF
172.28.1.0/24 172.16.16.1 System 2 OSPF
172.28.2.0/24 172.16.16.1 System 2 OSPF
172.28.3.0/24 172.16.16.1 System 2 OSPF
172.28.4.0/24 172.16.16.1 System 2 OSPF
172.28.5.0/24 172.16.16.1 System 2 OSPF
172.28.6.0/24 172.16.16.1 System 2 OSPF
172.28.7.0/24 172.16.16.1 System 2 OSPF
172.28.8.0/24 172.16.16.1 System 2 OSPF
172.28.9.0/24 172.16.16.1 System 2 OSPF
172.28.10.0/24 172.16.16.1 System 2 OSPF
172.28.11.0/24 172.16.16.1 System 2 OSPF
172.28.12.0/24 172.16.16.1 System 2 OSPF
172.28.13.0/24 172.16.16.1 System 2 OSPF
172.28.14.0/24 172.16.16.1 System 2 OSPF
172.28.15.0/24 172.16.16.1 System 2 OSPF
172.28.16.0/24 172.16.16.1 System 2 OSPF
172.28.28.0/24 172.16.16.1 System 2 OSPF
172.28.100.0/24 172.16.16.1 System 2 OSPF
172.28.200.0/24 172.16.16.1 System 2 OSPF
Total Entries : 35
Я хочу чтобы сети которые в area 0 не были видны на 3627G. Как отфильтровать это? Area 0 используется для серверов с quagga. Area 1 это для оборудования.
Tracert от абонента показал
1 хоп шлюз абонента
2 хоп непосредственно 172.28.200.5 (эта машина пускает в инет) и все далее ничего. Вся остальная локалка работает нормально. Перезагрузили сервер заработало.
Абоненты на DES-3526 подключены в 3627G непосредственно.
What does “Time to Live Exceeded” mean? TTL Explained
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 What is Time To Live Exceeded?
“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.
Table of Contents
- TTL: A background on IP networks
- What does the error message “Time to Live exceeded” actually mean?
- What to do about it?
- Do You Love Servers?
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
Gabriel Ramuglia
Gabriel is the owner and founder of IOFLOOD.com, an unmanaged dedicated server hosting company operating since 2010. Gabriel loves all things servers, bandwidth, and computer programming and enjoys sharing his experience on these topics with readers of the IOFLOOD blog.