There will be times when you want to test a physical copper link to validate the layer 1 path between two interfaces. If you were on-site of course you could use a physical cable tester but if you are working remotely like we often are, you still have an option. On some models of Cisco switches you can run a TDR or Time-Domain Reflectometer test. This test can be used to locate faults in the cable and provide information on the issue, such as which pair is at fault and location/distance information on the fault.
How does the TDR test work?
This topic can get a bit deep on the electrical engineering side of things so I’ll keep it surface-level. An electrical pulse is sent onto the cable and a reflection will be detected if there is an impedance change. If you know the Propagation Velocity, or speed at which an electrical signal can propagate through a cable in comparison to the speed of light, and the timing of the reflection you can calculate the distance to the fault. This data can also reveal what type of impedance change or failure may be present.
I want to call out two recommendations mentioned in the cisco documentation on this feature. The first is that it’s recommended to disconnect the test cable from the remote port prior to making the test. You can observe the ramifications of this in my testing below. The second is that auto-mdix may invalidate the results due to the changing of pairs between connected end-points to adjust for incorrect cable types (cross-over vs. straight-through).
Running the test
This is the command to initiate the test, ran from privileged exec mode:
test cable-diagnostics tdr interface <interface_id>
Here is a screen snip of the command execution:
Notice the output indicates the following command is necessary to show the results
‘show cable-diagnostics tdr’
Here are the TDR results from my test.
The open status indicates an open circuit indicating the cable pair is not terminated on the far end. Notice the status below after I connect the far end of the cable to a Cisco ISR 4k Router and re-run the test.
One thing I noticed on the test is that the cable length is incorrect. It shows 10 meters however it is a 2-meter cable. I ran the test multiple times and the remote pair designation changed between the 1st to the 2nd test. This is most likely the result of auto-mdix being enabled.
Now on to the fun part! I opened the sheath on my cable and snipped the 4/5 pair of the cable so we can observe the result.
Notice here that pair C is showing a status of ‘Open’ while the others that weren’t diabolically cut still show a ‘Normal’ status.
The last test I ran was on a FastEthernet interface so I could understand the impact on our test results. This was done with the far end of the cable disconnected. See the outcome below:
You can see here that the 4/5 and 7/8 pairs are ignored since they are not in use.
Final Thoughts
I’ve only covered a few of the possible ‘Pair status’ codes that may show up in your test results. ‘Short’, ‘Fail’, or ‘Impedance Mismatch’ could be seen in your results which can point to different issues with your cabling. I didn’t find a comprehensive document from Cisco covering all of the possible error codes and their meaning so additional research may be required depending on what results you get back. When TDR locates a faulty cable you should still use a cable testing tool to diagnose further, per Cisco’s recommendations. This test, however, is a great starting point if you can’t go straight to a physical cable testing tool. Just keep in mind some of the nuances of the test results when executing TDR from a switch, and run your test multiple times especially when you have auto-mdix turned on. Last but not least this test is intrusive and will cause the connected port to flap so be careful in your production network when running this test.
Happy Hunting!
-Eric Perkins