Wireless Access

Hi everyone,

One of our customers is having an issue with APs on their network - The devices are taking a number of hours to become available for provisioning on the controller. The device gets an IP address and discovers the master controllers IP address. I know this because a packet capture shows that the device ARP for the controller IP address and receives a reply. We've tried connecting APs to a controller before they are shipped to the customer so the have the firmware installed. In their office the devices are connected on the same subnet ready for provisioning but sometimes have to be left overnight to settle on the controller. I have had TAC involved previously but have yet to get to the bottom of the issue and hoped someone may have experienced a similar issue. The only unusual setting that may be affecting this is that they have control-plane security enabled with "auto-cert-prov". I don't have access to their controller at the moment but will have to attend site soon so any specific debugs that may help would be an advantage.

What controller module?

What AOS are u using?

please look on this,from the release notes: (of 6.1.3.9)

The controller they are using is a 650 running 6.1.3.8 code. I have read through the documentation for Control-plane security and it seems to be being implemented on the controller correctly - the APs have been whitelisted and they do eventually come up but not until after an extended period of time.

ok.

Did u checked if without CP enabled - it's taking less time (sec-min like it should) ?

TAC advised me on a remote session not to disable CPSec, however we did try this and some APs (they have a mixture of CAPs and RAPs) lost connectivity to the controller, so it was re-enabled. I am not sure why CPSec was enabled in the original design as all of our other customers run with this disabled. It was possible at the time of testing that some APs were not whitelisted, though since then I have advised that all APs be whitelisted.

after u disable or enable cpsec - usully ap unit are rebooting..to change their working mode.

but you should test it - to understand if the cpsec casuing the longtime provising.

Is there an 'aruba-master' DNS entry, DHCP options 43 and 60 set or are the APs using ADP to find the controller.

Check for the presence of all 3 as maybe an additional IP address is being put in to the list of controllers the APs could talk to.

I know for sure that ADP is disabled as their router are not forwarding on that type of traffic. DHCP option 43 is being used for something else. Their primary method was a DNS entry and I think we added the option 60 on the advice of TAC - I assume this is still running, so I think they should be finding the same master address using those two methods.

FWIW: When I have a problem with APs' not registering with the controller, I'll sh / no sh the LAN interface in order to reboot them. On most implmentations they will begin to show up after at most two rounds of reboots after the initial power up.  ...But I am using ADP for device discovery and registration.

It takes about 5 minutes for the AP to show up after a reload.

When you say DHCP option 43 is used for something else does that mean the value of this option is different to the IP address resolved from the DNS entry for aruba-master?

ADP will be used if the APs and controller are on the same subnet and is has not been disabled on the controller.

Are you able to post the console output from the AP booting up?

Attached is the log from the console output. Just to confirm - ADP is disabled on the controller. I will be visiting the customer at the end of the week to do some on-site investigation. Does anyone have any useful debug commands to log PAPI traffic etc. Also what exactly does the "packet-capture tcp/udp" commands pick up management traffic passing through the controller/client data traffic/only traffic destined for or sourced from the controller.

Attachment(s)

aplog.txt   20 KB 1 version

Matt,

I know you might not be able to answer this, but what is providing DHCP to the access point?

The DHCP is provided by their Microsoft server and the option 43 is being used for another purpose, not sure what. The AP seems to be getting an address and discovering the master but after that things seem to stall.

If you statically set the master controller IP address via the console on the AP (as below) does this make any difference?

setenv master=X.X.X.X

setenv serverip=X.X.X.X

I will be attending site soon to see if I can sort this out so I will try the static IP approach. I have read that IPsec is used when CPSec is enabled could this be affecting the join process?

A site visit yesterday and a lengthy TAC investigation has still not resolved the issue, master discovery happens quickly when all environment variables are set. CPSec is now disabled and the AP attempting to join has lots of message in the log of this type -

Aug  9 07:22:16  dhcpdwrap[1609]: <202086> <INFO> |dhcpdwrap|  netlink_arp_changed(): ker_mac 00:24:6c:ca:b2:ee pkt_mac 00:24:6c:ca:b2:ee cip 172.31.201.140

Due for another TAC session today.

Finally this issue has now been solved. There was a device on the network that was responding to PXE boot requests which was causing the issue.