DMVPN Phase 3 OSPF Routing

(Rene Molenaar) #1

This topic is to discuss the following lesson:

0 Likes

(Harvinder G) #2

Rene,

what would be the reason for nbma 192.168.123.2 to inside ip 172.16.123.2 be showing twice under “show dmvpn” command? It has shown several times in your examples.

Thanks.

0 Likes

(Rene Molenaar) #3

Hi Harvinder,

Take a look below:

Spoke2#show dmvpn        
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
        N - NATed, L - Local, X - No Socket
        T1 - Route Installed, T2 - Nexthop-override
        C - CTS Capable
        # Ent --> Number of NHRP entries with same NBMA peer
        NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
        UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface: Tunnel0, IPv4 NHRP Details 
Type:Spoke, NHRP Peers:2, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     2 192.168.123.2      172.16.123.2    UP 00:01:27   DT2
                          172.16.123.2    UP 00:01:27   DT2
     1 192.168.123.1      172.16.123.1    UP 00:02:57     S

Above you can see two entries for the spoke1 router. When we add the detail parameter, you can see why there are two entries:

Spoke2#show dmvpn detail 
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
        N - NATed, L - Local, X - No Socket
        T1 - Route Installed, T2 - Nexthop-override
        C - CTS Capable
        # Ent --> Number of NHRP entries with same NBMA peer
        NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
        UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface Tunnel0 is up/up, Addr. is 172.16.123.3, VRF "" 
   Tunnel Src./Dest. addr: 192.168.123.3/MGRE, Tunnel VRF ""
   Protocol/Transport: "multi-GRE/IP", Protect "" 
   Interface State Control: Disabled
   nhrp event-publisher : Disabled

IPv4 NHS:
172.16.123.1  RE priority = 0 cluster = 0
Type:Spoke, Total NBMA Peers (v4/v6): 3

# Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb    Target Network
----- --------------- --------------- ----- -------- ----- -----------------
    2 192.168.123.2      172.16.123.2    UP 00:01:52   DT2         2.2.2.2/32
      192.168.123.2      172.16.123.2    UP 00:01:52   DT2    172.16.123.2/32
    1 192.168.123.3      172.16.123.3    UP 00:01:52   DLX         3.3.3.3/32
    1 192.168.123.1      172.16.123.1    UP 00:03:22     S    172.16.123.1/32

There’s an entry for 2.2.2.2/32 and 172.16.123.2/32 network.

Hope this helps.

Rene

0 Likes

(Lordly M) #4

Rene I set this up, Spoke still use Hub as next-hop, Spoke 2 is fine but Spoke 1 still shows 172.6.132.1 as next hop in cef
see output below

Spoke 2
Spoke2#traceroute 2.2.2.2 source loopback 0
Type escape sequence to abort.
Tracing the route to 2.2.2.2
VRF info: (vrf in name/id, vrf out name/id)
  1 172.16.123.1 32 msec 28 msec 24 msec
  2 172.16.123.2 76 msec 32 msec *
Spoke2#show ip cef 2.2.2.2
2.2.2.2/32
  nexthop 172.16.123.2 Tunnel0

-

Spoke 1
Spoke1#traceroute 3.3.3.3 source loopback 0
Type escape sequence to abort.
Tracing the route to 3.3.3.3
VRF info: (vrf in name/id, vrf out name/id)
  1 172.16.123.1 28 msec 52 msec 28 msec
  2 172.16.123.3 52 msec 44 msec *
Spoke1#show ip cef 3.3.3.3
3.3.3.3/32
  nexthop 172.16.123.1 Tunnel0

I checked all Tun0 configs, ip nhrp redirect, and ip nhrp shortcut are on the Tun0. All 3 routers are using same code 15.2(4)M6 Adv Enteprise.

Please advise. Thanks

0 Likes

(Stefanio L) #5

How should the behavior when it is deployed with the ISIS? It would be nice to post a lesson of ISIS in phases 1, 2 and 3.

0 Likes

(Rene Molenaar) #6

Hi @stlourenco,

That is a short answer…you can’t :smile: IS-IS is not supported in DMVPN.

IS-IS doesn’t use IP for routing and NHRP only supports IP for address resolution.

0 Likes

(Ricardo V) #7

Hello there,

Hey Rene, you DMVPN phase 3 with OSPF definitely made a difference in this whole nightmare. I spent several hours researching and trying to troubleshoot an OSPF point-to-multipoint issue. At this point I am still not sure what the problem is. I have a customer network that experience this same behavior where the spoke to spoke traffic does randomlt go direct via a new tunnel. Because this is a DMVPN backup network there’s no traffic all the time. I have waited enough time to allow for the first set of packets to traverse to the destination via the Hub but the next-hop override never get’s installed in some of the spokes. Trust I tried everything and nothing made a difference. I ensured that all configuration were in accordance to the latest Cisco’s best practices including the following:

  • Static default route at each site pointing to the Internet. All DMVPN NBMA IP address were reachable via that path.
  • Hub using “ip nhrp redirect”
  • spoke using “ip nhrp shortcut”
  • All OSPF network types “Point-to-Multopint” ***** THIS IS INTERESTING ONE

Pretty much at least three people have checked the config and none have been able to determine what the problem is. I then went through your article and you mentioned an interesting thing about the OSPF point-to-multipoint behavior in regards to the next-hop. This is exactly where I’m not a 100% sure on what’s causing the issue but if I change all the OSPF interface to “BroadCast” the thing works like a charm. I move them back to p-2-multipoint the spoke-to-spoke traffic keep not being stable in terms of it’s path. That inconsistency keeps causing routing changes in terms of OSPF cost and undesired behaviors.

If possible it would be awesome if you can throw some light on what you think of the following:

  • Is there a well known issue with DMVPN phase 3 when using OSPF point-to-multipoint in terms of how the CEF table get updated with the next-hop override information? Are there any issues on why the override is never seen on certain spokes regardless those have the exact config (Except IP addresses and mappings)?

  • Is there a specific reason why to use point-to-multipoint over than Broadcast other than having to manually set OSPF priorities to manually set the DR/BDR routers?

Thanks a lot,
Ricardo

0 Likes

(Rene Molenaar) #8

Hi Ricardo,

The difference between OSPF P2MP and broadcast/non-broadcast is that with P2MP, the next hop will always be the hub and with broadcast/non-broadcast it will be the remote spoke. I have an example for this:

This is about frame-relay but it’s the exact same thing with DMVPN. If it’s working with broadcast (where the next hop is the remote spoke, not the hub) then it indeed sounds like an issue with the next hop override.

You could try to enable some NHRP and OSPF SPF debugs on your routers, see if anything happens. Is there a reason why you want to use OSPF? Since it’s a link-state routing protocol, it’s not the best option for DMVPN. All your routers are in the same area so any change triggers an SPF calculation.

If broadcast works then I don’t see a problem to use that instead of P2MP.

Rene

0 Likes

(Hugo d) #9

Hello Rene,

Do you think that is possible to set up a DMVPN Phase3 in a single Cloud environment with Dual Hub and Dual spokes (without using IOS XE and nhrp summarize features) ? What should I have to keep in mind regarding NHRP possible conflicts in LAN-to-LAN traffic between spokes?

Thank you very much for your time :slight_smile:

0 Likes

(Rene Molenaar) #10

Hello Hugo,

This shouldn’t be a problem. Did you see this example?

If you do this, it’s best to use EIGRP or BGP.

Rene

0 Likes

(Rafael A) #11

Hi Rene,

What do you say that ospf cant be summarized on pahse 3, if the main purpose of phase 3 is to summarize the netowrks

0 Likes

(Lazaros Agapides) #12

Hello Rafael

Rene mentions in the conclusion that summarization cannot be applied. This is not a limitation of DMVPN Phase 3 but a limitation of OSPF. Summarization within the same area cannot be implemented. For this reason, all spoke routers will have to have specific routes to all other destinations, something that is not ideally efficient.

On a side note, the purpose of DMVPN Phase 3 is to allow spoke routers to directly communicate with each other rather than to communicate via the hub. This is done using NHRP redirect on the hub which will instruct the hub to inform spokes that they can communicate directly. Secondly, it is accomplished using the NHRP shortcut feature in the spoke routers which allows them to make changes to the CEF entry when they receive an NHRP redirect message from the hub. More on this can be found here:

I hope this has been helpful!

Laz

0 Likes