Migrating from ASA


Migrating from ASA



I am currently working on migrating from a single ASA to Meraki MX100, and I'm having issues.


The LAN is entirely cisco. Access layer switches are stacked 3750x with multiple unique vlans on each switch.


The core switch is a dual 6509 stack with multiple VRFs containing the VLANs from the access switches, segregating untrusted networks.




Currently the 6509 has multiple access ports each configured in a VLAN that is part of its respective VRF. Eg: vrf ENTERTAINMENT contains vlan 11. Int g1/0/5 is an access port in vlan 11 connected to an interface on the ASA. There is an SVI for every vlan on the network. (eg: vlan 57. IP address is a member of vrf ENTERTAINMENT) VRF entertainment has default gateway of - IP address on the interface of the ASA.



One port on each switch stack in the redundant pair is configured as an access port in a VLAN that is a member of its respective VRF.


   6509: int g1/3/3 vlan 14 (not part of any VRF)

             int g1/3/4 VLAN 9 (VRF DIGITAL_SIGN)

             int g1/3/5 VLAN 27 (VRF PARKING)

             int g1/3/6 VLAN 11 (VRF ENTERTAINMENT)

             int g1/3/7 VLAN 16 (VRF PUB_ENT)


 MX100: port3: VLAN 14

              port4: VLAN 9

              port5: VLAN 27

              port6: VLAN 11

              port7: VLAN 16


I duplicated the static routes from my ASA on the MX100, one for each vlan in the vrf (example points to that is being sent to the MX100.


When I changed my static routes on the core 6509 to point to the Meraki, (eg: vrf ENTERTAINMENT gateway is - the IP address of vlan 11 on the MX100)  the static routes defined on the Meraki will not stay up. I am not able to reliably ping the gateways on the core switch.


I keep getting these messages in the error logs on the MX100


Route connection change       peer_type: gateway, peer:, connection_status: connected

Route connection change       peer_type: gateway, peer:, connection_status: disconnected


Can anyone help with what I am doing wrong? I spent several hours on the phone with Meraki tech support, and my approved change window ran out of time, so I couldn't include Cisco on the call.




Kind of a big deal
Kind of a big deal

Do you see stp changes on your switch?


No. The ports stay up physically.

Are you able to create a couple of test VRFs on the 6509’s and connect the MX up and test again prior to another cutover?


I worked extensively on quite a few such VRF deployments using 6509’s and ASA’s a decade ago for shopping centres.  Each deployment would throw up its own nuances so there’s possibly something quirky configured on the core which is causing the issue.

Darren OConnor | doconnor@resalire.co.uk

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.

Yes, I can. What would you like me to configure for testing?

Kind of a big deal
Kind of a big deal

What should happen is the additional ports being used on the MX should all be blocked on the 6500 due to spanning tree.  Only one of the ports should remain up.


Instead you could create a single physical connection between the MX and the 6500 and trunk all of the VLANs through.

Do you mean spanning tree internal to the MX100s? The ports are not blocking at any time on the core switch.


Each port on the Merakis is in a separate vlan

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.