Cable Testing issues on xGbE ports on MS350-24X

[itskdog]

I've been told by support that this is a known issue, but the case has been sitting open as "support action pending" for multiple years at this point (and every time I go back to see if there's an update, I just get a response that it's being actively investigated by the Engineering Team and there's no update on the issue.

Weirdly, it isn't showing as a known issue in the firmware update notes, when the switch lights issue has been there the whole time, so I'm getting worried it will never be fixed before the end of support, and would like to post in the community to see if this really is an issue others are facing as I haven't seen any other posts in a search on this topic.

Cable testing on xGbE ports on our MS350-24X results in an empty table being returned. It worked in the past, but just suddenly stopped.

It still works on the GbE ports, but our MR52 APs are all on the xGbE ports to get a 2.5GbE uplink, which is frustrating as these are the devices I find myself needing to cable test most often when I get email alerts of an AP going online and offline frequently, sometimes caused by a patch cable needing to be replaced, and being able to have certainty of that before going to the server cupboard would be handy.

[GIdenJoe]

I haven't really used the built in cable test feature that much.
If there are AP's that are really unstable or negotiating a lower speed often then I would personally go onsite with a fluke to verify onsite.

The only real useful thing about the builtin test is to get a sense of the length of the cable.  This way I could catch an electrician that pulled all the AP cables towards the same switch... 170 meters long...

If you don't get any responses it does not hurt to callin and input the case number.  There is a slight possibility that the problem is hardware related or extremely difficult to solve and maybe they just binned it.  But you need to know why.

I personally also have an issue that has been open for years and they have not been able to solve it yet and that is the unique client identifier issue.  The moment you enable that some clients are no longer showing up on the correct switchports and you get all kinds of incorrect logging.  I had two cases open for that issue since when that feature originally came out and it is still unsolved.  This is the reason I have to split up MX networks from MS+MR networks where there is L3 switching going on (even Meraki L3 switching).

[DarrenOC]

Electrician….cable/data engineer…two very different skill sets.  That’s why we see so many knackered and poorly installed cables.

[cmr]

Any curly haired data engineers 😉

[cmr]

@GIdenJoe I've had a case open for a week or so now about the second issue, for me it seems to only occur when there is a C9300L in the network, with the MS220s, MX75 and MRs/CWs it works fine.  What switches do you have in the network(s) that have this issue? 

[itskdog]

I've been replying to the case every so often looking checking for an update, surely the support teams are given the same training on both phone and email, so surely I'd get the same response on the phone, right?

I'd be shocked if a company the size of Cisco has such poor customer service that they "binned" tickets that were too difficult for their engineers.