One of the things as a partner I try to educate customers on is “who is recommending what, and why.”
My experience has been that the BU is trying to drive feature adoption, sell APs and controllers. That’s why they exist, so don’t fault them for it. They tend to recommend new APs, new versions of code and new features. Why? Because they are in the business of selling. Tac is all about which code results in defects are going to generate the least amount of tickets, and hopefully that means more stability. As a partner I try to ride the line. I tend to determine a customer’s appetite for risk, longevity, their market and their staff capability. This puts them into 3 buckets: proven technology only, moderate, and bleeding edge. I’m accountable if I recommend something and it doesn’t work well, so I tend to be more conservative. Bleeding edge gets you further in a lifecycle if equipment, but you better be prepared to deal with some bugs in the short term. And I sit down and talk with them about why I feel they should be buying and operating in the bucket that makes sense for them. Ultimately they make the buying decision. Sometimes things bite me, it happens. But it happens less and less over time. For those of you who are feeling the pain, somehow you are listening to the wrong folks, buying outside the bucket that fits your org, or the person helping you with that decision is looking at things in a way that doesn’t align with your business. Having the relationship with the BU is important. Know how to work with Tac and having a trusted partner is also important. And ultimately the you, the customer gets to make that decision on where and how you go. Sent from my iPhone > On Aug 2, 2017, at 8:54 AM, Jeffrey D. Sessler <j...@scrippscollege.edu> > wrote: > > Lee, > > I can only speak to my experience, and in the case of the x800 series, we > were a first-customer-ship and had them in production in Aug 2016. I ran into > a few bugs, mostly stuck radios, but with direct engagement with the BU, I > was getting code fixes (or viable workarounds) within hours. I was also > having weekly meetings with the BU engineering team, and my local SE and SE > manager were on top of it. I have a similar relationship with the PI team, > although PI has been solid for me for a long time, and I use the channel > mostly for enhancement requests. > > For the size of your deployment, I’d pursue the same direct relationship with > the BU. As customers, we can either say to Cisco, “Hey, you have mind reading > skills so figure it out” or, we can engage directly in an attempt to make the > product better. I choose the later since I know how complex these systems are > and I’d rather do my part to improve the product. > > On the feature side, I divide items into “essentials” and “fluff”, and I put > AVC in the “fluff” category. Yes, it’s nice to have, but I can get this > information from other sources and it’s not necessary to provide the base > service i.e. I leave the controllers dedicated to the essentials. I suspect a > lot of customers do the same, so there isn’t the same amount of > testing/feedback on that feature – thanks for the 400 hours dedicated to > fixing it. Additionally, on the development bug-resolution front, if I was > Cisco, I’d prioritize fixing the essentials over the fluff. On the positive > side, with the AVC off-load features in the new WAPs, controllers should do > much better with AVC moving forward. > > Someday I’d love to compare notes. Somehow, we seem to be dating the same > girl, yet she’s totally different when she’s with me vs when she’s with you. > Maybe a nice box of chocolates is in order? LOL ;-) > > Jeff > > > > From: "wireless-lan@listserv.educause.edu" > <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of "lhbad...@syr.edu" > <lhbad...@syr.edu> > Reply-To: "wireless-lan@listserv.educause.edu" > <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > Date: Wednesday, August 2, 2017 at 6:04 AM > To: "wireless-lan@listserv.educause.edu" <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > Subject: Re: [WIRELESS-LAN] Cisco Code Version > > I value what Jeff is doing with Beta, but also have to agree with James. > Universities might be different- but we’re not THAT different that > controllers and APs should crumble after all these years and generations of > vendor offerings. I find code updates can be problematic, too many APs dump > back to factory defaults, etc. And we’ve been particularly burned by: > > 8510s did not live up to spec when running AVC > 8540s gave great results with AVC, to a certain code version, then it failed > hard. 400+ TAC/engineering hours (and at least three “now try THIS code” go > rounds) later, we stopped using AVC. Couldn’t go back to the code that used > to work because it didn’t support the APs we were now using. > Too many TAC cases drag on far too long for both PI and WLC > The assumption is that you will leave your network in duress- possibly > impacting thousands of customers- during lengthy debugs > Too many problems happen only at large scale, so even lab-testing doesn’t > find them first > Too many escalation builds > Code out there for download that really ought to have warnings about its use > Mixed messages from SEs, TAC, and Cisco partners on what code can be trusted > or not > > If colleges/universities are so challenging, seems like Cisco should have a > design guide by now that incorporates the differences to head off the > problems. And if large-scale networks are problematic, then the > recommendation should be to reduce large networks to multiple small ones > using smaller controllers. Whatever the case, we’ve had countless cycles of > hearing contrition (“yes, we need to do better on our code bugs.. and we > will!”) but it never seems to get there. The 3800 rollout was a debacle- > these awesome APs were overshadowed by poor code for almost a full year > before there was code that you could actually take a chance on. Cisco isn’t a > start-up, and it just feels like either AireOS was never that good, or > somebody is way too eager to bloat it up with endless features at the expense > of stability. > > At my end, the overarching philosophy is Stability Above All, because we’re > years into the WLAN being a critical resource. It just feels like that isn’t > really embraced by the vendor. > > Like with the early days of the 3800 AP, it would be nice to be able to look > forward at Fabric-Enabled Whatever and actually be impressed and excited. But > when we’re juggling constant WLC/AP bugs, features we can’t use because they > break and no one can figure out why, the perception of a development culture > that isn’t doing much to improve the bug front, and recently an increase in > switch/PoE bugs, it’s really hard to get enthused about adding APIs into > components that already have long-running issues. > > We keep it on the rails for our almost 30K-daily-peak clients, but sometimes > it can be maddening in ways that you just don’t get on any other product set. > > -Lee > > > > Lee Badman | Network Architect > > Certified Wireless Network Expert (#200) > Information Technology Services > 206 Machinery Hall > 120 Smith Drive > Syracuse, New York 13244 > > t 315.443.3003 f 315.443.4325 e lhbad...@syr.edu w its.syr.edu > SYRACUSE UNIVERSITY > syr.edu > > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of James Helzerman > Sent: Wednesday, August 02, 2017 7:57 AM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > Subject: Re: [WIRELESS-LAN] Cisco Code Version > > With your beta controller how many access points and concurrent device > connections are you able to test? > > We are setting up a similar scenario, not so much for beta testing as for a > stepping stone to upgrades of our campus controllers. The controller pair > are 8540s and should have 250-300 APs with around 1000+ devices. The user > base is our IT folks in 3 locations so we hope to get good feedback. > > I agree that edu is a unique beast for wi-fi but in the end it's seems some > core functions are what is failing us such as code upgrades and APs stuck in > CAPWAP flapping state that require the switch ports to be bounced. > > Jimmy > > On Aug 2, 2017 3:00 AM, "Jeffrey D. Sessler" <j...@scrippscollege.edu> wrote: > I participate in the betas and even run a beta controller in production. This > is complex stuff, and especially in EDU, we see things that no enterprise > customer will even encounter – or test bed can simulate. For the most part, > I’ve had no show-stopper issues going back to the post 5.2 days. That said, I > keep a very open and direct dialog with the BU, and with something like the > x800 series WAPs, my team did a lot of testing of the product to help get all > the little bugs worked out. > > Jeff > > From: "wireless-lan@listserv.educause.edu" > <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of James Helzerman > <jarh...@umich.edu> > Reply-To: "wireless-lan@listserv.educause.edu" > <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > Date: Tuesday, August 1, 2017 at 3:39 PM > To: "wireless-lan@listserv.educause.edu" <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > Subject: Re: [WIRELESS-LAN] Cisco Code Version > > I feel like we might be used as QA......anyone else? > > On Aug 1, 2017 6:32 PM, "Mccormick, Kevin" <ke-mccorm...@wiu.edu> wrote: > They just released 8.2.160.0. They have not vetted the release as being > stable. They will recommend after enough downloads and not a lot of bug > issues. > > Kevin McCormick > Network Administrator > University Technology - Western Illinois University > ke-mccorm...@wiu.edu | (309) 298-1335 | Morgan Hall 106b > Connect with uTech: Website | Facebook | Twitter > > > On Tue, Aug 1, 2017 at 4:00 PM, Marcelo Maraboli <marcelo.marab...@uc.cl> > wrote: > Hello all > > I wonder why CISCO keeps 8.2.151 as "suggested" and not 8.2.160 ?? > > just a precaution ? > > My Cisco partner is telling me to stay in 8.2.151 even if there is 8.5.x code > our there. > > > what's your opinion ? > > > regards, > > On 7/31/17 4:11 PM, Paul Thompson wrote: > > .160 fixes some real world SIP and 802.11r Fast Transition bugs, if you're > using either of those features. I was told by a coworker that the > engineering prereleases of it had helped with some real life Apple > connectivity tics, but have less detail on specifics of that. > > On Mon, 31 Jul 2017, Lee H Badman wrote: > > > > > 151 here as well- is a bit frustrating that 160 just came out as we’re in our > “freeze” period now for making changes, pre-semester. Other than the typical > laundry list of cryptic bugs corrected, does anyone know if 160 addresses any > real-world, commonly impactful 3800-related bugs? > > > > Lee Badman | Network Architect > > Certified Wireless Network Expert (#200) Information Technology Services 206 > Machinery Hall 120 Smith Drive Syracuse, New York 13244 > > t 315.443.3003 f 315.443.4325 e lhbad...@syr.edu w its.syr.edu > > SYRACUSE UNIVERSITY syr.edu > > > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of James Helzerman > Sent: Monday, July 31, 2017 1:57 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > Subject: [WIRELESS-LAN] Cisco Code Version > > > > Hi. For those with Cisco access points what code version are planning on > running for start of fall semester? > > > > At this point we looking at 8.2.151 possibly 8.2.160 but havent tested yet. > > > > Thanks > > > > -Jimmy > > > > -- > > James Helzerman Wireless Network Engineer University of Michigan - ITS > > Phone: 734-615-9541 > > ********** 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. > > -- > Marcelo Maraboli Rosselott > Subdirector de Redes y Seguridad > Dirección de Informática > Pontificia Universidad Católica de Chile > http://informatica.uc.cl/ > -- > Campus San Joaquín, Av. Vicuña Mackenna 4860, Macul > Santiago, Chile > Teléfono: (56) 22354 1341 > ********** 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. > ********** 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.
