the ENV variable "master" is used by controller-based APs, as previously commented IAPs do not use a static conductor IPv4 address.
See Instant User Guide ~ page 18 "Assigning an IP address to the Instant AP"
apboot> setenv ipaddr 192.0.2.0
apboot> setenv netmask 255.255.255.0
apboot> setenv gatewayip 192.0.2.2 <----------------------- note "gatewayip"
apboot> setenv dnsip x.x.x.x
A controller based AP would add these to achieve a static connection to a specified controller;
setenv master x.x.x.x
setenv serverip x.x.x.x
It sounds like the affected unit is an IAP, since the gateway ENV should be gatewayip, the default next hop is not reachable, and the IAP is performing
DHCP fallback. what is odd is that it's trying, but not succeeding, and landing with an RFC 5735 169.x.x.x address, so DHCP is failing.
Is the IAP managed by central ? or perhaps at least contacting activate ?
Interesting discussion:
https://community.arubanetworks.com/discussion/disable-fallback-dhcp-from-aruba-ap
An IAP log might contain clues that the IAP :
- reaches activate and receives "no-prov" message - meaning there are no provisioning instructions for this IAP.
- cannot reach it's default GW
- cannot reach Central
- receives some DHCP answer
If all conditions are true, the IAP then removes the static IP and tries to use DHCP.
This log message indicates this fallback has occurred:
Dec 13 18:10:50 cli[2640]: <341004> <WARN> |AP AP205:c2:61:5c@10.10.59.50 cli| dhcp probe sucessfully for cloud recovery
Suggestion:
If all IAPs have static IPv4, we need to ensure there is no DHCP server present, and the static IPv4 is working between the affected IAP and the current conductor/VC.
check the ap-env variable list, in apboot "printenv"
ensure no DHCP server exists in the VLAN where the IAPs connect.
use apboot to configure static IP, from apboot we can use the "dhcp" and "ping" commands to verify that there is no DHCP server present, and the IAP can reach the conductor.
Ensure the conductor allows the affected IAP MAC address
verify whether cluster-security (DTLS) is enabled on the conductor/VC
Consider configuring exactly one IAP as the preferred-conductor (ap-env IAP specific settings).
APboot commands:
dhcp
printenv
Helpful commands: (please consult appropriate IAP version user and CLI Reference Guides)
IAP CLI mode:
show ap-env
show ap-env-backup
clear ap-env-current
clear ap-env-backup
ap-env <STRING:env_name> <STRING:env_value> # caution - this will set the apboot ENV variables
show recover
show configuration
show backup-config
show log dhcp
show log dhcpv6
show activate status
show ap debug cloud-server
show ip route
show ip interface brief
Note that IAP 8.6.0.21 and 8.11.1.0 provide a fix for IAPs which incorrectly remove static IPv4 and use DHCP.
Hope this helps.
------------------------------
Shawn Adams
------------------------------
Original Message:
Sent: Apr 28, 2023 11:43 AM
From: jdoetsch
Subject: Aruba AP not connecting to IAP Network after power outage
One of our APs went down due to a power outage recently, and is now stuck in a bootup loop. I got a console cable plugged in and saw that the static IP we assigned was gone. I've gone into apboot and re-applied the static IP, but it is still attempting to get a DHCP address when booting. When the DHCP fails, it assigns a "default ip", which is then rejected by the master (Rebooting AP due to default-ip is denied in this network).
Here are the settings I added:
ipaddr=10.1.10.5
gateway=10.1.10.1
netmask=255.255.255.0
master=10.1.10.3
Unsure how to proceed, as DHCP is not an option in this particular case. This was working previous to the power outage