Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

massive amounts of discards and tx queue not available errors

Status
Not open for further replies.

wizo

Technical User
Oct 23, 2002
55
AU
Hi Guys

noticed on our metwork management software that massive amounts of discards were occuring on one of our 4006 Catos access layer switches, did a show counters and found that every active port has an extremely high count on the below.

23 txQueueNotAvailable = 3328440

I thought maybe one port was causing the tx queue to be blocked but have been unable to isolate it so far..

any ideads?

cheers
 
Sounds like someone on the switch may have a virus and is broadcasting like all get which gets passed to all active ports. Clear the counters and see if one port is a lot higher than others. also look for any built in spanning tree loops. See if the switch sees itself on any ports via cdp .
 
No loops, cleared counters, no single port with more errors than the others.......

strange
 
try to pull out one cable at a time on the switch and see if any of the cables are causing problems on the switch. if one cable is messed up it might cause problems for the other network devices.
 
try to pull out one cable at a time on the switch and see if any of the cables are causing problems on the switch. if one cable is messed up it might cause problems for the other network devices.
That's not always possible in a production environment. Plus the 4000 switch might have multiple 48 port blades.

Wizo: Is the tx queue on the interfaces saturated? For example, 'show interface' shows 255/255 on txload. Check out running a SPAN session if the traffic is being transmitted across the wire:


If it is an issue with saturation then you can find the offending traffic with SPAN. Alternatively, you could run a capture through wireshark on one of the end-hosts. Since the traffic is hitting all ports, it has to be some type of broadcast like vipergg stated--provided they are all in the same VLAN. Check the MAC table too, it could be flooded: show cam count, show cam dynamic


Rich
Network Engineer - CCNA
 
If you do a show logging, are you getting any other indicators of a problem? I assume this is limited to a single vlan? Does NBAR/Netflow give any detail on traffic type?

Are you using port security to prevent any port from overflowing the CAM table? If that overflows it'll resort to hub operation. If that's not it, I'd suggest using a protocol analyzer like others have said to find out what type of traffic this is, and go from there.

CCNP, CCDP
 
I'd be looking for which interface has the highest *rx* - that tx must be coming from somewhere...
 
Not if the switch is generating those Tx's due to it being in a failover state after a CAM overflow attack. In that case the switch would flood all traffic, spiking Tx but it wouldn't be from any particular source.

CCNP, CCDP
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top