12-12-2017 08:17 PM - edited 03-05-2019 09:38 AM
Hello all,
I have something that seems pretty straightforward that I'm trying to emulate. I'm trying to assign a DHCP address to a spoke tunnel interface on a DMVPN setup. I have the DHCP server on a separate router (172.16.0.3) and the hub acting as the DHCP relay.
I see:
1. The request getting to the DHCP server, and the server creating the binding.
2. The debug DHCP on the DHCP relay shows that it's forwarding a reply.
3. On the spoke, I don't see any DHCP packets being received (verified with a logging ACL)
#********************************************************************
Hub Router (DHCP Relay)
!
ip dhcp support tunnel unicast
!
interface Tunnel0
ip address 172.16.2.1 255.255.255.0
ip helper-address 172.16.0.3
ip nhrp network-id 1
ip nhrp holdtime 600
tunnel source Ethernet1/1
tunnel mode gre multipoint
!
interface Ethernet1/1
ip address 172.16.0.1 255.255.255.0
!
interface Ethernet1/1
ip address 172.16.1.1 255.255.255.0
ip helper-address 172.16.0.3
#********************************************************************
Spoke Router
!
interface Tunnel0
ip dhcp client broadcast-flag clear
ip address dhcp
ip nhrp network-id 1
ip nhrp holdtime 600
ip nhrp nhs dynamic nbma 192.168.27.1 multicast
tunnel source Ethernet1/0
tunnel mode gre multipoint
!
interface Ethernet1/0
ip address 172.16.1.2
#********************************************************************
DHCP Server (Router for Proof of Concept)
interface Ethernet1/0
ip address 172.16.0.3 255.255.255.0
!
ip dhcp pool Tunnel-Pool
network 172.16.2.0 /24
default-router 172.16.2.1
!
ip dhcp excluded-address 172.16.2.1
#********************************************************************
Here's some of the DHCP Relay's logs:
*Dec 12 20:01:14.787: DHCPD: client's VPN is .
*Dec 12 20:01:14.787: DHCPD: No option 125
*Dec 12 20:01:14.787: DHCPD: forwarding BOOTREPLY to client ca04.05a4.0000.
*Dec 12 20:01:14.791: DHCPD: Forwarding reply on numbered intf
*Dec 12 20:01:14.791: DHCPD: no option 125
*Dec 12 20:01:14.795: DHCPD: ARP entry exists (172.16.2.4, ca04.05a4.0000).
*Dec 12 20:01:14.795: DHCPD: unicasting BOOTREPLY to client ca04.05a4.0000 (172.16.2.4).
12-12-2017 09:13 PM
Sorry if I misunderstood the setup but are the spoke supposed to get IP through Hub?
How it would be possible if it needs an IP in order to establish the tunnel?
-If I helped you somehow, please, rate it as useful.-
12-12-2017 09:29 PM - edited 12-12-2017 09:35 PM
Yes, it gets the IP through the hub. I'm not showing the IPSec, but it's in there as well. I know it's possible, just trying to find out if I hit a bug or something.
@Flavio Miranda wrote:
Sorry if I misunderstood the setup but are the spoke supposed to get IP through Hub?
How it would be possible if it needs an IP in order to establish the tunnel?
-If I helped you somehow, please, rate it as useful.-
12-13-2017 12:22 AM
Yes it is. I read a nice article right after comment and the tunnel can be stablished and then the spoke can get an IP address.
Maybe you already saw that one but just in case:
http://www.fragmentationneeded.net/2015/09/assigning-dmvpn-tunnel-interface.html?m=1
-If I helped you somehow, please, rate it as useful.-
12-13-2017 04:27 AM
Thanks, but I don't see anything in the article that I'm not already doing. Am I overlooking something?
12-13-2017 04:43 AM
What about the static route he created? I didn't see on your config.
-If I helped you somehow, please, rate it as useful.-
12-13-2017 09:07 AM
I tried to add that, but it had no effect. That said, my purpose is to use dynamic addresses. It seems like creating a static route to the subnet that I'll be assigned, goes against the purpose of dynamic addresses.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide