CEF Unsupp'ted question

Guys, quick question on CEF packet handling. Say you get a line like this on one of your 6500's...

Switch# show cef not-cef-switched
CEF Packets passed on to next switching layer
Slot No_adj No_encap Unsupp'ted Redirect Receive Options Access Frag
RP 3579706 0 0 0 41258564 0 0 0

This isn't output from one of our actual switches, but we are getting similiar unsupp'ted results on ours that increment up by the second. What are these "unsupported packet features" that cause this number to be so high...or better yet do you all have any ideas on how I can find out? I am going to do a bit more research, but thought someone else might of had similar experiences in the past.

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

kryolla

some packets are not cef switched like packets destined to the router or originating from the router. Also policy based routing and packets with IP options. Check for for packets that are punted or does a search on the criteria for packets to get punted

networker050184

There is a way to sniff the punted packets, but its a little complex. We had to do it not to long ago on a 7600 with a Sup 32. I believe its the same procedure with other Sups, but you may need to verify.

1.  Set up port monitor as normal
     Router(config)# monitor session 1 source interface x/y (an unused interface)
     Router(config)# monitor session 1 destination interface x/y

2.  Login to SP
     Router# remote login switch

3.  Enable monitor on switch
     Router-sp# test monitor add 1 rp-inband both

All of the traffic punted to the RP will be pumped out the monitor port. You can then use wireshark to see what traffic is being punted.

jason_lunde

Thanks for the replies. I will try that span session out networker. I will check the documentation out for our sup's. I am assuming at this point that it is some PBR that I implemented mid-week to reroute some traffic to a different gateway. I will do a quick capture and post my results here. Thanks again.

marlon23

This strongly depends on the platform, however for 6500, basic policy-routing is done is hardware.
To check if this is an issue check the CPU level both on RP and SP, especially the interrupt level (aka 25/14% means 14% are interrupts = traffic punted to the CPU). If the interrupt level is under 10% I wouldn't worry.

-To capture traffic going to the CPU just run:
show platform capture buffer collect for 10
show platform capture buffer data filtered
show platform capture buffer data sample XX <- to see detailed

depends on the IOS version you can even do usual SPAN with a source "cpu".

networker050184

marlon23 wrote: »

This strongly depends on the platform, however for 6500, basic policy-routing is done is hardware.
To check if this is an issue check the CPU level both on RP and SP, especially the interrupt level (aka 25/14% means 14% are interrupts = traffic punted to the CPU). If the interrupt level is under 10% I wouldn't worry.

-To capture traffic going to the CPU just run:
show platform capture buffer collect for 10
show platform capture buffer data filtered
show platform capture buffer data sample XX <- to see detailed

depends on the IOS version you can even do usual SPAN with a source "cpu".

Are these hidden commands? They don't seem to be supported on any of my 6500/7600 regardless of Sup or IOS (not that I have all the possible IOS versions).

If these work that would be a lot easier than the method we used.

jason_lunde

Ya I could not get those commands to work on our 6509's either marlon. I havent freed up any time to try yours out networker but I hopefully will sometime this week. Great sources of information though from both of you. Thanks!

marlon23

you need "service internal" enabled first in global configuration mode, if that doesn't work the simpliest method ever is:

debug netdr capture
show netdr captured-packets

If that wont work either please let me know your supervisor and IOS version.

jason_lunde

Thanks Marlon!
"debug netdr capture
show netdr captured-packets"

Trying to decipher some of the output of those capture debugs....
Is there anything specific within these **** that signifies a packet is being punted instead of CEF switched?

kryolla

Jason did you check to see what the CPU util is for interrupts which Marlon recommended

To check if this is an issue check the CPU level both on RP and SP, especially the interrupt level (aka 25/14% means 14% are interrupts = traffic punted to the CPU). If the interrupt level is under 10% I wouldn't worry.

jason_lunde

How do you post code in here? Tried pasting some output in but it jacks it all up.

jason_lunde

kryolla wrote: »

Jason did you check to see what the CPU util is for interrupts which Marlon recommended

Ya, our CPU is extremely low on this guy...very underutilized right now. I was able to find out a little more regarding what is going on...why stuff is punted etc... Sorry the output is kind of messed up, it looks good until I hit submit.

 XXXXXX-1#sh cef not-cef-switched
% Command accepted but obsolete, see 'show (ip|ipv6) cef switching statistics [feature]'

IPv4 CEF Packets passed on to next switching layer
Slot  No_adj No_encap Unsupp'ted Redirect  Receive  Options   Access     Frag
RP         0       0          53227624        0     75767260        0        0        0
5/0        0       0           0                  0        0                0        0        0
2/0        0       0           0                  0        0                0        0        0
1/0        0       0           0                  0        0                0        0        0


XXXXXX-1#sh ip cef switching statistics

       Reason                          Drop           Punt           Punt2Host
RP LES Packet destined for us      0          75767343         0
RP LES No adjacency                394079          0              0
RP LES Incomplete adjacency     383061          0              0
RP LES Unresolved route              2                0              0
RP LES Bad checksum                2322             0              0
RP LES TTL expired                      0               0         53226659
RP LES Unclassified reason          60                0              0
RP LES Neighbor resolution req     2612231     1025            0
RP LES Total                             3391755   75768368   53226659

All    Total                                  3391755  75768368   53226659

XXXXXXX#sh ip cef switching statistics feature
IPv4 CEF input features:
       Feature                Drop    Consume       Punt  Punt2Host      Gave route
       Policy Routing            0          0          0          0                 79450
Total                               0          0          0          0                79450

So it looks like Marlon was correct in that the PBR is being done in hardware given the last command. I am a little confused on the punt2host though...any ideas?

marlon23

TO CHECK THE TRAFFIC RATE punted to the CPU:
sh ibc brief <- if it is not tens of megabits its ok

TO CHECK WHAT IS THE TRAFFIC:
debug ip cef receive

debug netdr capture <- all the output captured by this, is traffic punted to the CPU. The reason why it happens & what are the sources can be found partially from show commands you have done already and deciphering the packet ****.
The sources/causes are network specific, one time I have seen a flood of multicast getting into CPU because IP camera was sending multicast stream with TTL=1

Sometimes applications are just violating IP in the most perverted ways.