AutoVPN+OSPF+Overlapping Static route "in vpn" = ?

[thomasthomsen]

How to start ... hmmmm .... - Please see the attached picture. 🙂

Is that really "how it works" ?

Is there no way to "filter out" static routes learned from AutoVPN, that overlaps with a local static route away from the OSPF advertisements ?

In this instance each MX will tell their connected core that they have 10.0.0.0/8 (because it was learned from AutoVPN), so in theory the core will start sending traffic to 10.0.0.0/8 to the connected MX, that MX then has a static route back.... this will get very bad quickly 🙂

I know we could "just" setup the MXs in VPN-Concentrator mode, and that would fix the problem (because we dont have any static routes there). But we dont "like" concentrator mode in this setup.

Any suggestions ?

We are looking into route filter on the cores, but then the routes would still be in the OSPF database of the core.

Merry Christmas 🙂

/Thomas

Spoiler

Feature request
Routing loop

[thomasthomsen]

The reason we would like to use OSPF, is in case of datacenter failure.

The templates used for the Z3s has different "Auto-gererate" pools, and different central MX as primary Hub.

So in case fx. DC2 fails the Z3s would switch to DC1 MX, and then that would advertise the Z3 with the DC2 templates routes.

(I have no idea if the above sentences makes sense 🙂 )

[jdsilva]

Huh, yeh I see your problem. Interesting...

I don't have a good solution here. There's no way to filter the auto-VPN routes on the MX so you're stuck. The only solution I can think of here would be to have MXDC1 and MXDC2 not establish a tunnel with each other so they don't pass the 10.0.0.0/8 route to each other...

So on that note... That might be your solution here. You could "flip the script" so to speak. Instead of making the two MXDC's Hubs you could make them Spokes, and then make all your remote autoVPN sites Hubs. 

Yes, this is backwards... But it might work.

If you make both MXDC's spokes then they won't establish a tunnel with each other, and they won't advertise the 10.0.0.0/8 to each other. And if you make all the other sites hubs then both MXDC's will establish tunnels to them. Oh sure, the remote sites will also establish tunnels with each other, but routing is king and those tunnels will most likley just be idle. You only have to be careful if you have a large number of remote sites and the VPN tunnel limit of the MX at those sites. 

So I *think* that could be made to work. I'm likely missing some details here as I just got to the office and I'm just getting into my first coffee... But this might do what you want even though it appears backwards.

[thomasthomsen]

Thanks for the reply.
I see your point, about "flipping it", but I dont think we want to do this.

(In the real setup we will have 3 DCs not just 2, and we will have about 500 to 900 Z3s connect to each Datacenter).

Furthermore we found out that we cannot do the incomming route filter on the Core routers as I was thinking about, that has to be done on the advertising end, and thats not possible in the current Meraki MX config options.

So I think we will go with Static routes from the core and not OSPF, and then skip the failover between datacenters option. (we have two MX in each datacenter, so we do have some redundancy there).

But I would still like to hear if anyone else knows of a good solution (either whats possible now, or if someone knows of a "Beta" feature that will "save" us 🙂 )

/Thomas