Solved: DMVPN PHASE 3 with OSPF - Network type Broadcast or Point-to-Multipoint ?

Matthew burnley · ‎05-30-2016

Hi guys,

Ive been doing some studying and labbing today in GNS3 on the DMVPN technology, but i cant find a definitive answer to this question.

So i understand that phase 1 is achieved by setting the OSPF network type to point-to-multipoint so any spoke to spoke traffic is routed via the hub. I also get that phase 2 is achieved by using the network type broadcast command and this allows direct spoke to spoke connectivity as the DR router does not alter the next hop of the spoke route and with the help of NHRP it can build a direct tunnel to that spoke.

I guess my confusion is with phase 3. I get that you need the "ip nhrp shortcut and ip nhrp redirect" on the hub interfaces and just "ip nhrp shortcut" on the spoke interfaces and i get that the NHRP redirect will be triggered when a packet comes into one interface and is to be routed out the same interface then the NHRP redirect will be sent.

But does Phase 3 only work when the OSPF network type is Point-To-Multipoint? I have labbed it in GNS 3 and i can see that the next hop for the routes shows the next hop to be the HUB router but after the NHRP redirect is received it goes directly to the spoke amid a next hop override. I labbed it with the NHRP redirect and shortcut command and the changed the OSPF network type to Broadcast, but the next hop always shows as going directly to the spoke so i cant see any difference between phase 2 and 3?

Can anybody clear this up for me? Im struggling to find details on this one.

Thanks.

Tim Y · ‎05-30-2016

Hi,

It will work if the OSPF network type is broadcast, however you will be limited to two hubs and won't be able to take advantage of the hierarchical hub design that DMVPN Phase 3 offers (which is mostly the point of using Phase 3 to begin with).

I would configure it as Point-to-Multipoint. When it is configured this way the DR and BDR requirements go away. In terms of the routing, it should look different than Phase 2.

In Phase 2 you would see the route next hop to be the spoke

In Phase 3, the route next hop would still be the hub but there would be a CEF rewrite:

192.168.0.0/16         <spoke tunnel IP instead of hub>        Tunnel110

Also, in Phase 3, if you're running IOS-XE or IOS 15.X, you will be able to see a % next to the route showing there is a next hop override, and also NHRP routes:

O % 192.168.0.0/16 [110/XXXX] via <Hub IP>, 3d21h, Tunnel110
H 192.168.1.1/32 [250/1] via <Spoke IP>, 3d21h, Tunnel110

To summarize your routes and CEF prefixes should look different when using Phase 3. But the big difference is how you can set up your DMVPN network hierarchy. It becomes way more modular and scalable and makes way more sense when you have hubs in varying physical regions.

Regards,

Tim

View solution in original post

Tim Y · ‎05-30-2016

Hi,

It will work if the OSPF network type is broadcast, however you will be limited to two hubs and won't be able to take advantage of the hierarchical hub design that DMVPN Phase 3 offers (which is mostly the point of using Phase 3 to begin with).

I would configure it as Point-to-Multipoint. When it is configured this way the DR and BDR requirements go away. In terms of the routing, it should look different than Phase 2.

In Phase 2 you would see the route next hop to be the spoke

In Phase 3, the route next hop would still be the hub but there would be a CEF rewrite:

192.168.0.0/16         <spoke tunnel IP instead of hub>        Tunnel110

Also, in Phase 3, if you're running IOS-XE or IOS 15.X, you will be able to see a % next to the route showing there is a next hop override, and also NHRP routes:

O % 192.168.0.0/16 [110/XXXX] via <Hub IP>, 3d21h, Tunnel110
H 192.168.1.1/32 [250/1] via <Spoke IP>, 3d21h, Tunnel110

To summarize your routes and CEF prefixes should look different when using Phase 3. But the big difference is how you can set up your DMVPN network hierarchy. It becomes way more modular and scalable and makes way more sense when you have hubs in varying physical regions.

Regards,

Tim

Matthew burnley · ‎05-30-2016

HI Tim,

Thanks for the reply. When i did this in GNS3, for Phase 2 with OSPF broadcast network type i saw the next hop as the tunnel interface IP of the spoke as expected.

When i added the redirect and shortcut commands to the hub and the shortcut command to the spokes and rerun the test i saw the next hop as still the spoke directly.

Although when i changed the network OSPF type to point-to-multipoint, i could see that the next hop was the HUB but when i did a trace it went to the spoke directly.

Not sure if this is a bug :/

Tim Y · ‎05-30-2016

Hey,

Although when i changed the network OSPF type to point-to-multipoint, i could see that the next hop was the HUB but when i did a trace it went to the spoke directly.

That's not a bug. That's exactly what I described in my last post. The next hop in the routing table will be the hub, but there will be a CEF rewrite to the spoke. It routes via CEF.

Regards,

Tim

Please don't forget to rate useful posts and mark answers as correct.

Matthew burnley · ‎05-30-2016

Thanks Tim.

I was referring to the bug possibly been when i had the OSPF network type set to broadcast and was using the phase 3 config, i was still seeing the next hop as the spoke directly. Where as when i change to point-to-multipoint the next hop is the hub.

Im wondering if this is normal behaviour or not bearing in mind phase 2 uses OSPF network type broadcast natively and just adding the phase 3 config

ip nhrp redirect/shortcut etc

would not necessarily change the next hop to the hub?

Tim Y · ‎05-30-2016

Ah. Yeah that's likely not a bug. Check your CEF adjacency table and see if the entry was able to be rewritten. If not, it's likely that it wasn't able to do so because the OSPF network type is broadcast.

Cisco documentation for OSPF deployments all say to use point-to-multipoint for DMVPN Phase 3 and this is probably one reason why.

Good luck!

Regards,

Tim