Cable Testing issues on xGbE ports on MS350-24X

itskdog
Just browsing

Cable Testing issues on xGbE ports on MS350-24X

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.

5 Replies 5
GIdenJoe
Kind of a big deal
Kind of a big deal

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
Kind of a big deal
Kind of a big deal

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

Darren OConnor | doconnor@resalire.co.uk
https://www.linkedin.com/in/darrenoconnor/

I'm not an employee of Cisco/Meraki. My posts are based on Meraki best practice and what has worked for me in the field.
cmr
Kind of a big deal
Kind of a big deal

Any curly haired data engineers 😉

If my answer solves your problem please click Accept as Solution so others can benefit from it.
cmr
Kind of a big deal
Kind of a big deal

@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? 

If my answer solves your problem please click Accept as Solution so others can benefit from it.
itskdog
Just browsing

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.

Get notified when there are additional replies to this discussion.