HPE/Aruba recently released advisory ARUBA-SA-20191219-PLVL08 which states the following;

There is a software defect that may impact Aruba Instant Access Points (IAP) and its accessibility through Aruba Central, Activate, and AirWave. This bug is tied to an SSL certificate in the Trust Anchor (TA) file of Instant OS, and may result in the loss of connectivity to management platforms unless the recommended action is taken prior to February 07, 2020. This is not a security vulnerability, but a software defect that may cause loss of connectivity to management plane.

Like many organizations we leverage Aruba Airware Management Platform (AMP) and we’re looking at possibly leveraging Aruba Central in the near future so we took the opportunity to update our IAP-135s, IAP-215s and IAP-315s.

Thankfully AMP makes the process pretty simple and straightforward although out of some 550+ upgrades we had one where the Aruba Virtual Controller didn’t recover after upgrading. Unfortunately I’ve seen this behavior before – when you run 550+ individual LANs you are bound to see just about everything and anything. In this specific case I could see the Instant Access Points (IAPs) were pulling power but weren’t pulling a DHCP IPv4 address from the local router. So I shutdown everything on that VLAN, disabling all the switch ports, with the exception of the IAPs and then rebooted each of them by cycling the PoE state on each switch port. Within a few minutes all the IAPs had recovered and were up and running. What was the issue? There was a rogue DHCP server on that network which was handing out bad IPv4 addresses. The IAPs were grabbing these ‘bad’ DHCP IPv4 addresses and were the ultimately unable to communicate with the rest of the network. Unfortunately the kit that we currently have in the vast number of locations doesn’t provide DHCP snooping or the ability to filter DHCP responses from trusted/untrusted ports.

Cheers!