fundamental but experience related question on cabling

[jimfixit]

has anyone had cables that were bad but which did not produce physical (as in layer 1 or 2 type errors) on the switch?

I know a bad cable can cause retransmissions and such but wouldn't you expect to see errors recorded on the switch if you had a bad cable?

I'm about to replace a really hard to get to cable because of behaviors observed that resemble a bad cable but...there's no manifestation of actual errors on the switch. I've never personally seen that before.

just validating my sanity before I do this...

 

[jeter]

Did you test end to end? Not just the cable but the jack, patch cords, switch port, etc etc?

Granted the cable could be the cuase of your problems but what if it's not.


Go Army!
Tek-TIP Member 19,650

 

[Flyers01]

Can you just run a temp cable to see if that fix your.
don't know what type of cabling or issue you have
but I would start with replace patch cable then repunch down.

if it is fiber test the fiber patch cable also

 

[jimfixit]

Thanks. The cable runs through a wall, there's no way to patch around. It's isolated so I can't just 'try a different run' as there are none to this area. I can't cut the ends off and re-terminate as it is fiber.

The symptoms for the device at the end is excessively long or slow data transfer times and occassionally windows shows in the server logs that the network connection dropped. On that basis I wondered about the cable (Nic too but I don't have a spare I can put in and test with).

However there's nothing in the switch log for this port showing that the connection dropped and came back (I have snmp also monitoring this port and I get no traps either for the link up/down or errors). There are 0 errors (runts checksums and whathave you) counts on the switch port, either. On that basis I kind of felt it wasn't likely the cable.

This server is trying to talk to a NAS unit. I can see drops on the switch port for the NAS unit but not the server at the other end. Again, no errors. I always believed that drops without errors pretty much meant you were overrunning the receiving device and thus the switch queue filled up and started dropping. That too would not be a cable. problem but something peculiar to the NAS.

In the end, I am not responsible for either the server or the NAS unit. I am responsible for the network and have had the oneous placed on me to 'prove' this is not my network infrastructure causing the slowness. But short of pulling that cable and the problem not going away, how do I prove that? It follows switch ports so it's not my switch. I just wanted to avoid a costly and painful operation if I could say, "look there are no errors so it's not the cable". But I'm not sure that's 100% true. It is in my experience, but I wondered what others have seen.

Thanks!

 

[Flyers01]

Well if it is fiber all u probable needs is to retip the ends
I would test fiber and make sure DB loss is under 4 before I wold run cables.

Also if you are using gbic look for symbol errors

show controllers ethernet-controller gigabitEthernet ?/?

 

[vipergg]

On the switch how is it hooked up ? Via gbics , sfps etc.. Right fiber being used for the gbic and on the server itself what does the server nic support for fiber? Multimode, singlemode etc... Just stuff to think about and or verify ...

 

[unclerico]

If you're not a fiber wiz, you need to get someone on site that is. Have them test both ends of the fiber. Are you running the fiber directly in to the switches or are you using fiber distribution panels??

I hate all Uppercase... I don't want my groups to seem angry at me all the time! =)
- ColdFlame (vbscript forum)

 

[jimfixit]

thanks for the show controller I forgot all about that...mostly I use it on serial ports for my wan links but forgot it could be useful in other situations.

It was the gbic, swapped it out problem solved. Not sure why that didn't translate to errors on the port but...stranger things have happened I suppose.

Thanks all