To be fair, I was at the Airheads keynote, in the audience during the update. It was not 'seamless' when client match moved my client - but it was as seamless as client match can get. I noticed several roams as my MacBook was getting shuffled around: [image: Inline image 1]
While not inherently an issue, forced client roams can indeed cause packet loss. There are supposedly mechanisms in place to prevent this happening on voice calls, etc but I did not experience that particular feature first hand. Also of note was that after my client was moved around, there were periods of time where I experienced large gaps in connectivity resulting in chunks of ping timeouts. This was discovered to be due to a bug where clients were not moved 'back' to their AP and has been reportedly resolved. Shameless self-plug - Blake Krone and I discuss our experiences over at the No Strings Attached Show: http://nostringsattachedshow.com/2017/04/26/e62-aruba-did-what/ -Sam On Thu, Jun 8, 2017 at 4:05 PM, Jonathan Waldrep <wald...@vt.edu> wrote: > My understanding was that it worked based on the MM's knowledge of which > APs are neighbors, not based strictly on channels. This may have changed. > > For what it's worth, they did a live upgrade during the keynote at > Airheads. From the client's view, it seemed seamless. It's worth noting > that a large auditorium is an ideal location for this, due to a lot of > overlapping coverage. If you have a one-off office with a single AP, there > will be ~2 minute outage when the AP reboots. > > Disclaimer: I haven't gotten any road time with 8.x outside of a lab, yet. > > -- > Jonathan Waldrep > Network Engineer > Network Infrastructure and Services > Virginia Tech > > On Thu, Jun 8, 2017 at 4:49 PM, Harris, Robert <robert.har...@culinary.edu > > wrote: > >> What he said, basically it’s a “client aware” option for AP upgrades.. >> >> >> >> >> >> >> *Robert Harris **Manager of Network Services* >> >> *Culinary Institute of America* >> >> 1946 Campus Drive >> >> Hyde Park, NY >> 845-451-1681 <(845)%20451-1681> >> >> www.ciachef.edu >> >> *Food is Life* >> >> *Create and Savor Yours.™* >> >> >> >> *Please consider the environment before printing this e-mail.* >> >> >> >> *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto: >> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Samuel Clements >> *Sent:* Thursday, June 8, 2017 4:46 PM >> *To:* The EDUCAUSE Wireless Issues Constituent Group Listserv < >> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>; Harris, Robert < >> robert.har...@culinary.edu> >> *Subject:* Re: [WIRELESS-LAN] ArubaOS 8.X Experiences >> >> >> >> At AirHeads it was described this way: >> >> >> >> Code is loaded on one WLC, WLC is rebooted and running new code. >> >> Client match is used to encourage clients to leave APs on a selected >> channel. >> >> All APs on that selected channel are elected for update and moved to the >> WLC with the new code. >> >> Moved APs get new code, reboot, come back into service. >> >> APs running new code are eligible for taking on new clients and client >> match should start moving clients to the new code APs. >> >> Lather, rinse, repeat until all channels have been rotated through. >> >> Once the WLC is unloaded, it gets new code and is rebooted. >> >> >> >> So, not really 'hitless' as advertised, but yes- far better than taking >> them all out at once. Assuming of course that client match successfully >> behaves. ;-) >> >> -Sam >> >> >> >> >> >> >> >> On Thu, Jun 8, 2017 at 3:38 PM, Joachim Tingvold <joac...@tingvold.com> >> wrote: >> >> On 8 Jun 2017, at 19:11, Sweetser, Frank E wrote: >> >> […] and from there I'm really looking forward to seeing how well the live >> upgrades work! >> >> >> Hi, >> >> Do you know how that works in detail? All I can find is the sales >> mumbo-jumbo that over-promises (as usual); "[…] allows customers to upgrade >> their wireless network in real time without any impact to user >> connectivity. Upgrade process is simplified, no maintenance downtime […]". >> >> Looking at the installation manual of 8.1.0, it doesn't say how it's >> done, but I managed to find a "dumbed down" non-official explanation that >> went something along the lines of "[…] move all APs to secondary >> controller, then upgrade the primary controller. After primary is upgraded, >> APs are gradually upgraded/moved to the primary controller (i.e. not all at >> once). Once all APs is upgraded, the secondary controller is upgraded, and >> then the redundancy is restored". >> >> How are those APs selected? Just random order? If so, that doesn't really >> mean "no downtime" or "no impact on users", as you could risk neighboring >> APs to be upgraded at the same time, causing smaller or larger blindspots. >> Of course it sounds better than to "take it all down", but, yeah, not >> really ISSU… >> >> -- >> Joachim >> >> >> >> ********** >> Participation and subscription information for this EDUCAUSE Constituent >> Group discussion list can be found at http://www.educause.edu/discuss. >> >> >> >> ********** Participation and subscription information for this EDUCAUSE >> Constituent Group discussion list can be found at >> http://www.educause.edu/discuss. >> ********** Participation and subscription information for this EDUCAUSE >> Constituent Group discussion list can be found at >> http://www.educause.edu/discuss. >> >> > ********** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at http://www.educause.edu/ > discuss. > > ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
