due to some Exchange server problems we've been having I've been asked to replace all the ethernet cables (UTP Cat 5e) that connect the servers to the switch (Cisco 6509). Each server has 2 NICs and each one of these connections to the switch goes from patch panel to patch panel (i.e. there's 3 cable lengths between server and switch). There would be 18 calbes to replace in total.
The cable lengths are only about 15 metres or so in total. I was wondering if this is necessary. The server team are clutching at straws as they don't know what's causing the problem. There are no errors on any of the switch ports connecting the servers to the 6509.
Basically my question is this, if there are no errors of any type on a switch port is there any possibility of a problem with the cabling? Do cable problems always generate interface errors? If the fact that there are no errors means that the cabling is definitely fine then I can tell them that there's no point in replacing the cables.
If the switchport is not registering any errors, then probably the cables are OK, but not guaranteed. You are only seeing the errors from the switchport's point of view. It could be that the server is experiencing receive errors, but you would not know about it from looking at the switchport. Ask the server team to tell you the error count on their NICs. (It is not guaranteed that they will know how to do that, but I think you should insist.)
Other than that, I would go ahead and replace the cables. I know it is clutching at straws, and I know it is hard work, but at least it would eliminate their hypothesis.
Have a look at the duplex settings on your ports. Are your switchports in auto or fixed? Are the server ports set up as auto or fixed? They must match.
thanks for the reply. I've checked the server NICs myself and there are no errors. The first thing I checked were the speed and duplex settings and the switchports are set to 'speed nonegotiate' whereas the servers are autonegotiate. I've already requested that a change be approved for the servers to be hardcoded to 1000Full to match the switches. This will probably be done later this week after approval. If that doesn't solve the problem then I suppose the cables will be the next step. It will be interesting to find out if replacing the cables does actually cure the problem even if there are no errors on the switches or servers.
In that case, I am guessing that hardcoding both the NICs and the switchports will resolve the problem. But conversely in this case I am surprised not to see any receive errors on the NICs. (You may have to re-boot the servers for the change to take effect. :-( )
Please let us know the result so we can all add it to our "experience".
Hardcoding the nics will probably not help a lot, the autonegotiation on 1000BT is working very well in most situations. My hint for this situation would be to check the teaming mode of the servers. Best would be to test it:
Have the server guys kill the team on one server and check if there is any difference in performance.
Ok thanks for that, I'll bear that in mind. The teaming is set up for fail on fault so there is only 1 NIC active at one time in each server. If the other changes don't prove fruitful I'll ask the server guys to break the teams and run with just the one NIC per server and disable the other.
Fail on fault would be the setting to use but I have seen strange behaviour on nic-teams frequently.
If some of the servers were installed on the same machine, (and then swapped the disks) there could be a duplicate mac issue on the teams.
As there is nothing pointing to a cabling issue I would rather do this test for a start, it will save you some work.
If running gig it takes all 8 wires to run gig and all must be good or this will cause problems. Also I would pull the nonegotiate paramter if the nics are at auto and then recheck for errors with the "show int count error" command. If there is no errors then as Kevin said its probably not a media problem . Of course verify with extended ping tests while the servers are under load to see if anything is being dropped and use large packets ...
glen.grant makes a good point there, because the cable is more critical in Gig. Not only should the cable be correctly connected pin-for-pin, but it is also critical which wire pairs are twisted together. That is, the wire connecting pins 4 must be twisted with the wire connecting pins 5 to make pair 1, the wire connecting pins 3 must be twisted with the wire connecting pins 6 to make pair 2, etc.
Normally if the cable came from a decent source it should be correctly connected.
Thanks for the advice guys. I'll be sure to try the things suggested before any cables are replaced. If we cure the problem I'll be sure to post an update on this group with all the details.