Cisco – Why Cisco Discards TTL=1 Packets for Own Interface

ciscoipv4protocol-theory

There have been a number of questions about router behaviour with IPv4 packets with TTL=1 and apparently contradictory answers. This question is not about what should a host or router do, it is a practical question about what equipment does in the field.

Question: In IPv4, can we find a models/configuration of Cisco router or other manufacturer where the router discards a TTL=1 packet as expired when the packet has a destination address which is one of the addresses of an interface of that router?

My belief has been that a router will reply identically to packets for any of its IP addresses (ACLs permitting), and so far this has been confirmed by my experiments with the equipment I have easily available. But it is contradicted by Ron Maupin's experiment here https://networkengineering.stackexchange.com/a/45421

  • Behaviour 1 is that end point router decrements TTL to cross from near to far interface
  • Behaviour 2 is that end point router does not decrement TTL to cross from near to far interface

I have only been able to find routers with Behaviour 2. 

          MINIMAL                NON-MINIMAL

           =+=               +---R2---R3--...--+
            |Afar            |                 |Anear
            R                R1                Rn
            |Anear           |                 |Afar
    ===+====+====     ===+===+====           ==+==
       |                 |
       H                 H
   Anear = address of interface nearest H
   Afar  = address of interface not nearest H

EXPERIMENT 1: MINIMAL, PACKETS SENT WITH TTL=1

This experiment is intended to be essential identical to Ron Maupin's in his answer https://networkengineering.stackexchange.com/a/45421

We find that packets with TTL=1 reach near and far interfaces.

  • H is Ubuntu 192.168.0.210/24, default route to 192.168.0.1
  • R is Cisco 867VAE with Version 15.2(4)M3 nearside is vlan0 192.168.0.1/24, farside is loopback0=10.0.0.1/24

Ping nearside

$ ping -t 1 -c 1 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=1.72 ms

tcpdump on H shows packets leaving with TTL=1, answers returning

17:43:52.960574 IP (tos 0x0, ttl 1, id 11971, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.210 > 192.168.0.1: ICMP echo request, id 10823, seq 1, length 64
17:43:52.962266 IP (tos 0x0, ttl 255, id 11971, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.1 > 192.168.0.210: ICMP echo reply, id 10823, seq 1, length 64

Ping farside

$ ping -t 1 -c 1 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=255 time=1.27 ms

tcpdump on H shows packets with TTL=1 and answers returning

17:44:32.094832 IP (tos 0x0, ttl 1, id 8632, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.210 > 10.0.0.1: ICMP echo request, id 10830, seq 1, length 64
17:44:32.096070 IP (tos 0x0, ttl 255, id 8632, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.0.1 > 192.168.0.210: ICMP echo reply, id 10830, seq 1, length 64

EXPERIMENT 2: NON-MINIMAL

This is intended to be the same, but the interfaces are all physical and TTL is sent to be just enough to reach the router. We find that TTL=2 fails on near and far interfaces and TTL=3 succeeds on near and far interfaces.

  • H is Ubuntu on 192.168.0.210/24
  • Rn is Cisco 2811 15.1(4)M10 with nearside FastEthernet0/0 on 172.30.20.251/24 and farside FastEthernet0/1 on 172.31.20.254/24

Results are the same for TTL=2 (both fail) and TTL=3 (both succeed) for nearside and farside addresses. 

$ ping -t 2 -c 1 172.30.20.251 | fgrep -i From
From 192.168.253.254 icmp_seq=1 Time to live exceeded
$ ping -t 2 -c 1 172.31.20.254 | fgrep -i From
From 192.168.253.254 icmp_seq=1 Time to live exceeded
$ ping -t 3 -c 1 172.30.20.251 | fgrep -i From
64 bytes from 172.30.20.251: icmp_seq=1 ttl=252 time=49.2 ms
$ ping -t 3 -c 1 172.31.20.254 | fgrep -i From
64 bytes from 172.31.20.254: icmp_seq=1 ttl=252 time=49.1 ms

These are the tcpdumps from H:

With TTL=2, packets leave and time exceeded returns

Near

18:31:23.098358 IP (tos 0x0, ttl 2, id 38235, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.210 > 172.30.20.251: ICMP echo request, id 11423, seq 1, length 64
18:31:23.146825 IP (tos 0xc0, ttl 253, id 36603, offset 0, flags [none], proto ICMP (1), length 56)
    192.168.253.254 > 192.168.0.210: ICMP time exceeded in-transit, length 36
    IP (tos 0x0, ttl 1, id 38235, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.210 > 172.30.20.251: ICMP echo request, id 11423, seq 1, length 64

Far

18:31:23.152807 IP (tos 0x0, ttl 2, id 61977, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.210 > 172.31.20.254: ICMP echo request, id 11425, seq 1, length 64
18:31:23.201199 IP (tos 0xc0, ttl 253, id 36606, offset 0, flags [none], proto ICMP (1), length 56)
    192.168.253.254 > 192.168.0.210: ICMP time exceeded in-transit, length 36
    IP (tos 0x0, ttl 1, id 61977, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.210 > 172.31.20.254: ICMP echo request, id 11425, seq 1, length 64

With TTL=3, ICMP echo and response for both nearside and farside addresses

Nearside:

18:31:23.211459 IP (tos 0x0, ttl 3, id 38260, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.210 > 172.30.20.251: ICMP echo request, id 11427, seq 1, length 64
18:31:23.259514 IP (tos 0x0, ttl 252, id 38260, offset 0, flags [DF], proto ICMP (1), length 84)
    172.30.20.251 > 192.168.0.210: ICMP echo reply, id 11427, seq 1, length 64

Farside

18:31:23.268194 IP (tos 0x0, ttl 3, id 61985, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.210 > 172.31.20.254: ICMP echo request, id 11429, seq 1, length 64
18:31:23.316748 IP (tos 0x0, ttl 252, id 61985, offset 0, flags [DF], proto ICMP (1), length 84)
    172.31.20.254 > 192.168.0.210: ICMP echo reply, id 11429, seq 1, length 64

Best Answer

It appears that different routing devices do this differently, and this answer details only a single case. The discussion in comments about varying behaviour, and that in IPv6, is very helpful. The following is not to be taken as a definitive answer to my general question.

Test procedure with packet capture on router

A router Cisco 867VAE-K9 with 15.2(4)M3 has a number of local interfaces, and a test computer connected on the far side of Virtual-PPP1. We will ping the near interface and two far interfaces, one vlan, one loopback.

We do it across a multi-hop network so that we can see that a change in the TTL of the sent pings results in success or failure of the packets arriving on the router and the ping responses, in order to discount any other configuration issues such as ACLs, routes.

Pings are sent from H to GW and require TTL=3 to arrive. TTL=2 packets do not arrive and are expired by R255 (with ICMP time exceeded messages).

                       R255
                  .255/  \.255
 tunnels in          /    \
 192.168.253/24   .8/      \.0 on Virtual-PPP1
                  R8        GW---| 10.0.0.1 on Loopback0
  192.168.8/24    |.1       |.1 on Vlan1
       ======+====+==     ==+===
             |.192
             H

Interfaces

gw#show ip int b
Interface                  IP-Address      OK? Method Status                Protocol
Loopback0                  10.0.0.1        YES NVRAM  up                    up      
Virtual-PPP1               192.168.253.0   YES IPCP   up                    up      
Vlan1                      192.168.0.1     YES NVRAM  up                    up

Access list for the packet capture

gw#show access-list 111
Extended IP access list 111
    10 permit ip host 192.168.8.192 any
    20 permit ip any host 192.168.8.192

Packet capture

gw#monitor capture buffer BUF1
gw#monitor capture buffer BUF1 max-size 2000 
gw#monitor capture buffer BUF1 filter access-list 111
Filter Association succeeded
gw#monitor capture point ip process-switched POINT1 both
gw#monitor capture point associate POINT1 BUF1
gw#monitor capture buffer BUF1 clear
gw#monitor capture point start POINT1

On far computer, these all fail (and will not show in the packet capture on gw)

ping -c 1 -t 2 192.168.0.1
ping -c 1 -t 2 10.0.0.1
ping -c 1 -t 2 192.168.253.0

On far computer, these all succeed (and will all show in the packet capture)

ping -c 1 -t 3 192.168.0.1
ping -c 1 -t 3 10.0.0.1
ping -c 1 -t 3 192.168.253.0

Finish capture and export PCAP file

gw#monitor capture point stop POINT1 
gw#monitor capture buffer BUF1 export tftp://192.168.0.32/ping.pcap

Capture shows packets arriving with TTL=1 and responses sent, equally for near and far interfaces.

$ tcpdump -nv -r ping.pcap 
reading from file ping.pcap, link-type RAW (Raw IP)
20:14:18.328670 IP (tos 0x0, ttl 1, id 20579, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.8.192 > 192.168.0.1: ICMP echo request, id 25603, seq 1, length 64
20:14:18.328670 IP (tos 0x0, ttl 255, id 20579, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.1 > 192.168.8.192: ICMP echo reply, id 25603, seq 1, length 64
20:14:18.556668 IP (tos 0x0, ttl 1, id 46061, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.8.192 > 10.0.0.1: ICMP echo request, id 25604, seq 1, length 64
20:14:18.556668 IP (tos 0x0, ttl 255, id 46061, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.0.1 > 192.168.8.192: ICMP echo reply, id 25604, seq 1, length 64
20:14:18.780667 IP (tos 0x0, ttl 1, id 38504, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.8.192 > 192.168.253.0: ICMP echo request, id 25605, seq 1, length 64
20:14:18.780667 IP (tos 0x0, ttl 255, id 38504, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.253.0 > 192.168.8.192: ICMP echo reply, id 25605, seq 1, length 64

Conclusion

We see the TTL=1 ECHO REQUEST packets arrive and then the ECHO REPLY packets leave, for near and far interfaces.

Therefore we conclude Cisco routers do not decrement TTL to reach, but not exit, a different interface than the ingress interface of an IPv4 packet.

Related Topic