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 10.163.57.1 is a member of vrf ENTERTAINMENT) VRF entertainment has default gateway of 10.163.11.2 - 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 10.163.57.0/24 points to 10.163.11.1) 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 10.163.11.3 - 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
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 | email@example.com 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.