DMVPN Phase 1 Basic Configuration

Hello Pradyumna

I’m not sure what you mean by “cloud configuration”. Do you mean the “cloud” found within the diagrams like this?
image
If you want to do a lab that matches the above topology, the only thing you need is to put a switch in the centre and connect the hub and spokes to that switch. Simply make sure that all interface IPs are in the same subnet and the routers can communicate with each other. This will create the underlay network, as described in the lesson, which, in a real-world example, would be the Internet itself, where all routers would have a public IP address so that they can ping each other. The DMVPN configuration on top of that is the overlay network, which will carry the user traffic and data.

If you need further clarification, please let me know.

I hope this has been helpful!

Laz

1 Like

Ok got it but if we can use switch then why are you using cloud?, if i am right you are using cloud just to represent sites are on wan network but actually it is a switch on internet ?

Hello Pradyumna

A cloud is being used in the diagrams because a real DMVPN topology will function over a network like the Internet. A DMVPN network would never be implemented on a local network with the use of a switch, except in a lab environment. However, I can see how this can cause confusion. I will let Rene know to see if he can clarify the lesson to avoid this confusion…

I hope this has been helpful!

Laz

1 Like

Hi Rene / Laz,

I recreated this lab, and whenever i shut and unshut the Tunnel of Hub, the DMVPN does not come up automatically, i have to either do same on each spoke or type “clear dmvpn session peer 172.16.123.1 static”

Can you let me know why this is happening.

Hello Justin

In order for a DMVPN connection to take place between a spoke and the HUB, the spoke sends an NHRP Registration request. The spoke initiates the communication. The HUB responds, and then the tunnel is established. If you shutdown the tunnel interface of the HUB, and then bring it back up again, the spokes are not aware of any such changes. When the tunnel interface comes back up, it does not send out any information to the spokes to say “hey I’m back up again” because all communication with the spokes has been lost, and remember that the initial connection is always initiated by the spokes.

So, you find that when you bring the HUB tunnel back up, you are not getting an established connection to the spokes right away. In order to have them reestablish right away, you need to shut and no shut the tunnel interfaces of the spokes.

I labbed this up and duplicated your results. However, if you wait long enough, the spokes will eventually send a keepalive to the HUB and will realize that the connection had failed, and will send a new NHRP registration to re-establish connectivity.

I hope this has been helpful!

Laz

Thanks for your reply.

So, just a curiosity, is there a way to make it quicker.

Hello Justin

Yes, it is possible to adjust this parameter, and it has to do with the NHRP registration process. NHRP is governed by a few timers, including the holdtime and the timeout. More detail on these timers and the way the function can be found at this Cisco documentation:

I hope this has been helpful!

Laz

Hi Rene,

I am trying to inject default route from Hub, but its not working… could you please look at the configuration and let me know what’s wrong…

Also please advise how can i send summary route towards spoke routers

Hub#show run int tu1
Building configuration...

Current configuration : 286 bytes
!
interface Tunnel1
 ip address 192.168.1.1 255.255.255.0
 no ip redirects
 ip nhrp authentication DMVPN
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 no ip split-horizon
 ip summary-address rip 0.0.0.0 0.0.0.0
 tunnel source GigabitEthernet1/0
 tunnel mode gre multipoint
end

Hub#

spoke1#show run int tu2
    Building configuration...

Current configuration : 266 bytes
!
interface Tunnel2
 ip address 192.168.1.2 255.255.255.0
 ip nhrp authentication DMVPN
 ip nhrp map 192.168.1.1 1.1.1.1
 ip nhrp map multicast 1.1.1.1
 ip nhrp network-id 1
 ip nhrp nhs 192.168.1.1
 tunnel source GigabitEthernet1/0
 tunnel destination 1.1.1.1
end

spoke1#


spoke2#show run int tu3
Building configuration...

Current configuration : 266 bytes
!
interface Tunnel3
 ip address 192.168.1.3 255.255.255.0
 ip nhrp authentication DMVPN
 ip nhrp map 192.168.1.1 1.1.1.1
 ip nhrp map multicast 1.1.1.1
 ip nhrp network-id 1
 ip nhrp nhs 192.168.1.1
 tunnel source GigabitEthernet2/0
 tunnel destination 1.1.1.1
end

spoke2#

Hub#show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
        N - NATed, L - Local, X - No Socket
        # 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: Tunnel1, IPv4 NHRP Details
Type:Hub, NHRP Peers:2,

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 1.1.1.2             192.168.1.2    UP 00:01:23     D
     1 1.1.1.3             192.168.1.3    UP 00:01:22     D

Hub#

Hub#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
   D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
   N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
   E1 - OSPF external type 1, E2 - OSPF external type 2
   i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
   ia - IS-IS inter area, * - candidate default, U - per-user static route
   o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
   + - replicated route, % - next hop override

Gateway of last resort is not set

  1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        1.1.1.0/24 is directly connected, GigabitEthernet1/0
L        1.1.1.1/32 is directly connected, GigabitEthernet1/0
  11.0.0.0/32 is subnetted, 1 subnets
C        11.11.11.11 is directly connected, Loopback1
R     22.0.0.0/8 [120/1] via 192.168.1.2, 00:00:28, Tunnel1
R     33.0.0.0/8 [120/1] via 192.168.1.3, 00:00:54, Tunnel1
  192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.1.0/24 is directly connected, Tunnel1
L        192.168.1.1/32 is directly connected, Tunnel1
Hub#

Hello Pushpender

It looks like you’re configuring DMVPN Phase 1 with the use of the RIP routing protocol. Take a look at the following lesson where Rene has configured such a topology using RIP and has injected a default route from the HUB to the spokes:

I hope this has been helpful!

Laz

HI Laz,

1)Here On Hub and Spokes which commands are responsible for generating NHRP request and NHRP Reply?

  1. can we use interface address instead of ip address as destination and why are we using underlay network address for specifying tunnel destination rather than overlay network address?

Hello Pradyumna

The commands that establish the NHRP peering are those that enable the generation of NHRP. Specifically, it is the ip nhrp map command that tells the spoke the hub’s tunnel and public interface addresses, so it knows where to send the request.

Both underlay and overlay addresses are needed for communication. The underlay for the tunnel termination, and the overlay for the routing of the user traffic. The routing uses the overlay address (to get to the final destination which is a host behind one of the spokes) and the underlay address is used to establish the tunnel necessary to get to the spoke.

I hope this has been helpful!

Laz

Hi Rene,

I need to know how does the spoke routers already know about each others private/overlay IP address?

Hello Muhammad

In this particular lesson, we’re looking at how DMVPN Phase 1 operates. In Phase 1, the spokes register with the hub router using NHRP. Because all spoke tunnel interfaces have an IP address in the same subnet if you ping Spoke 2 from Spoke 1, the subnet is considered directly connected to the tunnel interface, therefore any such pings will exit the tunnel interface. Such a ping will reach the hub, which will use NHRP to determine how to reach the destination.

Now keep in mind that this lesson describes only the connectivity between the routers. If you have subnets behind each spoke, and you want hosts behind one spoke to reach hosts behind another, then you need to employ a routing protocol, or to apply static routing at the spokes.

For more information on how Phase 1 operates with NHRP take a look at this lesson:

For information on how to employ EIGRP on a DMVPN Phase 1 network, take a look at this lesson:

For information on how to employ other routing protocols on DMVPN networks of various phases, take a look at all of the DMVPN lessons in the series.

I hope this has been helpful!

Laz

Thanks Laz,

It’s clear, much appreciated…!!

1 Like

Hi, A question about “show dmvpn”
when I run this show command I see in state NHRP and UP, trying to understand what is the difference ?

Hello Max

Under the State column of the output, if the tunnel is up, it will show UP. If the tunnel is down, it will show you the reason for the down state. It will display one of the following three things:

  • IKE
  • IPsec
  • NHRP

This indicates the reason for the error. NHRP indicates that there is a problem with the operation of NHRP.

More info can be found here:

I hope this has been helpful!

Laz

1 Like

Hello, everyone.

I am a little confused by some of the commands here.

ip nhrp map multicast dynamic: this command tells the hub router where to forward multicast packets to. Since the IP addresses of the spoke routers are unknown, we use dynamic to automatically add their IP addresses to the multicast destination list when the spokes register themselves.
ip nhrp map multicast: here we specify which destinations should receive broadcast or multicast traffic through the tunnel interface. The confusing part is that you have to enter the NBMA address here. We need this command since routing protocols like RIP, EIGRP and OSPF require multicast.
ip nhrp map: we use this on the spoke to create a static mapping for the hub’s tunnel address (172.16.123.1) and the hub’s NBMA address (192.168.123.1). This will be stored in the NHRP cache of the spoke router.

ip nhrp nhs: this is where we specify the NHRP server, our hub router.

The first 2 commands that confuse me are ip nhrp map multicast and ip nhrp map multicast dynamic. Why do we need to specify destinations which should receive broadcast and multicast traffic? We’ve built P2P GRE tunnels in the previous lessons and even ran an IGP over it, which means that a GRE tunnel supports multicast/broadcast by default, does it not?

Then there are the ip nhrp map, ip nhrp nhs

ip nhrp map maps the hub’s tunnel IP to its public IP.
ip nhrp nhs is to specify the NHRP server

These two feel a little redundant to me. The first one maps the hub’s (the NHRP server’s) tunnel IP to its public IP, but then we also have to configure who the NHRP server is? Didn’t we just technically do that?

And then again, there’s the tunnel destination command which also requires us to specify the IP of the hub router.

I don’t know, these 3 just keep mixing for me and they feel like they do the exact same thing.

Could someone please clear these problems up for me? Thank you :slight_smile:

David

Hello David

DMVPN does indeed use GRE as its underlying tunnel-creating mechanism, however, it also uses NHRP in order to dynamically resolve the next-hop router’s IP address. These commands are applied for the benefit of the operation of NHRP.

On the hub, we issue the ip nhrp map multicast dynamic command to tell the router to dynamically learn and map multicast sources to remote sites. When the hub receives multicast traffic, it will use NHRP to determine which remote sites are interested in the multicast group and then forward the multicast traffic only to those interested sites. If the command is not issued, the hub router will treat multicast traffic as unicast traffic, sending a copy to each remote site regardless of whether they have active receivers interested in the multicast group.

On the spoke, we issue the ip nhrp map multicast <ip_address> command where <ip_address> is that of the hub. This command essentially defines a mapping for multicast traffic, so that the spoke will send all multicast traffic to the hub. If the command is not issued, the spoke may send the multicast traffic to multiple hubs (if they exist) or it may even broadcast it over the entire network.

These commands essentially apply mappings that tell NHRP how to handle multicast traffic in a more efficient and correct manner.

I can see how these commands may seem somewhat redundant, however, they serve different purposes.

The ip nhrp map command maps the hub’s tunnel IP to its public IP. This defines the map[ping between the logical tunnel and the physical NBMA address of the hub. This is needed to perform address resolution to help spokes determe where to send NHRP requests.

The ip nhrp nhs command specifies the IP address of the NHRP server for NHRP registration of the spokes. The key here is that although it’s common for the hub router to also serve as the NHRP server, this is not always the case. In larger and more complex DMVPN deployments, you may choose to have a dedicated device other than the hub serve as the NHRP server. In that case, the IP address of the server and the IP address of the hub’s tunnel IP will be different.

I hope this has been helpful!

Laz

Hello Laz.

Thank you very much again for your great explanation, all is clear to me now :slight_smile:

I’ve one more question. What’s the use of the

tunnel key x

command in DMVPN? The OCG says that it helps identify the the DMVPN tunnel interface if multiple tunnel interfaces use the same tunnel source interfaces.

What does this mean? Have you got an example for this, please?

Thank you!

David

Hello David

The tunnel key command is used not only in DMVPN scenarios, but in all scenarios that use GRE tunnels. You can find out more about it at this lesson:

I hope this has been helpful!

Laz