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.