4

This is a question that bothers me a lot. And I cannot argue with colleagues because all switches I see can response the ping request even my TTL=1.

So my question is, does TTL decrease between interfaces on a switch? For example, I have 192.168.1.1/24 on interface 0/1, 192.168.2.1/24 on interface 0/2 and a loopback interface with 1.1.1.1/32. If I connect my PC on interface 0/1, should I be able to ping interface 0/2 and loopback interface on the switch?

Edit: The switch I mentioned above is actually a router. Sorry for a confusing question.

2

Yes, a TTL value of 1 is sufficient.

According to RFC791 for IPv4 and RFC2460 for IPv6, the TTL value is a decremented by 1 whenever the packet is forwarded by a node. Since the packet is not forwarded when it is passed on to the loopback interface, the TTL is not decremented and a TTL of 1 is sufficient. The IP datagram does not egress on an interface and therefore is not forwarded to another node.

15
  • The loopback is an interface, and the IPv4 TTL is supposed to be decremented by the IP module, by at least 1, before it is forwarded to the loopback. The loopback is on a different network, so the packet is actually routed from the VLAN network to the loopback network. – Ron Maupin Nov 3 '17 at 19:50
  • RFC791 does not say that TTL is decremented when a routing decision is made, only when the IP header is processed, which is a bit vague. All the major vendors (Cisco, HPE, Juniper) do not decrement TTL for local interfaces. – Karl Billington Nov 3 '17 at 21:46
  • @Ron Maupin♦ Yes, the loopback interface is a network interface. But it is not a another hop and the datagram does not leave the current hop. – user2964971 Nov 4 '17 at 6:28
  • @user2964971, yes, it is another hop, and the TTL is decremented, and it drops a packet. Just try it on a Cisco router. Look at the edit to my answer. – Ron Maupin Nov 4 '17 at 6:35
  • @Karl Billington The same RFC literally specifies a time to live. On page 14: The maximum time the datagram is allowed to remain in the internet system.. On page 30: The time is measured in units of seconds. – user2964971 Nov 4 '17 at 6:36
3

TTL is checked on ingress packets and decreased when forwarding (=routing) packets. Accordingly, sending out a packet with TTL=1 will enable it to reach a local destination but it will not be routed.

TTL is a layer 3 (IP) scheme, switches don't decrement it (unless they are routing). The Ethernet frame has no TTL value whatsoever and the IP TTL isn't changed while switching inside a L2 segment.

2
  • Umm I should say the switches I mentioned are actually routers(L3 switches). Anyway, the problem that confuses me is when packet's destination is on same device but has different IPs on different interfaces. Should TTL be decreased in very same device since it's not forwarding it? – Pue-Tsuâ Nov 3 '17 at 5:02
  • 1
    L3 switches only decrease IP TTL when routing. As long as they're switching (same VLAN) it isn't changed. – Zac67 Nov 3 '17 at 5:58
2

Layer-3 devices (routers, PCs, etc.) are supposed to decrease the TTL on IPv4 packets as the network stack processes the packet (see this answer for a full explanation). Most PC OSes do not actually do this, but routers do. The IPv4 TTL is really supposed to reflect the processing time.

On the other hand, layer-2 switches are transparent devices that only look at the frame, which encapsulates the packet. The switches do not know or care about anything in the packet. This lets them carry any type of layer-3 protocol (IPv4, IPX, IPv6, AppleTalk, etc.), even at the same time. You would not, for example, want to replace all your switches when adding or changing to IPv6, which has a different IP header than IPv4.

Your example of a loopback is like a host on a different network, and your packet must be routed to a different network, so the TTL will be decremented. When it reaches 0, the packet will be discarded. Basically, any packet with a TTL of 1 reaching a router will be dropped, unless the packet is for the router interface where it entered the router.

On the other hand, if the switch is using an SVI, the SVI will be on the the same LAN as the source, and the frame is switched at layer-2, so the TTL is never decremented.


Edit:

Here is an example where I pinged the next-hop router VLAN interface, and then I pinged the router Loopback0 interface, with a TTL of 1. I received ICMP replies for every ping attempt, but the pings to the loopback expired in transit:

D:\>ping 198.18.1.1

Pinging 198.18.1.1 with 32 bytes of data:
Reply from 198.18.1.1: bytes=32 time<1ms TTL=128
Reply from 198.18.1.1: bytes=32 time<1ms TTL=128
Reply from 198.18.1.1: bytes=32 time<1ms TTL=128
Reply from 198.18.1.1: bytes=32 time<1ms TTL=128

Ping statistics for 198.18.1.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

D:\>ping -i 1 198.0.0.8

Pinging 198.0.0.8 with 32 bytes of data:
Reply from 198.18.1.1: TTL expired in transit.
Reply from 198.18.1.1: TTL expired in transit.
Reply from 198.18.1.1: TTL expired in transit.
Reply from 198.18.1.1: TTL expired in transit.

Ping statistics for 198.0.0.8:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
17
  • So when a switch is acting as router, TTL is supposed to be decremented when crossing a LAN, even it is on same device, right? I know the fact that TTL will be decremented when crossing multiple IP network and not when inside a LAN (L2). It's just that example is really confusing me. – Pue-Tsuâ Nov 3 '17 at 5:03
  • No. The TTL is decremented as the packet is processed by the network stack. Switches transparently switch frames on the LAN, not looking at the packet. The router module in a layer-3 switch only sees the packet when it strips off the frame as the packet is routed from one network to another network. Think of a layer-3 switch as a separate router and a separate switch put in the same box. A layer-3 switch is first a layer-2 switch. It only routes when a packet is destined for a different network. – Ron Maupin Nov 3 '17 at 11:35
  • I disagree that the TTL would be decremented when routing to loopback, RFC791 only states that the TTL is decremented when the IP header is processed. In reality all the major network vendors do not increment TTL when forwarding to a local interface, only if a packet exits a router. – Karl Billington Nov 3 '17 at 21:48
  • The IP header is processed when the router determines where to send it next. The destination address is examined in order to determine that the packet is sent out the loopback interface. According to the RFC, the TTL should be decremented. In fact, the TTL is supposed to be decremented by the destination host as the packet is processed by the IP module of the destination host before it is passed to the upper-layer protocols. In reality, none of the host OSes actually do this. The point of the TTL is to protect the upper-layer protocols from old data. – Ron Maupin Nov 3 '17 at 22:25
  • Using that logic the router would always drop a packet arriving with a TTL of 1 as it would decrement when examining the header on ingress, and drop. The RFC says when processing, but we can't assume what their definition of processing is as it isn't stated. As I say, in reality all the major router vendors (Cisco, HPE, Juniper) decrement on physical egress only when rewriting the IP header. See the example in my response. I would have to side with their logic as that is how all the equipment I (and most people) work with operates, so that is how TTL processing operates in the real world. – Karl Billington Nov 3 '17 at 23:05
0

As others have commented, IP packets with a TTL of 0 are discarded and the TTL is updated whenever the IP header is processed/rewritten, and usually decremented by 1. In practice, the TTL is decremented whenever a packet exits a router through a physical interface.

To answer your question more specifically, the TTL is decremented only when it egresses the router. In your case, for packets destined for the loopback interface or interface 0/2, the packet does not exit the router, the IP header is not updated, so TTL is not decremented and pings are returned.

Looking at a couple of examples using your topology:

  • Ping from host 192.168.1.50 to 1.1.1.1 or 192.168.2.1: The ping is received by the router on interface 0/1, the TTL is 1 so the packet is accepted, the ping is destined for a local interface so the IP header is not updated and TTL is not decremented, the packet is received by the IP interface (1.1.1.1 or 192.168.2.1). Ping succeeds.

  • Ping from host 192.168.1.50 to 192.168.2.50 (a host on the LAN): The ping is received by the router on interface 0/1, the TTL is 1 so the packet is accepted, a routing decision is made and the packet will be routed out of interface 0/2 to the destination (192.168.2.50), at this stage the IP header is updated, the TTL is decremented and the packet is discarded as the TTL is 0. Ping fails.

In summary, if you connect your PC to interface 0/1, yes, you should be able to ping interface 0/2 or the loopback interface. With the same setup, if you attempted to ping another host on 192.168.2.0/24 (not the router), the ping would fail.

I have set this up with Cisco 7200 routers to prove how this works in real life:

  • PC1 is connected to router interface E1/1 with IP address 192.168.1.50/24
  • PC2 is connected to router interface E1/2 with IP address 192.168.2.50/24
  • Router has IP 192.168.1.1/24 on E1/1
  • Router has IP 192.168.2.1/24 on E1/2
  • Router has loopback address 1.1.1.1/32

First, a ping from PC1 (192.168.1.50) to router E1/2 (192.168.2.1) with TTL of 1 (PING SUCCEEDS):

Router debug output:

*Nov  3 20:55:33.447: IP: s=192.168.1.50 (Ethernet1/1), d=192.168.2.1, len 84, rcvd 0
*Nov  3 20:55:33.451:     ICMP type=8, code=0
*Nov  3 20:55:33.451: ICMP: echo reply sent, src 192.168.2.1, dst 192.168.1.50, topology BASE, dscp 0 topoid 0
*Nov  3 20:55:33.451: FIBipv4-packet-proc: route packet from (local) src 192.168.2.1 dst 192.168.1.50
*Nov  3 20:55:33.451: FIBfwd-proc: packet routed by adj to Ethernet1/1 192.168.1.50
*Nov  3 20:55:33.451: FIBipv4-packet-proc: packet routing succeeded
*Nov  3 20:55:33.451: IP: s=192.168.2.1 (local), d=192.168.1.50 (Ethernet1/1), len 84, sending
*Nov  3 20:55:33.451:     ICMP type=0, code=0
R2#
*Nov  3 20:55:33.451: IP: s=192.168.2.1 (local), d=192.168.1.50 (Ethernet1/1), len 84, sending full packet
*Nov  3 20:55:33.455:     ICMP type=0, code=0
*Nov  3 20:55:33.455: IP: s=192.168.1.50 (Ethernet1/1), d=192.168.2.1, len 84, input feature
*Nov  3 20:55:33.455:     ICMP type=8, code=0, packet consumed, MCI Check(88), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
  • Router receives IP packet 192.168.1.50 -> 192.168.2.1
  • Router does not route the packet this is a local interface, packet will not exit router
  • Router creates an ICMP Echo Reply from 192.168.2.1 -> 192.168.1.50
  • Router routes the reply and sends out of interface E1/1

Second, a ping from PC1 (192.168.1.50) to PC2 (192.168.2.50) with TTL of 1 (PING FAILS):

Router debug output:

*Nov  3 20:57:23.419: FIBipv4-packet-proc: route packet from Ethernet1/1 src 192.168.1.50 dst 192.168.2.50
*Nov  3 20:57:23.419: FIBfwd-proc: packet routed by adj to Ethernet1/2 192.168.2.50
*Nov  3 20:57:23.419: FIBipv4-packet-proc: packet routing succeeded
*Nov  3 20:57:23.419: ICMP: time exceeded (time to live) sent to 192.168.1.50 (dest was 192.168.2.50), topology BASE, dscp 0 topoid 0
*Nov  3 20:57:23.419: FIBipv4-packet-proc: route packet from (local) src 192.168.1.1 dst 192.168.1.50
*Nov  3 20:57:23.419: FIBfwd-proc: packet routed by adj to Ethernet1/1 192.168.1.50
*Nov  3 20:57:23.419: FIBipv4-packet-proc: packet routing succeeded
R2#
*Nov  3 20:57:23.419: IP: s=192.168.1.1 (local), d=192.168.1.50 (Ethernet1/1), len 56, sending
*Nov  3 20:57:23.419:     ICMP type=11, code=0
*Nov  3 20:57:23.419: IP: s=192.168.1.1 (local), d=192.168.1.50 (Ethernet1/1), len 56, sending full packet
*Nov  3 20:57:23.419:     ICMP type=11, code=0
*Nov  3 20:57:23.419: IP: s=192.168.1.50 (Ethernet1/1), d=192.168.2.50, len 84, input feature
*Nov  3 20:57:23.419:     ICMP type=8, code=0, packet consumed, MCI Check(88), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
  • Router routes the packet from E1/1 to E1/2
  • TTL is decremented to 0, time exceeded, packed discarded
  • Router sends ICMP TTL exceeded to packet source
  • ICMP packet is routed out of E1/1 to PC1
2
  • Does the IP header is processed include a switch that applies an IP ACL on a switched port? – user2964971 Nov 4 '17 at 6:47
  • I guess it could do according to the definition as technically that could be classed as processing, but in practice vendors don’t touch the TTL when it isn’t being L3 forwarded – Karl Billington Nov 4 '17 at 13:52

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.