Higher Education

Ok gang, riddle me this,

I have several access points (mostly AP93s but one or two AP105s) that have recently started just losing their configs and just sit there doing nothing. They stay on the network as I statically assign their LAN IPs. My main monitoring software does not  register them as down because it can still ping their addresses but they are truly down as they have stopped communicating with the controllers, stopped broadcasting and they just hang there like potatoes with Ethernet cables jacked into them. The only way I have found to correct the situation is to manually take the APs down, serial into them and factory rest them and them put them back up and then re-configure them. They seem to be okay for anywhere from a week to as long as three weeks and then they do it again.

Has anyone experienced this or something similar? I am considering opening a case with TAC but wanted to see if anyone had any insight before I did.

Thanks gang!

Sorry, can't say that I have heard of this problem, but I had to reply because I literally laughed out loud when I read your description.  I was just talking about when I was going to get the potatoes planted in the garden five minutes before I saw your post.  What firmware are you running on the controller(s)?

Jim

We have had a similar issue with AP 130 series and even 220 series.  I found that doing a reboot seemed to resolve the issue.  Our APs are not statically assigned and are DHCP however.  For our environement it seems that the entire AP group needs to be rebooted.  The time in between when they need to be rebooted may be as little as an hour or as long as several months.

TIL  AP = broadcasting potato

I had this exact issue with an AP-65 last week.  The AP was showing up on the controller and in Airwave but was showing zero clients connected to it (see screenshot).  When I sent the apboot ap-name command from the controller the AP would stay up and not reboot.  I manually rebooted the ap by killing the switchport and the AP came back up and started working as it should.  That only lasted a day or two so I replaced the AP with a known good AP and it had been working fine ever since.

I only discovered this issue because a student in a dorm room complained that his signal strength suddenly got worse.  I am wondering if this is happening with other APs across Campus.  Does anyone know of a way to check this other than looking for APs with zero clients?

I am running 6.3.1.16 on 72xx controllers with a mix of AP-65, 70, 85, 93H, 105, 115, and 225.

That is essentially what is going on with some of mine with one exception, reboots will not bring them back up. Like I said earlier, I have to fully factory reset them. very odd. Someone asked what version I am running on my controllers - 6.4.2.0 is what I am running on all of mine. Also, this is not restricted to a single controller. I have it happening on a few at out North Campus on a 3600US controller and a few at our main Downtown Campus on a 7210US controller.

We are running 6.4.2.5 on a 3600 master and m3 locals.  6.4.2.5 seemed to fix a lot of issues that we were having.

I missed the "factory reset" part of your original post.  My issue may be totally different than yours.  Hopefully mine was just a bad AP.  We have not migrated to the 6.4 code yet as we still have legacy APs.

---

@americanmcneil wrote:

That is essentially what is going on with some of mine with one exception, reboots will not bring them back up. Like I said earlier, I have to fully factory reset them. very odd. Someone asked what version I am running on my controllers - 6.4.2.0 is what I am running on all of mine. Also, this is not restricted to a single controller. I have it happening on a few at out North Campus on a 3600US controller and a few at our main Downtown Campus on a 7210US controller.

 

---

Americanmcneill,

Please upgrade from 6.4.2.0 when you can.  There are plenty issues fixed with 6.4.2.5 and beyond.  

In addition, very few users actually deploy static ip addresses, but when you do, you can run the serious risk of assigning a device that already has that ip address, or a device TAKES the ip address of an existing access point and it will function like you said.  Aruba APs were designed primarily to have dynamic ip addresses because it is such a chore to maintain static ip addresses.  They are normally monitored using an NMS that polls the controller to get up to date information about the devices like ip addressing.  You have only given us limited information about your issue, so it is hard to say what is happening, but the initial step of upgrading your ArubaOS could definitely help other problems.

Hey CJ,

After a fair amount of reading here on the boards, I upgraded to 6.4.2.5 last night. As soon as I get a chance I'll reset those few AP's again and then see what happens.

As far as statically assigning IPs to the AP's, I hear ya and I'm picking up what your putting down. I started the slow migration to dynamic IPs as I add new ones and as old ones need to get fixed or replaced. I originally inherited  this network from another administrator and it was a lot smaller at the time. As I grew the network, I followed his documentation schema which included keeping AP's statically assigned. Now that we have broken the 200 AP barrier (I know, small potatoes to most of you guys out there in Aruba Happy Land), he is seeing what a pain in the ass it is to do so with the APs. So yeah, I totally get it and have started to move away from it.

I'll be sure to post a follow up to let everyone know if the AOS upgrade did the trick. Thanks for everyones help and insight!  :-)

Okay gang, it looks like the upgrade to version 6.4.2.5 did the trick. After resetting the radios in question after the upgrade not a single one has dropped on me.

So it looks like Old Man 6.2.4.0 was the culprit. And he would have gotten away with it too had it not been for you meddling kids...

I had a handful of 103Hs forget their configs during an upgrade/reboot of the MAS that was powering them.  We use DHCP so they joined back to the controller default group and we could reconfigure them, but not something that gives me the warm fuzzies.

Gentlemen,

I'm reviving this thread because I just experienced a similar issue;

After 4 months of problem free service,  10 AP's lost all configuration after a suspected power outage at APs only, not at the switch.   The 10 AP's rejoined the master controller in default mode while  4 other AP277's  on same switch rejoined with proper configuration parameters.

Has anyone else have this issue recently? thanks

7220 Controller code is 6.4.3.7,  AP277's,  DHCP,

I would open a TAC case. I haven't seen large numbers of APs behave that way, and it would only happen if, somehow, the AP's set environment variables was wiped (could be from a power surge if the APs were subjected to higher than expected voltages on the supply). 

Thanks J,

Power supply is suspect as we are using POE/FOC's for this deployment. We'll explore options....Thanks for the info.

We have this issue, or at least a somewhat similar issue. The very root cause of the problem seems to be under powered POE switches. We are using enterasys B5G Poe switches which only offer about 375 watts of power across all 48 ports. Not enough. Because of this, some of the access points continuously reboot. I don't know why continuously rebooting is wiping the configs on the access points, but as soon as we resolved the power problems, the AP's stopping losing their configs.

Hopes this helps.

Thanks,  Power seems to be primary suspect here.

We'll explore options on upgrading the current set up and let you know if we continue to have the "potato" problem.

thanks