Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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!

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

1 Answer 1

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

 
discard

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.