MS Switching / MX Campus Design Peer Review

Solved
ToryDav
Building a reputation

MS Switching / MX Campus Design Peer Review

Hello!

I would love some feedback on the following designs. Looking for ways to improve the technical design and check for correctness.

2x MX in H/A (WAN NOT SHOWN) (LAYER 1 CABLE DIAGRAM)

ToryDav_0-1625173170670.png


Layer 2 Diagram

ToryDav_1-1625173255499.png

LAYER 3 DIAGRAM

ToryDav_2-1625173317922.png


For the Layer 3 diagram, I've debated with putting the layer 3 gateways on the MX but I would prefer to have a true core as well where the gateways and DHCP reside on the MDF switch stack instead with Layer 2 trunks to the IDFs.

Thus I would create a transit VLAN X with a /30 for each MX for connectivity between the core and both MX.

Thoughts? Constructive feedback?

Thanks,
Tory

1 Accepted Solution
Bruce
Kind of a big deal

@ToryDav, in general, pretty good. A few comments I’d make are:

 

Physical - why keep all the uplinks and downlinks in the top and bottom members of the stack? Why not spread them out more so that a failure doesn’t take out so many links?

 

Layer 2 - I’d use aggregated ports (LACP) on the links between the MDF and IDF so you can utilise the bandwidth of both links. It also simplifies the STP model as you have a single logical link. The links to the MX have to rely on STP.

 

Laye 3 - both the MX have to be in the same VLAN as they share an IP address on the LAN side. I’d use the MS for the Layer 3 core, with the transit VLAN from the MXs. You’ll need another VLAN on the MXs though for all your management IPs to reside in (the management IP on the core switch shouldn’t be in the same VLAN as one of the Layer 3 interfaces in the stack). Make sure the MS you are using supports DHCP… 😀

 

Hope that’s some help.

View solution in original post

6 Replies 6
Bruce
Kind of a big deal

@ToryDav, in general, pretty good. A few comments I’d make are:

 

Physical - why keep all the uplinks and downlinks in the top and bottom members of the stack? Why not spread them out more so that a failure doesn’t take out so many links?

 

Layer 2 - I’d use aggregated ports (LACP) on the links between the MDF and IDF so you can utilise the bandwidth of both links. It also simplifies the STP model as you have a single logical link. The links to the MX have to rely on STP.

 

Laye 3 - both the MX have to be in the same VLAN as they share an IP address on the LAN side. I’d use the MS for the Layer 3 core, with the transit VLAN from the MXs. You’ll need another VLAN on the MXs though for all your management IPs to reside in (the management IP on the core switch shouldn’t be in the same VLAN as one of the Layer 3 interfaces in the stack). Make sure the MS you are using supports DHCP… 😀

 

Hope that’s some help.

DarrenOC
Kind of a big deal
Kind of a big deal

Good design and feedback. I presume your core is a mix of 225’s and 210’s hence the top and bottom spread of fibres?

Darren OConnor | doconnor@resalire.co.uk
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.
Bruce
Kind of a big deal

@DarrenOC probably not if he plans to run DHCP on the core

ToryDav
Building a reputation

@DarrenOC @Bruce 


Likely it will be MS 390's

The top and bottom spread is just how I chose to do it, it's a stack so really I could put one link on each switch. Logically all one switch.

Also Bruce thanks for the tips. I will aggregate the links and spread those links out better. Makes perfect sense, not sure why that got past me on this one.

Bruce
Kind of a big deal

@ToryDav if you're using MS390 then the requirement around the Management IP are slightly less, have a look in the Layer 3 Interface Caveats listed in this document, https://documentation.meraki.com/MS/Layer_3_Switching/MS_Layer_3_Switching_and_Routing.

 

Also, just be aware that you may end up encountering a few issues with the MS390 devices, they're physically good devices, but the firmware is still a bit raw - you'll probably want to run the latest beta firmware to get the best experience. If you're looking at future proofing, and you're not planning to do anything complex (e.g. no MAC whitelisting, not getting too carried away with 802.1x) for the moment, then you should be fine. If its a critical network (i.e. you can't afford downtime) then I'd seriously consider the MS50 or MS355 switches.

ToryDav
Building a reputation

     

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