Greetings @hmc250000! What @UCcert is true! HA configuration is quite straightforward and the doc you originally posted should do! To your questions: "Where do we configure the VIP?" The VIP can only be configured on the WAN interfaces "Can we use private ip addresses?" Private address space can be used for your WAN interfaces including your VIP - likewise, these must be in the same subnet. So just make sure there is at least a /29 to accommodate the 3 address. A-WAN1/B-WAN1/VIP How would this work for the LAN?" Typically, we see, depending on the placement of the MXs and the gateways, the LAN ports configured as transit or management networks. There also needs to be communication between the LAN ports of each MX via a switch downstream in order to exchange VRRP heartbeats. The MX doesn't participate in STP, so it is best like Willette.Works' doc mentions to prune out your Mgmt/Heartbeat VLAN on a specific LAN port to prevent unintended BPDU flooding.   Hope that helps! ... View more

Hey @Greyston! Thanks for reaching out! Quick clarification: Meraki APs don't tunnel/connect/need a Cisco WLC for their connectivity. They will, however, listen to your other Cisco AP wireless infrastructure and adjust their channels, power, etc to make sure the experience of connected clients is ideal. Another point to note: Meraki MESH will only mesh with other Meraki APs. This is only because Meraki developed a proprietary mesh that will seamlessly allow a wired uplink to flip to a wireless uplink and not miss a beat with connected wireless clients. So, all that's to say - If you would like to use a ruggedized Meraki AP anyone of these outdoor models (MR70/74/84/76/86) should work! You could drop a couple of these and barring wireless environments be able to mesh them with any other Meraki indoor AP in an area that doesn't require the ruggedization. Also, here's an interesting design if you want to wirelessly mesh a switch over as well! https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Extending_the_LAN_with_a_Wireless_Mesh_Link If you weren't to go the Meraki route, you can buy a Cisco AP and install Autonomous mode firmware and build a WGB via CLI to talk to another Cisco autonomous mode AP... but that's another forum for another time 😉 Hope that helps! ... View more

@arapheon VRRP will absolutely be implemented as this is the mechanism we leverage to elect which is the active MX. Do keep in mind VRRP advertisements are sent out the LAN ports only (once every second) as there is no guarantee the WAN ports will be able to communicate so they won't be sent out those interfaces. As far as your initial post about DHCP/VPN drops, I would definitely open a ticket with support so they can validate the issues you're seeing and offer their expertise!  Hope this helps! ... View more

Yep! What @cmr mentioned! The MX will be your gateway for all your devices... and it's WAN port will be plugged into your cable modem (which will give out DHCP by default) - then your MX will NAT all your network devices down stream. The FLAW with your design is the COPIOUS amount of hours you'll spend configuring, troubleshooting, upgrading, etc all your Ruckus gear O:)! An MR46 or two would be a nice touch! 😉 Cheers! ... View more

NO NAT requires 15.3+, so while your 15.42 is not labeled "beta" it does support it and support will be able to find that documentation.   Keep in mind: This is a beta feature, and w e do not recommend beta features for production environments, however, if your deployment requires the use of this feature, we recommend testing in a lab environment first.   Also, if this is a scenario to terminate a MPLS connection, we recommend using the MX in passthrough mode or terminate MPLS connections on the LAN side of the security appliance whenever possible. ... View more

@ww is correct - you can call into Meraki Support and they will be able to enable a No-NAT option, however, there are other ramifications that will happen that Support can explain.   I'm curious what the design is because we have a lot of customers who manage the Meraki way without the No-NAT option. A lot of times Meraki solves problems differently than the traditional networking ways and therefore one may not need a feature that was traditionally used in the past. ... View more

@SdotB While I may not be able to diagnose what is wrong, hopefully this could help you grasp the "Reason:Reserved"! 😉 Reason codes are based on  IEEE 802.11-2012 standard and for the wireless LAN management frame parameters. So, when there is a deauth and that deauth meets specific IEEE specifications, that reason code will be reported. However, when that deauth doesn't match, nor meet any of the IEEE defined specifications, the reason will be: "Reserved". (Which admittedly can be a LOT of reasons!) So, if you were to run a packet capture from the dashboard on the AP and dig into the frames, you'd be able to find the Deauthentication and management frames report that same reason. My recommendation would be to run a monitor mode capture and then submit that to Meraki Support. A monitor mode capture will be able to hear all the things in the air and not be limited to just want the AP hears. This could help illustrate and/or isolate where to focus your attention. Instructions for setting up a monitor mode packet capture can be found here: https://documentation.meraki.com/MR/Monitoring_and_Reporting/Capturing_Wireless_Traffic_from_a_Client_Machine  Hope that helps! ... View more