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.

Hi again.  We have two physical 7200 controllers and two VM Mobility Conductor servers controller all 173 access points.  No instant AP's at all, all from the controllers.  We don't have any filtering internally on the LAN, everything is on the edge watching the WAN and traffic monitoring but not alerting on the inside.  We have tried these AP's in 3 different switches in 2 locations, one was on an H3C 7500 switch and the others were on Aruba 2930 and a 5412-zl2.  We also set up a 505 AP just before these 2 on the same switch and it worked as expected.  It seems to be just these 2 units, or perhaps the 315 models.

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.

For controllers, forget about the auto-join, although the similar feature is auto cert provisioning under CPSec:

But that's just for some background. If these AP-315s are IAP-315 models, they may have converted back to Instant mode and may depending on the current running version need to be manually converted.

Regardless, the firmware download for upgrade may fail over a WAN connection if there is a reduced MTU or if there is significant latency. Does the same happen if the AP-315 is placed in the same LAN as the controllers? Having a WAN between the AP and controller is officially unsupported.

Do you have access to the AP console? It can during boot show if the AP already successfully upgraded (see the current version).

Do you have logs to share from either AP or controller when the AP can't connect?

Hi again.  We have two physical 7200 controllers and two VM Mobility Conductor servers controller all 173 access points.  No instant AP's at all, all from the controllers.  We don't have any filtering internally on the LAN, everything is on the edge watching the WAN and traffic monitoring but not alerting on the inside.  We have tried these AP's in 3 different switches in 2 locations, one was on an H3C 7500 switch and the others were on Aruba 2930 and a 5412-zl2.  We also set up a 505 AP just before these 2 on the same switch and it worked as expected.  It seems to be just these 2 units, or perhaps the 315 models.

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.

There is the global AP database and the allowlist database. Do you delete the APs from both databases? You can use the following commands in the mobility conductor:
clear gap-db wired-mac <wired-mac>
allowlist-db cpsec del mac-address <address> 

After a factory reset, connect a console cable and boot the AP in a VLAN where no L3 discovery is configured. Interrupt the boot process by pressing enter as soon as the message "Hit <Enter> to stop autoboot:" appears. This will get you into apboot mode. Enter printenv. Is AP name, AP group displayed? The group must not exist, AP name must be the same as MAC address. Enter reset, the AP boots. Observe the console output. The AP will not find a controller, you will see the message that nany-process is booting the AP. This would be correct behavior after the factory reset.

If auto cert provisioning is enabled, as Herman describes, then the following happens:
The AP boots, finds the controller via L3 discovery and automatically jont to the controller. It performs a software update and boots, its certificate is automatically approved, the AP boots again. At some point the AP goes online and is in the default AP group, if you use provisioning rules, it is moved to the corresponding group.

------------------------------
Regards,

Waldemar
ACCX # 1377, ACEP, ACX - Network Security
If you find my answer useful, consider giving kudos and/or mark as solution

Original Message:
Sent: Aug 23, 2024 10:38 AM
From: Herman Robers
Subject: Resetting AP's not working

For controllers, forget about the auto-join, although the similar feature is auto cert provisioning under CPSec:

But that's just for some background. If these AP-315s are IAP-315 models, they may have converted back to Instant mode and may depending on the current running version need to be manually converted.

Regardless, the firmware download for upgrade may fail over a WAN connection if there is a reduced MTU or if there is significant latency. Does the same happen if the AP-315 is placed in the same LAN as the controllers? Having a WAN between the AP and controller is officially unsupported.

Do you have access to the AP console? It can during boot show if the AP already successfully upgraded (see the current version).

Do you have logs to share from either AP or controller when the AP can't connect?

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.

Original Message:
Sent: Aug 23, 2024 10:04 AM
From: Kenny_10_Bellys
Subject: Resetting AP's not working

Hi again.  We have two physical 7200 controllers and two VM Mobility Conductor servers controller all 173 access points.  No instant AP's at all, all from the controllers.  We don't have any filtering internally on the LAN, everything is on the edge watching the WAN and traffic monitoring but not alerting on the inside.  We have tried these AP's in 3 different switches in 2 locations, one was on an H3C 7500 switch and the others were on Aruba 2930 and a 5412-zl2.  We also set up a 505 AP just before these 2 on the same switch and it worked as expected.  It seems to be just these 2 units, or perhaps the 315 models.

Original Message:
Sent: Aug 23, 2024 09:28 AM
From: Herman Robers
Subject: Resetting AP's not working

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.

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.

Original Message:
Sent: Aug 23, 2024 07:53 AM
From: Kenny_10_Bellys
Subject: Resetting AP's not working

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.

Original Message:
Sent: Aug 23, 2024 07:09 AM
From: Herman Robers
Subject: Resetting AP's not working

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?

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.

Original Message:
Sent: Aug 23, 2024 05:21 AM
From: Kenny_10_Bellys
Subject: Resetting AP's not working

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.