Re: DHCP for DMVPN Spoke Tunnel Interface

Cory Anderson · ‎12-12-2017

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).

Flavio Miranda · ‎12-12-2017

Hi @Cory Anderson

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.-

Cory Anderson · ‎12-12-2017

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.

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_dhcp/configuration/15-mt/dhcp-15-mt-book/dhcp-pool-dmvpn.pdf

@Flavio Miranda wrote:

Hi @Cory Anderson

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.-

Flavio Miranda · ‎12-13-2017

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.-

Cory Anderson · ‎12-13-2017

Thanks, but I don't see anything in the article that I'm not already doing. Am I overlooking something?

Flavio Miranda · ‎12-13-2017

What about the static route he created? I didn't see on your config.

-If I helped you somehow, please, rate it as useful.-

Cory Anderson · ‎12-13-2017

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.