OSPF for AutoVPN learned subnets on LAN Interface

[Doug_Barnes]

Will the MX appliance advertise the remote VPN learned subnets via OSPF out of the LAN interface(s)?  Seems, I have seen some code enhancements to allow this but unsure of the requirements/restrictions.

[PhilipDAth]

Yes it can advertise remote AutoVPN subnets - but it doesn't listen.

[Doug_Barnes]

Thank you PhilipDAth 

The key to me is that it will form an OSPF neighbor relationship and advertise via the LAN interfaces (not the WAN) interfaces.

Is that indeed the case?  Also, I have read a couple of Meraki guides that indicate the VLANs must be "disabled" for this functionality to work.  Any insight here?

[PhilipDAth]

Correct it will form an OSPF relationship.

I'm not sure about the VLAN question.  I test tried on an MX with VLANs enabled (running 13.28) and all the options for OSPF were still there.  So it looks like it would work to me with VLANs enabled.

[PhilipDAth]

I lie @Doug_Barnes.  I got my MX's mixed up.

The MX with VLANs enabled does not show the OSPF options.  Only the MX with VLANs disabled shows the OSPF options.

[GreenMan · Accepted solution]

The main difference is between an MX in NAT mode, versus Passthrough (VPN Concentrator). OSPF in NAT-mode is supported from firmware 13.4 onwards, but only with VLANs disabled. Note that, for the type of concentrator deployments where OSPF advertisement provides the biggest advantages (lots of spoke networks to advertise) it is recommended to use Passthrough mode. This is extremely useful, if you haven't seen it: https://documentation.meraki.com/MX-Z/Deployment_Guides/VPN_Concentrator_Deployment_Guide

[Doug_Barnes]

Thank you for your response GreenMan.  I have seen the Deployment Guide in the past, but thank you for bringing it to my attention again.

The customer (relatively small) has 6 remote sites, they will initially be using the MXs as both an Internet edge security appliance and AutoVPN termination device.  I am assuming that the dedicated VPN Concentrator (Passthrough mode) recommendation is for scalability reasons, which we will address as the customers grows to a larger number of locations.  But yes they will be doing full mesh AutoVPN for the foreseeable future.   I assume that there are no immediate "gotchas" with this?

The design calls for the MXes to connect to a pair of stacked Meraki 425 distribution switches that will be running OSPF to the access layer (MS250 stacks).    The need for dynamic advertisement of VPN learned subnets is great for dynamic failover to/from a future MPLS connection.  That will be handled by a Cisco ISR router also running OSPF to the Meraki 425 distribution.

[GreenMan]

If you're wanting a 'dual-purpose' HQ MX setup, you probably do want NAT-mode - and will need to choose the model carefully, bearing in mind the traffic being carried and the multiple processes that MX will be running.  As that will mean a default route, pointing at the MX from any upstream router/L3 switch anyway (thus covering all remote site subnets), I'm not sure what OSPF would give...?  (if you want resilient MXs, you can use warm standby failover, which halves the licensing)

What application is driving the need for a full mesh VPN setup?   Most environments - even those with site-to-site VoIP - can run successfully using hub and spoke, provided the majority of applications are hosted at/through the hub  (or maybe on the Internet, as SaaS via split tunnel).

You could do full mesh (every MX as a Hub), with only 6 or so sites in total, but you need to consider the extra load that number of tunnels places on each MX and choose appropriate models for each.  Of course, if the customer actually grows even a little way beyond that site qty, the tunnel count grows rapidly, for every extra site...

[Doug_Barnes]

Yep, great feedback, GreenMan.

The upstream/L3 switch that you mention will be the decision maker in this scenario.  In the future, they are considering a separate MPLS WAN (via Cisco ISR connected to distro Meraki425) that will also inject dynamic learned routes into the distribution. I like OSPF from the MXs for the dynamic nature of failover as I can get creative with some of the OSPF metrics for granular path selection.  Granted it my be overkill in this situation and I am aware of the longest prefix match for route selection,

VOIP and site-to-site file sharing (CIFS) is currently driving the need for full mesh.  This customer has no on premise servers anywhere (100% in the cloud) which I have never actually run across before.  There is no HUB.  We have sized their larger sites (~200 people) with MX100s and smaller sites (~50 people) with MX84s.  The design was for warm standby failover but we fully licensed both in case we needed to downshift to a dedicated VPN concentrator and dedicated NAT mode firewall to handle the load. 

Thanks for the discussions.  As always, I welcome any feedback.