This topic is to discuss the following lesson:
Hello René.
Great basic DMVPN lab but i have a request:
A DMVPN lab with 2 ISP’s (Multihoming) and load balancing using EIGRP Add-Path Support. I have had a hard time understanding the concept of that.
Hi William,
I just published two examples for this:
DMVPN dual hub single cloud
DMVPN dual hub dual cloud
I haven’t included EIGRP Add-Path Support (yet) but this might be useful.
Rene
1 Like
Hi Rene,
If I want to migrate DMVPN phase 2 to phase 3 with EIGRP configured … what are the 3 changes that need to be done ??
Hi Shashi,
For a detailed answer you can take a look here:
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:
- I note that the syslog message that appears says “next_hop_self value changed”. Are you using the
ip next-hop-self eigrpcommand? 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? - 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