we have cat-3550 switch and i just noticed one of its port has a high number of transmit errors and no receive errors. the port is configured to auto/auto and so is its downstream neighbour that happens to be a Unix machine. does this mean the switch port is bad?..
It could be as simple as a faulty cable running from the device to the switch or a simple speed / duplex mismatch.
Try the following:
1. Set the speed and duplex manually at both the host and the switch and then transmit data after clearning counters. Start from 100 full duplex down to 100 half duplex down to 10 full duplex down to 10 half duplex and in each of the cases see if dropping the speed / duplex solves the problem.
2. Replace the cable running from the device to the host.
thanks for your response. we have tried to hard code the settings on both ends, but to no avail. I am also having problem grasping the concept of the transmit errors on a switch port? - does that mean the switch port is bad???
another interesting fact is that the adapter on the other end of this link exhibits no errors. i.e the errors only appear on the switchport and those are the transmit errors....thanks
Transmit / recieve errors often result in my experience from speed / duplex mismatches mate.
To hard code a switchport use the commands below:
Switch# configure terminal
Switch(config)# interface gigabitethernet0/4
Switch(config-if)# speed 100
Switch(config-if)# duplex full
If you have tried to hard code the above settings and gotten an error, what error(s) was it ?
Please rate posts that help
in addition to Arvind´s post, it might be worth checking if a Windows machine attached to the same port renders the same results.
Also, which IOS version are you running on your 3550 ? This could be a bug...
the IOS version is 12.1(19)EA1c.The link is set to 100/full on both ends, but only the switch port is showing transmit errors. Could it be a bad port on the switch?
You didn't mention whether you've tried other cables ...(as mentioned by the first response) this is a likely cause of the symptops you've described.
It is even more likely if the cable was hand-terminated, or if it's an older cable (i.e., has been subjected to abuse).
The culpret (assuming it's not a hardware problem on the switch ... more later) is "Near End Cross-Talk ("NeXT") and "Far-End CrossTalk ("FeXT")
If your cables are not terminated properly, or damaged (as examples), the characteristics of the twisted pair that reduce the crosstalk (pair-pair) are significantly reduced.
The crosstalk (either NeXT or FeXT or both) can be significant enough that the sending interface senses it as a transmission error,
Some thing you can do to troubleshoot this a little closer would be to:
Move the cable to another interface and see if the errors follow the cable, or stay at the interface (moves=cable / far-end issue, stays with port=Port / hardware issue).
You should also look at the stats for the interface at the other end of the affected interface to see if there are any errors reported there.
IN ADDITION to that, you should put an analyzer (like Ethereal - free - www.ethereal.com) in the path and look for a high re-transmission rate on the traffic. You may not be seeing real errors on the opposing interface because it thinks the traffic is making it out / across the span without interference.
If you've swapped the cables (using known-good substitutes), and you've swapped the ports (on BOTH ends), and you still see the errors on the original port, then you (probably) have a bad port.
If the erros follow the cabling, even professinally done / commercial cabling, then you could have a bad punch on one of the panels or outlets, you could have interference along the span ... and maybe some other (less likely) candidates.
BTW: you may not / usually won't see collisions with a crosstalk-related problem, because the bit-encoded frame is not recognizable ... it looks like noise, which is not ususally monitored or reported as an interface statistic.
Let us know ....