DMVPN Phase 3 EIGRP Routing

Hi Shashi,

For a detailed answer you can take a look here:

DMVPN Phase 3

DMVPN Phase 3 EIGRP

The short answer is this:

Hub(config)#interface tunnel 0
Hub(config-if)#ip nhrp redirect 
Spoke(config)#interface Tunnel 0
(config-if)#ip nhrp shortcut

And you need to advertise a summary route on the hub towards your spoke routers that covers the networks behind your spoke routers.

I’m using the IOS image you said you were but for some reason when i try show ip route nhrp it doesn’t recognize “nhrp”

R2#sho ip route nhrp
Translating "nhrp"
                ^
% Invalid input detected at '^' marker.

Also my dmvpn table looks a bit different but still says two entries only displays one line for them

R2#show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incompletea
        N - NATed, L - Local, X - No Socket
        # Ent --> Number of NHRP entries with same NBMA peer

Tunnel0, Type:Spoke, NHRP Peers:2,
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     2   192.168.123.3    172.16.123.3    UP    never D
     1   192.168.123.1    172.16.123.1    UP 03:26:19 S

Last my route table doesn’t show the “%” and “H” indicators next to the routes when I configure as you did in your video.

Here is my image:
ROM: 3700 Software (C3725-ADVENTERPRISEK9-M), Version 12.4(15)T7, RELEASE SOFTWARE (fc3)

Hi Stephen,

The 3725 router is quite old and there are some differences in the commands for IOS 12.4 or 15.x. I did all my DMVPN examples on a recent IOS 15 router:

R1#show version 
Cisco IOS Software, IOSv Software (VIOS-ADVENTERPRISEK9-M), Version 15.6(1)T, RELEASE SOFTWARE (fc1)

Rene

Stephen,
If you happen to be using GNS3, my image of choice for DMVPN is the following:
c7200-adventerprisek9-mz.152-4.M6

Thanks Andrew I was able to get it to work with the 7200 image

Rene- I could not located the 3725 image you are using, what is the filename of it? as I would like to have it as well for sake of consistency.

Hi Stephen,

The 3725 image I used for most GNS3Vault labs is c3725-adventerprisek9-mz.124-15.T7.bin. Any of the other T versions should be fine.

Rene

Hi Rene,

I am a little bit confused here. When you advertise a default route with EIGRP, normally the spokes already have a default route (static maybe) because they are connected to the internet. in this case the EIGRP default route will not show in the routing table as it has a higher AD. and at the same time we cannot remove the default static route as we need it for the internet and also to reach the Hub router. To me, advertising a EIGRP default route here does not make sense because it will not be used. i was wondering if we can see a real summarization example at the Hub where the spokes still can directly communicate. thanks

Hi @hsawiris,

In my example(s), I could get away with a default route in EIGRP since my NBMA network was all directly connected, I didn’t need a default route there.

In a production network, you probably use a default route for Internet access so you can’t get rid of it. I used loopbacks with 2.2.2.2/32 and 3.3.3.3/32 so for summarization, that’s a terrible example.

2.0.0.0/7 would work though…

On a real network, you would probably use subnets that are easy to summarize. For example, something like this:

* Spoke1: 10.10.0.0/24
* Spoke2: 10.10.1.0/24
* Spoke3: 10.10.2.0/24
* Spoke4: 10.10.3.0/24

You could then advertise 10.10.0.0/22 on the hub router.

Hope this helps!

Rene

I configured ip nhrp redirect on the hub, and ip nhrp shortcut on the spokes, I am also using 15.2(4)M6 but ip nhrp redirect doesn’t work

traceroute 3.3.3.3 source loopback 0 still hits the hub first
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 16 msec 24 msec
  2 172.16.123.3 40 msec 16 msec *

Please advise

2 Likes

Hmm with the exact same config as I used? what if you clear NHRP, enable some debugs? does it tell you anything?

Hi Laz,

*Can you clarify why are we getting tunnel address two times of remote spokes?

*One more thing i want to know that you are using summary address command to advertise default route in eigrp so is this the way how can we advertise the default route in eigrp as well as one more thing that we have not specify default route manually on hub then how are we advertising it in eigrp w/o configuring it first?

Hello Pradyumna

You can see the answer in the following post:

Concerning the default route, the summary route is used simply to cause the spokes to send all traffic to the hub to be further redirected to the appropriate destination spoke. It doesn’t matter that there is no default route in the hub. Remember, for phase 3, you don’t need specific routes to each spoke, NHRP takes care of resolving the next hop address.

I hope this has been helpful!

Laz

Hey Rene,
I encountered the same issuse.
I copy pasted your Phase 3 configuration, cleared the nhrp process on both spokes and hub as well as shut-no shut the tunnel interfaces but still go via the hub instead of going directly to the other spoke.

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 192.168.123.1      172.16.123.1    UP 00:00:36     S
D*    0.0.0.0/0 [90/28160000] via 172.16.123.1, 00:03:52, Tunnel0
SPOKE1#trace 3.3.3.3 source loop 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 24 msec 20 msec 20 msec
  2 172.16.123.3 48 msec 40 msec 36 msec

interface Tunnel0
 ip address 172.16.123.1 255.255.255.0
 no ip redirects
 ip nhrp authentication DMVPN
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 ip nhrp redirect
 ip summary-address eigrp 123 0.0.0.0 0.0.0.0
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint

interface Tunnel0
 ip address 172.16.123.2 255.255.255.0
 no ip redirects
 ip nhrp authentication DMVPN
 ip nhrp map 172.16.123.1 192.168.123.1
 ip nhrp map multicast 192.168.123.1
 ip nhrp network-id 1
 ip nhrp nhs 172.16.123.1
 ip nhrp shortcut
 tunnel source FastEthernet0/1
 tunnel mode gre multipoint

Any advice?

Hello Dor

The very first time you do a traceroute from one router to the other, the packet will indeed go via the hub. This first packet is used to allow the spoke to resolve the

I’ve labbed it up and as soon as all my nodes come up, I traceroute from spoke 2 to the loopback of spoke 1:

Spoke2#traceroute 2.2.2.2
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 6 msec 4 msec 2 msec
  2 172.16.123.2 6 msec 3 msec * 

The packet does indeed go through the hub. But all subsequent traffic will go directly from spoke to spoke. I immediately issue the same command again and I get this:

Spoke2#traceroute 2.2.2.2
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.2 3 msec 2 msec * 
Spoke2#

This is because the very first communication from one spoke to another will go to the hub. The hub will then see that the destination is another spoke. This will cause the hub to send an NHRP redirect to both spokes, allowing all subsequent communication to take place directly between spokes. This process is furhter described in the Phase 3 section of this lesson:

I hope this has been helpful!

Laz

1 Like

Hi
As always, I’ve replicated this lab in GNS3, and I saw that if clear the next-hop-override on the Hub with the command clear ip nhrp, I loose all EIGRP routes until I do shutdown and not shutdown on all tunnel interfaces of each router

*Apr 12 18:22:30.492: %DUAL-5-NBRCHANGE: EIGRP-IPv4 123: Neighbor 172.16.123.2 (Tunnel0) is down: next_hop_self value changed
*Apr 12 18:22:30.493: %DUAL-5-NBRCHANGE: EIGRP-IPv4 123: Neighbor 172.16.123.3 (Tunnel0) is down: next_hop_self value changed
*Apr 12 18:22:31.203: %DUAL-5-NBRCHANGE: EIGRP-IPv4 123: Neighbor 172.16.123.3 (Tunnel0) is up: new adjacency
*Apr 12 18:22:31.408: %DUAL-5-NBRCHANGE: EIGRP-IPv4 123: Neighbor 172.16.123.2 (Tunnel0) is up: new adjacency

How can I prevent this behavior?

Thanks

Hello Giovanni

Keep in mind that in Phase 3, NHRP is responsible for resolving the next-hop IP address. As stated in the introductory lesson to DMVPN:

The final phase of DMVPN changes the way NHRP operates. The spoke routers no longer need specific routes to reach remote spokes and it doesn’t matter what the next hop IP address is. When a spoke router wants to reach a remote spoke, they will forward their traffic to the hub. When the hub receives the traffic, it will realize that another spoke is the destination and it will then send a NHRP redirect to both spokes.

When the spokes receive the NHRP redirect, they will both send a NHRP resolution to figure out each other’s NBMA IP addresses. The spoke routers will then install a new entry in the routing table so that they can reach each other directly.

So as soon as you clear NHRP mappings, you’re removing all next-hop IP address information, you lose connectivity, and you also lose EIGRP adjacencies. Typically, when a spoke attempts to communicate with the hub, NHRP will kick in again, and the exchange of NHRP packets will take place to reestablish the next hop and communication s well.

So my first question is, if you clear NHRP, and then attempt to ping from a spoke to the hub or the other spoke, is communication reestablished? If so, then the behavior you see is normal.

However, I have the following additional questions:

  1. I note that the syslog message that appears says “next_hop_self value changed”. Are you using the ip next-hop-self eigrp command? This is not needed for Phase 3 but is needed for Phase 2. Could it be that it was left over from a previous config you did?
  2. I also note that the syslogs appear to indicate that EIGRP forms a new adjacency almost immediately after the initial adjacency is lost, less than a second later. You mentioned that adjacencies don’t come back up until you reset the tunnels. What is the case there? Maybe adjacencies are made but NHRP next hop information isn’t sent simply because there is no traffic?

Just some thoughts that may help you in your troubleshooting process.

I hope this has been helpful!

Laz

Hi,

Am I right in assuming that when you advertise a default route from the hub, disabling split-horizon on the tunnel interface is no longer necessary?

I just noticed the answer to my question is in the Conclusions section, but just to clarify, you only don’t need to worry about split horizon if a default route is used - correct?

Regards,

Sam

Hello Samir

Yes, you are correct. Split horizon can become an obstacle when you want one spoke to advertise networks to another spoke. In such a case, it is necessary for an update to enter a particular interface on the hub, and be readvertised out of the same interface, which violates split horizon.

In the scenario in the lesson, we don’t have this situation because spokes don’t need to learn about each other’s networks.

I hope this has been helpful!

Laz

1 Like

Hello, everyone!

I was playing around with DMVPN and wanted to see the redirection process in action after it has already happened, so I issued the clear ip nhrp command to clear the NHRP cache and noticed the following packet pop up in Wireshark

Note: This is the link between the Hub and the two spokes. 3.3.3.3 is the hub and the rest are the spokes.


What exactly does this message do, please? Google says that when a network entry is deleted in the RIB, NHRP is notified of the event. But why do we care? For all we know, the Spoke could just send a packet to the hub, which would attempt to redirect it again.

Thank you.

David

Hello David

The NHRP purge request, as you correctly shared, is a message that is sent when a network entry is removed from the RIB. The message instructs the receiving device to remove a particular entry from the NHRP cache. What is the purpose of this? Of course, a spoke could send a packet once again to the hub, which would renew and update the NHRP entries. However, it is always preferable to keep the NHRP cache updated.

Over time, the NHRP cache may accumulate entries that are no longer valid. For example, a spoke might change its physical IP address, or a tunnel might become inactive. Keeping outdated entries can lead to inefficient routing and potential security issues.

The NHRP Purge Request is used to trigger the removal of such stale or invalid entries from the NHRP cache. It can be initiated by a network device (like a router) that detects a change in the network topology, or as a routine maintenance procedure.

Regular purging of the NHRP cache helps maintain optimal network performance in a DMVPN setup. It ensures that the path information is current, which is critical for the efficient and secure routing of traffic within the VPN network.

I hope this has been helpful!

Laz