Wireless Access

We removed a couple of AP315's and deleted them from the UI a few months ago to keep as spares.  When we come to reuse them now we did the physical reset on them and then plugged them in.  Instead of appearing in the 'Alerts' section and waiting to be allowed on the system they are immediately added to the access points column listed by their MAC addresses and then they drop off, reboot and do it again repeatedly.  Looking at the unit it says it's due to heartbeat timeout.  We did an update to 8.12.0.1_89864 as routine maintenance and tried again with the same results.

Why are reset AP's not behaving like factory default and asking to be allowed in the Alerts section?  We have spare licenses.  I have deleted the AP's from the UI.  I've even gone into the conductor and deleted them from the database in the CLI.  I can't delete them manually from the allowlist-db in the CLI because it does not appear to be up long enough.  I've tried manually renaming and regrouping them in the CLI as well to see if that helps and they don't take it either.

The Heartbeat issue seems to be something that has plagued everyone and usually we're told to check the wiring or check the licenses.  It's neither in this case as we have tried them in 4 different switches with different cables as well.  We have 173 AP's and licenses for 181 devices and they were on a couple of months ago with no issues.

Why are they not behaving like factory default APs after numerous resets?  Why the heartbeat issue?  We've never run into this before and been running them for years.

Do you have other AP-315s in the same network?

Are all APs in the same (native/untagged) VLAN and can the communicate freely without any blocking in that vlan? Example private ports, ACLs can block AP intercommunication.

Have the AP-315s that you try to re-add been in the network while you did multiple firmware upgrades? The backup-flash firmware is replaced with the last running firmware every time you upgrade. If you had the APs with a very old firmware, then only once upgraded, they could be after factory reset on a very old version.

Is auto-join enabled on the cluster/VC?

We removed a couple of AP315's and deleted them from the UI a few months ago to keep as spares.  When we come to reuse them now we did the physical reset on them and then plugged them in.  Instead of appearing in the 'Alerts' section and waiting to be allowed on the system they are immediately added to the access points column listed by their MAC addresses and then they drop off, reboot and do it again repeatedly.  Looking at the unit it says it's due to heartbeat timeout.  We did an update to 8.12.0.1_89864 as routine maintenance and tried again with the same results.

Why are reset AP's not behaving like factory default and asking to be allowed in the Alerts section?  We have spare licenses.  I have deleted the AP's from the UI.  I've even gone into the conductor and deleted them from the database in the CLI.  I can't delete them manually from the allowlist-db in the CLI because it does not appear to be up long enough.  I've tried manually renaming and regrouping them in the CLI as well to see if that helps and they don't take it either.

The Heartbeat issue seems to be something that has plagued everyone and usually we're told to check the wiring or check the licenses.  It's neither in this case as we have tried them in 4 different switches with different cables as well.  We have 173 AP's and licenses for 181 devices and they were on a couple of months ago with no issues.

Why are they not behaving like factory default APs after numerous resets?  Why the heartbeat issue?  We've never run into this before and been running them for years.

Hi Herman.  We have 173 AP's currently online, about 120 of those will be 315's and the rest are 505's or 515's.  The network is split into areas and we have 9 different AP controller VLAN's, one for each geographic area.  The faulty units are picking up valid IP addresses in the correct VLAN and getting their port configuration from the device profile settings on the switch.  There are no internal ACL's or firewalls to stop them reaching the controllers.

We did upgrade to 8.12.0.1 while these units were in storage.  I believe when we first plugged them in they did download and upgrade to the new firmware version.  I was watching for them joining and when they first rebooted the reason was listed as upgrade.  Every reboot after that has been listed as HbtTimout.

I don't even know where the auto-join option is on the cluster and I did not know it existed.  Normal behaviour for a new or reset AP in the past has always been for it to first appear in the Alerts tab awaiting authorisation.  I would then go into the CONFIG/ACCESS POINTS/ALLOW LIST and give it permission to join the controller.  Once it re-joined I would configure and provision it in the CAMPUS AP's section.  After deleting these 2 from the UI and the CLI database listing and physically resetting the AP's these ones just appear immediately in the Access Points list under their MAC addresses, no allow list permission needed.

Do you have other AP-315s in the same network?

Are all APs in the same (native/untagged) VLAN and can the communicate freely without any blocking in that vlan? Example private ports, ACLs can block AP intercommunication.

Have the AP-315s that you try to re-add been in the network while you did multiple firmware upgrades? The backup-flash firmware is replaced with the last running firmware every time you upgrade. If you had the APs with a very old firmware, then only once upgraded, they could be after factory reset on a very old version.

Is auto-join enabled on the cluster/VC?

We removed a couple of AP315's and deleted them from the UI a few months ago to keep as spares.  When we come to reuse them now we did the physical reset on them and then plugged them in.  Instead of appearing in the 'Alerts' section and waiting to be allowed on the system they are immediately added to the access points column listed by their MAC addresses and then they drop off, reboot and do it again repeatedly.  Looking at the unit it says it's due to heartbeat timeout.  We did an update to 8.12.0.1_89864 as routine maintenance and tried again with the same results.

Why are reset AP's not behaving like factory default and asking to be allowed in the Alerts section?  We have spare licenses.  I have deleted the AP's from the UI.  I've even gone into the conductor and deleted them from the database in the CLI.  I can't delete them manually from the allowlist-db in the CLI because it does not appear to be up long enough.  I've tried manually renaming and regrouping them in the CLI as well to see if that helps and they don't take it either.

The Heartbeat issue seems to be something that has plagued everyone and usually we're told to check the wiring or check the licenses.  It's neither in this case as we have tried them in 4 different switches with different cables as well.  We have 173 AP's and licenses for 181 devices and they were on a couple of months ago with no issues.

Why are they not behaving like factory default APs after numerous resets?  Why the heartbeat issue?  We've never run into this before and been running them for years.

Are you running Instant Mode? Or with a separate controller?

I assumed Instant, from your initial question, but it's not fully clear...

Regardless, if you see a hearbeat timeout, it's close to certain that there is something preventing free communication between the APs (Instant) or between the AP and the controller (controller based). It may be good to open a TAC case or work your Aruba partner for further analysis of the problem.

Hi Herman.  We have 173 AP's currently online, about 120 of those will be 315's and the rest are 505's or 515's.  The network is split into areas and we have 9 different AP controller VLAN's, one for each geographic area.  The faulty units are picking up valid IP addresses in the correct VLAN and getting their port configuration from the device profile settings on the switch.  There are no internal ACL's or firewalls to stop them reaching the controllers.

We did upgrade to 8.12.0.1 while these units were in storage.  I believe when we first plugged them in they did download and upgrade to the new firmware version.  I was watching for them joining and when they first rebooted the reason was listed as upgrade.  Every reboot after that has been listed as HbtTimout.

I don't even know where the auto-join option is on the cluster and I did not know it existed.  Normal behaviour for a new or reset AP in the past has always been for it to first appear in the Alerts tab awaiting authorisation.  I would then go into the CONFIG/ACCESS POINTS/ALLOW LIST and give it permission to join the controller.  Once it re-joined I would configure and provision it in the CAMPUS AP's section.  After deleting these 2 from the UI and the CLI database listing and physically resetting the AP's these ones just appear immediately in the Access Points list under their MAC addresses, no allow list permission needed.

Do you have other AP-315s in the same network?

Are all APs in the same (native/untagged) VLAN and can the communicate freely without any blocking in that vlan? Example private ports, ACLs can block AP intercommunication.

Have the AP-315s that you try to re-add been in the network while you did multiple firmware upgrades? The backup-flash firmware is replaced with the last running firmware every time you upgrade. If you had the APs with a very old firmware, then only once upgraded, they could be after factory reset on a very old version.

Is auto-join enabled on the cluster/VC?

We removed a couple of AP315's and deleted them from the UI a few months ago to keep as spares.  When we come to reuse them now we did the physical reset on them and then plugged them in.  Instead of appearing in the 'Alerts' section and waiting to be allowed on the system they are immediately added to the access points column listed by their MAC addresses and then they drop off, reboot and do it again repeatedly.  Looking at the unit it says it's due to heartbeat timeout.  We did an update to 8.12.0.1_89864 as routine maintenance and tried again with the same results.

Why are reset AP's not behaving like factory default and asking to be allowed in the Alerts section?  We have spare licenses.  I have deleted the AP's from the UI.  I've even gone into the conductor and deleted them from the database in the CLI.  I can't delete them manually from the allowlist-db in the CLI because it does not appear to be up long enough.  I've tried manually renaming and regrouping them in the CLI as well to see if that helps and they don't take it either.

The Heartbeat issue seems to be something that has plagued everyone and usually we're told to check the wiring or check the licenses.  It's neither in this case as we have tried them in 4 different switches with different cables as well.  We have 173 AP's and licenses for 181 devices and they were on a couple of months ago with no issues.

Why are they not behaving like factory default APs after numerous resets?  Why the heartbeat issue?  We've never run into this before and been running them for years.