Higher Education

I am currently running 6.3.1.5 and am getting ready to bump up to 6.3.1.10. I am also looking at 6.4. Anyone running 6.4? Pros? Cons? issues or smooth sailing? buggy or good out of the box? chocolate, strawberry or vanilla?

 

 

Been running 6.4.0.3 at various customers for a few months. No issues.

 

https://community.arubanetworks.com/t5/Unified-Wired-Wireless-Access/6-4-Code-for-the-Controller/m-p/195659/highlight/true#M39251

We are running 6.4.2.0 on our controllers.  We did have a few problems but it wasn't a code bug as far as we can tell.  We do have a local controller that keeps rebooting at random but we are not yet sure if it is a code bug or something wrong with the controller yet.  We are running a master-local environment with a 3600 as master and 4 m3 cards across 2 6000 chassis for locals.

We're on 6.4.0.3 as well and we didn't run into any huge problems.  Keep in mind that when you go to 6.4 RAP-2's or RAP-5's are no longer supported.

 

I have customer running 6.4.2 on 15 controllers (7200 and 7000) and no issues

I spoke with a gentleman who works with the Aurora School District in Aurora, Colorado.   They had an issue with a LACP link tying two 10GBe connections together.  They backed out to a 6.3 version and were waiting for a fixed version.   I don't know if this has been resolved or if it had something to do with their particular setup.

theres a bug on 6.3.1.9 with port channel but not sure if that fix has been added to 6.4.2 i know it was fixed on 6.3.1.9 

Been on 6.4.0.3 since April.  No issues except when we provision AP's.  While using Chrome at least, You need to click No on the Remote AP Authentication method, even though it is defaulted to No.  Otherwise, there are several fields left open and it will not let you provision te AP.  I have attached a screenshot.  

 

Other than that minor issue, there have been no issues.

We've been on 6.4.2 for a couple of months and it seems fine. The only thing I've noticed is that there a screwy number of client associations. It seems to be accumulating the numbers instead of just current reporting of associations.

---

@nogirs wrote:
We've been on 6.4.2 for a couple of months and it seems fine. The only thing I've noticed is that there a screwy number of client associations. It seems to be accumulating the numbers instead of just current reporting of associations.

---

nogirs, associations as reported by the controller or airwave?

 

Just on the main controller. The two locals seem to have correct
numbers. Airwave also seems to have the correct client associations (
within reason due to the time lag). Thanks for replying. Have a nice
labor day weekend.

Sent from my iPhone

---

@nogirs wrote:
Just on the main controller. The two locals seem to have correct
numbers. Airwave also seems to have the correct client associations (
within reason due to the time lag). Thanks for replying. Have a nice
labor day weekend.

Sent from my iPhone

---

nogirs,

 

We should probably take this to a separate post, but which numbers are you referring to on the main controller?

 

Anyone with an M3 controller up on 6.4 that can share their experience? Read these nasty bugs that kept me from upgrading a customer environment using M3 and bridge mode.

 

 

 

I just noticed that this weekend. On Saturday our freshman students arrived, and even though there were 1111 clients connected, one access point showed 1827 connections! (when viewed on the master controller, but not the local controller managing it)

Others showed numbers in the 400s and 500s, but there weren't that many all at the same time at each of these locations.

I opened a case with Aruba on this.

--Jim--

Jim Bingham
Network Specialist
Franklin Pierce University
40 University Drive
Rindge, NH 03461
603-899-1115 (W)
603-381-1740 (M)

Had an issue with DHCP on 6.4.2, or at least appeared that way.

 

Clients could connect the first time and get an ip address.  If they reconnected short time later, they did not get an ip address.  Could see the requests coming in but controller did not respond.

 

Controller was using the same DNS server as the clients, being a small guest solution.

 

I removed the DNS server from the controller, and now looking better.

Hope this helps if you guys are looking to upgrade.  The fix should be out this week.

We did hit the 104254 bugID but on 7240s TAC confirmed this morning.  We are running 6.4.2.0

From TAC:

What's happening is that C-STM UDP port is backed up and its response time exceeds the 2 timeouts in AP. AP makes it worse by sending a STA_DN to C-STM and also deauths the STA. The deauth causes STA to associate again leading to another a2c message. This causes a snowball effect and the system reaches a steady state where no client can associate on any AP.

 

 

---

@Michael_Clarke wrote:

Had an issue with DHCP on 6.4.2, or at least appeared that way.

 

Clients could connect the first time and get an ip address.  If they reconnected short time later, they did not get an ip address.  Could see the requests coming in but controller did not respond.

 

Controller was using the same DNS server as the clients, being a small guest solution.

 

I removed the DNS server from the controller, and now looking better.

---

Forget this.  I got my ACLs slightly wrong.  DHCP is fine.

Did anyone see any signal strength drops?  I upgraded to 6.4.2.0 after running 6.3.1.7 most of the last year.  Dorm rooms that had good signal last year are reporting unsable signal.  I have a TAC case open but was curious if anyone else had something similar.  

 

I took at AP 105 that is in service a floor below me and measured signal strength with a Fluke Aircheck.  I fired up my old 3200 controller and put 6.3.1.10 on it. I took an AP105 and put it on that controller then took it down and swapped it with the one below my office.  On 6.4 i was  seeing that the A & B/G radios were showing almost the exact same signal strength(withing 2-3db's).  When i swapped with the 6.3 AP i was seing about a 18-20db difference between the A & B/G radios.  The A radio was about 9-10db weaker, and the B/G was about 9-10db stronger compared to the 6.4 code.   

mwallen,

 

If you want to compare the EIRP vs the power set in the controller, you should use the show ap debug driver-log command:  http://community.arubanetworks.com/t5/Command-of-the-Day/COTD-Viewing-Radio-Power-quot-show-ap-debug-driver-log-quot/m-p/266/highlight/true#M51

 

 

As Always,Colin you are AWESOME!  Comparing the 2 controllers, i am seeing big differences.  on 6.4, its hovering between 9-12db as the set value but never anything higher then 12. Like so: 

2653 713629.768399 wifi1: Scheduling RADIO CONFIG update
2654 713629.784031 wifi1:(4) EIRP (Config: 9.0dBm, Set: 9.0dBm, AP Max: 22.5dBm, Reg Max: 22dBm), Conducted Power Set: 6.5dBm, Gain: 2.5dBm
2655 713629.784112 wifi1: disabling 40Mhz
2656 713629.784170 wifi1: RADIO CONFIG DONE

 

on the 6.3 software i see it bounce around more, but i see most of the log entries at 20-22db.  Like so: 

68 0.478246 wifi1: EIRP (Config: 24.0dBm, Set: 22.0dBm, AP Max: 22.5dBm, Reg Max: 23dBm), Conducted Power Set: 19.5dBm, Gain: 2.5dBm
69 0.478308 wifi1: disabling 40Mhz
70 0.478341 aruba100: enabling HT on 1/1
71 0.478397 wifi1: RADIO CONFIG DONE

 

Whats interesting the "config" setting.  I(TAC) restored a backup of the 6.4 controller onto the 6.3 controller so the config should be the same.  I will bring this new info to the technician i am working with and see what we can figure out.  

 

mwallen,

 

You should first set the ARM min and the ARM max at the same power and see if there is a different EIRP between builds.  "Bouncing around" could be in response to RF conditions, which could either be different or handled differently across the releases.  If the EIRP is different with the same TX power, that is a problem.

 

BTW, 6.4.2.1 is out as of last Friday.  Went to it yesterday, seems to have fixed the bug we had.

yah, i checked a few times on friday to see if it was out so i could do the update during a maintenance window on sunday, but it was not out when i left work.  I will aim to install in this coming sunday and hope that fixes a few of the issues i am running into. 

 

as an update, i did get one of my issues fixed this morning working with TAC.  It seems the AP205's auto set the MTU values.  The other AP's dont.  the 205's were setting this in a way that was causing incomplete information to be sent which causes random webpages to not load anymore.  Setting the SAP MTU to 1400 in the AP System profile solved the problem. 

#AP205

We were planning to wait on 6.4.x deployment until it went GA, but torrents are getting out of hand in our student population. I am heavily leaning towards upgrading our 7220 controllers to 6.4.2.2 this week during our maint window.

 

How is the updated AppRF working for everyone on 6.4? Anyone using it to throttle torrent traffic?

#7220

Pending some final QA testing, 6.4.3 will be GA in the next month or so.

Hey Tim, we've been running 6.4.0.3 for awhile now.  Anything I need to be on the lookout for in that version, or need to upgrade over?

I just want to bump this for anyone thinking of upgrading to 6.4.2.3.

 

We are having to revert to 6.3.1.14 tonight because of a bug that is causing the 7240 and 7210 controllers to drop traffic. 

 

 

 

#7210

Just curious: why don't you just manually set the port speed?

I guess I just don't trust it at this point? We were early adoptors of the 72XX and AP-22X product line, and we have worked through issues with TAC since 6.3.0.1. I've been pleased with how issues have been resolved along the way and this is the first time we will revert. I'm not happy that basic network connectivity was broken. 

 

 

 

very interesting, we recently attempted to upgrade a batch of 3600s to 6.4.2.3 and we lost remote access to them, reverting them back was the only option. TAC is still on it.

Do you have a bug id # you can share?

This is not the first time that coding of additional features in ArubaOS breaks “basic” L1-L3 functionality. :-(

That is why there are Technical Preview releases. These issues are supposed to be caught & fixed before Geneal Availability.

 

This is a GA release.

There is a known LACP flapping issue in 6.4.2.3

JMawyer,

 

Thank you for sharing this!

 

I wanted to chime in and say that I moved to 6.4.2.3 a little over a week ago on my 2 7210 controllers, and I have not experienced this problem. How did it manifest? (I am not missing pings or seeing AP's switch controllers in our HA-Lite cluster) Were there up/down events on the switch it was plugged into?

 

Thanks,

 

Aaron

#7210

You most likely will not see this issue if using 10G on ports 2-5.

It started as LACP timeouts, so the port channel would go down as a result. We then changed from active to passive and from timeout short to long on the controller end, and to timeout long on the router end. After that, we no longer had the LACP timeouts, but interface traffic would drop completely, and the APs would failover to the standby controller.

 

Our Network: 

2 7240 controllers Master/Standby

4 pairs of 7240 local controllers in active/standby configuration

 

All controllers connect to Juniper MX routers via port channels using 1G ports 2 through 5. 

 

 

Did hard setting the speed not fix the issue?

Just wanted to give an update now that school is back in full force and we will be rediscovering new problems. We moved away from LACP and moved to single 10G interfaces.

 

We are currently on 6.4.2.6 and currently dealing with random mass AP HA failovers, which is supposedly fixed in a future release. I've been gun shy about moving to any other release and was getting ready to pull on testing 6.4.2.11, and then they recalled it for hardware issues, sigh. The battle of the known problem versus the great unknown.

 

I'll watch 6.4.2.12 and see what unfolds.

 

We're on 6.4.3.2.  We used to have to turn intercontroller heartbeats

off until a software fix fixed the mass HA AP failovers.

 

We're running 2x10G LACP fine to a MAS from one controller, with speed

manually set.  The other controller is also actually in a LACP group but we had to

steal a port off it.  The MAS is, for now, running 8x1G LACP into a cisco just fine

with the following adjustments on the cisco side of the portchannel interface

(which is in turn applied to the 1G ports.)

 

switchport nonegotiate

speed 1000

duplex full

 

Without those that 8x1G bond was not happy at all.

 

We've got jumbo turned on now most places, but it was all working fine

before we did so as well.

 

The MAS is 7.3.2.0 because there's never a good time to upgrade it.