Trouble shoot with TDR

Reading Time: 5 minutes

This article is another example of trouble shooting by putting multiple pieces together. While it relies upon existing knowledge of the environment in which the article is based it should prove to be a good example of a trouble shooting process that will hopefully be able to spark some creative thinking the next time you have a problem that needs to be resolved.

The scenario starts out with a user ticket stating that the phone isn’t working. After some fact gathering the below details and possible solutions were outlined.


  1. Phone Powered Up
  2. Phone states “Ethernet Disconnected”
  3. Laptop in same port gets IP address


Possible Solutions:

  1. Bad Network Drop
  2. Bad Patch Cable(s)
  3. Bad Port on Phone

The first thing I wanted to look at was the port in question. Luckily, the desk side technician had plugged his laptop into the port to verify it was working correctly. Since ip device tracking was enabled I could find the port he was using.

At this point I know what port we are dealing with. With the fact gathering prior we know that the port is giving out power as the phones display is lit and it states Ethernet disconnected. I then looked at the power output on various ports including the suspect port.

Knowing all of our known POE device are Cisco APs and Phone notice the 2/0/7 Port has an Ieee PD listed. This indicates that the phone is not communicating CDP info to the switch. It is also receiving a similar about of power (4) when compared to a known working phone of the same model (3.5)  From here I decided to use a largely unknown diagnostics command on the port called TDR.

[notice]Mixed documentation and research indicated running this MAY cause interruptions on the device[/notice]

Notice how the port is listing at 100M for a speed in the TDR diagnostics but if you look at the interface it is set to auto. This plays a part in how we interpret the above diagnostics.

Putting the facts together:

  1. Port works with laptop
  2. Ethernet Disconnected error with phone
  3. Power lists Ieee PD instead of phone model
  4. TDR Cable Diagnostics list an Open Pair
  5. Opens and Shorts are listed at ~79 Meters and one Pair terminating correctly
    1. Indicated by 0 meters listed on the good pair
    2.  Assuming the opens/shorts all at ~79 meters the End to End cable is 79 meters.
  6. This concludes that the cable either has a bad termination at the end whether the patch cable to the phone, or the port on the phone itself.

With this in mind we can safely assume that it isn’t the port on the switch, the patch from switch to the patch panel, or the cable in the wall. In this particular case it was a bad port on the phone. However, with a few quick commands we saved time of having to walk across campus to play the trial and error troubleshooting method and could prove the network drop itself was good up to the termination/port on the end device.

Once the phone was swapped out with a working phone the TDR diagnostics were re-run showing the A and B pairs successfully being in a Normal State

These troubleshooting steps require an understanding and inside knowledge of the working environment but can be useful in many other situations. It took some research in the Cisco Documentation and other blogs to piece together how to properly read the TDR Diagnostics output. I have an article here that describes my findings.

Share this article:

Permanent link to this article: