Hello,
I have been tasked with replacing a Cisco 3750 core stack and 22 access switches with Meraki MS gear.
In my inventory I have a MS410 to handle the layer 3 traffic and 21 MS210 access layer switches. We are a hub and spoke environment with all remote sites landing on the 3750 stack. We have 12 VLANs with all gateway addresses handled by the 3750 stack. There are some odd configurations that are left over from some legacy T1 links (such as the vlan1 gateway existing on a Cisco 2611 router) and EIGRP AND OSPF running on the 3750 stack. We really don't have a need for IP routing protocols as all sites are direct connected to the 3750 (soon to be replaced by the MS410). All traffic reaches the internet through a WatchGuard firewall.
My thought is to one by one shutdown the vlan interface for each remote site on the 3750 stack and move the physical connection for that site to the MS410. The MS410 will be trunked to the 3750. The remote sites will have to learn a new route (I think/guess). If I can keep downtime to less than five minutes per site that would be ideal.
If this isn't going to work, my plan is to replace the far end 3750 access switches with the MS210s, trunked to the 3750 core, and then do a rip and replace of that core over a weekend.
We are a small local government with five sites and about 250 endpoints. This seems like it should be rather easy to do. But I've been doing this long enough to know that easy is a four letter word.
I am looking for suggestions, warnings, etc. Thanks in advance.
Solved! Go to solution.
On the face of it this sounds logical.
One thing to be aware of is that Meraki switches run MST for spanning tree. While they are technically compatible with PVST, where you'll usually see issues is when you have a Meraki switch in between two Cisco switches:
Cisco <trunk> Meraki <trunk> cisco
Oh, an of course if you drop the dynamic routing, you'll need to add static routes as applicable when removing the 3750.
On the face of it this sounds logical.
One thing to be aware of is that Meraki switches run MST for spanning tree. While they are technically compatible with PVST, where you'll usually see issues is when you have a Meraki switch in between two Cisco switches:
Cisco <trunk> Meraki <trunk> cisco
Oh, an of course if you drop the dynamic routing, you'll need to add static routes as applicable when removing the 3750.
Thank you for your reply.
The spanning tree info is helpful. I am going to have to draw this solution out to make sure I don't introduce any issues.
I have the MS410 and five MS210s in a lab connected to a VMWare server with copies of the Domain Controllers/DHCP and DNS servers with a WatchGuard firewall as the gateway on a separate WAN link. Everything works. What I don't have is a 3750 with the routing protocols in the middle.
What I might do is remove all VLANS from the MS410 and put the MS410 in production and trunk it to the 3750 stack. Create a new VLAN on the 3750 stack, trunk it to a MS210, test connectivity and then create that VLAN on the MS410 (shutting down the VLAN on the 3750) and move that MS210 link to the MS410 and see what happens. I need to keep an eye out for IP address conflicts. But that seems like a good production test.
I'd rather spend some time on the front end rather than rip/replace and run out of time because I missed something.
I'll be glad when this is done.
"[..] is remove all VLANS from the MS410 [..]"
I see this mentionend from time to time, and feel the need to make a short comment on this..
One fundamental detail that is different from Cisco, is that on Meraki all vlans are in principle already created on the switch and cannot be removed. Contrary to what we're used to in Cisco.
E.g.
conf t
vlan 10
...
This means and if a VLAN is not pruned on the trunk, whatever traffic will still flow in the VLAN over the trunk and be handled on the Meraki Switch.
A VLAN on Meraki is not created the instant it is configured on the access ports or in the trunk allow list.
(Unless of course, this behaviour has been changed or there are internal mechanisms that handle this I'm unaware of.. But this has been the case for several years.)
So if you have VLANs on a remote device that should not touch the Meraki, prune them on the trunk - preferably on both sides.
Thank you for responding and for that information.
One question - is this in reference to the MS210 access switches, the MS410 layer 3 switch or just in general for all switches?
I am still kicking around the best path forward here. Thankfully I have maintenance windows on Sundays. I am seeing that the first thing I need to address is vlan1. On my MS410 the gateway is 192.168.0.1. That address also exists on a legacy Cisco 2611. I am thinking I can trunk the MS410 to my 3750 stack and shutdown interface on the 2611, which is configured as follows:
interface FastEthernet0/0
description connected to EthernetLAN
ip address 192.168.0.1 255.255.255.0
duplex auto
speed auto
no mop enabled
The MS410 *should* then route traffic for 192.168.0.1 to the next hop which is the WatchGuard. The WG will either route the traffic to the internet or back to the 3750 core stack which is configured as follows:
interface Vlan1
ip address 192.168.253.1 255.255.255.0 secondary
ip address 192.168.0.243 255.255.255.0
192.168.0.243 is the next hop back to the network from the WG. Once all of this is done, the hop back to the internal network will be 192.168.0.1 on the WG.
I don't see where I can have a secondary interface on vlan1 on the Meraki.
I have inherited a bit of a mess due to the legacy routed network that was never cleaned up. The network now is flat. All remote sites are connected via fiber to the core. There are ACLs in place to prevent public traffic (library and community center wifi) from seeing private, but everything else is wide open between subnets.
I appreciate the time you took to respond to this 🙂
You cannot have a secundary IP address on Meraki MS. Meraki switches are not the same as Catalyst switches, you could say that they are much more limited.