Excessive process-switched traffic

Unanswered Question

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.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Loading.
glen.grant Fri, 07/20/2007 - 04:33

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 .

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.

Actions

This Discussion