Ah, that moment when you solve some weird IT issue in record time while a suitably impressed customer watches. The customer thinks you’re a genius yet you know you honed in on the solution so quickly not because of your crazy amount of talent and good looks (although these helped of course), but because you instantly recognized the peculiar, tell-tale signs of the odd ball problem at hand. Somewhere along the line you had seen it before and the memory stuck with you. And likely keeps you up at night, but that’s another story…
For that reason, I offer you this: a short recollection of symptoms I experienced when troubleshooting a data cable that turned out to be *mostly* plugged in.
After some re-cabling recently, my team was tasked with testing to confirm everything was coming up roses. All was good except for one thin client workstation out of 12. This one thin client couldn’t get a DHCP address, but every other device plugged into the same switch was good and chugging along.
I initially checked that the switch port was up and confirmed a physical status light of green as well. I also checked to see that a mac address was being learned off the port in question and looked at the interface statistics. From a physical perspective, things were looking good. I did try another port on the switch, but the issue persisted. At this point, some engineers would be inclined to look higher up the network stack or at a misconfiguration of the client. The single reason I hesitated to pursue this line of inquiry: I could reliably confirm the client worked before and that only the wiring had changed.
Now my regular blog readers can probably predict what I did next – yep, Wireshark to the rescue! In short order I had a SPAN port setup on the switch and within minutes I was looking at packet capture goodness. Want to take a guess what I didn’t see in the capture? A DHCP request from the client. In fact, I wasn’t seeing any packets from the host in question. Not what I was expecting.
Knowing packets don’t lie, I had to assume the issue was lower in OSI stack and sure enough, upon closer investigation, the wall cable to the device was just a wee bit loose. Now admittedly, I could have gone over to that room and checked the cable first. A loose or damaged cable would definitely have been a likely cause given the re-cabling scenario. Let’s be honest, however, I’ll use any excuse to fire up a packet capture. I highly encourage this habit too because seeing what “normal” and “abnormal” traffic looks like will go along way toward making you a better engineer in the long run.
So there you have it. Port looks up from a physical perspective, switch sees something alive on the port, but the device can’t get a DHCP address, you should be sure to check the cable to see that it’s seated properly. For some of us, this is old habit anyway, but now you can add this to the list of symptoms for this type of hardware issue. Just another helpful way to streamline your troubleshooting process.
Published 10/15/2013
Amy Engineer 
Reblogged this on ssl boy – Adventures in Enterprise Networks.
Thanks for sharing!
One time I made an UTP cable in the fly and ONLY one wire wasnt completely tight and for that reason the whole wire was not passing traffic!
My old man is a network guru and he always told me to start at layer 1 and work your way up the stack. I too have been bitten by the physical layer. Always charcoal your cables. Good read
Greeting from Malaysia 🙂 i used to face the same situation here in PETRONAS KLCC office.. Put all the hassle aside; the moment when the customer start to smile again and to think of you as a genius… PRICELESS 🙂
I had a ‘ping page’ of known devices that, should a device not respond, would allow a magic packet to be sent. I was scuppered by a recent furniture move that left a table leg on top of a cable though – still. easy to locate and sort.