Xmit-Err on all cisco catalyst 3550
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-29-2008 07:11 AM - edited 03-06-2019 12:30 AM
Hello,
I have a lot of Xmit-Err on all catalyst 3550 when I make an SHOW INT COUNTERS ERROR.
I have upgrade the IOS 1 month ago in version c3550-ipbasek9-mz.122-44.SE2.bin.
This message "Xmit-Err" indicate that the internal transmit is full.
Is there any bug in this version about "Xmit-Err" ?
Is there a network problem on this LAN ? Some time we have bad perform on this network....
All interface are in a-100Mb/a-Full.
Any information about this problem ?
Thanks
Hervé
- Labels:
-
Other Switching
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-29-2008 07:41 AM
From documentation:
Xmit Error
----------------
This is an indication that the internal send (Tx) buffer is full.
Common Causes: A common cause of Xmit-Err might be traffic from a high bandwidth link
being switched to a lower bandwidth link, or traffic from multiple inbound links being
switched to a single outbound link. For example, if a large amount of bursty traffic comes
in on a gigabit interface and is switched out to a 100Mbps interface, this might cause
Xmit-Err to increment on the 100Mbps interface. This is because the interface's output
buffer is overwhelmed by the excess traffic due to the speed mismatch between the incoming
and outgoing bandwidths.
Do you have buffer failures under the show int? If yes, you may want to consider a possible workaround (not a fix), buffer tuning by Configuring Minimum-Reserve Levels as explained under:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-29-2008 07:56 AM
Yes I have buffer failures under the show interface.
1154988 output buffer failures, 0 output buffers swapped out
Thanks for our help
Herve
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-29-2008 08:14 AM
Well, in that case try to configure something like the following in one port only, so you can test it. Remember to clear the counters at least for that specific interface so you can monitor.
Enable Qos:
switch # mls qos
## Assigning Level 8 to buffer size 170.
Switch(config)#mls qos min-reserve 8 170
## Configure a port for testing purposes.
Switch(config)#interface fastethernet
## Mapping Q-1-2-3-4 to level 8.
Switch(config-if)#wrr-queue min-reserve 1 8
Switch(config-if)#wrr-queue min-reserve 2 8
Switch(config-if)#wrr-queue min-reserve 3 8
Switch(config-if)#wrr-queue min-reserve 4 8
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-01-2008 12:12 AM
Hi Gary,
Thanks for your reply.
I work with Hervé on this problem.
I tried your workaround on an interface but the counters still increased on this one..
Do you think that this issue provided from a broadcast storm or something like that?
Thanks,
Angelique
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-01-2008 08:20 AM
It might be. Only way to be 100% sure is using a sniffer.
