I'm in the process of install a new Meraki network and would like the transit VLAN between the WAN provider router and the Meraki Core switch to be different to the VLAN used for the management interface on the Meraki Core switch and all downstream Meraki Edge switches.
My concern is whether or not the Meraki Core switch will be able to talk to the Meraki cloud through this setup.
My theory is that it should work if I create a Layer 3 interface (SVI) on the Meraki Core for VLAN 40 (the intended Meraki management interface VLAN) and get our WAN provider to have a static route on their WAN router pointing to this as the next hop for the VLAN 40 subnet (along with routes to all other SVIs/VLANs on the switch, and a connected route for the transit VLAN 200).
I'm only slightly doubting the design as I've only come across illustrations where the Meraki switch on one end of the transit VLAN has its management interface belonging to that same VLAN and configured an IP address in that address space.
Below shows the proposed layout. I'd be grateful if someone can confirm if this setup will provide my Meraki core switch with connectivity to the Meraki cloud.
Solved! Go to Solution.
Hey, I haven't read your explanation entirely but I get the main point.
You basically have two options in this kind of design.
1) You have a totally separate VLAN on the upstream router that only serves for the management of all your Meraki devices lan devices like switches and access points. And then you have your transit VLAN between the router and your core switch. In this case you will have a default gateway on the management of all your devices which is the router. And you will also have a 0.0.0.0 route defined on your coreswitch pointing to the transit VLAN router IP as next hop.
2) You can have only 1 interface on the router which is the transit VLAN. In this case your subnet used in the transit VLAN must be large enough to accomodate the routers IP, the core stack IP and all the management IP's of the core stack members. Then all switches and access points downstream of the CORE will have another management VLAN where they are in and they point to the CORE as default gateway.
Thanks for the reply.
I'll need the transit VLAN to carry traffic to/from all subnets defined on the Core switch (not just management) - i.e.
VLAN 10: 10.1.1.0/24, SVI 10.1.1.254
VLAN 20: 10.1.2.0/24, SVI 10.1.2.254
VLAN 30: 10.1.3.0/24, SVI 10.1.3.254
VLAN 40: 10.1.4.0/24, SVI 10.1.4.254
VLAN 200: 10.1.200.0/30, SVI 10.1.200.2
I'm intending VLAN 40 to be the management interface VLAN for all Meraki switches (core and downstream edge switches), so core will have interface IP 10.1.4.1 and edge01 will have interface IP 10.1.4.2 for example. However, I'd like the transit VLAN to be a totally separate VLAN (VLAN 200)
My theory is that the Meraki cloud should be able to reach the Meraki core on its 10.1.4.1 address in this way:
Meraki cloud traffic destined to the Meraki Core (10 1.4.1) will hit the WAN router which will then point to 10.1.200.2 as the next hop IP and send it down the link to the Meraki core switch.
The Meraki core switch should then receive this on its 10.1.200.2 SVI and internal routing on that device should result in it being sent to its management interface (10.1.4.1).
That's what I'm thinking...
There are some other topics about this. however at some switch types this works or worked before and some types do not work at all, but its recommended to have the management ip of the svi/core switch in the uplink subnet.
Thanks @ww , that's really helpful.
It does look like what I'm trying to do isn't currently officially supported by Meraki 😞
My design would rely on the switch using the default route in the internal routing table to route out and reach the Meraki Cloud/dashboard and that post you mention states the management interface cannot use the internal routing table.
Hope it is something that Meraki can add as its a common feature among other types of switches such as Cisco catalyst/IOS.
I also first learned Cisco through netacad. So I do know it’s hard to miss features which are common. However you need to wrap your head around the whole cloudmgmt.
Think of the management ip of a meraki switch as being purely out of band like a management Port of a switch living on it’s own VRF. And you can’t plug that mgmt Port into the switch itself. And that is why each stackmember has it’s own mgmt Ip which has nothing to do with the upstream transit VLAN.
I prefer using a separate VLAN directly terminated upstream. But in your case you could change your /30 into a /29 and put both stackmembers mgmt in the same subnet as the stack IP.