With the invention of Power over Ethernet (PoE) bringing up light devices such as VOIP phones and wireless access points has become very easy. Power and data flow over the same cable on various wire pairs. The simplicity is great but the electrical requirements are a bit more particular with PoE. With full Gigabit implementations all wire pairs are required for power and for data transmission. When one pair is not properly terminated strange things happen…

Recently I was part of a fairly large wireless implementation. The cabling was run as part of a building project and the in-house electrician performed the termination and labeling. He also mounted and connected the wireless access points. The APs were Cisco 1602s. When the APs are connected and powered on they go through a few startup phases until they are active. All of this is indicated by blinking of the LED. One AP, despite performing the LED sequence, was not available on the wireless controller as I would have expected. With the cabling information in hand I connected to the switch and started reviewing the output of applicable “show” commands.

“show cdp neighbors” exposes all access points except the one in question. I then issued a “show ip interface brief” and noticed the interface was reporting it was down all around.

GigabitEthernet0/42 unassigned YES unset down down

So how exactly was the AP powered on if the interface was down? A “show power inline” answered that question, in a way. You can see the interface with the issue, then one that is working correctly and finally an interface with no POE device connected:

Gi0/42 auto on 15.4 Ieee PD 3 30.0
Gi0/43 auto on 15.4 AIR-CAP1602I-A-K9 3 30.0
Gi0/44 auto off 0.0 n/a n/a 30.0

You can see the device connected on Gi 0/42 is not reporting its type but rather is just a generic name.

So what exactly is happening here?

As it turns out there was a break in one of the pairs within the cable. As a result the Access Point was powering up fairly normally but it was not able to communicate in any way with the network. As a result the switch port never came up from a data perspective, the interface LED on the switch was never lit, CDP information was not passed, and the access point never registered with the controller all while the LED on the AP was blinking away normally.

Fortunately the organization is fairly small so working directly with the electrician is easy to do. I suggested he re terminate the cable for that specific AP. I was able to suggest what end of the cable to examine because of the switches built in cable diagnostic functions.

First I initialized the test on the cable. The results take a few seconds to return. The cable test results are stored and can then be retrieved with a show command. The entire process is shown below.

sw1#test cable-diagnostics tdr interface gigabitEthernet 0/42
TDR test started on interface Gi0/42
A TDR test can take a few seconds to run on an interface
Use 'show cable-diagnostics tdr' to read the TDR results.
sw1#show cable-diagnostics tdr interface gigabitEthernet 0/42
TDR test last run on:
Interface Speed Local pair Pair length Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Gi0/42 1000M Pair A 323 +/- 10 meters Pair B Normal
Pair B 323 +/- 10 meters Pair A Open
Pair C 323 +/- 10 meters Pair D Normal
Pair D 323 +/- 10 meters Pair C Normal

As you can see there was an issue or an “Open” on one of the pairs. After re terminating the cable the access point again powered up. This time, however, the link light on the switch greened up and CDP information was shared with the switch. A quick look at the controller and the new AP was listed there as well.

In conclusion I would like to say that you may never experience this issue exactly. However, knowing how to leverage the diagnostic commands and utilities built into Cisco hardware can be a huge time saver particularly when facing cabling issues like I described here…