Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

# sh ip access-lists 199

  10 permit icmp host
  20 permit icmp host

# sh debug

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

# sh ip route | incl 192.168.100 is variably subnetted, 2 subnets, 2 masks
C is directly connected, BVI4
S [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, I ping 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


      Number of Half-open Sessions = 1
      Half-open Sessions
        Session 84DB9D60 (>( 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
       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 host
20 permit icmp host

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


share|improve this question
The reason I'm trying to trace the packet is that I never get any traffic back through the zone-pair - it never progresses beyond half-open, for any traffic, to any internal address. The only packets the EZVPN client receives are arp packets. I have more success debugging TCP traffic (I can see the debugging ACL get hit), but not enough (only the replies get logged). And even then, when debug ip packet shows that it's delivering the full packet to virtual-access 3, nothing shows up on the client end. – David Bullock Jul 21 '11 at 2:15
up vote 1 down vote accepted

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

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.