Controllerless Networks

The issue:  Setting up a POC.  DHCP addresses are not being handed out to wired/wireless clients.  Through debug pkt dump, I can see the client requesting an IP address but nothing returning.

Configuration:

7010 controller at HQ with IAPs at remote locations.  Client wants centralized DHCP using a DHCP at their HQ.

WAN on the IAP:  The IAP has a DHCP address assigned to eth0 from the cable modem.

I've created a wired & a wireless profile set to vlan 80.  On the wired profile, the port is set to trunk with native vlan 80.

I've created a Centralized L3 DHCP profile with relay IP to the corporate DHCP server.  The vlan IP is set to 10.80.10.254.  NOTE:  the 7010 controller is configured for OSPF and the vlan 80 subnet 10.80.10.0/24 is advertised.  I can ssh to 10.80.10.254 on the controller.  The DHCP scope is set for split tunneling will 10.0.0.0/8 & 172.16.0.0/12 passing through the tunnel.

I've got the IPSec VPN operating.  Show vpn status shows the tunnel operational with the AP being assigned an IP from the ip-pool.

What am I missing?  I would think the DHCP relay would use 10.80.10.254 as the source, pass through the tunnel and it would come back.

I helped the client setup DHCP and the scope is active.  I'm having him check the Event Viewer now to see if its receiving DHCP requests from either 10.80.10.254 or from the IP assigned by the 7010 controller for the VPN.

Thanks in advance.

I've got a PC on vlan 80 and have statically assigned it an IP address.

I've verified that I can reach that machine from within the HQ network using it's IP address.  So, routing is working properly.

It's just DHCP relay that appears to not be functioning.  I'm missing something but I don't know what.

Thanks again.

Hi

Has You tried this?
https://community.arubanetworks.com/t5/Controller-less-WLANs/How-to-configure-IAP-as-a-DHCP-relay-agent/ta-p/180004

Br

Juha-Pekka

Sorry, missed that You have L3
Not this solution then

Has You find solution?

I find this but seem to be what You already have in configs

https://community.arubanetworks.com/t5/Controller-less-WLANs/How-does-Centralized-L3-DHCP-relay-agent-functionality-works-on/ta-p/176338

Br

Juha-Pekka

So, it's working now.  I'm thinking the problem was either with the DHCP server or the network.  Here's the quick and dirty so far.

I tried changing from Centralized L3 to Centralized L2 having the DHCP relay at the IAP and at the 7010 controller.  No joy.  So, I changed everything back to the way it was:  Centralized Layer 3 still not working.

I ended up opening a ticket with Aruba TAC and walked away for a while.  When TAC contacted me and we began troubleshooting, we noticed that the workingstation got an IP address. 

We forced the client to renew/release a few times and it was working.

Same configuration I had on the IAP & controller as before.

So, something was going on on the network/DHCP server side.  It all started working after the close of business.

I'll check it again Monday morning to make sure it's still operating and if not, I'll be expanding root cause analysis.

I'll update this thread when i find the answer.

Thanks for the recommendations.

Here's an update.

After deploying a few IAPs remote offices the issue happened again.  At this point I was thinking "bug".  So I reviewed software version release notes and found a bug that had the same symptoms that I was seeing.  There are 4 bug IDs for the issue.

The issue was fixed in 6.5.0.3 and also in 6.5.1.x.  We upgraded the 7010 that is acting as the VPN concentrator and we haven't seen the issue since.

Thanks for the help.

Bug IDs:  139340, 144313, 144591, 150168.

Description:  Symptom: Devices or VMs that did DHCP with an indirect MAC— that is, either the devices were behind another device that did DHCP on their behalf or the host did the DHCP on behalf of the VM—did not get IP addresses. This issue is resolved by making internal code changes as well as by creating an indirect MAC entry for the broadcast-filter-arp disabled case, when the BOOTP client- MAC and the SRC-MAC were different.