This topic is to discuss the following lesson:
Hi !
Now i am on this , i get this debug message
Packet received via GigabitEthernet1/0, not configured for NHRPsrc 192.168.123.3 dst 192.168.123.1
*Dec 20 16:38:12.083: NHRP: Pak out GigabitEthernet1/0 would leave logical NBMA network
I have tried with giga int as source also…but the same. I was wodering if it is the platform i am using in GNS3
Hmm I haven’t seen that message before but I think it’s probably a misconfiguration.
Hi !
it works …but i cant use "sh dmvnp " ?
change to Cisco IOS Software, 3600 Software (C3640-IK9O3S-M)
try “show dmvpn” instead? 
Hi Rene,
Great article!!!
Possible minor typo when giving further details about the spoke configuration:
“ip nhrp map: we use this on the spoke to create a static mapping for the hub’s tunnel address (172.16.123.2) and the hub’s NBMA address (192.168.123.1). This will be stored in the NHRP cache of the spoke router.”
I think the tunnel address should read “172.16.123.1”
Thanks,
C
Thanks CĂ©sar! I just fixed this typo.
Hello Rene,
I was wondering if you would help with the following?
This was configured in GNS3, and I used the same IP addressing you have here. Well for the most part.
I can’t figure out why I keep getting the “retry limit exceeded” message below.
Hub# debug nhrp
*Nov 29 21:19:02.135: NHRP: Receive Registration Request via Tunnel0 vrf 0, packet size: 105
*Nov 29 21:19:02.135: NHRP: netid_in = 1, to_us = 1
*Nov 29 21:19:02.139: NHRP: Adding Tunnel Endpoints (VPN: 172.16.123.2, NBMA: 192.168.123.5)
*Nov 29 21:19:02.139: NHRP: Cache already has a subblock node attached for
Tunnel Endpoints (VPN: 172.16.123.2, NBMA: 192.168.123.5)
*Nov 29 21:19:02.143: NHRP: Tu0: Found and skipping dynamic multicast mapping NBMA: 192.168.123.5
*Nov 29 21:19:02.143: NHRP: Added dynamic multicast mapping for
NBMA: 192.168.123.5
*Nov 29 21:19:02.143: NHRP: New mandatory length: 32
Hub#
*Nov 29 21:19:02.147: NHRP: Attempting to send packet via DEST 172.16.123.2
*Nov 29 21:19:02.147: NHRP: NHRP successfully resolved 172.16.123.2 to NBMA 192.168.123.5
*Nov 29 21:19:02.151: NHRP: Encapsulation succeeded. Tunnel IP addr 192.168.123.5
*Nov 29 21:19:02.151: NHRP: Send Registration Reply via Tunnel0 vrf 0, packet size: 125
*Nov 29 21:19:02.155: NHRP: 149 bytes out Tunnel0
Hub#
*Nov 29 21:19:03.499: NHRP: NHRP successfully resolved 172.16.123.2 to NBMA 192.168.123.5
Hub#
*Nov 29 21:19:08.503: NHRP: NHRP successfully resolved 172.16.123.2 to NBMA 192.168.123.5
Hub#
*Nov 29 21:19:13.507: NHRP: NHRP successfully resolved 172.16.123.2 to NBMA 192.168.123.5
Hub#
*Nov 29 21:19:18.511: NHRP: NHRP successfully resolved 172.16.123.2 to NBMA 192.168.123.5
Hub#
*Nov 29 21:19:23.519: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.16.123.2 (Tunnel0) is down: retry limit exceeded
Hub#
*Nov 29 21:19:27.787: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.16.123.2 (Tunnel0) is up: new adjacency
Hub#
```
*Nov 29 21:19:27.799: NHRP: NHRP successfully resolved 172.16.123.2 to NBMA 192.168.123.5
Hub#
*Nov 29 21:19:29.803: NHRP: NHRP successfully resolved 172.16.123.2 to NBMA 192.168.123.5
Hub#
*Nov 29 21:19:32.807: NHRP: NHRP successfully resolved 172.16.123.2 to NBMA 192.168.123.5
Hub#
*Nov 29 21:19:37.311: NHRP: NHRP successfully resolved 172.16.123.2 to NBMA 192.168.123.5`
Thanks,
J
Joel,
Does it keep bouncing back and forth between “retry exceeded” then having a new adjacency? If so, this is usually indicative of EIGRP trying to use the tunnel to discover the tunnel endpoints themselves (so it becomes a recursive logic problem). We won’t know for sure until we see your config, though.
Hello Rene,
I’m trying to complete the DMVPN Phase 1 Basic Config in my home lab using your configuration steps and the diagram from the lesson. I don’t understand how you have two connections coming into the hub router using the same interface. I appear to have a cabling issue. As of now I can only get one of the spokes registered with the hub but not both sides. Please advise, thanks.
Willie Brown
Willie,
Assuming your hub is using interface Tunnel0, give us the output of the following:
“show run int tun0”
Do you have the tunnel interfaces configured as “mode gre multipoint”?
When you say “one of the spokes registers with the hub, but not both sides” do you mean another spoke can’t register?
I would like to practice DMVPN configuration on GNS3, I am looking for internet cloud appliance
Can anyone help me where i can find Internet cloud appliance ? so i can import in GNS3 .
Thanks in advance
Hello Venkateswara
Here is a link from the GNS3 site which allows you to download the Internet appliance and also tells you how to use it.
https://docs.gns3.com/appliances/internet.html
I hope this has been helpful!
Laz
This is outdated and not working. Thanks
Can you please provide me authentic link. Thanks a lot
Hi Venkateswara,
The link is still working here? If it’s not working, it’s best to check with gns3.com.
Rene
Andrew, I think I have the same question as Willie. The reference example shows the HUB connecting to both Spokes on the same interface. Physically, how is HUB connect to Spoke 1 and Spoke 2? Is there a switch or internet appliance connecting in the middle? I think, this is where I am confused
Shouldn’t the hub have 2 Gi interfaces configured, one to each Spoke?
Hello Alex
In a real world scenario, this topology would be configured over the Internet, or some sort of WAN. What actually exists between the routers can be any network infrastructure as long as the IP addresses of the physical interfaces are capable of reaching each other over that network.
In a lab scenario, the cloud can be replaced by a L2 switch. Notice the IP addresses of the physical interfaces are in the subnet 192.168.123.0/24, and thus they should be able to communicate with each other if they are on the same network segment. If you want to recreate the lab, just connect all routers to a single L2 switch and verify that their physical addresses do indeed have connectivity.
I hope this has been helpful!
Laz
2 Likes
I had problems following the configuration provided. I believe the spokes should not have tunnels destinations addresses and instead configured with “tunnel mode gre multipoint”
Hello Robert
When configuring DMVPN Phase 1, the HUB router will be configured with tunnel mode gre multipoint as the tunnel has multiple endpoints on the other end, while the tunnel on the spokes must be configured with a specific tunnel destination. These configuration parameters are set like so by definition of a DMVPN Phase 1 configuration.
Can you clarify where in your config you are having trouble and what behaviour you are experiencing? Let us know so we can help pinpoint the problem and help you in the troubleshooting process…
I hope this has been helpful!
Laz
Hi Lagapides, thank you for your response.
When I configured "tunnel destination " on the spoke routers I found that traffic from one spoke to the another was still going through the hub.
After removing "tunnel destination " and adding “tunnel mode gre multipoint” to my spoke routers, the traffic from one spoke to another was sent directly as expected.
Here is my configuration:
Hub Router:
interface fastethernet0/0
description WAN-Network
IP address 1.1.1.1 255.255.255.0
interface tunnel 0
description Hub - DMVPN Tunnel
IP address 192.168.1.1 255.255.255.0
tunnel source fastethernet0/0
tunnel mode gre multipoint
ip nhrp authentication CISCO
ip nhrp map multicast dynamic
ip nhrp network-id 1
Spoke Router 1:
interface fastethernet0/0
description WAN-Network
IP address 1.1.1.2 255.255.255.0
interface tunnel 0
description Spoke1 - DMVPN Tunnel
IP address 192.168.1.2 255.255.255.0
tunnel source fastethernet0/0
tunnel destination 1.1.1.1 <----- Removed this
tunnel mode gre multipoint <----- Added this
ip nhrp authentication CISCO
ip nhrp map multicast 192.168.1.1
ip nhrp map 192.168.1.1 1.1.1.1
ip nhrp nhs 192.168.1.1
ip nhrp network-id 1
Spoke Router 1:
interface fastethernet0/0
description WAN-Network
IP address 1.1.1.3 255.255.255.0
interface tunnel 0
description Spoke2 - DMVPN Tunnel
IP address 192.168.1.3 255.255.255.0
tunnel source fastethernet0/0
tunnel destination 1.1.1.1 <----- Removed this
tunnel mode gre multipoint <----- Added this
ip nhrp authentication CISCO
ip nhrp map multicast 192.168.1.1
ip nhrp map 192.168.1.1 1.1.1.1
ip nhrp nhs 192.168.1.1
ip nhrp network-id 1