DMVPN phase2 and OSPF design question

[ColForbin]

Apologies in advance for the crude drawing

There's an original setup where the green dmvpn did not exist, R1 is the home office R2/R3 are remote offices with substantial bandwidth to the home office, R4/R5 routed everything to R2/R3 over a GRE tunnel.  Everything was area 0, so all those Gig interfaces are pictured that way as they all contained the config ip ospf 1 area 0.

There's a new requirement, leaving that existing working config, but add a GRE tunnel from R4/R5 directly back to R1.  A phase 2 dmvpn was setup, the source on the hub router R1 is the loopback, R4 and R5 tunnels come up no issue.

OSPF.  R1/R4/R5 ip ospf network broadcast, priority on R4/R5 is set to 0.  R1/R4/R5 tunnel interfaces: ip ospf 1 area 1 so that *only* the 3 tunnel interfaces are area 1, everything else is left at area 0...is this good practice?  Or is there a better solution?  For instance, should all of the networks on R4/R5 be moved to area 1?

Keeping in mind all of those interfaces pictured are what's in play in production, point to point between routers, but the environment is just 5 routers in total so it's not enormous, but the other interfaces hanging off R1 and R4/R5 are local subnets for those offices.

Thanks in advance.

 

[paul driver]

Hello
Since you are using ospf as the transit underlay for R1,R4,R5  via R2-R3 why not use either iBGP/eBGP for the DMVPN overlay, It would then isolate the underlay/overlay routing process and be quite a simple setup to manage?

[ColForbin]

That is an idea, thanks.  Getting it approved in time to complete this project would prove difficult at best.  Just trying to get a feel for what we implemented and tested already is really a good plan.

[ColForbin]

Well you have my interest piqued. technically I can probably do this in the dev environment as a proof of concept and take the steps to getting bgp enabled in production approved. But I’m flying a little out of my comfort zone having never done it. So the config I can probably work out with a little trial and error, but just so I understand I’d be enabling bgp across the whole environment correct?  Not just specifically on the tunnel interfaces…?

[paul driver]

Hello

---

@ColForbin wrote:

 just so I understand I’d be enabling bgp across the whole environment correct?  Not just specifically on the tunnel interfaces…?

---

FYI -  Just on the dmvpn tunnels, the underlay will be as it is, the overlay will be bgp which I would say is a most applicable protocol to use for dmvpn.

[ColForbin]

Thanks for that tidbit. Part of me is a bit skeptical, that I’m going to see a problem getting the remote lans to route across the  tunnel…

[MHM Cisco World]

Friend two design of ospf with dmvpn

1- using p2mp network type

2- broadcast network type 

Which network type you use in dmvpn tunnel? 

MHM

[ColForbin]

It's broadcast...

[MHM Cisco World]

Sorry late for reply 

Now if it broadcast did you sure hub elect as DR ?

Can I see 

Show ip ospf neighbor in all hub and spokes

MHM

[Joseph W. Doherty]

. . . technically I can probably do this in the dev environment as a proof of concept . . .

BTW, if you have a dev environment, forget DMVPN for the moment, and build out a similar OSPF multi-area topology, and see its routing behavior.

You should then see the preference for intra-area routes over inter-area routes.

Some reference material:

https://notes.networklessons.com/ospf-route-preference-intra-area-vs-inter-area

https://community.cisco.com/t5/switching/ospf-difference-inter-area-and-intra-area-routes/td-p/1900023

https://www.networkacademy.io/ccna/ospf/ospf-best-path-selection

https://networklessons.com/ospf/ospf-path-selection-explained

Much more can be found if you search on this subject.

Basically, either don't use multiple areas, or you need a correct multi-area topology.

DNVPN can be used with either.

[ColForbin]

Thanks a bunch.  OSPF design predates me and several others here...you mean you can just slap an OSPF config on every interface and it just works?  Just kidding....but in response to your second post here, interesting you've pointed out network lessons...

https://networklessons.com/cisco/ccie-routing-switching/dmvpn-phase-2-ospf-routing

Section 1.2.2

"This is the best OSPF network type [BROADCAST] to use for DMVPN phase 2 and I’ll show you why. First let’s configure it:"

"Now let’s configure some network commands. We’ll go for “best practices” and use a different area number for the DMVPN network:"

That's where the original confirmation for creating a new area came from.  Adding the tunnel initially to area 0 caused a lot of flapping, this resolved that issue.  And presented a host of others.  But it's clear now that the problem, if the DMVPN overlay network should be in area 0, that there's a configuration issue with area 0 to begin with.

On to DEV to work out these issues with these comments in mind...

[Joseph W. Doherty]

Possibly the reason why flapping stopped when you moved tunnels to its own area might be due to them no longer passing traffic.  If fact, depending on costing, with tunnels in same area, they may have been the preferred path, but there's insufficient information to say why you were seeing flapping.

Also, BTW, I'm not saying you cannot have a multi-area design, but there are additional considerations, when doing so.

Lastly, from the information you've provided so far, a Phase 2 (spoke to spoke) design isn't perceived as being needed, correct?  (Incidentally, dynamic spoke to spoke has some touted advantages [true] but sometimes its disadvantages are overlooked.)

Actually for the few spokes you anticipate eventually needing, one could argue p2p tunnels would be acceptable.  (Although if spokes would benefit from external DHCP addressing, DMVPN using NHRP makes that relatively easy.)

Do I recall you mentioning a MPLS underlying network was being used?  With SPs, not typical ISPs, you may have other options for networking between your sites.

If optimal performance is being sought, SD-WAN might be considered.

Also, be careful going to BGP.  Personally, I sometimes get the impression some network engineers consider BGP a rite of passage, and you're not a fully qualified network engineer unless you can support it.  Laugh, actually some truth in the latter, as you might indeed need to be well qualified to use it well.  But, sometimes, perhaps, "can you" ignores "should you".

[ColForbin]

Thanks for the insights. The bgp route was just going to be a test but there’s a reason there’s a whole approval process, it’s not as simple as turning it on and everything suddenly works. Putting that aside for the time being I’ve always though thought the original problem was costing, just couldn’t put my finger on it and didn’t have enough time to debug, but that may be the way to go now. And yes phase 1 would be wholly acceptable it’s only spoke to hub communication. Phase two was just to future proof. 
Going to poke around a bit more today..

[Joseph W. Doherty]

. . .  I’ve always though thought the original problem was costing . . .

In a way, it is, i.e. intra-area is "costed" better than inter-area.  Sort of like, it has a better AD.

That said, your mention of flapping, is concerning.

A possible cause, if you have enough traffic, and for whatever reason, it causes OSPF hellos to be excessively delayed or dropped, OSPF will drop the connection.

When you work with tunnels, you often need to be aware of bandwidth across the tunnel might be much less than local physical interfaces provide.  This can become complex with DMVPN tunnels, because logically they appear separate but they share the underlying physical bandwidth.

Two simple examples, logically spoke<>hub<>spoke.  If all have a physical 10 Mbps hand-offs, the two spokes can send 20 Mbps to the hub.  Okay, so we upgrade hub to 100 Mbps, and now it can send 100 Mbps to each spoke.  (Spoke-to-spoke, compounds the issue.)  There are ways to deal with this, though.  (Or, also for physical hand-off is 100 Mbps, but you have a 25 Mbps CIR for your tunnel traffic.)

Also, when working with tunnels, especially encrypted tunnels, you need to account for extra bandwidth consumption due to tunnel/security headers, and also the possibility of fragmentation, which also uses even more bandwidth, besides impacting tunnel transmission performance and host reception.

BTW, when you optimally setup tunnels, like DMVPN, often, I found, it nearly/often performs on par with dedicated technologies (but can be much, much less expensive.)

[Joseph W. Doherty]

R1/R4/R5 tunnel interfaces: ip ospf 1 area 1 so that *only* the 3 tunnel interfaces are area 1, everything else is left at area 0...is this good practice?

Again, as intra-area paths are preferred over inter-area, if only the tunnels interfaces are in their own area, R4 and R5 wouldn't use them if there's an area 0 path and that's also the area for the local networks.  If you break the area 0 path, you also partition area 0.

So, overall, I suspect it isn't a good design, let alone good practice.  For example, why create area 1 to begin with?

I'm wondering, whether someone thought you cannot have too many routers in a single area, especially area zero, but a) especially with modern OSPF devices, and Cisco's OPSF implementation, OSPF is a bit more robust, size wise, than it was decades ago, and b) OSPF area design isn't just slap down an area wherever, whenever, its seems like it might be a "good idea".