Legacy network integration best practice

Pugmiester
Building a reputation

Legacy network integration best practice

Hi all, we're currently running a mostly Cisco Catalyst switch network (4500 core, 2960x access) with Meraki MR's and will soon be moving to include MX firewall appliances to replace the existing hardware and MS switches as budget becomes available and older hardware is ready to replace.

 

Are there any recommendations or pitfalls to avoid when mixing and matching the different technologies to minimise the pain?

8 Replies 8
PhilipDAth
Kind of a big deal
Kind of a big deal

With regard to switching you want to configure your existing switches to use mst spanning tree (spanning-tree mode mst).

 

MX functionality is reduced if the MX is unable to see the MAC address of the clients (such as per client group policy).  So ideally moved the layer 3 gateways to the MX.  Failing that, move the layer 3 gateways for just your clients to the MX.

 

With regard to MR's - jump directly to firmware 25.11 if you are below this.  Nothing to do with your existing environment, just 25.11 works best.

Pugmiester
Building a reputation

Thanks PhilipDAth.

 

We're running rapid-pvst across the current infrastructure (around 60 access switches and 2x4500's) so would you recommend we switch to MST before adding the Meraki switches?

 

The MX will become the default route to the internet so we should see the traffic flow but we will likely retain our existing core stack default gateway setup for now as there's a lot of LAN and WAN traffic that doesn't need to touch the MX, at least not initially.

 

All of our MR's are running 25.9 with it being the latest stable release. Just a little twichy about switch to RC versions.

PhilipDAth
Kind of a big deal
Kind of a big deal

If you can guarantee the links to the Meraki switches will be loop free you should be ok.  If you can't guarantee this plan to migrate to MST now.

Otherwise you may experience unplanned outages ...

 

25.9 contains annoying issues - particular one that makes it difficult for some brands of clients to roam or remain continuously connected.  I would only advise those who like users complaining about WiFI issues to stay on that release.

Pugmiester
Building a reputation

Most, if not all, of the current switch links have migrated over to Etherchannel instead of relying on Spanning-Tree with redundant connections so I'm reasonably confident we are loop free (famous last words).

The new switches will follow the same Etherchannel/port bonding route so that should mean we're OK.

We seem to only have the option for 25.9 at the moment and haven't run into any issues but I'll keep an eye out for 25.11.
PhilipDAth
Kind of a big deal
Kind of a big deal

One more case I forgot to mention.

 

If you have this scenario:

<legacy cisco switch> ---- <meraki switch> --- <legacy switch switch>

Also change to MST first.

 

Meraki use the standards approach of a "single" spanning tree, while rstp uses a tree per vlan.  As a result the above topology results in the two different types of switches calculating different spanning tree roots.

 

 

This one has bit me badly in the past.  I usually just switch to mst to avoid it now.  "Twice shy" as they say.

Pugmiester
Building a reputation

Thanks for the heads up.

What we have currently is :-
<FW> --- <Catalyst Core> --- <Catalyst Access> --- MR's
and we'll be moving to :-

<MX> --- <Catalyst core> --- <Catalys Access>
--- <Meraki Switch> --- MR's

Looks like a switch to mst may be the safer option then just to be safe.
jwwork
Getting noticed

I just replaced a 6500 core with a stacked 425 core.  Edge is a combination of 2960 and 3560 and all running rapid-pvst.  Once I migrated all the connections to the new 425 stack I had massive problems with links going up and down etc.  Once I changed spanning tree to mst on the switches directly connected back the Meraki stack the problems went away.  We have a loop free topology but still had issues until switching to mst.  I have additional Cisco switches trunked off those switches that connect back to the core and they are still running rapid-pvst.  The switch running mst in front of it will do a pvst simulation to the downstream switches.

Pugmiester
Building a reputation

Thanks jwwork,

There are a couple of areas out in the warehouse I've just remembered where we are relying on STP to manage redundant links, mainly because the switches are really low capacity with only a single Gig uplink so I couldn't build an Etherchannel with that and a 100Mbps link but thinking about it, the throughput is that low I could switch to a pair of 100Mbps links in Etherchannel and use the gig for a device connection and still have performance to spare, plus break the loop completely.
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