Uplink part of Management VLAN?

Solved
Jimbo1
Here to help

Uplink part of Management VLAN?

I hope this is a simple question, just a matter of (hopefully) confirming what I have gathered from documentation: If I'm migrating a L2 network to L3, I will need to put L3 interfaces on my core switch, and I'm going to need a transit L3 link between the upstream network and the L3 core switch.

 

Ignoring routing for the moment (I can use static/default or OSPF if needed) , can the transit link addressing be part of the management VLAN.

 

Asking the same question another way, can I take two unused addresses from the management VLAN scope and use them for the uplink? So for instance, if the management scope is 10.1.1.0/24, and my core switch management address is 10.1.1.1/24, can I use 10.1.1.100 and 10.1.1.101 for the uplink?

 

Thanks

Jim

1 Accepted Solution
Bruce
Kind of a big deal

@Jimbo1, you could use two separate links, although I’d normally put them as separate VLANs on a trunk (so same physical link) - the management VLAN as the native, the transit VLAN as a tagged VLAN (and with a Layer 3 interface in the transit VLAN at each end). If your upstream provider is only providing you a single link with a single VLAN you may well have to do what you were suggesting. Out of curiosity, what do you do for perimeter security, does the upstream provider take care of that for you as well?

View solution in original post

7 Replies 7
Bruce
Kind of a big deal

I try to avoid creating a Layer 3 interface on a Meraki MS switch that is in the same VLAN as the management interface - it might work but may well cause you issues somewhere down the track (https://documentation.meraki.com/MS/Layer_3_Switching/MS_Layer_3_Switching_and_Routing, Layer 3 interface caveats). Although it’s nice to have just a single transit VLAN to your core switch and the upstream network, in my experience it doesn’t end up that way. I’ve normally ended up with a /30 point-to-point link as a transit VLAN on the link, and then another VLAN (normally the native VLAN) which is the management VLAN. The management VLAN then has its Layer 3 interface on the upstream network, whether that’s an MX or something else (e.g. a Cisco router).

Hi Bruce,

You wrote " a /30 point-to-point link as a transit VLAN on the link, and then another VLAN (normally the native VLAN) which is the management VLAN. The management VLAN then has its Layer 3 interface on the upstream network, whether that’s an MX or something else (e.g. a Cisco router)."

 

Can you clarify for me: are you saying run two physical links with 

1) one physical link carrying a L2 link to the upstream firewall (a Firepower) for the management VLAN;

2) another physical L3 link for the other VLANs?

 

That would be a good solution, if I could, for instance, use addresses in the 192.168.0.0/24 space for the L3 link and 10.0.0.0/8 for the VLANs. However, I'm constrained by the uplink supplier, which does not allow that, which is why I wanted to use management addresses for the L3 transit as well

Bruce
Kind of a big deal

@Jimbo1, you could use two separate links, although I’d normally put them as separate VLANs on a trunk (so same physical link) - the management VLAN as the native, the transit VLAN as a tagged VLAN (and with a Layer 3 interface in the transit VLAN at each end). If your upstream provider is only providing you a single link with a single VLAN you may well have to do what you were suggesting. Out of curiosity, what do you do for perimeter security, does the upstream provider take care of that for you as well?

Hi Bruce,

 

The upstream security is provided by a Firepower firewall, perimeter security is a combination of .1x, PSK and splash on the wireless, .1x, MAC and physical security on the wired.

DarrenOC
Kind of a big deal
Kind of a big deal

I concur with @Bruce with regards placing the L3 interface for management on an upstream device.  We generally ask for a separate interface on the customers firewall solely for management traffic.  We’ve tried it the other way round and it has caused issues during deployment.

 

This way we can also build the networks separately without interfering with the existing LAN

Darren OConnor | doconnor@resalire.co.uk
https://www.linkedin.com/in/darrenoconnor/

I'm not an employee of Cisco/Meraki. My posts are based on Meraki best practice and what has worked for me in the field.

@DarrenOC @Bruce  Thanks for the information on the use of separate physical connections for VLAN 1 and the transit VLAN. I've focussed on doing it that way, and though it costs me a little address space, it makes migration simpler and I really don't want to encounter issues ("We’ve tried it the other way round and it has caused issues during deployment."), this is a running network and I want to minimise any outage.

 More when I have it!

J

AlexL
Comes here often

Sorry to resurrect an old thread, but I thought the use of the native vlan was not within best practice. Instead of using the native vlan, could one just tag the mgmt vlan on that same link that the transit vlan is on?

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels