Reply
Highlighted
Occasional Contributor I

Re: AP Down


Do "show ap database | include Down" on the commandline.

The APs that are down might have a flag next to them that says WHY they are down. If that doesn't work, do "show datapath session table " periodically to see if the AP is even attempting to contact the controller, and on what ports. You then might want to do a "show log system all | include " to see if there is a reason why the AP is being rejected, rebooting, etc from a system standpoint. (It could be that you don't have enough licenses on that controller, maybe?)

Last but not least, make sure there is no firewall blocking traffic between those access points and the the management IP of the controller.

If you open a case, of course, support can give you a much better idea.




Here’s a list of the current down APs since the firmware upgrade. There are no flags set on any AP:

(XXXmnDistGa1AC) # show ap database | include Down

XXXbt3a3AW XXX 70 10.224.84.124 Down 10.224.4.6
XXXbt3a6AW XXX 65 10.224.84.223 Down 10.224.4.6
XXXbt4a6AW XXX 65 10.224.84.175 Down 10.224.4.6
XXXbt6a5AW XXX 65 10.224.84.216 Down 10.224.4.6
XXXbt7a6AW XXX 65 10.224.84.227 Down 10.224.4.6
XXXmn4b8AW XXX 70 10.224.72.133 Down 10.224.4.6

No entries for the datapath session table:

(XXXmnDistGa1AC) #show datapath session table 10.224.84.124

Datapath Session Table Entries
------------------------------

Flags: F - fast age, S - src NAT, N - dest NAT
D - deny, R - redirect, Y - no syn
H - high prio, P - set prio, T - set ToS
C - client, M - mirror, V - VOIP

Source IP Destination IP Prot SPort DPort Cntr Prio ToS Age Destination TAge Flags
-------------- -------------- ---- ----- ----- ---- ---- --- --- ----------- ---- -----

Last entries in the log for this particular AP are during the time that the firmware was upgraded on the controller, and it was rebooted. You’ll notice it was in communication with the AP prior to the firmware upgrade:

(XXXmnDistGa1AC) #show log system all | include XXXbt3a3AW

Jun 29 19:04:39 :311002: |AP XXXbt3a3AW@10.224.84.124 sapd| Rebooting: SAPD: Reboot after image upgrade
Jun 29 19:04:39 :303086: |AP XXXbt3a3AW@10.224.84.124 nanny| Process Manager (nanny) shutting down - AP will reboot!

There is no firewall between the AP and controller. There are other APs on the same switch and the same controller that are working just fine. Controller is licensed for 256 APs, only 130 in use.

As I wrote previously, I have already removed power and reapplied to the affected APs, done shut/no-shut to the ports, etc.

Thanks for all of the suggestions. I guess it's time to open a TAC case.

Highlighted
Occasional Contributor I

Re: AP Down




I understand all of that, of course.

It's all a matter of the situation involved. If there is a known problem, the developers state that they have seen the problem, but in return say in essense that "It's no big deal, right?" then there has to be some concern with the end customer.

It's like a tire manufacturer states that 'we know periodically our new tires will go flat for no known apparent reason, we've seen that before, but it's not big deal, just change the tire and go on.' However, as the customer, I'm on a four-lane highway, traveling with dozens of other cars, 70 mph when this tire decides to go flat.

It's all a matter of perspective, and a bit troublesome that the manufacturer quips this happens from time to time, and where I am as the customer at the time it happens. :cool:

Garry

Guru Elite

Reboot

Garry,

Quite frankly, we were at a site today, where we upgraded about 400 APs and about twenty of them did not come back up until we bounced both physical switches that the APs were connected to. We tried disabling power and enabling power to the ports and that did not work. Half of the APS came back up because we bounced the switch and the other half were down because the DHCP options used to steer the AP to the controller were mysteriously removed from the customer's infrastructure. The switch was much older and exhibited the power issue before, but the customer forgot this.

APs are hardware devices and hardware can fail from time to time, but they also can fail to contact the controller for infrastructure reasons beyond that physical AP. The important thing is to get to the bottom of it, ASAP. Investing in a "Y" cable will give you the diagnostic information you need to find out exactly what that is, and possibly preventing it from happening the next time.

*Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba Networks or Hewlett Packard Enterprise.*
ArubaOS 8.5 User Guide
InstantOS 8.5 User Guide
Airheads Knowledgebase
Airheads Learning Videos
Aruba Central Documentation
ArubaOS Consolidated Release Notes
Aruba VIA ASE Solution - Configure VIA VPN
Highlighted
Contributor I

Some things to check

If your AP's are down, that means there are no GRE tunnels from the AP going to the Aruba Master... that could be one of the following issues:

DHCP, Did AP get an IP address?
Controller Discovery- are you using ADP, or Optiion 43 (make sure it is a global assignment for all your subnets) or DNS for Master discovery? and is the AP seeing this information (see previous posts about serial over ethernet into the AP with the Y cable).
If you just went from 2.4 to 3.1 the protocol for transferring image went from TFTP to FTP...
If the AP is finding a Master controller, and still not showing up... go into logging options and set them for WMS, and system messages and get more data to figure out where the breakdown occurrs. Also if the AP's are provisioned into a profile that doesn't have a defined vlan, they will be down...
Try this CLI command: show profile errors not sure that works in 3.1, but it does in 3.3
Also try the manual "shut" "no shut" on the Cisco switches... oddly sometimes that solves issues.
Make sure the switch is allowing PAPI (UDP 8211 on those ports)
Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: