Is it possible or advisable to use an MX250 as a Core Switch?

[RobertPHX]

Some basic background, virtually everything we access is a cloud resource, almost no local resources (all web based stuff).

Traditionally, we would be deploying a Firewall > Core Switch > Access Switches > APs...

HA is not a requirement nor in the budget, so we would not be deploying duplicate MX's or Core switches regardless.

Our thought & question is, is it possible to eliminate the core switch?

Here are our thoughts:

1. Buying a core switch to connect a handful of IDFs seems like a waste
2. Redundancy is not required / funded
3. If we have perfectly good SFP+ ports on an MX250 sitting idle, why can't we use those ports for core switching?
4. With all our resources being cloud based, our choke point is our internet connection
5. If the MX or Internet fails, users can't do anything anyway, so why would we build core & access stronger than our Internet?
6. Adding more equipment not only adds cost, but adds more points of failure (i.e. if we added 1 Core switch to the MDF rack it is more likely that we would have an equipment failure, than if we just had an MX.)

• Could a (simplified) network layout look more like this?
• Each of our locations has maybe 2-6 IDFs each serving a building
• Our MDFs serve the front office area, and yes, we do have an access switch in the MDF, but it's not in this diagram to prevent confusion, or people asking "why not use that as the core switch then?"

The MX doesn't seem to be intended to be used as a switch, which seems like a shame. The deployment guide doesn't mention much on this topic at all.

What gotchas should we be aware of before going down this road? Has anyone else deployed like this?

Thanks!

[PhilipDAth]

It will work.

The area where it is weak is the the MXs don't understand spanning tree.  So if you have loops formed (typically by a human) then it can become problematic.

Any chance you could squeeze in a 24 port MS125 for the core switch?  It has 4 x SFP+ ports.  You could even get the non-PoE model to save money.

https://meraki.cisco.com/products/switches/ms125-24 

Or giving up on 10Gbe, even an MS120-8 (once again you could use the non-PoE model to save money)?

https://meraki.cisco.com/products/switches/ms120-8 

[MattWhite · Accepted solution]

Short answer: It will work.

Long answer: You can have spanning-tree resiliency, but it’s controlled from something that runs an instance of STP; another switch would have to recognize a loop and block on non-root ports. This works, but based on your design considerations, it’s probably not for you.

If someone handed me your gear and told me to make the best network possible, I’d probably borrow a page from a routed-access playbook and use multiple uplinks in different /30 networks in each stack with the default next-hop a unique transit VLAN on the MX. You didn’t say which types of switches you have, and not all will handle this gracefully however.  Another limitation of this design is you’ll lose any L2 adjacency functions between each logical switch (think Bonjour) but if you are only concerned with internet access, you likely don’t care.

You will also be performing traffic inspection with routed traffic through the MX; AMP and IPS are not limited to the WAN ports.

There’s nothing inherently wrong with a collapsed-core, or other alternative-style campus design... I’ve just learned that the practice of segregating fault domains and isolating areas of complexity from other areas of complexity often produces the best result. 

Ultimately folks end up paying the same over the course of time. It’s been my experience (both customer and vendor) that you can either put that money into best-practice architecture up front, or pay gradually over the course of that same time period, often at 2am figuring out some weird issue that could not be foreseen. The former delivers the best user experience, though the latter is where I learned some really good lessons. 

I’ll leave it to you to decide which is more important for your organization.

Matt White

CCIEx7 #14533 | CCDE 2012::15

Cisco Meraki

Safer Schools Technical Lead

[NolanHerring]

Hey @MattWhite can you get more CCIE's please cause your slacking bro

[RobertPHX]

Thank you for this very detailed and thoughtful reply; this is exactly what I wanted to hear.

For sure, we'll use a switch instead of trying to use the MX. For us at least, you have provided more than enough valid reasons to not even consider using the MX as a core switch, unfourantently. It would appear more trouble than it's worth right now.

My biggest ask to Meraki I guess would be:

For a company focused on "Simplifying" things, Meraki has a great opportunity to further simplify functionality of their MX lineup, by implementing more switch type features from the MS Lineup.

I normally would say one of Meraki's great strengths is their holistic thought when building integrated products, and understanding how the product might be deployed and used.

This has not been the case for others, like Cisco, who have often just cobbled together, haphazardly acquired product lines, tweaked a few things, left a lot of the old companies code, and made it 'work' with the Cisco stack, sort of... The end result is often vastly different user interfaces, weird quirks, and unexpected behaviors.

My wish is that Meraki not become a company, where product line functionality becomes disjointed.

Sure, it bugs me a bit that we'll have to spend more on a core switch, but oh well, we can do that. It bugs me more that adding another switch to the mix adds a unnecessary point of failure, will require a couple more cables, will generate more heat, and will require additional UPS & rack capacity.

It seems like Meraki has the vision of converging traditional product segments into a single package. The MX68CW is a great example of this (switch with some POE, AP, router/firewall, cellular modem all in one box) - perfect for the branch office. so they don't need 4 boxes to do what everyone knows one can do.

I'm hopeful either via software update, or perhaps a future MX, Meraki will consider adding more switch type functionality to a larger MX otherwise, I fear many people with appliances like the MX250 will continue to leave 20 to 23 ports vacant, because they don't have a need for them other than switching.

Thank you @MattWhite and @PhilipDAth! Your responses were just what I was looking for.