Hi @TyShawn    I'm glad to hear that the initial issues you encountered with our firmware update that introduced IPv6 have been resolved.  I appreciate your feedback and understand the importance of having control over network configurations.  We strive to align our products with the needs of our users, balancing simplicity with providing necessary options. I apologize for any difficulty you experienced when communicating your concerns initially, and I assure you that your input is valued.  We appreciate your patience and understanding as we work towards implementing more functionality and give this request further consideration in the future. Thank you for your continued support. ... View more

Amy reached out out of band, so I am hoping to help answer the question. There are several reasons why disabling IPv6 on WAN interfaces is not supported, but I'll focus on the main ones.  Firstly, our cloud-connected products are designed to provide management flexibility using IPv4, IPv6, or both, ensuring they are future-proof.  Secondly, similar to IPv4, we maintain this approach for Dual Stack to avoid unnecessary complexity, as disabling IPv6 is not a widely requested feature.   Additionally, when IPv6 is enabled on the MX WAN uplink, it is limited to MX communications and does not impact client traffic or behavior. This is particularly true if the LAN/VLANs are not configured for IPv6, as no IPv6 prefix is available or expected to be delegated in this setup.  If IPv6 is not desired at all, it can often be disabled on the upstream device itself too. ... View more

Hi @jbright Thanks for the post and your insights.  In this situation the reason it likely works is because the SIM was not new and hence was already activated.  To that point the teams are working on FirstNet approval as you mentioned, so that will come in time.  As for the color of your MG, these were a special batch for Cisco Live purposes and can confirm normal production units will be the normal color like the MG51. ... View more

Welcome John! Its quite amazing to have a virtual Cisco Live and not being limited by space and location.  I've been enjoying some of the sessions myself.  Do you have any favorites? -Raul ... View more

Welcome Mike!  I think 2013 was around the time I got my first stack through a CMNA in Raleigh NCas well (MX60, MS220P and an MR26).  I was blown away by how quickly it was to replace some of my other gear and fell in love with Meraki then :).  Glad to see you had a similar experience too.   -Raul ... View more

Hi Everyone!   I am a long time lurker not poster, but here goes since I noticed an update in the IPv6 @ Meraki thread and wanted to get it in front of everyone in this thread as some may not be aware off or following the update thread. TLDR: Improvements to client VPN functionality to handle IPv6 only clients to connect through a NAT64 from their providers https://community.meraki.com/t5/Full-Stack-Network-Wide/IPv6-Meraki/m-p/81683/highlight/true#M1465 If you have IPv6 only connectivity and are leveraging NAT64, I urge you to share it with the community your ISP and if your setup works or doesn't.   Stay safe & healthy!   Cheers,   -Raul ... View more

There are a couple of ways to handle tags (The article assumes more than one MX, so the location tags are never removed/deleted hence they always exist in another network).  You can accomplish this by having an empty network hold the tags so they always exist.   1. Create a VPN config holding network:  (Network itself should not contain an MX - Good in the case only 1 MX has VPN config) Organization > Create Network > Select Security appliance name "VPN Tag Hold" 2. Add a tag to the network ^ ie. [location]_primary_up and [location]_backup_up Never remove the tags from this network, so they always exist. 3. Apply this tag to the multiple Non-Meraki Peers availability section This will hold the Non-Meraki VPN peers config as you switch real network availability tags as it cannot be empty. Then you can assign and remove the tags from the live MX network to fail between them without the error they don't exist. The other option would be to have a hold network and a tag per location that represent the MX location itself.  You would then have a VPN configuration in the availability will always have a holding tag from the network that's not used such as vpn_tag_hold (This merely maintains the configuration available in the site to site vpn Non-Meraki peers section.  From there you could always just add/remove the specific network's availability tag (ie. if primary is down, you'd use [location]_backup_up tag in the 2nd 3rd party peer however if the primary is up this config would be removed and you'd have [location]_primary_up in the 1st 3rd party peer availability section)   Cheers, -Raul ... View more

Think about it like this. Each network will have [Location]_primary_up and [location]_backup_up. So these will be on the network at all times. What changes is that you either have the [location]_primary_up or [Location]_backup_up configured as the selected tag in the Non-Meraki VPN peers > Availability section. The only time the tag information changes is what's configured in the availability section. The MX is always configured with both tags. So if you have two 3rd party peers, you'd remove the tag from the availability on the failed primary and add the tag to the online secondary peer (Vice versa, when you fail back to primary).  There should only be either [location]_primary_up or [location]_backup_up configured in the VPN section at a time. Hope that makes sense! ... View more