Should I expect ICMP transit traffic to show up when using debug ip packet with a mask on a Cisco IOS router?

Question

So I am trying to trace an ICMP conversation between 192.168.100.230/32 an EZVPN interface (Virtual-Access 3) and 192.168.100.20 on BVI4.

# sh ip access-lists 199

  10 permit icmp 192.168.100.0 0.0.0.255 host 192.168.100.20
  20 permit icmp host 192.168.100.20 192.168.100.0 0.0.0.255

# sh debug

  Generic IP:
    IP packet debugging is on for access list 199

# sh ip route | incl 192.168.100

    192.168.100.0/24 is variably subnetted, 2 subnets, 2 masks
C       192.168.100.0/24 is directly connected, BVI4
S       192.168.100.230/32 [1/0] via x.x.x.x, Virtual-Access3

# sh log | inc Buff
  Buffer logging:  level debugging, 2145 messages logged, xml disabled,
  Log Buffer (16384 bytes):

OK, so from my EZVPN client with IP address 192.168.100.230, I ping 192.168.100.20. I know the packet reaches the router across the VPN tunnel, because:

policy exists on zp vpn-to-in
 Zone-pair: vpn-to-in

  Service-policy inspect : acl-based-policy

   Class-map: desired-traffic (match-all)
      Match: access-group name my-acl

   Inspect

      Number of Half-open Sessions = 1
      Half-open Sessions
        Session 84DB9D60 (192.168.100.230:8)=>(192.168.100.20:0) icmp SIS_OPENING
          Created 00:00:05, Last heard 00:00:00
          ECHO request
          Bytes sent (initiator:responder) [64:0]


   Class-map: class-default (match-any)
     Match: any
     Drop
       176 packets, 12961 bytes

But I get no debug log, and the debugging ACL hasn't matched:

# sh log | inc IP:
#

# sh ip access-lists 198

Extended IP access list 198
10 permit icmp 192.168.100.0 0.0.0.255 host 192.168.100.20
20 permit icmp host 192.168.100.20 192.168.100.0 0.0.0.255

Am I going crazy, or should I not expect to see this debug log?

Thanks!

Answer 1

Yes, it is possible to debug transit traffic. However, it will only show up in the debug it it is 'routed in software'. Traffic to/from the router itself automatically qualifies, but transit traffic is usually 'process switched' using 'fast switching' or 'Cisco Express Forwarding' and is never handled by the router CPU.

In order to force it to be shown in a debug, it is necesary to disable fast-switching, using 'no ip route-cache' and/or 'no ip route-cache cef' in interface configuration mode.

See How to Verify Cisco Express Forwarding Switching