We currently have a core switch stack made up of 3 aging 24port 3870s. We wanted to install 2 MS390-48s in a stack, and move our core switch functionality over to the new MS390 stack. I am having a hard time finding documentation showing me how to set the Meraki stack to have the same functionality as the 3850 stack.
In our current 3850 stack, we have a number of VLANs defined, login to the stack is via RSA(my understanding is that on Meraki, we need to use Duo), have a number of Port-channels defined as links to wiring closets, has some static routes defined, and access lists to some VLANs and some by protocol.
I have never set up a core switch before, and this new Meraki stack will replace the 3850 stack. I'm trying to verify if this is a feasible switch, and how to do it properly. Currently I'm waiting for my secondary power supplies, stacking and power stacking cables to be able to create the stack. Then I need to nail down the steps to take to switch over, and some way to test without breaking the network.
Up till now, I've only deployed layer 2 switches, so this is all new to me.
hi @Dave_S , you've honestly got nothing to worry about. The biggest step up from Layer 2 to Layer 3 are your VLAN's and routing. Take a snapshot of these from your existing core noting the VLAN ID, description and any IP-Helpers. Then note the uplinks from the existing core, I would presume these are Trunks with a Native VLAN and as you've already stated they're Ether-Channeled. Is your existing core providing DHCP services at all? If so, note those down and replicate onto the new core.
Whilst I don't like the MS390's they're a suitable replacement for the Catalyst 3850's.
With regards setup and migration. I would bring each new ms390 online and register out to the cloud. once registered I would configure and build the stack. You could do this in isolation of your main network just to ensure STP doesn't throw a hissy fit. I would then replicate your existing config onto the new core stack. once happy schedule in a migration time and date.
Darren OConnor | email@example.com 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.
Can't avoid. they are what we have, so we'll have to see how it goes and make the best of it. I have been going over the current core config with a fine-toothed comb, so I can replicate as much as possible on the Meraki stack. The only issue is the difference in terminology between the two sometimes make it confusing in translation.