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.


6500 problem

we are having a problem nailing down someone who is burying a 6509 ,sup 720 . It gets to the point we can't even do anything with the mgt interface . The high process is IP input at the time of the problem . The thing is none of the interfaces seem to be running very high so we can't really pin it on anything . If it's hitting the supervisor it must mean it is not being hardware switched for some reason (broadcasts ????) but have no idea why .Very few acl's on the box . Running code 12.2.18SXD1 . We have tried looking at the netwflow cache but that isn't really giving us much so far . Anybody have any ideas on how to pin this down ? Also on the new 720's can you still use the scheduler allocate command to give you more managebility when things like this happen and what would you set it too???

New Member

Re: 6500 problem

In cases where extremely high network load presents itself on the interfaces, it is possible that other tasks will not be able to run. By default, the Cisco IOS allocates 5% of the CPU time to the lower priority tasks.

I recommend capturing traffic (e.g. using span ports) to learn more about the kind of problem you have.

You can also issue the command

show ip traffic | include assembled

If the counters are high and/or increasing rapidly, you have most likely a fragmentation problem.

To answer your second question:

Default values for the global command "scheduler allocate" are:

scheduler allocate 4000 200

Where 4000 is the maximum number of microseconds to allocate to fast switching any single network interrupt context, and 200 is the minimum guaranteed number of microseconds to allocate to process level tasks while network interrupts are masked.

While the default settings are largely adequate for most steady-state operation, you may find that modifications are necessary to ensure console access during periods of extreme network stress. Be careful, however.

New Member

Re: 6500 problem

Perform a global command "sh ip cache flow" command and find the host ip that is broadcasting unwanted packets. Once you have identified the ip perform the "sh arp | inc addy" which should give you the mac for the host. Then you would kill the port connection to the host on the port level "sh mac address-table | inc "mac address". This should take you a step further to determine if the system is infected with a virus. Also, you may want to kill the connection at the firewall layer.


Re: 6500 problem

thats the first thing we tried but we really didn't see anyone that looked suspicious with there traffic patterns . The next thing we are going to try is to upgrade to 12.2.18SXD4 and see if that has any impact .

New Member

Re: 6500 problem



New Member

Re: 6500 problem

Put a sniffer in p mode on a port on the switch without spanning and ports to it, you may find one of the few with in the first few minutes.

1) MC Traffic - Symantec GhostCast caused us this same problem, Also any other MC traffic gone nuts

2) BC Traffic - although it has to be A LOT LOT, it can still cause you some odd issues especially on trunk links if you are not pruning.

3) Check all trunk links for errors or unidir links. if not using UDLD you can have a spanning tree problem - you will also see this on the sniffer because it will pick up the change control frames.

4) Do a show int look for any errors on interfaces that are excessive - clear counters and look again. Although this SHOULD not cause a problem you need to eliminate any possibility of a problem.

5) check static routes to make sure they are correct, if using a routing protocol make sure you are not reconverging often, if EIGRP no SIA's.

New Member

Re: 6500 problem

And setup a SYSLOG Server and logging to it from this and other devices. Turn up logging as high as possible at until you find the issue.

ALSO What modules do you have in this chassis.