Separate VLAN for Transit VLAN versus Meraki Core switches management interface

[Anthony202]

Hi there

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.

• Transit VLAN:
• VLAN 200: 10.1.200.0/30
• Meraki Management Interface VLAN
• VLAN 40: 10.1.4.0/24

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. 

Thanks

Anthony

[GIdenJoe]

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.

[Anthony202]

Hi Joe

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...

[ww]

 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.

https://community.meraki.com/t5/Switching/Management-VLAN/m-p/19025

[Anthony202]

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.

[PhilipDAth · Accepted solution]

Here is the main crux of it - the management configuration can not use a L3 VLAN configured on the switch for its default gateway.

[Anthony202]

Thanks @PhilipDAth and @GIdenJoe. You’ve saved me a lot of potential pain and head scratching. 

[Maaaaaaaaaaaark]

Just wanted to say thank you as this really helped me out with moving the VLANs from an MX to the switch stack. Was a little leery of blowing away the DHCP reservations and VLANs on the MX but it worked out fine! Thanks again folks!

[GIdenJoe]

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.

[FrequentRain]

@GIdenJoe Just digging up an old thread. 

We are currently looking at implementing Option 2 as the hosted ISP has requested the use of a transit VLAN.  Just thinking about the points you raised.

I assume this setup would require the transit network to be a L3 interface on the core?  I thought we could not use a L3 interface for management that is provided by the same switch, or will this be okay as the default gateway of the cores will be the router?

I assume that under the Switching > Configure > Switch Settings i would have to specify the management VLAN as the one that will be used downstream by the other switches and WAPs.  Would this have any impact on the cores management VLAN and try to change it at global level or will the static assignment overwrite?

[GIdenJoe]

Talk about timetravelling 😉

So the while the management of the core switches itself is separate from the routing that it provides for downstream devices the limitation is that you cannot use the routing of the core switch to route it's own management traffic.  So in case you want to use the same subnet for management of the core as it's own uplink you need to have that subnet large enough so it fits both upstream ISP router IP(s) the core stack SVI AND the management IP's of both stackmembers.  And yes the router of the ISP is then the default gateway for the management of the core switch.

About the switch settings page.  You are welcome to enter a VLAN ID there which will become the default for all the MS switches in the same network that DO NOT have a VLAN ID configured on their own management settings.  So you could enter for example VLAN 100 as management that has an SVI on the core switch to route the downstream switch mgmt while having a different VLAN ID on the core switches themselves by entering the VLAN ID individually on both core switch mgmt IP.