Cable Test TDR CLI on C9300L switch

[eeebbunee]

Hello Professionals!

I am using Cisco 9300L-48P-4X-E switch on my company, and realized that showing the result of command line,

'test cable tdr int gi1/0/x' doesn't provide me the information correctly.

Following the Cisco references, it seems like some C9300 series switch can only check the tdr command status, but I couldn't throw my hope.

Cause, I am able to get the command result like this:

Interface  Speed   Local pair        Pair length              Remote pair      Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Gi1/0/23 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

It seems like they CAN, but they don't show me.

Is it impossible that I can get tdr result from Cisco 9300L switch?

Thank you for reaching my subject.

[Flavio Miranda · Accepted solution]

Hi

You switch is on the supported list.  Which IOS  version is it?  You are probaby hitting the Bug CSCvw97924  

https://bst.cisco.com/bugsearch/bug/CSCvw97924

Symptom: After running the cable diag test, the status of the interface will show TDR running, and test results will be Not complete, example as following: Interface Speed Local pair Pair length Remote pair Pair status --------- ----- ---------- -----

Known Affected Releases (1 of 1)

17.5.1

TDR feature is supported on the following modules:

• C9300-24T

• C9300-48T

• C9300-24P

• C9300-48P

• C9300-24U

• C9300-48U

• C9300-24UX

• C9300-48UXM

• C9300-48UN

[eeebbunee]

My switch is running on version 17.8.1r.

Probably that's why.. so this bug is still going on, until Cisco provides improved OS, right?

Thank you for letting me know.

[Flavio Miranda]

It should be fixed on the following version. But, only testing to know.

17.9.3a

17.9.3

17.9.2a

17.9.2

17.9.1y

17.9.1x1

17.9.1x

17.9.1w

17.9.1a

17.9.1

17.8.1a

17.8.1

17.7.2

17.7.1b

17.7.1a

17.7.1

17.6.5

17.6.4

17.6.3a

17.6.3

17.6.2

17.6.1z1

17.6.1z

17.6.1y

17.6.1x

17.6.1w

17.6.1a

17.6.1

17.5.1c

17.5.1b

17.5.1a

17.5.1

17.11.1a

17.11.1

17.10.1b

17.10.1a

17.10.1

17.05.01c

[Leo Laohoo]

TDR no longer works correctly on switches with IOS-XE.  The bug not just affect Catalyst 9k but also 3650/3850.

[eeebbunee]

Right.. that sounds bad to me.. 

Thank you for letting me know.

[Leo Laohoo]

Hey @Rich R, 

Did TAC came back with any updates to C.SCvw97924?  

Bug ID shows fixed versions and I am not totally sold by this.  The Known Affected Version(s) of "17.5.1" is not even close to "accurate".  Does this mean that TAC only "tested" or verified only 17.5.1?

[Rich R]

That's actually not the same one we raised @Leo Laohoo 
Ours is https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwd97177
Logged against 17.3.5 - so obviously what they tested in lab even though we reported it on 17.6.2.

As for the status of CSCwd97177 - on Monday we got the same update we've been getting for months "the BU is discussing with the chipset vendor". We were promised a real update this week but it's no surprise that we didn't get one.  It feels like it's been relegated to the "will never get fixed" category at this stage since they can't even give us an actual update and I can't believe they've been "talking to the vendor" for 6 months without any progress.

@eeebbunee are you sure your IOS version is 17.8.1r (I don't think so)?
That sounds like the ROMMON version (the clue is the "r" at the end of the version number).

Use "show ver" to check your IOS version?

The good news is if you run a version affected by CSCvw97924 you can update to a fixed version but the bad news is that then even though the tests may complete the results could be completely unreliable because of CSCwd97177.

[Leo Laohoo]

I am very confident CSCvw97924 & CSCwd97177 are the same.

Whether it is a 3650, 3850, 9200, 9300, 9400 or 9600, TDR results are neither reliable nor accurate and cannot be trusted across all IOS-XE based switches.

Unless there is a very big/large Cisco client &/or an "executive sponsor" this bug is not going to get fixed.  

[rdeluhery]

What vendor are they talking to, regarding the bug?  Is it Broadcom?  The TDR test can be very helpful.  Really though,  on a daily basis,  it is rarely used by most folks.  I can see why you have the delay in fixing this.  If more people used it, it would be flagged as a major issue. 

I wish Cisco would take more into the physical layer of the interfaces and add more functions.  I'd like to see intelligent patch panels and network ports that could automatically do the TDR test based on certain configurations or commands,  then also configure the ports specific to the output of the TDR test.   Also perhaps to send a TONE signal to make toning cables easier.  

rfid,  or other methods of smart patch panels,  combined with CDP neighbor,  could show a good network map.   something similiar is already being sold by others.

[Leo Laohoo]

---

@rdeluhery wrote:
If more people used it, it would be flagged as a major issue. 

---

It is not a question about "If more people used it" but, rather, "If more IMPORTANT people used it". 

I have seen bugs with several hundred of TAC cases not getting fixed but on the flip side, I have seen TAC investigate 3rd party optics integration issue after a very important client (important enough not to ignore, or else!) raise TAC cases and get the same bug fixed in later releases.  
 

---

@rdeluhery wrote:
it is rarely used by most folks.

---

I doubt it.  TDR is one of the tools TAC is trained how to use and it is one of the troubleshooting guides in DNAC.  

Without any "executive support" or a push from a very important (external) customer this bug is going into the too-hard basket and will stay there until the next foreseeable future, gathering dusts and unfixed.

---

@rdeluhery wrote:
Also perhaps to send a TONE signal to make toning cables easier.  

---

Now that is an idea.  

No offence, talk to your Cisco Account Manager and ask them to raise this idea with the BU.  The worse they can say is "no" but at least you tried.