Circuit aggregation via MS to dual MX

Solved
JesseLeiker
Here to help

Circuit aggregation via MS to dual MX

 Good morning y’all. Thank you in advance for any knowledge base on this subject. I’ll try to keep it brief. 

 

Preface:  these are all new deployments, with new out-of-the-box devices. 

 

 I have a circuit on single port, offering a /29 LAN block to feed the WAN1 port for a pair MX84’s.  Some locations have a catalyst 3650 and some have MS250’s for switching. 

 

On both switching platforms forms I would run a single copper from router to switch Port 52 on trunk: native VLAN671.  I would run copper from switch ports 47-48 to WAN1 on each MX via Access: VLAN671.  My production VLANS and VLAN 671 terminate on the MX’sin warm-spare mode.  I now runcopper up from MX ports LAN3 to switch ports 45-46 via Trunk: Native VLAN 1, allowed: 300,310,320 (production only - 671 is pruned). See attachment for visual representation.

 

Using the catalyst for switching this works efficiently and effectively. Exactly as intended.

 

 Using the MS 250 for switching this does not exactly. I have some packet loss I can’t run down… I have a Shortell void switch that seems to be unable to keep a connection… If I ping using specific packet counts I can hit everything in the legacy network at 1373, but no higher than.  Switch MTU is default... I can hit all the way up to 1500 and above from the catalyst architecture. I suspect I have an issue somewhere. 

 

 I know the MS switching likes to use defined uplinks, the MS is currently showing uplink on switch ports 45–46, I should think it should be showing on 52 as that is the genuine Uplink to the router.   I did use 45 for initial switch to router cloud connectivity... perhaps I need a factory reset using 52 has the initial athlete, then build out my aggregation?    If somebody has some insight I don’t. This is my first time using MS switching platform. Feel free to ask questions for additional information.   

 

 

 

 

1 Accepted Solution
GIdenJoe
Kind of a big deal
Kind of a big deal

This is a supported design and should not give any problems.

I do prefer not to use trunk ports towards the SP router/modem though.  Or at least only allow your external vlan 671 on the port to the router/modem.  If you don't prune off the internal VLANs on the link leading to the router all internal traffic will be flooded there also which is bad.

If you specifically set your management VLAN IP on one of the internal VLANs behind the MX the uplink should be the port leading up to the LAN interface of the active MX.

So example:

Your switch has it's management IP in VLAN 2.
And the external VLAN is 671.

Then you should have on the switch:
switchport mode access, access VLAN 671 on 3 ports ( one leading to the router, and two leading to WAN1 of both MX'es )  That VLAN 671 should have a /29 or lower so it can support both MX interface IP's and preferably a vIP too.
Then the ports on the LAN side of the MX'es should return to that switch or a pair of switches if you have a redundant design where only the internal VLANs are trunked on.  Do make sure you do NOT use drop untagged traffic since that will cause an RSTP loop between those switches and your MX'es.  Use one of the used downstream VLANs as native between MX'es and MS.

I've done this design and never had issues.
And if you have a second ISP you could run those links towards your second switch with external VLANs so you could have a switch fail but traffic will still be forwarded albeit on the other WAN connection.

View solution in original post

11 Replies 11
JesseLeiker
Here to help

Woops!  Forgot the attachment.  This should give you a better representation - my apologies I know this is a bit confusing.  I did clear this with Meraki support as the "best practice" for circuit aggregation when not using a breakout switch between the router and MX firewalls.

 

Broadmoor.jpg

PhilipDAth
Kind of a big deal
Kind of a big deal

Are you able to post a higher resolution version of the diagram?  I can't read it.

JesseLeiker
Here to help

 OH yeah - absolutely.  See if Snapshot.jpg

 

this works (I've blacked out any local IP addressing, hostnames, etc.)

cmr
Kind of a big deal
Kind of a big deal

When using the MS, you do have it in a separate network to the MXs don't you?  If in the same it can cause issues.

If my answer solves your problem please click Accept as Solution so others can benefit from it.
JesseLeiker
Here to help

 Apologies, I’m not sure what you mean by separate network?

cmr
Kind of a big deal
Kind of a big deal

In the Meraki dashboard you have an Organisation and one or more networks inside it.  Each network can contain switches, APs and a router (or HA pair).  The switch used for the WAN split should be in a separate network to the routers (MXs).

If my answer solves your problem please click Accept as Solution so others can benefit from it.
theguywhoroutes
Here to help

Care to explain what issues you'd face? or provide some real issues?

GIdenJoe
Kind of a big deal
Kind of a big deal

This is a supported design and should not give any problems.

I do prefer not to use trunk ports towards the SP router/modem though.  Or at least only allow your external vlan 671 on the port to the router/modem.  If you don't prune off the internal VLANs on the link leading to the router all internal traffic will be flooded there also which is bad.

If you specifically set your management VLAN IP on one of the internal VLANs behind the MX the uplink should be the port leading up to the LAN interface of the active MX.

So example:

Your switch has it's management IP in VLAN 2.
And the external VLAN is 671.

Then you should have on the switch:
switchport mode access, access VLAN 671 on 3 ports ( one leading to the router, and two leading to WAN1 of both MX'es )  That VLAN 671 should have a /29 or lower so it can support both MX interface IP's and preferably a vIP too.
Then the ports on the LAN side of the MX'es should return to that switch or a pair of switches if you have a redundant design where only the internal VLANs are trunked on.  Do make sure you do NOT use drop untagged traffic since that will cause an RSTP loop between those switches and your MX'es.  Use one of the used downstream VLANs as native between MX'es and MS.

I've done this design and never had issues.
And if you have a second ISP you could run those links towards your second switch with external VLANs so you could have a switch fail but traffic will still be forwarded albeit on the other WAN connection.

JesseLeiker
Here to help

So this is just about precisely how I've built this, with the exception of taking your suggestion on changing the trunk native VLAN 671 up to router to "access vlan 671."  Thank you so much for vetting this - it is very much appreciated! 

JesseLeiker
Here to help

So interestingly - I'm working on a few variations just to see what I can get...but the one thing I noticed is: 

A Meraki Throughput test from the MX units are giving me around 85Mbps (100Mbps circuit), however;

 

the same test on the MS behind it is getting 18-19Mbps.  I am wondering where the drop in throughput is coming from?  I am using my access 671 via GLC-T SFP's on Ports 50 and 52.  Do you think this could be a performance-based issue due to the "non-Meraki SFP's" I'm using?  

 

Just in case - I'll move them all to dedicated non SFP ports and see if that improves performance.  Otherwise; maybe I should just call Meraki support on this.  

PhilipDAth
Kind of a big deal
Kind of a big deal

Do the speed testing using a notebook.  The Merak speedtest isn't really suitable for doing comparitive testing like this.,

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