Noob question - Upgrading to a MS250 for all layer 3 switching.

Solved
Closey1200
Conversationalist

Noob question - Upgrading to a MS250 for all layer 3 switching.

Hi All,

 

Real apologies for such a noob question, but here goes.... in our small office environment we have a very old Catalyst 3560 acting as a layer 3 core switch with a few SVI's set up for each subnet (doing all our inter-vlan'ing) and some static routes. This is directly connected to our firewall. We've recently been slowly upgrading everything below the 3560 with our new MS250 and MS225's switches in layer 2 distribution/access setup in preparation. The plan over one weekend is to unplug the old 3560 and to make the MS250 as the new layer 3 core switch replicating all rules etc from the old switch.....

 

Silly question time... how am i supposed to configure the MS250 as a layer 3 creating the same settings once we've unplugged the 3560, can i still get onto the cloud and configure the 250 if i statically assign the management IP in the same subnet as the firewall and connect the old wired connection into the new switch? Once I'm on the switch with all the settings at my disposal i should be ok, its just that first initial bit. I've looked at the local settings page (http://switch.meraki.com/) but this seems restricted to just a small subset of options.

 

Hope that makes sense. 🙃

1 Accepted Solution
GIdenJoe
Kind of a big deal
Kind of a big deal

You must point the management of the new switches directly toward the IP of the firewall.  You can never use the switch itself as gateway for it's own management IP.  And if you have IP addresses to spare you can just add both MS250 stack members inside the 10.0.0.0/24 subnet.  That means you will have to point your endpoints to the other IP .253 as gateway or swap both IP's before proceeding.

After that those switches will be fully online and ready to receive your SVI configurations in your upgrade window.

So both your MS250 stackmembers will have a separate management IP.  But the stack as a whole will only have one IP on the SVI.  Also remember when you go to the routing & DHCP page you will have to create the upstream SVI first because there will be a mandatory default gateway there which will be the IP of the upstream firewall.  After that you can freely create all other downstream SVI's.

View solution in original post

8 Replies 8
DarrenOC
Kind of a big deal
Kind of a big deal

Hi @Closey1200 , as you say, connect the new switch onto the network with an IP in your management subnet.  Then during the outage window migrate a VLAN or service at a time.  If the management subnet has continuous Internet access then you’re good.

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

Noted! I’ll give this a try. Thank you Darren

GIdenJoe
Kind of a big deal
Kind of a big deal

Designwise I have always learned to use L3 switching and then having a router or firewall upstream.
However in small designs it is important to discuss the merits and tradeoffs of this design especially with Meraki since there is a client tracking component there.

The simplest full stack design in a Meraki network is a design for a single building campus where the devices are in a combined Meraki network using client tracking via MAC address.  VLAN's are terminated at the MX directly.  This design can work in cases where you have predominantly north-south traffic (internet or SD-WAN bound) instead of east-west traffic (traffic between VLAN's locally).  In this case you can easily apply group policies and never have any duplicate client issues due to the layer 3 switches.  The distribution switch is usually a stack of at least two switches where every access switch is connected to with two uplinks in a port-channel.  In even smaller networks the distribution switch stack can be access switches too by using MS210 up to MS355 and even the C9300 switches instead of the full SFP based switches.  This design also has the advantage that all interVLAN traffic is inspected by the MX and all rules are stateful.

In larger designs however where you have a distributed campus or you have alot of east west traffic you have to use L3 switching and have to rely on ACL's or Adaptive policy to have at least some security between your clients.  What is a limitation at this time is that Meraki switches at this time do not support VRF's what means if you have some VLAN's you really need to send to an upstream MX you will need to put a Catalyst switch is native IOS-XE mode there optionally monitored by Meraki dashboard.

I would really consider both options here.
Now about your situation.  It is important to note that the Meraki management IP's of the switches have nothing to do with the routing on them.  Also and this is a very key part: You cannot use the switch L3 routing table to route it's own management IP!!  This means you either have to L2 pass the switch management VLAN directly on to the upstream router/firewall or you have to account for a bigger transit subnet so your distribution switches each can take their own management IP in the upstream VLAN while also having the L3 SVI there.

So you have some options:
You could have a separate transit VLAN behind your upstream device and already add the MS250's management to that so the switches are already online while still having your Catalyst switches there.  You can then proceed by adding the transit L3 SVI to the switch and test if you can ping to the upstream router via that SVI.
Then it is a case of removing each SVI individually from the old switch and add it to the Meraki stack while updating the routing table of the upstream device to use the new transit VLAN to get there.  Advantage here is you can do it one VLAN at a time reducing downtimes.

If that is not an option and you need to keep everything on the existing transit you could make a second transit between the old Catalyst and your Meraki stack and perhaps have a separate link going to the upstream device for your management.  And then you can route each VLAN from the old Catalyst to the new MS stack via that transit.  And once you are done you can remove the old transit from the Catalyst and add it to the Meraki stack and add your default route there.

Closey1200
Conversationalist

Hi GIdenJoe. Thank you for your detailed response. I truly appreciate the clarity you've provided. I'd like to offer some additional context about our current setup to give you a more comprehensive view of our goals. This should help us refine our approach and ensure we're on the right path. I apologize if this leads to any repetition from your previous answers, but I want to make sure I fully understand the situation.

 

Here’s a simplified version of our topology…

 

Closey1200_0-1721812293620.png

As mentioned earlier, our plan is to replace the old Catalyst 3560 switch and designate the Meraki MS250 as the core switch in stack 1, handling all IP routing and inter-VLAN routing. Our goal is to replicate the functionality of the Catalyst 3560 as closely as possible with the MS250.

Since Meraki devices don't use a CLI, I'm trying to understand the first steps for configuring the MS250 with all the necessary SVIs and routing. Should I first disconnect the Catalyst 3560 and connect directly to the MS250 via its configuration port? Then, do I assign it an IP address that allows for internet connectivity to bring the switch online in the Meraki Dashboard? After connecting the firewall link to the switch, can I proceed with the configuration through the dashboard? I'm just a bit unsure about this initial setup phase.

 

Please be aware downtime for a few hours is ok.

 

Many Thanks.

GIdenJoe
Kind of a big deal
Kind of a big deal

If the 10.0.0.253 and 254 are part of a larger /24 10.0.0.0 subnet then you have 2 options.  If the 10.0.0.253 and .254 are part of a small 10.0.0.252/30 then you have one option.

First you'll have to make sure your MS250's have a management IP.  If using 10.0.0.0/24 you can add them to that upstream subnet.  If it is 10.0.0.252/30 then you will need a second subnet coming down from your firewall (perhaps op a VLAN on the same physical port).

 

In your upgrade window of a few hours you can then start by removing the 10.0.0.254 SVI from the old core and add it to the MS250's with a default gateway pointing to 10.0.0.253.  And then remove all other SVI's from the old switches and add them to the MS250 stack.

This has to happen where every switch has full layer 2 connectivity of course else you will have reachability errors.

Closey1200
Conversationalist

The .253 & .254 are part of a larger /24 subnet so no need to create a separate subnet on the firewall. All other switches have their management IP in this same subnet also, but their gateway is pointing to .254

 

So to be clear, this is all done whilst both connections are still in place. Would i put the management IP on the new core pointing to the .253 as its gateway? I can then start by removing the .254 SVI from the old switch and adding it to the new?

 

Thanks,

GIdenJoe
Kind of a big deal
Kind of a big deal

You must point the management of the new switches directly toward the IP of the firewall.  You can never use the switch itself as gateway for it's own management IP.  And if you have IP addresses to spare you can just add both MS250 stack members inside the 10.0.0.0/24 subnet.  That means you will have to point your endpoints to the other IP .253 as gateway or swap both IP's before proceeding.

After that those switches will be fully online and ready to receive your SVI configurations in your upgrade window.

So both your MS250 stackmembers will have a separate management IP.  But the stack as a whole will only have one IP on the SVI.  Also remember when you go to the routing & DHCP page you will have to create the upstream SVI first because there will be a mandatory default gateway there which will be the IP of the upstream firewall.  After that you can freely create all other downstream SVI's.

Closey1200
Conversationalist

Thank you GldenJoe, you've been very helpful with your responses. This now makes sense. Thanks again for your help and have a great day.

Get notified when there are additional replies to this discussion.