DHCP Relay Error: DHCP relay IP address must be connected or reachable via site-to-site VPN

[DerekH]

I have an mx250s in vpn concentrator mode in one building and I've setup an mx67 spoke and it has formed an autovpn tunnel. Routing is working fine and I can access all internal subnets within the hubs ie dns, dhcp, ad etc. I can see in the spoke routing table that I have 2 defaults, 1 over the autovpn tunnel (Meraki VPN: VLAN with a next-hop of the Hub peer - I'm using full tunnel), and then 1 default WAN route. I'm trying to configure a DHCP relay forwarder on a few local vlans I've created on the spoke mx67 but it won't let me save the DHCP server IPs. I am getting the error message below:

There were errors in saving this configuration:
The DHCP relay IP address must be in a subnet connected to this Meraki network or to a Meraki network reachable through site-to-site VPN. Relaying through a non-Meraki VPN peer is not supported.

I don't have any non-Meraki peers or any other static routes on the hub or spoke. I have a default route over the autovpn, but I don't have the more specific for the DHCP servers of course. Does the Meraki need to see a more specific route for the DHCP servers (even a 10.0.0.0/8 etc) via the autovpn, or is it enough that it has the default over the autovpn? I can't create VPN "Local Networks" on the Hub VPN concentrators so that the spokes see the more specifics over the autovpn tunnel due to this issues -https://community.meraki.com/t5/Security-SD-WAN/OSPF-advertises-entire-route-table/m-p/68841. If I did then it would create an issue for the rest of my internal network and I can't be filtering these hub re-advertised routes on our core network. Any ideas?

[CN]

Meraki Support can disable hubs from sharing routes with each other. If you call (during a change window) and open a case with Meraki Support they can disable this on the backend. This will prevent hubs from sharing routes with each other. This will prevent the local subnets that are defined at one hub from being shared with the other hubs. Then you can go in and advertise the specific subnet of the DHCP server without it going to other Hubs. 

For testing purposes, I would recommend getting this enabled on a test organization before implementing it in production. The "No Hub to Hub" can be applied to specific Hubs (if new hubs are added you'll need to have it disabled again) but it is recommended that it be disabled globally in the organization (new hubs will automatically have it turned off). 

[DerekH]

Awesome thanks I'll open a ticket with support. Do you know if this lack of more specific routes over the autovpn tunnel is the reason that I can't configure the dhcp forwarder/relay IPs? 

Out of interest, is there a list of these "features" that support can enable in the backend (so customers are aware) & some roadmap for them being available for customers to configure themselves?

[CN]

Yes, the lack of a specific route is preventing the IP helper from being saved. If you share the /32 IP of the DHCP server on the hub then it will allow the spoke to save the DHCP relay. 

Unfortunately, there is no list. 

[DerekH]

Hi CN, thanks for you help, I really appreciate it. Support told me that the error that I am getting when configuring the dhcp relay is not expected behaviour and that I should be able to add this even with only a default route advertised from the hub. They've passed it to the engineering team to look at and provide a resolution. They say that they can add the dhcp servers in the backend manually to resolve the issue, but I'd need to contact support to change, add etc, so obviously not a scalable solution, especially for numerous spokes.

They also said as an alternative they can disable hub/hub tunnel formation in the backend (was this was you were referring to previously - I thought that was just disabling the readvertisment of of hub local networks), but I don't know what the knock on effect of this would be. I guess hub/hub tunnels are there for purpose and breaking that could lead to other issues. I tried to get out of the support person what this could be. He said he would find out, but didn't elaborate when he emailed me later so I'll follow up. Do you know any caveats to disabling the hub/hub tunnel, or if this should be avoided?

[CN · Accepted solution]

Sorry if it wasn't clear. Yes, the hub to hub communication will stop. It is pretty much telling the hub MX that it shouldn't form a VPN tunnel with any other hubs. They won't share routes with each other because there is no tunnel. Having a tunnel sharing routes is what could cause problems if Hub A advertises a subnet that now all of a sudden gets advertised into Hub B. 

It sounds like there is some overlap which would cause some looping in your network where having Hub A routes getting advertised into OSPF in Hub B's data center would cause some problems. If the VPN tunnel isn't there then it wouldn't get advertised into OSPF. 

I've worked with lots of customers to disable hub to hub. They know they don't want them talking as both data centers share the same subnets, so disabling the hub tunnels will prevent them from causing routing loops. It would really depend on your setup. Testing in a lab organization would be your best way to see how it behaves.