Being a Cisco Partner I get the joy of learning new technology in the Cisco family. I was tasked to deploy a complete Meraki network with full redundancy at each layer of the campus. Everything was going smoothly until it came time to deploy the two Meraki MS320’s in warm spare mode.
Before I tell you about the problem let me describe the architecture of the network first. We had two MX100s on the edge in warm spare each with a connection to the internet, from there we duel homed down to two MS320s. The MS320s were setup to act as a collapsed core, with a routed link up to the MX100s (using the management vlan) and was the gateway for the various user vlans coming from the MS220 access switches downstream. Like i just said, we had MS220 access switches duel homed to the MS320 and set up as trunks (making sure spanning-tree was acting the way it should).
So here is the problem. We were having strange intermittent internet connectivity issues for devices downstream of the MS320s, however we did not have any issues pinging out to the internet from the MS320 switches. After a few hours of troubleshooting and countless calls to Meraki support we eventually figured out the issue.
As it turns out, the issue was related to the management vlan being used as the routed link to the MX100s. For those who don’t already know, Meraki’s warm spare on both the MS and MX lines use VRRP. In the design, all of the devices management IP addresses were labeled with both warm spare switches having separate static addresses. When it came time to implement we added the static address to each switch, then set the VRRP VIP to use the primary MS320s static address. This caused issues with the ARP table in the MX100s as the VIP virual MAC address and the primary MS320 burned-in MAC were fighting over who should be in the CAM table.
I highly suggest anyone who is deploying a Meraki network to check out the documentation for the Meraki product your deploying. Check it out at https://documentation.meraki.com
The InterNetwork 