Replacing a Firepower with an MX in an all Meraki switches environment- VLAN and LACP questions

[MSakr]

Hi All

We are planning to replace our Cisco Firepower Firewall with an MX series one, and the downstream is an all Meraki Layer 3 switches that is segregated into VLANs on an MS425 core stack..

Now currently the stack uplink ports are aggregated on the stack side and LACPed on the current Firepower and a transit VLAN is set between the Firepower and the core stack.. my 2 questions:

- I am looking to setup VLANs on the MX LAN interfaces so I can setup a similar IDed transit VLAn and also assign an IP to the interfaces/VLAN .. didn;t see any other option.. is it a proper approach? will setting up such a VLAN on the Switch stack and on the MX conflict somehow?

- As it is not possible to setup LACP on the MX, I will be connecting each core switch stack member uplink to a Lan port on the MX, and hope that STP guard will block the redundant links and keep one active at anytime.. any suggestions here?

Thank you all for the help

[Brash · Accepted solution]

One thing to note straight up is that an MX is definitely not a 1 to 1 replacement for a firewpower. They have significant differences in features. That's said, it sounds like you've been looking into the differences and limitations of the MX which is good 👍 

As for your questions, yes, a transit vlan between the core and the MX is certainly doable and makes sense. Just create the VLAN interface on the MX and the core and trunk the VLAN between.

As for the cabling, yes, you'll need to rely on STP to keep the links down. Just ensure your STP root is configured on the correct switch and you should be right.

[MSakr]

Hi @Brash thanks.. 

definitely some of the drawbacks were the limitations in the ACLs, NAT and granularity of features and event logging but it compensates in the ease of managing it and reduces uncertainties for the less experienced team... but before we do the switch, it might be great if any have some pointers to comparisons if any made..

"STP root configured to the correct switch.." hmm that's a good pointer.. we have 6 stacks and the core stack is the one connecting all the stacks together and to the firewall , I presume its the core stack we are talking about?

thanks again

[DarrenOC]

Configure Root Guard on the links from your core to your edge switches and then Loop Guard on the uplinks from the core switch to the MX. You’ll see straight away that one of the uplinks from the core to the MX will be shutdown via STP.

[MSakr]

Hi @DarrenOC 

RSTP is enabled on the link between the core stack and the Edge/Access stacks switches but STp guard is disabled, I wans't the one who configured them initially, likely to maximize traffic throughput.. and this setup has been working flawlessly..  

Same setup goes currently from the core stack switches uplinks to the current firepower:

And all the up/downlink ports are in forwarding mode

[DarrenOC]

Hi @MSakr , I guess you’ve been lucky thus far.  I would personally enable stp root guard.

[MSakr]

Hmm.. does it make sense to do it so on aggregated ports? knowing that our architecture is a hub and spoke with the core stack connecting only to each of the edge/access stacks by separately aggregated ports, the uplink ports of each switch of a stack are aggregated with the downlink ports in each switch of the core stack connecting to that specific access/edge stack.. thus the only loop would be between the aggregated ports, which in theory should not as they are aggregated and used in parallel for bandwidth stacking, see as an example below how 2 are interpreted:

[MSakr]

The rough design will look something like this.. I presume I will need to enable loop guard on the links between the core stack and the MX for sure given no LACP can be configured on the MX..

[DarrenOC]

👍🏻

[DarrenOC]

Hi @MSakr , just revisiting this one following a busy day. Whilst you have aggregated links from the core to downstream switches you still need to enable root guard on those links at the core to prevent the downstream switches becoming the root.

[MSakr]

Yeah, the core stack is the one set as root..

[MSakr]

Hi

after connecting the new MX, the Core MS stack is not able to ping the mx on the 66 vlan, I suspect the issue of configuring the vlan on the MX as packets are tagged on both sides might be the culprit

--

Disregard, I had to make sure the Native VLAN was correct now on the IF