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:

1 Like

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

1 Like

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

Hi All
Thank you for this great lesson !

I just want to know , what is the different between these network types (broadcast or non-broadcast ) when i am using DMVPN ?

Hello Hosam

DMVPN is a network topology that has a particular behaviour. Specifically, DMVPN is a NBMA network topology, similar to Frame-Relay. Even so, OSPF considers any GRE multipoint tunnel interface as point to point. If you configure OSPF without any designation of network types, the default will be point to point. You can verify this by creating a topology, configuring OSPF without any network type configuration, and then issue the show ip ospf int tunnel 1, you’ll see the following:

Tunnel1 is up, line protocol is up
  Internet Address 10.255.253.10/24, Area 0
  Process ID 100, Router ID 10.10.10.10, Network Type POINT_TO_POINT, Cost: 11111

Note the Network Type information. Unless you change this to an appropriate configuration, it will simply not work.

If you choose to use broadcast, then OSPF will function just like any Ethernet-based network will function by default. All three routers, which are in the same subnet on their tunnel interfaces, will learn each other’s routes, and neighbor adjacencies will form (assuming you’ve configured the hub to be the DR, as per the lesson.)

If you choose non-broadcast, then the result is exactly the same, except for the fact that neighbor adjacencies will not form automatically, but must be manually configured, as stated in the lesson.

I hope this has been helpful!

Laz

1 Like

Hi Laz,

can you explain what does it mean, " You can also see that 1.1.1.1/32 shows up as an inter-area route. This is good, it means we can summarize networks “behind” the hub towards the spoke routers if we want"

Hello Pradyumna

Remember that you are only able to summarize OSPF routes between areas. OSPF does not have any mechanism that allows you to summarize routes within an area. Since the routes that appear in the routing table are IA routes, this means that we can summarize all routes from other OSPF areas, resulting in smaller and more efficient routing tables.

More information about summarization in OSPF can be found at the following lesson:

I hope this has been helpful!

Laz

Hello all,

i am facing issues with DMVPN phase 2 ospf-non-broadcast.
Headoffice

Hub-Headoffice#show run int tun 1
Building configuration...

Current configuration : 255 bytes
!
interface Tunnel1
 ip address 172.16.1.1 255.255.255.0
 no ip redirects
 ip nhrp authentication DMVPN
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 ip ospf network non-broadcast
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint
 !
end

Hub-Headoffice#show run | sec router ospf
router ospf 1
 log-adjacency-changes
 network 1.1.1.1 0.0.0.0 area 0
 neighbor 172.16.1.3
 neighbor 172.16.1.2
Hub-Headoffice#show ip ospf neighbor

Branch office:


interface Tunnel1
 ip address 172.16.1.2 255.255.255.0
 no ip redirects
 ip nhrp authentication DMVPN
 ip nhrp map multicast 200.200.200.1
 ip nhrp map 172.16.1.1 200.200.200.1
 ip nhrp network-id 1
 ip nhrp nhs 172.16.1.1
 ip ospf network non-broadcast
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint
 !
end


Branch1-Spoke1#show run | sec router ospf
router ospf 1
 log-adjacency-changes
 network 2.2.2.2 0.0.0.0 area 0
 network 172.16.1.0 0.0.0.255 area 0
Branch1-Spoke1#show ip ospf neighbor