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
Route connection change peer_type: gateway, peer: 10.163.9.1, connection_status: connected
Route connection change peer_type: gateway, peer: 10.163.9.1, 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.
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.
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.