DMVPN Phase 2 OSPF Routing

This topic is to discuss the following lesson:

Excellent lesson

 

What amazing posting ! Thx Rene.

Hi Rene,
what is the default network type for DMVPN tunnel?

If it is point-to-point, we must change it and become mandatory to change it?

Mahmoud,
You are exactly right. The default network type of a DMVPN tunnel is Point-to-Point.

One of the rules of a P2P interface is there can be at most 1 OSPF neighbor. With the Hub’s tunnel interface, however, the OSPF process hears Hello messages from numerous different neighbors’ OSPF processes. This causes the Hub’s OSPF process to churn over and over, throwing out the previously formed Exstart relationship to form a new neighborship with the most recently received Hello. When this happens, you will see these messages on the Hub over and over again for each Spoke it has:
OSPF-5-ADJCHG: Process 1, Nbr 150.1.2.2 on Tunnel0 from EXSTART to DOWN, Neighbor Down: Adjacency forced to reset

To fix this, you MUST change the network type of the tunnel. You have two choices here, Point-to-Multipoint or Broadcast. Which should you choose? If you pick the P2MP network type, DMVPN will not be able to function any more efficiently than at Phase 1. The reason for this is because the P2MP network type changes the next hop value of all traffic to be the hub. This means that all traffic flows through the hub, and you are no better off than Phase 1.

Therefore, you should change the network type of the tunnel to be Broadcast. Even this, however, has its pitfalls. You must ensure that each spoke is configured so that it will never be elected as the DR or BDR via the “ip ospf priority 0” command.

Can you see why it is generally recommended NOT to run OSPF via DMPVN? :slight_smile:

Many Thanks Andrew for your support

Hey There,

is it really required to change the OSPF priority to 0 on the spokes in case you go for OSPF network type Broadcast?
(if i recall it right with DMVPN Ph2 you should have spoke-to-spoke direct connectivity and if this is true then it should be technically possible for the spokes to be elected as DR/BDR )

Regards,
Salvatore.

Hello Salvatore

Yes you are correct that for Phase 2 with a broadcast network type, there is direct spoke-to-spoke connectivity. However, this direct connectivity is achieved AFTER the initial communication occurs with the HUB. When a spoke router wants to reach another spoke, it will send an NHRP resolution request to the hub to find the NBMA IP address of the other spoke. This means that initial connectivity must be made with the hub router.

Additionally, in order to achieve this direct spoke-to-spoke connectivity, you need two things:

* Spoke routers need to have a route for the network that they are trying to reach.
* The next hop IP address of the route has to be the remote spoke.

So really in order to achieve spoke-to-spoke connectivity, routing between the spokes must first be established. Initial communication only occurs between the Hub and each individual spoke and this is where the routing exchange must occur.

I hope this has been helpful.

Laz

Ciao Lazaros,

thanks for your detailed description,

if i understood it right, it seems to be a matter of priorities:
before the spoke-to-spoke communication can work I should have hub & spoke reachability which means that, in case I decide to use OSPF, the DR/BDR election it’s a prerequisite for the spoke-to-spoke communication to be established

Thanks,
Salvatore.

Ciao Salvatore

Yes, this is essentially correct. These are the things that have to happen and in this order so that spoke to spoke communication can occur:

  1. Communication from spoke to hub via NHRP resolution must take place to find the NBMA IP address of the other spoke
  2. Once the NBMA IP address is learned, a route to the other spoke must be determined (even if it is directly connected). In order for this to take place, OSPF must already have gone through the route determining processes, so the DR must be at the hub
  3. Once the routes have been determined, spoke to spoke communication can occur.

OSPF convergence is a prerequisite of spoke to spoke communication.

I hope this has been helpful!

Laz

For Phase2 ; first hit of the traceroute displays also the Hub node. Is it correct ?

SPOKE-2#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** 64 msec 48 msec 64 msec
  2 172.16.123.2 56 msec 60 msec *

Hello Maodo

All traffic will go through the hub when you configure a point to multipoint network (both broadcast and non broadcast). This is expected behaviour. All other types of OSPF networks should not see the hub router as the first hop.

The type of OSPF network being used will also determine how traffic will be routed. For the topology of this network, the multipoint OSPF network types will have the hub as the next hop while the others will have the destination as the next hop.

I hope this has been helpful!

Laz

  • First call of traceroute : RIP, EIGRP, OSPF (BROADCAST, NBMA, POINT-TO-MULTIPOINT). All 5 labs do show the HUB hop.

  • Next calls : Only OSPF (POINT-TO-MULTIPOINT) does show the HUB hop at each call.

Below is OSPF (POINT-TO-MULTIPOINT) output.

**SPOKE-2#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 16 msec 8 msec 8 msec
  2 172.16.123.2 20 msec 20 msec *
**SPOKE-2#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 12 msec 20 msec 12 msec
  2 172.16.123.2 28 msec 28 msec *
**SPOKE-2#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 8 msec 16 msec 8 msec
  2 172.16.123.2 32 msec 20 msec *
**SPOKE-2#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 12 msec 12 msec 20 msec
  2 172.16.123.2 32 msec 40 msec *
**SPOKE-2#**

Hello Maodo

For all DMVPN phase 2 configurations, when using RIP, EIGRP, or OSPF, the first packet is always sent to the hub. This is why you see initially that traceroute has a next hop of the hub IP. After that, because NHRP functions to provide the sending spoke with the direct IP address of the other spoke(s), in the rest of the traceroutes you will see only the next hop of the destination spoke.

This is the case EXCEPT for point to multipoint networks for OSPF. Only then will you see the hub in ALL subsequent traceroutes.

I hope this has been helpful!

Laz

Thank you for the answer Lazaros.

According to what you say. For all these articles on DMVPN Phase 2 ; a text explaining that the “traceroute” to be considered is not the first one must be added.

1 Like