Wireless Access

Hello,

Just wanted some advice on using 6.4.1.0 in ED.

Is it stable enough when ED to use in a live environment? 

I work in hospital and it can be a pain to arrange downtime so I would like to avoid the possibility of arranging downtime to deploy 6.4.1. and then find I need to do it again to correct a problem, although I understand if there were a problem of significance chances are we'd have to do it anyway to get it working.

I need the new version to start using the new AP-205s.

How long does it normally take for a version of code to go from ED to GA?

Thanks

Ian

Please:

- Read all the 6.4.1 release notes in its entirety (twice) and focus on the upgrade instructions.  If you don't understand anything, please consult tac for an explanation.

- If you are coming from two major versions of code or earlier (6.2 and earlier) much more attention has to be paid to changes in behavior and support for hardware in the release notes.

- If you can,  upgrade to a test enviroment to make sure that everything is working in your environment as expected.

- Submit your logs.tar from your current deployment with TAC and ask if there is anything that is keeping you from upgrading (tell them everything you are using it for and if you are having any current problems).

- Consult your local Aruba SE to find out if there are any gotchas with your current deployment.

6.4.1 has only been out for a month.  There is an internal mechanism that determines if code is GA based on how long it has been out, how many customers of what size have deployed it, and how many outstanding TAC cases of what type are open against it.  It will take some time.

I am kind of in the same boat.  I have some 205's that i want to use but i dont want to put early release code in my production environment if i can help it.  I fortunatly have the time to let them sit for a couple months before i need to deoply them so hopefully any software bugs will get worked out before then. 

Its a little frustrating that Aruba will release hardware but not release the proper software to support it at the same time. 

mwallen,

I fully understand your position.  Please leave your comments here.  https://arubanetworkskb.secure.force.com/cp/ideas/ideaList.apexp

My thoughts and my thoughts alone below:

There are 3 very unappetizing choices when releasing new hardware

1. - Put major code changes like hardware releases into GA code and take the chance that GA code is destabilized...

2. - Delay GA code (6.3.1.2) until we can release the hardware, which keeps Aruba from declaring the code GA for months and months.

3. - Start another train in parallel and ensure that the changes necessary for new hardware isolate GA code from major changes..

The safest route is #3, which isolates changes necessary for new hardware from GA code.

The chicken and the egg with GA code is that it cannot be declared GA until enough people have been using it and the majority of serious bugs are addressed.  That means that new hardware is never released on GA code, because nobody has ever used it.

Aruba customers deploy Aruba code in many different combinations that are not even thought of by Aruba.  It is impossible to test all of those combinations.  If Aruba did, what takes months to release, would take years.   Meanwhile, everyone wants features, fixes and new hardware, so at some point, some code needs to ship.

The best way to deal with this is to completely read the release notes and deploy your target version of code in a lab.  You should also solicit opinions on Airheads here from other people who have done the same, so that you can crowdsource and get feedback on any strategy you want to come up with.  This is highly encouraged, because we leverage the information on Airheads to improve the product and get out ahead of issues.  Some people already have 6.4.1 deployed in production, so please solicit their opinions here.  You can also submit your logs.tar to Aruba TAC for your production network and they can see if there are any red flags that would keep you from upgrading to 6.4.1.

You can also notify your local Aruba sales team of ideas or things you want improved.

Also, and I know it's easier said than done, but most of my critical customers have a WLAN deployment with the Production network, and a PIlot/Test network. They run the same configs, same hardware (or new hardware as it were) and have two separate controllers. They dpeloy the ED code on the Pilot system and monitor performance. This is a good way to protect the WLAN 'system' and still get a view of what is or isn't working ,possible bugs, etc. It only needs to be a small controllers, so if uptime/performance is critical, $5k or so should not be a huge swing to bring on as a pilot system.

Otherwise, Colin is spot-onwith his assessment. 

We're in the same boat, but worse. We have a bunch of 103Hs on the way towards the end of the month and we have to have the system stable by the beginning of the school year.

Right now we are wrestling with some problems with occasional missing HA heartbeats that apparently are irreproducable by TAC that appeared when we upgraded to 6.4.1.0.. This produces disconnects for users 2-3 times a day and there is nothing in any log to give us a clue, so we may have to punt on the HA for a semester. YMMV, and it depends a lot on the feature sets you are using.

Having a test controller would be handy but some problems won't exhibit without scale or real users.

bjulin,

If push comes to shove, You have VRRP-based or lms-ip based redundancy which has been around for years as an option, if you are having specific issues with HA.