Summary: TTL is not decremented when pinging hosts on a "network path"

My laptop ( is connected via OpenVPN to a server ( which hosts several network interfaces. One of them is, the gateway to the network. is one host on that network.

The path from the laptop to is

>tracert -d

Tracing route to over a maximum of 30 hops

  1    34 ms    32 ms    32 ms
  2    83 ms    34 ms    35 ms

I am now looking at TTLs when pinging the various interfaces, from my laptop up to the far remote host.

Reply from bytes=32 time<1ms TTL=128

Reply from bytes=32 time=37ms TTL=244

Reply from bytes=32 time=30ms TTL=64

Reply from bytes=32 time=29ms TTL=63

I thought that the TTL is expected to be decremented on each hop - which is not the case above. It starts with 128, jumps to 244, then 64 and 63. What can be the reason for this?

More detailed information about the setup: the test is done from Windows 10 (, a hardware NIC), connected via OpenVPN to an Ubuntu 15.10 with several interfaces (, a TUN and, a hardware NIC). The target device is a RPi running Raspbian (~Debian - with a WiFi NIC).


The hop limit (or TTL) is decreased at each hop (unless something in your network is seriously broken). The values you are seeing are not from the packets you are sending, but rather from the replies you are receiving.

As you send packets onto the network, the hop limit will decrease at each hop until it reaches the destination. If the destination replies to your request the reply will be a new packet with a new hop limit to be decreasing.

The initial hop limit is chosen by the system generating the packet. Some of the common values for the initial value are 64 and 255. In some rare cases you will see systems copy the remaining hop limit from the request to the reply.

The different values you see are simply due to the systems you ping being configured differently.

| improve this answer | |
  • Thank you. It is now obvious, as they are echo replies (so new packets). Is there a way to check the TTL along the trip of the packet? (I wonder if this is not in essence the traceroute command) – WoJ Mar 30 '16 at 18:00
  • @WoJ Unless you can log in on the routers along the path, you cannot see the hop limit decreasing. If a hop was actually increasing the value as it forwards the packet, it would cause the following hops to be "invisible" to your traceroute. But increasing the value on a forwarded packet is risky as it can cause the network to break down in case of a routing loop. – kasperd Mar 30 '16 at 18:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.