Wireless Access

This is the first time we are using AP375s and we have a crate of them. I opened one and tested it and looking at the console, it was getting 169.254.x.x IP. I purged it and even factory reset it then restarted it again and still getting the same problem.

I took another box and tested it and still getting the same exact output.

Just to make sure I still have IPs in this VLAN and this port actually works, I took an AP325 and AP215 and they got an IP with no problem.

This is my testbed and all other APs gets an IP for themselves. The AP375 isn't getting one for some reason. Why is it behaving like this when all other AP works fine out of the box. Is there something I am missing here? This switch is btw a POE+.

.
.
..
Jan  1 00:02:13 udhcpc[3270]: send_discover: pkt num 2, secs 27648
Jan  1 00:02:13 udhcpc[3270]: Sending discover...
DHCP timed out.
Installing default ip.
Default IP comes up.
[  165.714651] ip_time_handler: Got ip and packets on bond0 Started master election 484-0, rand 18
DHCP timed out.
DHCP got ip address.
[  166.518431] (08:02:33) !!! Init ---> Slave
Jan  1 00:02:35 udhcpc[3270]: send_discover: pkt num 0, secs 33280
Jan  1 00:02:35 udhcpc[3270]: Sending discover...
Jan  1 00:02:37 udhcpc[3270]: send_discover: pkt num 1, secs 33792
Jan  1 00:02:37 udhcpc[3270]: Sending discover...
Jan  1 00:02:39 udhcpc[3270]: send_discover: pkt num 2, secs 34304
Jan  1 00:02:39 udhcpc[3270]: Sending discover...
169.254.10.225 255.255.0.0
Compressing all files in the /etc/httpd directory...
Done.
..
.
.

Please try switching the cable to enet1 and see if it makes a difference.

The other ENET is fiber but I still tried it by powering the POE port with just a POE+ injector. I am sure the AP detected  something is plugged in the fiber port  because if not, the AP becomes a Mesh Point if both ENET is unplugged.

Anyway, ENET0 or ENET1, they are showing the same thing. Still unable to grab an IP for itself.

Looking at our DHCP configs, we did have some rules that works just fine on older non-AP375 APs.. What changed on AP375? Is the vendor "Aruba" have changed to "HP" now?

class "aruba-ap" {
       match if substring (option vendor-class-identifier, 0, 9) = "ArubaAP";
}


subnet 10.111.14.0 netmask 255.255.254.0 { # b01-aruba-mgmt;xxxxx.net;internal
       option routers 10.111.14.1;
       option domain-name "xxxxx.net";

       pool {
               allow members of "aruba-ap";

               option vendor-class-identifier "ArubaAP";
               option vendor-encapsulated-options "134.x.x.x";

               failover peer "cpp";
               deny dynamic bootp clients;

               range 10.111.14.11 10.111.14.255;
               range 10.111.15.1 10.111.15.254;
       }
}

What other model APs do you have that are working? I am assuming they are not Unified APs? The 37x is a unified AP that comes with a provisioning image, but unfortunately depending on the DHCP server used and settings, it can get missed. You need to create another Option43/60 (both pointing to the same controller IP) for 'ArubaInstantAP', that should allow your DHCP server to respond to the 375 coming up and point them at the controller for it's initial image download. Once it loads the controller firmware, it will use ArubaAP from there on out.

So we sniffed the AP375 and compared it to the older ones. We found out that the AP375 Vendor Class Identifier is "ArubaInstantAP" rather than "ArubaAP" on the older AP325 and below APs. We use the Vendor Class Identifier in our DHCP config to only allow "ArubaAP" string.

The funny thing is, the AP375 box and AP stickers doesn't give a hint it is an IAP. 

This issue is solved, AP375s now get their IP however, they still can't find the cluster VIP even if I edit "setenv master" and "setenv serverip" on the AP console..... which is another issue.  :( 

I wonder if this IAP needs to be converted first to CAP so it can find the cluster VIP.

It's a long and painful explanation as to WHY that was done, but the short of it is, Universal APs (the new APs we ship sans code outside the provisioning image) need to be more flexible for other discovery mechanisms (like Cloud and AirWave) and most of the infrastructure was already built around 'ArubaInstantAP'. So a UAP model AP will ask for that first. MOST (not yours but MOST) people's DHCP will just return the same Opt 60 no matter what (basic DHCP, windows DHCP, etc) and the UAP firmware is set to recognize ArubaAP or ArubaInstantAP and reach out accordingly. Your DHCP server is configured ONLY to return when the ask matches (which some customers do but not many). The simple fix (if you haven't done it already) is to just have a line for both (Opt60 of ArubaAP and ArubaInstantAP) and return the Opt 43. Once the UAP pulls firmware and reboots, it will ask for ArubaAP. If it converted to Instant (Central or AirWave) then it will ask for ArubaInstantAP. 

For the few customers that don't like that, they can usually either temporarily enable both until deployed and then remove, or they can stand up a provisioning VLAN for staging before mounting where both are returned. 

If you were using this for Instant or Central, then no changes would obviously be needed.