Possible Switch to Meraki Switching - Need Opinions and Experience

detinater
Here to help

Possible Switch to Meraki Switching - Need Opinions and Experience

We're looking at Meraki for school campus, it's a bit remote so Meraki would be ideal because of the cloud management we wouldn't need to have an IT guy on site. I wanted some opinions from others on using Meraki gear in this scenario.

 

Background on what we're doing. There are 3 buildings on the campus, all interconnected with fiber that dead ends at a single DC in one of the buildings. Buildings have cisco VOIP phones as well as video cameras for wired devices. Each building has about 30 UBNT APs (not in budget to replace right now). All clients (about 1200 total between all buildings) use primarily 5ghz wireless. DC has 1GB fiber internet connection and 250mb failover, a few ESXI servers, a Synology (doing surveillance stuff) and a few misc other servers.

 

That said the main thing I'm wondering (see my buildout below) where would it be best to locate layer 3 and DHCP? Should I do it on the MX250 HA pair or should I do it on the aggregation switches (because everything plugging into them, other switches, esxi servers, synology) Or do I do a mix of things, dhcp on MX with layer 3 on the MS425 switches. Also the other factor being processing power of the device, not sure who's guts are newer, the MX or the MS switches.

 

That's my primary question which ties into this one regarding LACP and virtual switch stacking. I know the MS425 can be virtually stacked and supports LACP. So how does that work for moving data around, do you use the 40GB ports as an uplink between switches? Do they somehow pump that data around between the LACP connection to the outside switch stacks? I need failover here because of the remoteness of the location, but unsure how exactly "virtual Stacking" works. That aside, if you have a pair of MS425 in a virtual stack, how would I uplink that to my MX? For instance, an uplink cable running from switch 1 to mx 1, and switch 1 to mx 2, then a cable running from switch 2 to mx1 and switch 2 to mx2. Is this going to cause a loop or would I have a 20GB uplink because it's coming from two virtually stacked switches? I drew a simplified model of this at the bottom to help better illustrate what I'm thinking. 

 

Any thoughts or experience with Meraki in a similar situation is GREATLY appreciated.

 

Buildout:

MX250 X 2 in HA Pair
Dual 10GB Fiber Uplink from each mx to each MS Switches
MS425 16p Aggregation Switch x 2 in Virtual Stack
10GB Fiber links (two each) to each Server and Synology using LACP
10GB Fiber links (4 total, 2 to each building switch stack) using LACP

 

Building 1

Meraki MS225-48FP x 3 switches with RPS2300

Dual 10GB LCAP link back to MS425 stack, one link to each switch

 

Building 2

Meraki MS225-48FP x 3 switches with RPS2300

Dual 10GB LCAP link back to MS425 stack, one link to each switch

 

IMG_0030.PNG

7 Replies 7
PhilipDAth
Kind of a big deal
Kind of a big deal

The advantage of having the switches doing the L3 is it is wire rate.  So if you want to route 10Gb/s between VLANs you can (particularly to your servers).

 

The advantage of using the MX for L3 routing is you can have per-user group policy.  To use this feature the users need to be using the MX as their default gateway.  If you don't want/need this feature then go with the switches.

 

The MX used to provide better visibility of traffic but with the new "Unique Client Identifier " this is no longer a limitation.

https://documentation.meraki.com/MX/Monitoring_and_Reporting/Client_Tracking_Options#Unique_Client_I... 

 

 

So if you need the performance more (and the performance you need is greater than the MX can deliver) go with routing on the L3 switches.

If you need the additional security controls more do the L3 on the MX.

 

You can also do a mix.  Sometimes I have put all the users on a VLAN routed by the MX, and everything else routed by the L3 core.

PhilipDAth
Kind of a big deal
Kind of a big deal

Note you can not LACP across a virtual stack.  You probably want to physically stack the MS425s.

detinater
Here to help

Got ya, I actually think I misread the specifications on the MS425-16 and thought they didn't physically stack. Which they do, so that eliminates my question on the virtual stacking.

 

I see what you mean about limited bandwidth going to the MX now, it will be limited at 10GB uplink vs everything else having 20GB LACP links. 

 

I could potentially use your suggestion and move the user traffic to the MX as 95% of their traffic isn't inter-vlan or to the various servers, it's mostly going to the internet. 

 

Is there any documentation from Meraki on how to do the above setup? 

PhilipDAth
Kind of a big deal
Kind of a big deal

The MX250 might have 10Gbe interfaces, but the actual inter-vlan throughput will be closer to 4Gb/s.

 

Based on the traffic mix, I'd be tempted to do all the routing on the MX ...

 

Putting the VLANs on the MX are straight forward.

https://documentation.meraki.com/MX/Networks_and_Routing/Configuring_VLANs_on_the_MX_Security_Applia... 

 

If you want to combine routing on the MS425s as well follow this guide:

https://documentation.meraki.com/MS/Layer_3_Switching/Layer_3_Switch_Example

 

detinater
Here to help

That was my thought as well, given the size of the network and clients.

 

Looking at the current setup there is very little inter-vlan traffic, mainly printing, dns but nothing too data intensive. The biggest traffic is inside of the security vlan with traffic between the security cameras and the synology. 

 

I'll have to read up on the documentation for these things, but going back to your original post you mentioned per user group policy for the MX over the MS doing routing. We don't use anything like that, filtering is done in the cloud with GoGuardian and the students using ChromeBooks.

 

So with that in mind would it make sense to just put it on the MS so we have that wire rate overhead and call it a day? 

PhilipDAth
Kind of a big deal
Kind of a big deal

>So with that in mind would it make sense to just put it on the MS so we have that wire rate overhead and call it a day? 

 

Nothing wrong with that decision.

Uberseehandel
Kind of a big deal

To avoid any post implementation surprises, I'd suggest categorising the existing IP traffic. Should any devices be dependent upon accessing multicast IPTV, for example, then alternative arrangements will have to be made for those devices. I do this by filtering off the multicast traffic ahead of the MX.

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel
Get notified when there are additional replies to this discussion.