Troubleshooting AP Connectivity and Configuration Sync with HPE Aruba Central

At some point, an AP will not connect to Central, and you must figure out what is happening. The first thing to do is think through your basic troubleshooting process. Identify the problem. When did the issue begin? Is this issue happening on a single AP or multiple APs? Is the issue happening within a single site or multiple sites? This will help you develop a hypothesis on what could be happening and allow you to create a plan of action to work out the issue. If the issue is on a single AP, dig into that device. If the issue is seen on multiple APs, something in the network may be blocking access upstream from the APs, or Central itself may be experiencing an issue. In this post, I will walk through typical issues I’ve seen and how to work through and resolve them.

HPE Aruba Central requires connectivity to several ports and destinations depending on the network device type. Instead of listing them all here, I will provide a link for reference:

HPE Aruba Central Connectivity Requirements

Work with your security team to ensure your devices can connect to all the required destinations.

The first thing an AP needs to connect is a valid IP address. I know this is basic, but always start with the basics and work your way up. If you have direct console access to the AP, use the command “show IP interface brief” to display IP-related info on all interfaces of the AP.

Here is a working AP:

You will want to look for the br0 interface. For reference, here is the output from an AP where I removed the AP mgmt VLAN from the allowed VLANs list of the switch uplink to simulate a DHCP failure:

As you can see, br0 does not have an IP address. To further diagnose the issue, the “show log system” command provides debug output relating to the core AP system, which tells us that the AP failed to receive an IP.

Once the AP has an IP address, the next phase is to validate reachability to the internet. You could start by pinging the Default Gateway of the AP management VLAN. Next, try pinging a public IP address like Google DNS. Here is an example:

One issue you may encounter with this approach is that some networks restrict ICMP. I’m not a fan of that approach, but it happens.

Another command I like to use at this point is “show uplink status.” This command provides the AP’s internal and public IP address for all its interfaces:

It provides excellent info, including the DHCP server, DNS server, and cloud reachability status.

Another useful command is “ show ap debug lldp neighbor interface bond0”. This command provides the VLAN assigned and PoE information from the switch interface where the AP is uplinked.

Next up on the list of required services is DNS. The AP needs to be able to resolve device.arubanetworks.com.

Note: The destination device.arubanetworks.com will not respond to the ping, but you should resolve the name and receive the IP address of the activate server. Here is a working scenario where the AP is able to resolve the hostname:

This is what a DNS failure will look like:

Since connectivity to HPE Aruba Central uses secure protocols, network devices must have a valid clock time to ensure the validity of their certificates. By default, APs will attempt to connect to pool.ntp.org for NTP. If you restrict access to public NTP servers, be sure to assign a local NTP server. Use the “show clock” and “show ntp status” commands to validate that the AP is in sync with the current time:

The final requirement for AP connectivity to Central is that each device must have a valid subscription assigned. The command “show ap debug cloud-connectivity” provides almost everything you need to troubleshoot Central connectivity issues, including a subscription assignment. In the output below, no provisioning rule assigned by Activate indicates that the device does not have a valid subscription.

Here is a working example for reference:

This command output provides a summary of all of the requirements for Central connectivity, including:

• IP address

• DHCP server

• DNS server

• NTP status

• Activate connectivity

• Assigned Central Instance

• Configuration Sync Status

The above output was from an AP running an older version of AOS 10. AOS 10.7 will enhance the command's output to show the latency from the AP to the assigned Central Instance. The maximum recommended latency for device connectivity to Central is 500 ms.

Here is a sample output from an AP running 10.7 showing the latency:

Once the AP has hit Central, you will want to verify the configuration synchronizes. When you update the configuration of a group, you will see the config push process through the Audit Trail. Here is a screenshot of a recent change in my environment:

In the group context, you should see an “Access point configuration sync successful” message for every device in that group. You can validate the commands pushed by clicking the three vertical dots beside the configuration change request description. The output should show all of the modifications to the configuration in that change.

To validate that the AP configuration matches the request, run “show ap debug cloud-config-received.” The output will display a list of configurations received by the AP from Central. The AP saves the last six batches of configurations received from Central. Warning: This output is cleared when an AP reboots. Here is a sample of the change above:

The final command I want to share is “show ap debug cloud-server.” This output shows the current connection status for that AP with Central, including details like connection uptime, config received status, and the reason for the last Central disconnect:

Hopefully, this post has helped you understand the process an AP uses to connect to Central and how to troubleshoot any issues you may encounter. If I missed other failure scenarios, let me know, and I will update the post.