Possible solution    Meraki access manager + cloud pki   Check out this solution    Meraki access manager + cloud pki    https://www.hypershift.com/blog/meraki-intune-cloud-pki ... View more

Take a look at this solution.  Meraki access manager + cloud pki   https://www.hypershift.com/blog/meraki-intune-cloud-pki ... View more

Take a look at this option   Meraki access manager + cloud pki   https://www.hypershift.com/blog/meraki-intune-cloud-pki ... View more

I have been by Cisco folks that this is exactly what happened. ... View more

MS 18.1.1 Beta firmware release notes indicate a fix for this issue. I haven't tested it yet though. ... View more

These were completely non cisco, but I meant speed wise as that was the reference I made. These were 10gb sfps in 1gb slots ... View more

Ok adding to this, seems like when someone is connected to the AnyConnect the customer loses connection to the far end of the S2S VPN locally. AnyConnect user doesn't seem to lose connectivity to the S2S VPN at all just local LAN (Wi-Fi) users. Can see lots of logs of DNS failure on the Wi-Fi during that time, DNS server is at the far end of the S2S VPN. Anyone seen anything like this before?    ... View more

It is working fine for one of my customers (actually, this is an MX105 now I double check it).   ... View more

I can't add much more except to say you tend to use BGP from the VMXs back to your layer 3 core switches to handle route redistribution. https://documentation.meraki.com/MX/Networks_and_Routing/Border_Gateway_Protocol_(BGP)   ... View more

^^ This but even providing feedback has been watered down, you use to be able to include screenshots / attach files but thats a thing of the past now.  ... View more

Is the MX the only firewall that does not use it's own lookup?  Most firewalls I've seen work just fine by doing their own lookups.  Might be a good idea to implement this on the MX too.  Too many rules I have need to double up by adding the IP's from the responses I do myself. ... View more

Oh okay nice.  So when a vlan is scoped it will behave like a group policy that overrides the local firewall but leave other vlans untouched. ... View more

I am personally very interested to see how a Cisco URWB bridge would work in this situation since that solution can handle all the normal LAN extention features like VLANs and broadcasts. ... View more

It is bad design to interconnect your access layer switches. Always double uplink your access switches to a distribution switch/stack. And of course if you can make sure your uplinks use a different path for decent redundancy. Also having copper links in uplink port-channels is a risk since you can have negotiation issues where one link gets negotiated lower than 1 Gbps causing your port-channel to drop.  So fiber is recommended between distribution and access layer even if you are only using 1 Gbps links. ... View more

Ah, so that explains the odd behaviors I've been seeing on my Apple devices at home in my lab. ... View more

  I didn't even see your post when I was posting so I believe we posted on the same time 😉 The info provided by our friend @alemabrahao is based on a misunderstanding that OP wants to route between auto and non meraki VPN. The way the MX knows which local subnets to potentially explose to the non-meraki peer is by enabling them on the AutoVPN settings.  So in any case the subnet is explosed whether you want it or not but the outbound firewall rules can handle this just fine. I only wish Meraki would finally separate the two types of VPN because this is a shortcoming in the VPN settings since you always expose your local subnets even to other Non-Meraki VPN peers even when they don't need it.  Luckily the non-Meraki VPN negotiation has been solid for quite a few major MX versions now and we don't see any issues where there is a mismatch between the remote side only needing one of our subnets while we expose multiple of our subnets.  The phase 2 SA's seem to negotiate just fine. If they would just completely seperate the config between non-Meraki and AutoVPN that would actually simplify things alot!!!!!  And give us our route based VPN's without needing BGP now please! ... View more

You need to have ISE3.3 Patch5 or later release. If you look at the Release Notes, the corresponding bug ID addressing the issue is CSCwk30242, which is available starting from Patch5: https://www.cisco.com/c/en/us/td/docs/security/ise/3-3/release_notes/b_ise_33_RN.html   The fix is also available for ISE 3.4 starting from Patch2: https://www.cisco.com/c/en/us/td/docs/security/ise/3-4/release_notes/cisco-identity-services-engine-release-notes-34.html     ... View more

And I ALWAYS use a vIP.  This is the best solution since you always have the same outbound IP. Of course you can use different IP's in the same subnet for 1:1 and 1:many inbound NAT connections however the Secure client VPN and non-meraki VPN are always terminated on the either the vIP if you use it or the physical IP of the active forwarding MX if you don't use vIP. This means your IP changes in a failover causing either a temporary delay if you use the meraki dynamic DNS hostname or a permanent stop of function if you use a fixed IP. ... View more

Both MX devices need L2 connectivity to each other to pass their VRRP keepalives.  So the FTD uplinks must either be a bridge group or interfaces connected to intermediate switches to split between both MX units. ... View more

Two days ago Cisco released the 17.18.1 IOS-XE release so it's only a matter of time before we get the version in dashboard 😉 ... View more

So here a quick update: Support is unfortunately very slow at the moment. They are currently telling me, that if the switch is onboarded in cloud configuration mode, the CLI is read-only and are referring to this documentation: https://documentation.meraki.com/MS/Cloud-Native_IOS_XE/Cloud_CLI_for_cloud-native_IOS_XE#Hybrid_mode_IOS_XE_configurations I cannot really read that here. It just states that you have to change the mode in org settings. However, the error message is gone now and I am only getting read-only access without any errors. ... View more

I’d like to share some feedback regarding the recent updates to the Client360 dashboard. While I appreciate the enhanced visibility into client onboarding issues and the streamlined troubleshooting workflows, I’ve noticed several limitations that impact our day-to-day operations: Loss of Application Visibility: The removal of built-in application and traffic insights—unless ThousandEyes is integrated—has reduced our ability to monitor client experience effectively. This functionality was previously available without additional licensing and was critical for policy setup and performance analysis. Licensing Barrier: Requiring ThousandEyes for full application monitoring introduces a cost and setup barrier that may not be feasible for all organizations, especially those who relied on the legacy features. Limited Historical Data: The one-week lookback window restricts our ability to perform long-term trend analysis and identify recurring issues. Fragmented Context: Navigating between dashboard sections sometimes causes loss of context, making it harder to track client issues across different views. We value the direction Meraki is taking with Client360 and hope future updates will restore some of the legacy functionality or offer more flexible integration options. Thank you for your continued innovation and support. ... View more

Darren made an excellent point with the amount of tunnels since if both are running in NAT mode and each side has 2 ISP's you can take your site count and quadruple that number to know your tunnel count. However maximum sessions is indeed another issue to tackle with.  It must be that you have too many hosts each making small concurrent sessions.  In that case if you want to keep the SD-WAN design you may need to change up to one-armed concentrators instead and group branches each to their own preferred concentrator. ... View more

When physical stacking ports go down and your stacking cables have been tested then you simply have a crashing switch and are in need of an RMA.  That support engineer shouldn't have left you by yourself and should have helped more. I suggest you call in about the case and friendly ask for an RMA. Do know that MS 410's are practically no longer in supply and the chances they will give you a C9300 variant instead is possible.  That would be a C9300-48S.  In that case make sure they replace both stack units since you cannot stack a C9300 with an MS410 obviously.  And they will have to convert your licenses. I recently had a simple issue with a MS410-16 stack and they replaced it with C9300-24S switches.  And had those issies where they only replaced one at first ;p. ... View more