cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Circuit aggregation via MS to dual MX

SOLVED
Highlighted
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

Accepted Solutions
Highlighted
Head in the Cloud

Re: Circuit aggregation via MS to dual MX

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
Highlighted
Here to help

Re: Circuit aggregation via MS to dual MX

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

Highlighted
Kind of a big deal

Re: Circuit aggregation via MS to dual MX

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

Highlighted
Here to help

Re: Circuit aggregation via MS to dual MX

 OH yeah - absolutely.  See if Snapshot.jpg

 

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

Highlighted
Kind of a big deal
Kind of a big deal

Re: Circuit aggregation via MS to dual MX

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.

Highlighted
Here to help

Re: Circuit aggregation via MS to dual MX

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

Highlighted
Kind of a big deal
Kind of a big deal

Re: Circuit aggregation via MS to dual MX

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).

Highlighted
Here to help

Re: Circuit aggregation via MS to dual MX

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

Highlighted
Head in the Cloud

Re: Circuit aggregation via MS to dual MX

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

Highlighted
Here to help

Re: Circuit aggregation via MS to dual MX

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! 

Highlighted
Here to help

Re: Circuit aggregation via MS to dual MX

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.  

Highlighted
Kind of a big deal

Re: Circuit aggregation via MS to dual MX

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

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.