**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.