Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Excessive process-switched traffic

Hello all ?

I?m trying to figure out what is causing the input queues on my 6509 core router vlans to fill up to the point where excessive input drops are occurring. Related to this is the question of why most of the traffic on those vlans is process-switched, instead of fast- or cef-switched. A ?show ip cef adj punt? and ?show ip cef adj drop? shows nothing dropped or punted.

Output from "show interfaces [type number] switching" and then "show ip traffic? showed that there were no cache misses, indicating that the excessive processing was for traffic destined for the router, and that the dropped traffic was 'ip traffic' dropped due to "encapsulation failed" and "no route".

I understand that ?encapsulation failed? indicates a missing ARP entry, and that ?no route? means just what it says ? no route to the destination.

I would suspect that the excessive process-switched traffic is due to excessive traffic, but there are no ?punts? or ?cache misses?. Is there some way I can break this down further (when the congestion is not actually happening) to see what ARP entries and routes are missing?

Each 6509 has a Cat6k-MSFC2 (R7000) processor with 114688K/16384K bytes of memory.

Thank you in advance for any suggestions.


Re: Excessive process-switched traffic

Check to see if someone is multicasting that should not be , this will all get sent to processor if multicasting is not setup on the 6509, I have seen one person bury a Sup720 because of this .

New Member

Re: Excessive process-switched traffic

Interesting. That would be a good explanation, but I don?t know if I?d be able to identify a rogue multicast source. As far as I can tell, the only multicasts coming in should be eigrp-related. The input queue drops that are happening seem to be happening in bursts. We do have Netflow switching enabled on many of the vlans. Maybe that is where the assault is coming from.