How to use Time-Domain Reflectometer (TDR)

Document

Oct 11, 2011 2:57 PM
Oct 11th, 2011

I’m no electrical engineer, (the closest experience I have with electricity is the amount of electrocution I received when I was a child [due to faulty cabling of electrical appliances]) so I will spare readers technical jargons and boring formulas because this guide is not aimed to be published in the International Journal of Mumbo-Jumbo. This guide is to help anyone how to confidently use the TDR feature when troubleshooting basic Layer 1 Ethernet issue.

My knowledge with this feature is based entirely on experience and a lot of trial-and-error.

What is Time-Domain Reflectometer (TDR)?

“A time-domain reflectometer (TDR) is an electronic instrument used to characterize and locate faults in metallic cables (for example, twisted wire pairs, coaxial cables)1.”

For the sake of this document, “TDR testing” and “TDR” are used interchangeably to sow confusion to the un-initiated. They both mean the same.

How can TDR help me?

TDR, in its simplest form, can help you determine IF you have a cable problem, WHICH pair(s) is/are faulty and HOW FAR away the fault is.

Typically, when you have a Layer 1 issue there are a lot of factors to consider:

  1. Local-end Side (LeS) patch cable;
  2. Local-end Side (LeS) patch panel (including punch block);
  3. Horizontal cable;
  4. Remote-end (Red) patch panel (including punch block);
  5. Remote-end (Red) patch cable; and
  6. Remote-end (Red) device NIC

So you see, dear readers, TDR minimize the guess-work.


Picture this …

Before we begin, let me give you the “lay of the land”. Presume the following scenario:

Drawing1.jpg


What model of Cisco switch does TDR work on?

Firstly, not all switch model support TDR. TDR feature first came out with the Catalyst 2960. So here is the list of which ones will work and will not:

Model

TDR Support

2960

Yes1, 2

2960G

Yes

2960S

Yes

2918

Unknown

2350

Unknown

2360

Unknown

2975

Unknown

3560

No

3560G

Yes

3560E/3560X

Yes

3750

No

3750G

Yes

3750E/3750X

Yes

Nexus 2K

Unknown

Nexus 5K

Unknown

Nexus 7K

Yes3

Sup7E/X4548

Yes

Note:  

  • 1.        The 2960 will support TDR in both the FastEthernet and dual-personality GigiabitEthernet port, however, when used on a FastEthernet port, TDR will only test the first two pairs, namely Pairs A & B.  For obvious reasons, Pairs C and D will not be tested when used on non-GigabitEthernet ports.

  • 2.       Except the WS-C2960-48PDL, when using the copper GigabitEthernet port of the Catalyst 2960, one must manually set the interface to copper using the command “media rj” before the test can be conducted.

  • 3.       Confirmed by Cisco TAC, Ankur Garg.

The list does not include modules/blades for the Catalyst 4000/4500, 5000/5500, 6000/6500 although it is mentioned here that TDR was introduced with IOS Release 12.2 ZY for the Catalyst 6000/6500. It’s not included in the list above because I don’t have the resources to test and verify.

Legacy Cisco Catalyst models 1900, 2900XL/3500XL, 2940/2950/2955, 2948G and 2970 are not supported. Routers are also not supported. I do not have any resources to test router Ethernet Switch Modules (NME, HWIC, EHWIC). Wireless Access Points do not support TDR.

Why doesn’t the FastEthernet-flavoured 3560 and 3750 support TDR and but the cheaper FastEthernet 2960 support TDR?

Base on the time-line, the “plain” (or non-GigabitEthernet copper port) 3560 and 3750 came out BEFORE the 2960. The “chip” for the TDR was included in the design of the 2960. When Cisco released the 3560G and 3750G later, someone made the ultimate decision to include the TDR feature as a standard. Therefore, the plain 3560 and 3750 are the only two series that WON’T HAVE the TDR feature. (Take note reader: Emphasis on the words “WON’T HAVE”)


Any Gotchas I need to be aware of?

  • Switches need to run IOS version 12.2 or later. TDR is supported in IOS version 15.0. IOS version 12.0 and 12.1 do NOT support TDR.

  • If you are running IOS version 12.2(46)SE or earlier, TDR test is DISRUPTIVE. During the test, the interface will go down and up. For obvious reasons, anything connected will lose network connectivity.

  • If the remote-end device is a power-over-ethernet (PoE) device, the test will cause the device to lose power. If you have, for example, a Voice over IP (VoIP) phone and a PC client is connected to the phone, both the phone and client will lose network connectivity because the phone does not have a bypass functionality. This will affect ALL IOS versions.

  • Particularly when you are running old IOS versions, the test can take between five (5) to seven (7) seconds.

  • TDR works on 10/100/1000BaseTx. Fibre optic ports (any flavours) is not covered/discussed here. TenGigabitEthernet copper port DOES NOT (YET) support TDR.

  • Cisco GLC-T/GLC-TX SFP module does NOT support TDR.

The next two Gotcha items are for those who plan to use the TDR feature on Cisco Catalyst 2960 and 2960G (2960S not included):

  • 1. The 2960 will support TDR in both the FastEthernet and dual-personality GigiabitEthernet port, however, when used on a FastEthernet port, TDR will only test the first two pairs, namely Pairs A & B. For obvious reasons, Pairs C and D will not be tested when used on non-GigabitEthernet ports. Pairs C and D will report a result of “Not Supported”.

  • 2. Except the WS-C2960-48PDL, when using the copper GigabitEthernet (Gig 0/1 and Gig 0/2) ports of the Catalyst 2960, one must manually set the interface to copper using the command “media rj” before the test can be conducted.


How to use TDR?

The commands are very simple: One to start the test and the second command to display the result. Here is simple procedure:

  1. Command to start the TDR: “test cable tdr interface <interface of your choice>”;
  2. Wait for about 5 to 7 seconds for the test to run; and
  3. Command to show the result of the TDR test: “show cable tdr interface <interface of your choice>”

See? Easy! Now let’s see what the I results would look like.

Interface

Speed

Local pair

Pair length

Remote pair

Pair status

Gi0/1

1000M

Pair A

3 +/- 1 meters

Pair A

Normal

Pair B

3 +/- 1 meters

Pair B

Normal

Pair C

3 +/- 1 meters

Pair C

Normal

Pair D

3 +/- 1 meters

Pair D

Normal

So what does this result above tell us?

  1. Port tested is on GigabitEthernet 0/1;
  2. Port has negotiated to 1 Gbps;
  3. Cable use is a straight-through cable (look and compare the values of “Local pair” and “remote pair”);
  4. Cable length is approximately 3 metres long and an error (length-wise) of 1 metre; and
  5. All four pairs are working fine (Pair status)

Under “Pair status” you can get the following results:

Result

Explaination

Normal

Ideal result you want.

  • If testing FastEthernet, you want Pair A and B as “Normal”.
  • If testing GigabitEthernet, you want ALL as “Normal”.

Open

Open circuit. This means that one (or more) pair has “no pin contact”.

Short

Short circuit.

Impedance Mismatched

Bad cable. For more explanation, go here.

An ideal result is “Normal”. In practice, whether the remote-end device is FastEthernet or GigabitEthernet, I will never accept a TDR result other than “Normal” in all four pairs.


Cable Pairs explained?

This is how I see what each Pairs control:

Pairs

Function

A

This pair controls whether or not the port should go up or down.

B

Protocol-level and controls FastEthernet.

C

Power over Ethernet (PoE)

D

GigabitEthernet

More examples

Interface

Speed

Local pair

Pair length

Remote pair

Pair status

Gi0/11

100M

Pair A

13 +/- 1 meters

Pair B

Normal

Pair B

12 +/- 1 meters

Pair A

Normal

Pair C

0 +/- 1 meters

Pair D

Open

Pair D

0 +/- 1 meters

Pair C

Open

Normally, this result would freak me out. Look at the items in RED. Pairs C and D are reporting a cable value of “0”. Next I move to the “Pair status” and it’s reported as an Open circuit. No pin contact. Whao! But look at the speed. It’s 100 Mbps. So it’s normal … I guess.

But wait. What if the remote-end side (Red) client is a GigabitEthernet. So where is the faulty cabling? Which one of the patch cables? Or is it a horizontal cabling? Does the client support GigabitEthernet or not?

Here’s another clue: Look at the length of the cable for Pair A and B. It’s reporting around 12 to 13 metres. Experience has taught me that my Local-end Side (LeS) cable doesn’t exceed two metres. So that rules out my cable, however the horizontal cabling is more than 10 metres. So what’s between the horizontal cabling and the remote-end client? You have three suspects: 1) The remote-end punch block; 2) the remote-end patch cable; and 3) remote-end client.

Culprit was the remote-end punch block and the horizontal cabling: Cable contractors only terminated two pairs.


Never ask a boy to do a man’s job!

Interface

Speed

Local pair

Pair length

Remote pair

Pair status

Gi1/0/48

auto

Pair A

149 +/- 1 meters

Pair B

Normal

Pair B

151 +/- 1 meters

Pair A

Normal

Pair C

35 +/- 1 meters

Pair D

Short/Impedance Mism

Pair D

21 +/- 1 meters

Pair C

Short/Impedance Mism

Its results like the ones above that makes me want to cry.

Ok, I look under “Pair status” and I see “Short/Impedance Mism” for Pair C and D. No question about it. It’s bad cabling. This is not what makes me want to cry. Look at under “Pair length” of Pair A and B. NOW cry.


Should I be worried?

Interface

Speed

Local pair

Pair length

Remote pair

Pair status

Fa0/39

100M

Pair A

6 +/- 1 meters

N/A

Open

Pair B

49 +/- 1 meters

N/A

Open

Pair C

N/A

N/A

Not Supported

Pair D

N/A

N/A

Not Supported

Looking at the result, I can confidently say that the appliance was a 48-port Cisco Catalyst 2960. How? Look under “Interface”. Look at “Pair status” for Pair C and D. Only the plain 2960 FastEthernet ports can support TDR.

But look at “Pair status” for Pairs A and B. What does that mean?

Drawing2.jpg

It means that the remote-end (Red) patch cable is missing.

Weird things have happened before

I’ve taken the opportunity to do limited testing on TDR on a 4510R+E. The chassis has a Sup7E and with a X4548-RJ45V+ line card (IOS version 03.01.01.SG). The result(s) are very, very weird. Oh, by the way, the TDR testing on this setup takes 60 seconds. 60 seconds! Good grief! I have no idea whether the Sup7E or the line card is the factor.

The sample below is coming from a GOOD cable:

Interface

Speed

Local pair

Pair length

Remote pair

Pair status

Gi2/36

1Gbps

1-2

29 +/-10m

Unknown

Fault

3-6

30 +/-10m

Unknown

Fault

4-5

29 +/-10m

Unknown

Fault

7-8

30 +/-10m

Unknown

Fault

And the sample below is coming from a BAD cable:

Interface

Speed

Local pair

Pair length

Remote pair

Pair status

Gi2/37

0Mbps

1-2

56 +/-10m

Unknown

Fault

3-6

0 m

Unknown

Fault

4-5

56 +/-10m

Unknown

Fault

7-8

59 +/-10m

Unknown

Fault

As you can see, whether or not you have a good or a bad cable the result from the “Remote pair” and “Status” can be deceiving. The ONLY WAY to determine if you have a bad cable issue or not is to look at the “Speed” and the output to the “Pair length”.

I am suspecting that the misleading result of the “Remote pair” and the “Pair status” is an IOS bug.

-- END OF TRANSMISSION --

Average Rating: 5 (12 ratings)

Comments

edwin.summers Wed, 10/12/2011 - 06:31

Great document - thanks!  I was not aware of this feature and look forward to trying it out in the lab.  A few questions I'm researching that you may know based on your experience:

1. Are there options to change cable characteristics (such as NVP)?

2. Do you know if there is a minimum cable-under-test lenght or what the accuracy of the length measurement is (assuming all cable characteristics are known)?  (Example: I've used a Fluke Optiview where the minimum CUT was 3ft and accuracy was +/-6ft assuming the correct cable characteristics were provided.)

Regardless, this can be an invaluable tool.  I had the benefit of being able to borrow a TDR from work for my home Cat6 install and it saved much time and troubleshooting effort down the road.  I was immediately aware of any issues that required re-pulling or reterminating runs before I had data problems down the road.  The TDR isn't just an installer's tool.  Anyone that integrates, installs, or upgrades network equipment can benefit from knowing how to use this feature.  At some point you will likely be establishing connectivity across infrastructure that someone else installed, and "proving" that the cabling is the problem can be a difficult task.  The TDR is a great asset in this case, especially when the equipment is too far apart to simply run a known-good patch cord.

Leo Laohoo Wed, 10/12/2011 - 14:12 (reply to edwin.summers)
1. Are there options to change cable characteristics (such as NVP)?

Nope.  Not possible.

2. Do you know if there is a minimum cable-under-test lenght or what the accuracy of the length measurement is (assuming all cable characteristics are known)?  (Example: I've used a Fluke Optiview where the minimum CUT was 3ft and accuracy was +/-6ft assuming the correct cable characteristics were provided.)

Someone tested this and apparently is accurate based on the "+/-" figures posted.

Regardless, this can be an invaluable tool.  I had the benefit of being able to borrow a TDR from work for my home Cat6 install and it saved much time and troubleshooting effort down the road.

We are rolling out >400 wireless access points across the network.  You have no idea how this tool has helped us (of course the cable contractors were not too pleased).

The TDR is a great asset in this case, especially when the equipment is too far apart to simply run a known-good patch cord.

For our WAPs, we purchased a significant quantity of patch cable.  With TDR, we found around 9%-10% failure rate.  And these are BRAND-NEW cables.

By the way, thanks for the feedback.  I'm still in the process of formating the document properly and making improvements (grammar and spelling).

ankugarg Fri, 10/14/2011 - 04:44

Very nicely written article..Everything is explained to full.

I tried these on my setup.I got pair length on 3 +/- 10..Error of 10 m for a length of 3m looks weird.You have any idea how does the switch derives the value of error ?

You said that Pair C and Pair D are not relevant for fast ethernet.What about pair D for fast ethernet poe port ?

Leo Laohoo Fri, 10/14/2011 - 16:20 (reply to ankugarg)
You said that Pair C and Pair D are not relevant for fast ethernet.What about pair D for fast ethernet poe port ?

Won't work because TDR feature on FastEthernet for 2960 will only test for Pairs A and B.  There's no way to test Pair D.  It'll come up as "Not Supported".

I tried these on my setup.I got pair length on 3 +/- 10..Error of 10 m for a length of 3m looks weird.You have any idea how does the switch derives the value of error ?

                   

Sorry, Ankur.  Your guess is as good as mine.  This is internal to Cisco and I'm my electrical knowledge level is, frankly, non-existence.  Length of 3 and an error of 10?  That's not a value I'd take.  What IOS are you running?  I've seen results like these when we were using 12.2(50)SE or something ...

Does that help Ankur?

Leo Laohoo Sat, 10/15/2011 - 15:56 (reply to ankugarg)
Thanks leolaohoo for reply..IOS used is 15.0(1)SE,of which you are totally against

LOL!

I may be against using 15.0(1) BUT the TDR function of this version is pretty good.  So can I ask if you try another patch cable?

Excellet Doc! TDR is a very handy but often overlooked tool.

                   

Thanks for the rating and comments Kapil.  Let me know if you guys/gals have any feedbacks/comments/questions/violent reactions so I can make improvement(s) to the document.

By the way, can you guys/gals from Cisco confirm if TDR is supported in Nexus? 

ankugarg Sun, 10/16/2011 - 00:53 (reply to Leo Laohoo)

Sure,will try with another patch cable and let you know the results...If i'll be able to get to access any nexus,i'll let you know if it support tdr or not.

ankugarg Tue, 10/18/2011 - 23:35

Hi Leolaohoo,

I have two switches connected.I ran the test on both the switches,on the interface on which they are connected.Following are the results--

IBD!!#sh cable-diagnostics tdr interface g1/0/14

TDR test last run on: March 22 18:04:41

Interface Speed Local pair Pair length        Remote pair Pair status

--------- ----- ---------- ------------------ ----------- --------------------

Gi1/0/14  1000M Pair A     1    +/- 10 meters Pair B      Normal             

                Pair B     1    +/- 10 meters Pair A      Normal             

                Pair C     1    +/- 10 meters Pair D      Normal             

                Pair D     1    +/- 10 meters Pair C      Normal 

4-mem-stack#sh cable-diagnostics tdr interface g4/0/14

TDR test last run on: March 17 05:48:28

Interface Speed Local pair Pair length        Remote pair Pair status

--------- ----- ---------- ------------------ ----------- --------------------

Gi4/0/14  1000M Pair A     21   +/- 1  meters Pair A      Normal             

                Pair B     21   +/- 1  meters Pair B      Normal             

                Pair C     21   +/- 1  meters Pair C      Normal             

                Pair D     21   +/- 1  meters Pair D      Normal             

4-mem-stack#

4-mem-stack#sh cdp nei | inc 4/0/14

IBD!!            Gig 4/0/14        175             R S I  WS-C3750E Gig 1/0/14

Now two questions--

1)Why is cable length different in both the cases.Is it normal ?

2)First result implies that it is cross over cable,while second result implies that it is straight cable..Are these results ok?

Thanks,

Ankur

Leo Laohoo Wed, 10/19/2011 - 16:07 (reply to ankugarg)

It's because of MDI/MDI-X.  I replicated what you saw when using a straight-through cable.  Now when I change the cable to a cross-over and turned off MDI/MDI-X, the result came back the same length and error but the cable is reporting to be a straight-through cable.

Both switches running the same IOS,  12.2(58)SE2.

Thanks for the confirming the TDR on the Nexus 7K.  Document updated about Nexus 7K support. 

(Does the 2K/5K support TDR too?)

mjdoggett Thu, 07/18/2013 - 11:14 (reply to Leo Laohoo)

Thanks for the confirming the TDR on the Nexus 7K. Document updated about Nexus 7K support.

(Does the 2K/5K support TDR too?)

I can confirm that the 5K supports the TDR command at least as early as 5.0(2), unfortunately all of our interfaces are 10G/fiber, so I cannot say how well it works - but the command is there.  Great article by the way, thanks.

yantiscompany Wed, 11/23/2011 - 08:08

Great article!  I have a feeling I just created a lot of work ahead of me.  2 of the 3 ports I ran it on showed problems!  One was my IT Director's, and it left me a bit confused.  Output on Pair C gives a length, a remote pair, but says its open.  His POE and GigE work fine. His A and B pairs also show swapped.  What does this mean?

version is 12.2(55)SE1 on a C3750G

Interface Speed Local pair Pair length        Remote pair Pair status

--------- ----- ---------- ------------------ ----------- --------------------

Gi2/0/34  1000M Pair A     15   +/- 4  meters Pair B      Normal

                Pair B     17   +/- 4  meters Pair A      Normal

                Pair C     13   +/- 4  meters Pair C      Open

                Pair D     15   +/- 4  meters Pair D      Normal

Leo Laohoo Fri, 11/25/2011 - 19:13 (reply to yantiscompany)

Thanks Justin,

Your post has complete information.

Pair A and B local pair is "swapped" in the remote pair because the cable is a cross-over cable.  (I can't tell which side that is.)

I also notice that Pair C, which controls PoE, may not be working.  The fault is approximately 9 to 13 metres away from the switch port.  This could be from the punch block up to cable connected to the client at the far end.

Does this help?

yantiscompany Mon, 11/28/2011 - 12:15 (reply to Leo Laohoo)

Ya, that makes total sense.  Cables are running behind his big heavy desk, so we probably wont mess with it seeing as POE is indeed working.

Excuse my noobness, but is there a way to run the command against all of the ports?  It'd be nice to just run one command, and then output it one command.  Otherwise I'll be here forever if I have to do them one by one.

Leo Laohoo Mon, 11/28/2011 - 13:25 (reply to yantiscompany)
Excuse my noobness, but is there a way to run the command against all of the ports?

Not possible as of the moment.  I believe this was done so that no one will accidently send TDR test commands to all the ports and shut down the PoE (and associated devices connected to it).

The only way to do this is to do it via scripts.

yantiscompany Mon, 11/28/2011 - 14:10 (reply to Leo Laohoo)

Well that sucks.  I was planning on doing that very thing during the break, but totally forgot.  On the few ports I've tried it on, I have yet to see PoE take down a Cisco IP phone connected to it.  Does it only have to shut down PoE sometimes, or do you think its simply doing it so fast that the phone is able to take the hit?

Leo Laohoo Tue, 11/29/2011 - 14:18 (reply to yantiscompany)

Hi Justin,

Yes.  If you have a PoE device and a client connected to this device, the TDR will cause both links to loose network connectivity. The reason is because TDR will test Pair "C" which controls PoE. 

Leo Laohoo Mon, 12/12/2011 - 19:25

Document updated to include TDR testing using WS-X45-SUP7-E with WS-X4548-RJ45V+ linecard.

Leo Laohoo Thu, 01/05/2012 - 20:33

Update to everyone using this TDR guide for a 4500.  According to the TAC Engineer and the Dev Team, the 4500 TDR feature is taken from the 6500. 

Comment from Cisco TAC & Dev Team regarding the TDR result for the 4500:

Four pairs of standard category 5 cable exist. Each pair can assume one of the following states: open (not connected), broken, shorted, or terminated. The TDR test detects all four states and displays the first three as "Fault" conditions, and displays the fourth as "Terminated."

Although the CLI output is shown, the cable length is displayed only if the state is "Faulty."

So which means, unlike the 2K and 3K switches, if you have a pair that is either open circuit, short circuit or Impedance Mismatched, then the 4500 will display it as "Fault".  If the result is "Normal" then the output is "Terminated". 

HOWEVER, there is a bug.  Look at the TDR output below.  Can one point out which one is faulty?

Interface Speed Local pair Cable length Remote channel Status

Gi2/37   0Mbps   1-2         56 +/-10m   Unknown       Fault      

                 3-6         0 m       Unknown       Fault      

                 4-5         56 +/-10m   Unknown       Fault      

                 7-8         59 +/-10m   Unknown       Fault      

Interface Speed Local pair Cable length Remote channel Status

Gi2/41   1Gbps   1-2         44 +/-10m   Unknown      Fault      

                 3-6         46 +/-10m   Unknown       Fault      

                 4-5         45 +/-10m   Unknown       Fault      

                 7-8         46 +/-10m   Unknown       Fault

Interface Speed Local pair Cable length Remote channel Status

Gi7/1     0Mbps   1-2       N/A         Unknown       Terminated  

                 3-6       N/A         Unknown       Terminated  

                 4-5         12 +/-10m   Unknown       Fault      

                  7-8         13 +/-10m   Unknown       Fault      

Interface Speed Local pair Cable length Remote channel Status

Gi7/2     0Mbps   1-2       N/A         Unknown       Terminated  

                 3-6       N/A         Unknown       Terminated  

                 4-5         12 +/-10m   Unknown       Fault      

                 7-8         13 +/-10m   Unknown       Fault 


Let me know your what you think.  I've sent an email to my Cisco SE to request for an improvement of this feature.

PS:  Any Cisco staff willing to assist me in understanding why the results are "out of this place" is welcome. 

ghahn Wed, 03/28/2012 - 13:53

Nice article indeed, but it looks to me like Cisco totally underutilizes this feature/capability!

1. A switch should periodically scan ports in "notconnect" status, then report in "show interface status" whether there is a cable plugged in or not.   There are so many cases when I'd like to assign a port in a switch for a new end device but I cannot tell just by "notconnect" if there's something plugged in just not turned on.  This would fix that (I realize accuracy would not be perfect for very short cables...highly unlikely in closets).

2. For non-Gig ports, unused pairs could be scanned while the port is up and operational.

3. A "test cable-diagnostics tdr all [interrupt]" should be available with a warning that continuing will interrupt port operation. This would allow a "show cable-diagnostics tdr all" which would give a summary report for all ports showing pair length and status.

4. Add status to Cisco Prime NCS information.

Leo Laohoo Thu, 03/29/2012 - 14:14 (reply to ghahn)
4. Add status to Cisco Prime NCS information.

I attended the recent Cisco Live 2012 here in Melbourne, Australia and I've asked the speaker if TDR was or will be included.  The speaker was going to recommend this to the NCS developers.  Whether or not they'll incorporate this is subject to debate and speculation.  I do hope that they do because programming TDR is simple.

Two of my current colleagues were able to do TDR scripting using both SNMP and PERL.

To anyone reading this response and agrees that TDR should be incorporated to NCS I have this to say:  Contact your local Cisco Sales Engineer (not your local authorized dealer) and ask to raise a Product Enhancement Request (PER). 

3. A "test cable-diagnostics tdr all [interrupt]" should be available with a warning that continuing will interrupt port operation. This would allow a "show cable-diagnostics tdr all" which would give a summary report for all ports showing pair length and status.

I wouldn't recommend this feature if PoE was enabled because running a TDR on a PoE port would disable the power.  Now if you have a setup like PC-Phone-switch then your PC would also loose network connectivity because majority of phones don't have a "bypass" functionality.

However if Cisco will incorporate this with NCS then you don't need this, I think. 

PS:  Thanks for your comment.

ghahn Wed, 04/04/2012 - 06:44 (reply to Leo Laohoo)

Thanks for the PER advice.

As for scanning PoE, it depends, right?  802.3af uses the "used-pairs" (data pairs) for power even on 100Mbps, and therefore would not be disruptive; while Cisco legacy PoE indeed uses the unused pairs.  Anyway, the function would be able to determine whether it's safe or not at any given port.

Leo Laohoo Mon, 04/09/2012 - 15:33 (reply to ghahn)
As for scanning PoE, it depends, right?  802.3af uses the "used-pairs" (data pairs) for power even on 100Mbps, and therefore would not be disruptive; while Cisco legacy PoE indeed uses the unused pairs.  Anyway, the function would be able to determine whether it's safe or not at any given port.

Tried it on a CP-7975 and a 3750E and my phone died.  This is because alot of VoIP don't have "bypass" functionality.

Leo Laohoo Tue, 05/08/2012 - 23:16 (reply to ghahn)
1. A switch should periodically scan ports in "notconnect" status, then report in "show interface status" whether there is a cable plugged in or not.   There are so many cases when I'd like to assign a port in a switch for a new end device but I cannot tell just by "notconnect" if there's something plugged in just not turned on.  This would fix that (I realize accuracy would not be perfect for very short cables...highly unlikely in closets).

The Nexus 5K will support a "range" sub-command for TDR.

I don't think you can run TDR on the 2K. 

Leo Laohoo Tue, 05/08/2012 - 21:40

Switch#sh cable tdr int Gi2/0/16

TDR test last run on: May 09 14:36:06

Interface Speed Local pair Pair length        Remote pair Pair status

--------- ----- ---------- ------------------ ----------- --------------------

Gi2/0/16  auto  Pair A     65535 +/- 4  meters N/A         Normal

Pair B     65535 +/- 4  meters N/A         Normal

Pair C     65535 +/- 4  meters N/A         Normal

Pair D     65535 +/- 4  meters N/A         Normal

LOL!

mmillington_nal Wed, 08/29/2012 - 13:58

So, what results should we expect from a Gigabit port that is configured to 10 Mbps to be compatible with a device. Would we expect all Normal results?

Leo Laohoo Sat, 09/01/2012 - 03:37 (reply to mmillington_nal)

Hi Matt,

If you have a GigabitEthernet port and you forced the port to negotiate to 10 Mbps, then TDR will NOT work.  When you run the TDR combination commands on a port forced to negotiate to 10 Mbps, all the result will be "Not Supported".

Regardless, you should get Pair A and B as "Normal".

Leo Laohoo Sat, 11/10/2012 - 17:42

There is a BUG in this IOS.  When you run TDR on a 2960-series family of switches (2960/G/S) and at the same time running 15.0(2)SE, your port will get "STUCK".  This is a COSMETIC bug.  If you issue the command of "sh interface <INTERFACE>" you'll see a disturbing output at the end of the first line that goes like this:

<INTERFACE> is up, line protocol is up (connected: TDR running)

I can easily duplicate this with a 3750E and 2960, 2960G and 2960S. 

FlavioBoniforti1 Mon, 12/10/2012 - 06:10

Hello leolaohoo.

Could it be that the same bug affects C3560CPD switch?

And BTW: is this bug effectively recognized from Cisco? Or should I open a TAC case for it?

Thanks a lot.

F.

Leo Laohoo Tue, 12/11/2012 - 19:08 (reply to FlavioBoniforti1)
Could it be that the same bug affects C3560CPD switch?

Sorry for the late response.  I just saw this post.

The answer to your question is YES.  As long as you are running 15.0(2)SE.  I didn't bother raising a TAC Case because it's cosmetic.  I also believe that not alot of people will be using IOS version 15.0(2)SE anyway.

And BTW: is this bug effectively recognized from Cisco?

Not sure.

Justin Shore Tue, 01/29/2013 - 08:27

In my testing the bug in 15.0(2)SE is not just cosmetic.  It also prevents you from getting the TDR results in some cases.  All ports that I've attempted to run the TDR against that were in an up/up state resulted in a Pair Status of "Not Completed".  However if the port is up/down then the TDR test will run successfully.  The cosmetic bug still applies though, even to the successful up/down TDR test.  I have TDR tests that I ran on numerous 3750x stacks several months ago that have never completed.  I've verified these results on all my 3750x stacks running 15.0(2)SE.  These stacks previously had a 12.2 release on them and I know for sure that 3 of them were working fine at the time.

Here's the results of the broken TDR test on the up/up port:

Interface Speed Local pair Pair length        Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Gi1/0/5   1000M Pair A     N/A                N/A         Not Completed       
                Pair B     N/A                N/A         Not Completed       
                Pair C     N/A                N/A         Not Completed       
                Pair D     N/A                N/A         Not Completed       
Leo Laohoo Tue, 01/29/2013 - 12:57 (reply to Justin Shore)

Hi Justin,

Thanks for this information.

I have checked this "issue" on the newer 15.0(2)SE1 and it looks like it may have been fixed.

However, due to other people reporting CPU hog errors on 15.0(2)SE1, I still don't recommend anyone using IOS versions  12.2(58)SE, 15.0(1)SE and 15.0(2)SE and later versions. 

Justin Shore Tue, 01/29/2013 - 13:01

I agree.  In retrospect I wish I'd never upgraded to IOS 15.  It's been painful for the CPU utilization on all my switches.  I'm not sure if I can role back to an older release now that the ASICs have been flashed. 

I'm opening a ticket on 15.0(2)SE right now to report the bug.  I searched the bug DB and couldn't find anything.  I won't let them close it until the bug is documented.

Leo Laohoo Tue, 01/29/2013 - 13:10 (reply to Justin Shore)
I'm not sure if I can role back to an older release now that the ASICs have been flashed.

Yes you can.  Try my favourite:  12.2(55)SE6

I'm opening a ticket on 15.0(2)SE right now to report the bug.  I searched the bug DB and couldn't find anything.  I won't let them close it until the bug is documented.

Good on ya, mate!

FlavioBoniforti1 Thu, 01/31/2013 - 01:35

Hello everybody.

I'm quite new to this TDR stuff (which is really a cool feature indeed!), so I'm a bit confused about following results:

vxs12a1#show cable-diagnostics tdr int gi0/23

TDR test last run on: January 31 10:01:26

Interface Speed Local pair Pair length        Remote pair Pair status

--------- ----- ---------- ------------------ ----------- --------------------

Gi0/23    100M  Pair A     24   +/- 4  meters Pair A      Normal

                Pair B     27   +/- 4  meters Pair B      Normal

                Pair C     27   +/- 4  meters Pair C      Short

                Pair D     28   +/- 4  meters Pair D      Short

vxs12a1#test cable-diagnostics tdr int gi0/23

Link state may be affected during TDR test

TDR test started on interface Gi0/23

A TDR test can take a few seconds to run on an interface

Use 'show cable-diagnostics tdr' to read the TDR results.

vxs12a1#show cable-diagnostics tdr int gi0/23

TDR test last run on: January 31 10:26:56

Interface Speed Local pair Pair length        Remote pair Pair status

--------- ----- ---------- ------------------ ----------- --------------------

Gi0/23    auto  Pair A     23   +/- 4  meters Pair A      Normal

                Pair B     26   +/- 4  meters Pair B      Normal

                Pair C     27   +/- 4  meters Pair C      Short

                Pair D     28   +/- 4  meters Pair D      Short

My first question starts at the speed: why is it changing from 100M to "auto"?

Secondly, why would pair lengths for pairs A and B change?

Third: what should I understand of the pair status "short" for pairs C and D?

This is the switch version:

WS-C3560G-48PS     15.0(2)SE

Kind regards,

Flavio.

Leo Laohoo Fri, 02/01/2013 - 23:11 (reply to FlavioBoniforti1)

Hi Flavio,

Let me interpret your output.

My first question starts at the speed: why is it changing from 100M to "auto"?

When you run a TDR on a 10/100BaseTx, your link shouldn't go down (unlike the older IOS), but if you run the "sh cable tdr interface G0/23" again, you should see the speed come up.  Sometimes it takes awhile for the results to come back in.  I've seen this several times.

Basically, this means that there's a fault approximately 23-24 metres (+/- 4 metres error) from your switch port.  This does not mean 23-24 metres "as the crow flies".  It means 23-24 metres from the switch port WHEN you follow the cable.

Secondly, why would pair lengths for pairs A and B change?

Your cable length didn't change very much.  Granted it's a difference of 1 metre but in reality, it's not alot.  Also observe that there's an "error margin" of +/- 4 metres.

Third: what should I understand of the pair status "short" for pairs C and D?

In my experience, "short" means it's a short-circuit.  So what does this mean for pairs C and D?

Well, pair "C" controls your PoE and "D" controls your GigabitEthernet.  If you have a "short" then it means that the remote end will not get PoE and won't negotiate to GigabitEthernet.

Another thing ... I observe you are running 15.0(2)SE.  Take note that there's a bug.  If you do "sh interface Gig 0/23" you might see, in the first line of the output and to the right, an error like "(connected: TDR running)".  Don't worry, your interface is not "stuck" and normal traffic will continue to flow.  It's just an annoying sight.

FlavioBoniforti1 Mon, 02/24/2014 - 02:40 (reply to Leo Laohoo)

Hi Leo. I need to get back on this...

In fact the situation where I get pairs A + B = normal and C + D = short could be interpreted as "the cable is ok, the connected device simply negotiates 100 Mbps"... is my assumption correct?

Thanks and regards,

Flavio.

Leo Laohoo Tue, 02/25/2014 - 13:58 (reply to FlavioBoniforti1)

Hi Flavio,

Your assumption and understanding is correct:  The downstream client will ONLY negotiate to 10- or 100 Mbps.  If you plug a power end device, like an IP Phone or wireless access point, then it won't work. 

FlavioBoniforti1 Thu, 02/27/2014 - 08:36 (reply to Leo Laohoo)

Hi Leo, thanks for your feedback.

Now it looks like this on a couple of ports on a C3850 with the latest 3.3.2 IOS on it:

vxs12a1#sh cable-diagnostics tdr int gi1/0/45

TDR test last run on: February 27 17:23:19

Interface Speed Local pair Pair length        Remote pair Pair status

--------- ----- ---------- ------------------ ----------- --------------------

Gi1/0/45  auto  Pair A     124  +/- 1  meters N/A         Normal

                Pair B     124  +/- 1  meters N/A         Normal

                Pair C     27   +/- 1  meters N/A         Short

                Pair D     29   +/- 1  meters N/A         Short

vxs12a1#sh cable-diagnostics tdr int gi2/0/3

TDR test last run on: February 27 17:23:24

Interface Speed Local pair Pair length        Remote pair Pair status

--------- ----- ---------- ------------------ ----------- --------------------

Gi2/0/3   auto  Pair A     127  +/- 1  meters N/A         Normal

                Pair B     127  +/- 1  meters N/A         Normal

                Pair C     24   +/- 1  meters N/A         Short

                Pair D     26   +/- 1  meters N/A         Short

vxs12a1#sh cable-diagnostics tdr int gi1/0/9

TDR test last run on: February 27 17:23:28

Interface Speed Local pair Pair length        Remote pair Pair status

--------- ----- ---------- ------------------ ----------- --------------------

Gi1/0/9   auto  Pair A     69   +/- 1  meters N/A         Normal

                Pair B     69   +/- 1  meters N/A         Normal

                Pair C     46   +/- 1  meters N/A         Short

                Pair D     47   +/- 1  meters N/A         Short

vxs12a1#sh cable-diagnostics tdr int gi2/0/17

TDR test last run on: February 27 17:23:32

Interface Speed Local pair Pair length        Remote pair Pair status

--------- ----- ---------- ------------------ ----------- --------------------

Gi2/0/17  auto  Pair A     70   +/- 1  meters N/A         Normal

                Pair B     70   +/- 1  meters N/A         Normal

                Pair C     39   +/- 1  meters N/A         Short

                Pair D     41   +/- 1  meters N/A         Short

vxs12a1#sh cable-diagnostics tdr int gi1/0/44

TDR test last run on: February 27 17:23:36

Interface Speed Local pair Pair length        Remote pair Pair status

--------- ----- ---------- ------------------ ----------- --------------------

Gi1/0/44  auto  Pair A     123  +/- 1  meters N/A         Normal

                Pair B     65535 +/- 1  meters N/A         Not Supported

                Pair C     27   +/- 1  meters N/A         Short

                Pair D     29   +/- 1  meters N/A         Short

vxs12a1#sh cable-diagnostics tdr int gi2/0/42

TDR test last run on: February 27 17:23:40

Interface Speed Local pair Pair length        Remote pair Pair status

--------- ----- ---------- ------------------ ----------- --------------------

Gi2/0/42  auto  Pair A     69   +/- 1  meters N/A         Normal

                Pair B     69   +/- 1  meters N/A         Normal

                Pair C     46   +/- 1  meters N/A         Short

                Pair D     48   +/- 1  meters N/A         Short

I measured above ports, because the logs tell me that

025116: Feb 27 17:00:12: %ILPOWER-3-CONTROLLER_PORT_ERR: Controller port error, Interface Gi1/0/45: Power Controller reports Short detected

for each of the above ports.

At the time I did the TDR, all above ports were "notconnected"... and the weird one with 65535 meters???

Thanks for your thoughts/suggestions on this one...

Regards,

Flavio.

Leo Laohoo Thu, 02/27/2014 - 13:29 (reply to FlavioBoniforti1)

The output for Gi 1/0/44 could be faulty.  I've seen a case like and I immediately knew it was due to a faulty cable.

Gi 1/0/45 and Gi 2/0/3 both have a distance of >100 metres (Pair A & B).  I am suspecting this is correct and you'll never get PoE with that distance.  Look at the distance displayed for Pair C & D, they are almost similar.  By this, I'd believe the values to be correct.  You've got a bad cable and I think some of the wires were re-splice or you have a "consolidation point" somewhere between the back of the patch panel to the end of the line.

Look at the output to Gi 2/0/42 .  Look at the distance to Pair C and Pair D.  Again, the values look very similar to Gi 1/0/45 and Gi 2/0/3.

My recommendation is that you've got enough data to go back to your cable contractors and get them to re-test the lines affected.  I would also recommend that you DO NOT accept form of "testing" unless the result comes from a Fluke DTX-1800 machine. 

kebleview Thu, 02/14/2013 - 04:46

Hi. I am new to TDR but love it.  Quick question:

Does the connection to the target drop when the TDR test is performed?

(I get mixed results when I test).

Cheers. Ade

Actions

Login or Register to take actions

This Document

Posted October 11, 2011 at 2:57 PM
Stats:
Comments:62 Avg. Rating:5
Views:44348 Contributors:15
Shares:2
Categories: Switches
+

Related Content

Documents Leaderboard

Rank Username Points
1 177
2 64
3 60
4 50
5 23
Rank Username Points
5
0