Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About akh223
akh223
Getting noticed
Member since Mar 18, 2020
Dec 18 2024
Community Record
27
Posts
32
Kudos
1
Solution
Badges
Oct 18 2022
6:25 AM
We continue to see this problem on MS425's, MX100, MX250, and MS225 series switches. The MS425's are still the most problematic.
... View more
Jan 24 2022
6:44 AM
This is the info support gave me in my case. "You could be hitting a known issue on our MX15 platform which can be addressed with a backend change. Please call us during a maintenance window so we can apply this backend setting. The problem you're seeing is that the device is rebooting and thus triggering a failover, what's causing the behaviour is flow tables being very large on the MX."
... View more
Jan 19 2022
2:23 PM
I sent you a message with the info.
... View more
Jan 19 2022
1:39 PM
We continued to see the MX HA pairs reboot when on MX 15.44. A support case was opened, and Meraki support knew of some memory settings that they could tweak to keep the crash/reboots from occurring. We have not seen the MX HA pairs crashing/rebooting since this memory setting has been tweaked by support. Wish I could tell you exactly what the setting was called, but support wouldnt tell me.
... View more
Nov 9 2021
4:36 PM
1 Kudo
@jay_b yes, we have seen it with a MX250 HA pair that we have in production.
... View more
Oct 25 2021
2:55 PM
Looks like we got hit with this today. Our HA pair of MX450's that act as our SD-WAN concentrators started having problems. The primary went completely unresponsive and had to be power cycled to come back online. The spare took over, and for some reason reported that it had a bad power supply, which it didnt....lights were fine. Looks like I am going back to 15.43.
... View more
Oct 20 2021
6:29 PM
We are seeing issues like this with a new set of MS425 cores also. Did support ever give you any clues as to what was happening? This is not our first MS425 stack, and the others seem to work correctly. We are using MS225 stacks at the remote IDF's, and I did notice that for some reason, the Aggregate uplinks between the core stack, and the IDF stacks started to put one of the links in STP blocking as it started seeing a loop instead of an aggregate.
... View more
Oct 7 2021
6:13 PM
I havent noticed the links not coming back on the MS425's, but I also havent tested that scenario. If I get some time next week I will put a MS425 up in a lab and test it out to see if I can replicate your problem.
... View more
Oct 6 2021
11:13 AM
2 Kudos
Yes, the SFP's work and will provide a link.....but the tension on the cables can also pull them out over time since they are not secured in the sfp port.
... View more
Sep 17 2021
6:45 AM
3 Kudos
After further investigation, I believe that this is going to be a widespread issue with Meraki manufacturing. I have now tested 6 new MS425's and 6 new MX100's. They are all exhibiting the same issues with copper SFP's. The Meraki copper SFPs; (which are simply Cisco GLC-TE's in a Meraki bag) are only locking in to 84% of the ports on these devices. I am trying to push Support to figure out what is really happening, but so far I am not seeing any interest from the Meraki side in actually figuring out what has happened.
... View more
Aug 29 2021
6:59 PM
2 Kudos
Yes, to me it looks like the metal SFP ports are a little to far back, and the SFP's can go far enough in to lock. The SFP's hit the front metal faceplate that surrounds the ports before the SFP is all the way locked in. What's strange is that it is the same way on 2 new 425's and 2 new MX100's. I hope we arent seeing the beginning of a manufacturing error that is going to be present on a large number of 425's and MX units.
... View more
Aug 29 2021
5:34 PM
1 Kudo
@BlakeRichardson @PhilipDAth I have never had this problem before on our MS425's either; but these 2 newest MS425's sure have an issue. Waiting to see if support will do anything to get me a RMA on this gear, as we cant leave these in production with no way of holding the SFP's in the switches.
... View more
Aug 29 2021
10:55 AM
1 Kudo
Does anyone else have any experience with MS425 core switches not being able to lock in copper SFP's? I just installed a stack of 2 MS425's, and on both switches there are multiple SFP+ ports that will not lock in a copper SFP. It looks like the Copper SFP can not be put in far enough to engage the locking mechanism. We have tried Cisco and Finisar SFP's, and I am wondering if anyone else is seeing these problems now also? It looks to me like the SFP+ ports on the MS425's may be recessed just a tiny bit too much behind the face of the switch? Also have this same problem on a pair of MX100's....but I dont really need the copper SFP ports on it.
... View more
May 6 2021
10:33 AM
1 Kudo
Glad to help!! On firmware version 15.42 our SAP traffic works properly, but we found another application that was incorrectly categorized as bittorrent. Of course, you cant do the AnyConnect VPN stuff on 15.42, so you are at the mercy of Meraki support and the next version of code they release.
... View more
May 6 2021
6:44 AM
1 Kudo
Not sure about the AnyConnect fixes, but 16.6 is still incorrectly categorizing SAP client traffic on my test box.
... View more
May 5 2021
6:53 PM
2 Kudos
Not sure if this will help, but I have identified and opened a case with Meraki Support about our MX's that we are testing 16.4 on. 16.4 is incorrectly identifying our SAP application traffic as P2P application (bittorrent), and since I have a rule that blocks all P2P applications it is getting blocked. I wonder if some of your O365 traffic is being classified as an incorrect application and being blocked by the Layer 7 firewall rules? Do you have any Layer 7 firewall rules? If so, can you disable them and see if everything starts working? If you are dumping all the MX logs to a syslog server, you can search the syslog messages for "l7_firewall" to see if you are getting traffic blocked. I dump ours in to splunk, and it shows up like this: May 5 21:46:25 10.x.x.x 1 1620265585.486264487 XXX_FW01 l7_firewall src=10.X.X.X dst=X.X.X.X protocol=tcp sport=58700 dport=3299 decision=blocked Hope it helps.
... View more
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 3977 | May 5 2021 6:53 PM |
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 3 | 14104 | |
| 2 | 14007 | |
| 2 | 14243 | |
| 2 | 3977 | |
| 1 | 13430 |
© 2025 Cisco Systems, Inc.
