10-10-2012 10:10 AM - edited 03-04-2019 05:49 PM
I have an issue that looks to be cef related.
Design is essentially a private L2 cloud to multiple customers. Head end router then creates an encrypted tunnel via a virtual template, and vrf lite.
Design runs smooth on a 3945 but with about 10 meg sustained I noticed about 30% cpu utilization for the ip input process alone.
After doing some checking I believe it is all related to packets being process switched instead of CEF due to unsupported features.
I'm trying to deterine if that is the case, and if so, what the unsupported feature may be so I can fix the design.
some relevent information -
Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version 15.0(1)M4, REL
System image file is "flash0:c3900-universalk9-mz.SPA.150-1.M4.bin"
"sh cef drop" -
IPv4 CEF Drop Statistics
Slot Encap_fail Unresolved Unsupported No_route No_adj ChkSum_Err
RP 0 0 2798289680 99 0 0
*** Interface Template and an associated virtual access interface
interface Virtual-Template1 type tunnel
ip vrf forwarding BLUE
ip unnumbered Loopback1
ip access-group vrf_traffic_filter_2 in
load-interval 30
tunnel source Loopback0
tunnel mode ipsec ipv4
tunnel protection ipsec profile P1
!
service-policy output mpls-shape
end
interface Virtual-Access3
ip unnumbered Loopback1
ip access-group vrf_traffic_filter_2 in
load-interval 30
tunnel source Loopback0
tunnel mode ipsec ipv4
tunnel destination 172.16.3.49
tunnel protection ipsec profile P1
no tunnel protection ipsec initiate
!
service-policy output mpls-shape
end
MPLS-HE#sh int Virtual-Access3
Virtual-Access3 is up, line protocol is up
Hardware is Virtual Access interface
Interface is unnumbered. Using address of Loopback1 (172.16.2.1)
MTU 17888 bytes, BW 100000 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL
CDMA vaccess, cloned from Virtual-Template1
Vaccess status 0x4, loopback not set
Keepalive not set
Tunnel source 192.168.22.201 (Loopback0), destination 172.16.3.49
Tunnel Subblocks:
src-track:
Virtual-Access3 source tracking subblock associated with Loopback0
Set of tunnels with source Loopback0, 27 members (includes iterators), on interface <OK>
Tunnel protocol/transport IPSEC/IP
Tunnel TTL 255
Tunnel transport MTU 1448 bytes
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Tunnel protection via IPSec (profile "P1")
Last input never, output never, output hang never
Last clearing of "show interface" counters 2w1d
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
30 second input rate 25000 bits/sec, 60 packets/sec
30 second output rate 222000 bits/sec, 61 packets/sec
30488660 packets input, 2061222615 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
29446885 packets output, 11700198786 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
MPLS-HE#
MPLS-HE#sh cef int virtual-access 3
Virtual-Access3 is up (if_number 19)
Corresponding hwidb fast_if_number 19
Corresponding hwidb firstsw->if_number 19
Internet address is 0.0.0.0/0
Unnumbered interface. Using address of Loopback1 (172.16.2.1)
ICMP redirects are never sent
Per packet load-sharing is disabled
IP unicast RPF check is disabled
Input features: Access List
Output features: CCE Post NAT Classification, AF Policing, Post-Ingress-NetFlow
Post encapsulation features: IPSEC Post-encap output classification
IP policy routing is disabled
BGP based policy accounting on input is disabled
BGP based policy accounting on output is disabled
Interface is marked as point to point interface
Interface is marked as tunnel interface
Hardware idb is Virtual-Access3
Fast switching type 14, interface type 21
IP CEF switching enabled
IP CEF switching turbo vector
IP Null turbo vector
VPN Forwarding table "BLUE"
IP prefix lookup IPv4 mtrie 8-8-8-8 optimized
Input fast flags 0x21, Output fast flags 0x4008
ifindex 22(22)
Slot Slot unit 3 VC -1
IP MTU 1448
Real output interface is GigabitEthernet0/1
MPLS-HE#
Truncated cef information from the vrf :
MPLS-HE#sh ip cef vrf BLUE
Prefix Next Hop Interface
10.160.49.0/24 172.16.2.49 Virtual-Access3
172.16.2.49/32 172.16.2.49 Virtual-Access3
192.168.1.128/25 10.95.0.1 GigabitEthernet0/0
10.95.0.9 GigabitEthernet0/2
192.168.1.240/28 10.95.0.1 GigabitEthernet0/0
10.95.0.9 GigabitEthernet0/2
172.16.2.1/32 receive Loopback1
10.95.0.9 GigabitEthernet0/2
192.168.190.0/24 10.95.0.1 GigabitEthernet0/0
10.95.0.9 GigabitEthernet0/2
MPLS-HE#
I have the design running in a test lab (2900 instead of 3900) so I can test.
So far, I have tested by removing the tunnel, and placing all interfaces into the same vrf. In that case the cef unsupported drops no longer increments.
Can anyone provide and ideas what I should look at, and/or a link to unsupported features in cef?
10-10-2012 12:50 PM
Can you check "show ip cef switching statistics feature" output too? I am hoping it would give some info on why the packets are punted. If this is a test setup try "debug ip cef drops".
10-10-2012 01:58 PM
From the production device:
MPLS-HE#sh ip cef switching statistics feature
IPv4 CEF input features:
Feature Drop Consume Punt Punt2Host Gave route
Access List 0 0 0 24323291709 0
Total 0 0 0 24323291709 0
IPv4 CEF output features:
Feature Drop Consume Punt Punt2Host New i/f
AF Policing 7 0 0 0 0
Total 7 0 0 0 0
IPv4 CEF post-encap features:
Feature Drop Consume Punt Punt2Host New i/f
IPSEC Post-encap 73 24233024017 0 0 0
Total 73 24233024017 0 0 0
IPv4 CEF for us features:
Feature Drop Consume Punt Punt2Host New i/f
Total 0 0 0 0 0
IPv4 CEF punt features:
Feature Drop Consume Punt Punt2Host New i/f
Total 0 0 0 0 0
IPv4 CEF local features:
Feature Drop Consume Punt Punt2Host Gave route
Total 0 0 0 0 0
MPLS-HE#
So an access list is causing the punts??
Based on what I've read cef works off the ingress interface, and there are no access lists on either of the inside interfaces (example below)
interface GigabitEthernet0/0
description to Core
ip vrf forwarding BLUE
ip address x.x.x.x x.x.x.x
!
!
ip flow ingress
duplex auto
speed auto
!
The only thing that does have an ACL is the virtual-template (limiting inbound traffic to be sourced from 10.160.0.0/16)
Based on the above I'll think I'll try ripping the ACL off in test lab to see the result.
I'll also do the debug cef drops in lab when I get a chance.
10-10-2012 03:24 PM
I am wondering if ACL would be the issue here. I guess it could be your VPN traffic getting punted or something. Not sure if your vpn configuration is supported in CEF. But as per your plan, do continue your tests and let us know the results.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide