Category Archives: Mobility Field Day

The Network is Code: Cisco at MFD4

It’s always a bit of a thrill to visit Cisco HQ, and to step within the walls of this global network powerhouse. I got to do that again at Mobility Field Day 4, and as usual the presentations and the visit just went too fast. Such is the way these events go… On this go round, Cisco offered us:

Each is interesting and informative, especially when combined with the delagates questions. You’ll be glad you watched them, if you haven’t yet.

But something else jumped out at me at this event, and it may seem silly to even mention. Have a look at this sticker:
Code Pic

The wording of it got my mind working. In a number of directions.

I’m just sharing what’s in my head as a long-time Cisco wireless customer as I ponder the message on that innocous sticker.

I’m glad to see that CODE is the network, because it hasn’t always been. CODE, as presented like this, implies “reliable code, as surely you don’t want an unreliable network”. To that I would add “especially at the costs charged for licensing the hell out of everything”.  The sticker mentions CODE + the 9000 Catalyst Series, and perhaps sends the message that it’s a new day for reliability? On that topic, the CODE in this case is IOS-XE, which displaces AireOS as what powers the Cisco line of wireless controllers. I do hear often that “IOS-XE has been out a long time so it has to be solid by now” kinda talk.

I’m not sure I buy into that, but am hopeful. If I’m a little skeptical, it’s because IOS-XE packaged as a wireless controller brain is a new paradigm, despite the maturity of the OS. And… despite many, many mea culpa  sessions in private with Cisco’s wireless business unit through the years over wireless code quality, I have yet to see any sort of public-facing commitment to not repeat the development sins of the past as the new magic seeks to gain traction. This bothers me, in that I don’t know that the background culture that allowed so many problems with the old stuff isn’t being carried over into the new. My problem, I know. But I’m guessing I’m not alone with this feeling.

The other thing thing that this sticker has me thinking about is this: if  the network is code, why do I need controller hardware? Yes, I know that the 9800 WLC can run in VM- but VM instances ultimately run on hardware. As a big Cisco customer with thousands of 802.11ac access points that run the latest AP operating system, I would love to be totally out of the controller business (and all the various management servers needed) WHILE KEEPING MY INSTALLED ACCESS POINTS. If the network is code, maybe let me point these things at my Meraki cloud and simplify life?

I’m just one man, with opinions. But that sticker did get me thinking…

 

Code, Heal Thyself: Mist Systems Brings Something Badly Needed to WLAN Market

If you do any profession long enough, you’ll experience all sorts off good and bad along the way. For me, “good” has been the honor of providing reliable Wi-Fi to hundreds of thousands of client devices through the years, and “bad” has been fending off downtime and damage to organizational reputation when code bugs hit. Why focus on code bugs? To me, they are the one huge factor in WLAN system operation that we as wireless professionals can’t control. We can get everything else right from RF environmental design to RADIUS server capacity to onboarding clients, but we can’t defend against what evil lurks in the lines of code that runs the system hardware. Nor should we have to- that’s where we expect vendors to hold up their end of the deal on hardware and software that ain’t getting any cheaper.

Oh, how I have bitched and whined and complained about code bugs through the years. There was “The Horrible Bags We Hold For WLAN Vendors“. And “Code Suck Regulation: Should We Sue Vendors For Major Code Bugs?” I got a bunch of them… and it’s not just me. One of my favorite people, Jake Snyder, laid down a really good video lament on the topic. No one can forget my own video from the Wireless LAN Professional Conference in 2017 where I detailed real-world impact of code bugs. It’s a real thing, ya’ll.

I titled one post on the topic “Will Reliability Be Prioritized Before Wi-Fi’s Whiz-bang Future Gets Here?” (a house built on suck cannot stand).  This one jumped to mind yesterday as I sat in a Juniper Networks conference room in San Jose and heard Mist Systems talk about reliability. What I heard was refreshing.

Mist CTO Bob Friday and his crew presenting at Mobility Field Day 4 detailed how the company’s AI does all kinds of things- but among the most important is finding it’s own system anomalies. The gravity of the point is fairly significant, as one vendor after another wants to put a dashboard in front of you that calls out anything and everything as a wireless problem for you to chase after, but none that I know of will raise their hand and admit “OK- I’m actually the problem here… me, the system. I screwed up… I’ll fix me so we can all move on. Beg your pardon…” But now Mist is promising that, and it’s huge.

CTO Friday not only called out this capability, but was kind enough to give me a shout out for my years of crying like a school girl about code bugs, which was thoughtful.

IMG_3558.jpg

Well done, Mist Systems! There was a hell of a lot more to the presentation- and in the couple of hours I listened, I was impressed that Mist has managed to boil the hype off the concept of AI and actually did a decent job of explaining real-world, practical applications and benefits. There are several videos from the session, and they are worth watching.

More about Mobility Field Day 4 here.

 

Say Hello to NetAlly- a New Old Friend

When it comes to wireless tools, there are some products that are just beloved by most of us in the trenches. When conversation turns to WLAN verification and characterization,  the AirCheck G2 comes up pretty quickly. I’ve written about it on occasion myself, like here.  My friend Sam Clements has also covered it, and the Air Check G2 and other related products were featured prominently at last year’s Mobility Field Day 3, under the NetScout banner. The G2 and it’s related products are easy to appreciate, and get their fair share of coverage, as it should be.

But things change in San Jose.

The AirCheck G2 and select other NetScout tools and software have spun off into their own new company, called NetAlly. The press release can be found here, and the new NetAlly product family includes all of these from NetScout:

So… some tools we know and love have a new logo… big deal, right? It actually is, as NetAlly’s focus on a smaller product set (handhelds/laptop software) should bode well for product development and updates.

Speaking of which-  the new company will be presenting at Mobility Field Day 4, which can only mean new magic will be revealed. I’ll be watching it first hand, on site as company reps do their announcements. More information on that session, with eventual video  of the live streamed event, can be found at this Mobility Field Day page.

Given that the G2 products have a huge following (and many of us are waiting for AirMagnet to get new development before we pay for ongoing support), this will absolutely be worth following.

Ally

What I Hope I Don’t Hear at Mobility Field Day 4

With another Mobility Field Day 4 coming up soon, I can’t help but ponder what this year’s briefings will bring. (If you’re not familiar with Mobility Field Day or the Field Day franchise, have a look here.) As I bang this blog out, the agenda features:

  • Aruba
  • Cisco
  • Fortinet
  • Metageek
  • Mist
  • …and a secret company you’ll all find out about during the event

This list may or may not grow a little, we never know right up until the last minute. As is, it’s a nice mix of old-guard industry leaders, up-and-comers, crowd favorites, and tool-makers. The event is gonna sizzle as each vendor attempts to show their newest offerings and best face, and I’m both proud and priveleged to be in attendance.

That being said- As a loooong-time Wireless Doer and frequent delegate for Field Day events, I’d like to share some of what I sincerely hope I DO NOT see and hear at this awesome event. This is a voice from the trenches speaking…

  • AI and Machine Learning as THE THING. Given the line-up of pesenting vendors, I promise that you’ll get intoxicated if you take a drink everytime you hear “AI” or “machine learning” during MFD4. I’m all for letting the world know that these processes are at work under the hood- but companies also have a way of overselling buzzwords. Just because a vendor has incorporated artifical intelligence, machine learning, SDeverything, analytics, etc, it doesn’t mean the product won’t ultimately be problematic. There needs to be more to the presentation than “AND WE FREAKIN’ USE AI- NOW CUT US A P.O.!”
  • Over-Licensed Proprietary Features Masked as Innovation. Vendors have the right to charge whatever they want, and some have certainly turned complex licensing paradigms into huge cash cows.

    Hear me now vendors: license away- but know that fair play counts. And some of you have lost your sense of fair play in favor of squeezing every rediculous cent out of long-time loyal customers with obscene, over-complicated license paradigms that are poorly disguised as “innovative”.  You can show us the most useful and revolutionary features in the world, but when even your own sales folk get tripped up in the complexity of licensing, the aftertaste is not worth using the feauture set.

  • BMW Pricing for Ford Fiesta Feature Sets.  If it’s buggy, incomplete, “coming in Q1 next year”, bundled with a slew of other functions we really don’t want, or implemented with an out-of-touch developer’s view on wireless, it is not worth a premium. Back to the fair play thing- roadmap feautures are fine. But don’t charge me today for what I can’t use for 6-12 months. Or expect customers to be thrilled to pay for a laundry list of features they don’t need to create the illusion of some kind of wonderful deal is at hand. Be San Jose and let your merits carry you, and not Detroit- I’d rather have another vascetomy than visit a car dealership.
  • A New House Made of Crap is Still a House Made of Crap. There are product sets on the market that are long in the tooth and perpetually problematic and buggy. The delegates in the rooms at MFD4 will be all too familiar with hidden TCO that comes with lack of QA and rushed-out-the-door code and hardware. I sincerely hope that we don’t hear about “new” anything being added to product sets that need to be sunsetted for everyone’s benefit. In this spirit I would also like to hear honest explanations about how whatever new stuff is coming is developed with higher QA standards than in the past applied. It’s fun seeing RF test facilities and such, but the radios usually aren’t the issue- it’s substandard code that runs the radios. It’s hard to get excited about new features added to old problems.
  • Dahboard Fever. Marketing departments love to wow us: “each of your network users will have 87 IoT devices on them by next year- YoUR NETWORK IS NOT READY”. Besides baseless huge numbers and predictions of overwhelm, another trick is the accross-the-board generalizations that we all have deep, deep problems that only one more dashboard can solve. So what if you have more dashboards now than you can monitor- this next one is THE fix, and will scrape all of the dumb off your ass to bring clarity at long last. Pffft.

You’ll notice that my little list here really doesn’t just apply to Mobility Field Day. To me, it’s just common sense narrative that applies to vendor relationships day in and day out. But I also know that too often product managers and C-levels have a distorted view of how wonderful their stuff is, and hopefully Field Day gets us a little closer to honest, direct dialogue with those vendor bigs who may only get filtered feedback.

There is a lot to get excited about right now out there in WLAN Industryland… 802.11ax, WPA3, 5Gish stuff, new operating systems, fresh analysis resources, and a slew of technologies all ready to propel our networks and the industry forward. But it has to be based in reality, attainable, affordable, and implemented with STABILITY for end users in mind.

See you at Field Day.

___

Note: on Twitter, follow @TechFieldDay and #MFD4 for this event, August 14-16

Mojo (Arista) Answers The Layer 2 Situation for WLAN Migration To Cloud

I recently wrote about the challenges, as I see them, with the Layer 2 aspects of moving from an established controller-based WLAN solution to one like Aerohive, Meraki, Mist, or Ubiquiti that is managed in the cloud. That article is here, at IT Toolbox.

Want the short version of The Layer 2 Situation? Being all about value, I can help you out… Let’s start with the simple view of VLANs that underpin a controller-based WLAN environment:

L2-1

Betwixt the switch and the AP you have a single VLAN. It’s simple, it’s clean. It’s not a spanning tree asspain. But cut into that single VLAN with your magic network knife, and you’ll find a CAPWAP tunnel with as many VLANs as you need. In large environments, that may be dozens o’ VLANs for various SSIDs scattered across thousands of APs.

Contrast that with the typical fat AP/cloud AP VLAN underlay:
L2-2

Ugh- see the difference? In those large WLAN environments- where thousands of APs equals hundreds of switches- you might have to configure thousands and thousands of switch interfaces to convert the simple CAPWAP-oriented LAN to the VLAN-heavy LAN needed by fatty-fat APs- AND most cloud APs.

Ugh.

Mojo evidently agrees with that ugh and offers an option that preserves the goodness of the cloud approach (No NMS to keep up, easier code upgrades, no buggy controllers to babysit, etc) while providing an easy way to NOT go down VLAN rabbit holes when converting from controller to cloud. This magical hybrid approach features the Multiservice Platform:

multiservice_platform_3

Tres sexy, no? I had heard about Mojo’s Multiservice Platform last year at Mobility Field Day 2, but will admit I lost some of the messaging in the din of all the “Cognitive blah blah blah”. But when I recently wrote about The Layer 2 Situation, two good citizens from WLAN land came forward and reminded me that this nut has indeed been cracked, and by Mojo.

Recall if you will- Mojo has been acquired by Arista Networks since Mobility Field Day 2. I also happened to be present at the Mojorista MFD3 presentation, which I wrote about here.

So… will Arista continue with the Multiservice Platform? I have to say that I really hope so. I hope they promote the heck out of it, and that other cloud Wi-Fi vendors follow suite. I don’t know whether I’ll ever run a massive cloud AP WLAN (I do currently run a massive controller-based Wi-Fi network and a lot of cloud-based branches), but if I do it’s nice to know that there is at least hope for The Layer 2 Situation.

Catching Up With NETSCOUT at MFD3, Big News, and “Body Fade” Explained

Touching Base at Mobility Field Day 3

Everybody’s favorite handheld network tool tester provided updates on their G2 and AirMagnet tools at Mobility Field Day 3. NETSCOUT hosted those of us in attendance at their San Jose office, while simultaneously live-streaming to a lot of interested folks out on the interwebs. We heard about product evolutions coming to the AirCheck G2, the LinkRunner G2, the very handy Link-Live web service, and a little bit on the AirMagnet product line. The G2 improvements are incremental, well-designed, and show that NETSCOUT is not letting grass grow under it’s flagship testers. The AirMagnet brief sounded a bit apologist and fairly thin, but also not unexpected given that the line has gone almost stagnant for long periods of time.

You can watch the presentations for yourself here.

Big News

This one took us by surprise… It’s a bit weird to find out only a couple of days after being at Netscout’s offices that the very product line we were discussing has been sold off to Nacho Libre… or is it StoneCalibre? Whatever… it just feels funky to those of us who know and love our AirCheck and LinkRunner products.  What goes in this move?

  • LinkSprinter
  • LinkRunner (AT & G2)
  • AirCheck
  • OneTouch AT
  • AirMagnet Mobile (Spectrum, Survey, Planner, Wi-Fi analyzer)

Hopefully whoever this new backer is does not mess with all that’s good in the toolbox, and either breathes new life into AirMagnet or retires it. Read about the acquisition here.

Netscout HQ

What the Heck is Body Fade?

bodyfade

During the MFD sessions, we heard about several improvements- including refinements to the AirCheck G2’s Locator Tool. I tweeted out my recent success with the tool, and suggested that anyone using become familiar with “body fade” as technique to make the locator tool even more effective.

A couple of folks gave a thumbs-up, retweet, or similar affirmation, but one fellow emailed me to ask “what are you talking about with body fade?”  Let’s talk about that just a little, using a real-world case from my adventures in G2 Land.

The notion of body fade comes into play in any situation where you have a hand-held receiver in your hand (like the AirCheck G2 or a small ham radio with a bandscope display) and are trying to locate the origin of a signal of interest. By putting my body- including my rock-hard abs- between the signal and the tester, you can make the signal strength drop enough to notice. That means that the signal is somewhere behind you… do this enough times, and you get a really good sense of where to go look for the device faster than just running around staring at the dancing signal needle.

In my example, we see this rascally rogue running rebellious somewhere in another part of my building:
locate5By golly, that’s not one of mine. We gotta find the interloper and teach him or her some manners, I tellya. I fire up the AirCheck G2, invoke the locate option, and see what I see in my office.
Locate4
Not so impressive yet. We have a fairly weak signal somewhere. But how to get started on this foxhunt? BODY FADE to the rescue. I hold the G2 in front of my Adonis-like physique and slowly turn (the slowly part is important)… until I see a 3-4 dBm DROP in signal strength. This is my body inducing loss to the signal and thus showing you where to turn around and what direction to walk towards…

OK… so I start walking, and I’m making progress. The signal is getting stronger, and I use body fade to help further refine my path. But alas- I hit an obstacle! Once I get to THIS signal strength, I’m bamboozled:

Locate 3Nothing I can do from the spot of this reading with body fade changes the signal strength at all. If I walk away from the spot in any direction, the signal drops, but it is strong in this one spot. Yet the rogue is absolutely not there (in a hallway). What gives?

Remember that we’re dealing with signaling in three dimensions. When body fade at X-marks-the-spot yields no changes in signal strength, it means it’s time to go upstairs or down. In my case, there is no downstairs, so up I went. I picked up the trail, and soon hit the jackpot:
locate2
This was screen-shotted in the doorway of the office where the offending device was found. After roughing up both the rogue router and the gent who dared to plug it in, balance was restored to The Force.

Body fade is pivotal to some really neat radio hobbies- like this one.

 

 

 

 

Figuring Out What Bothers Me About Wi-Fi and “Analytics”

I’ve been to the well, my friends. And I have drank the water. 

I was most fortunate in being a participant in the by-invitation Mobility Field Day 3 event, this past week. Few events get you this close to so many primary WLAN industry companies and their technical big-guns, on such an intimate level and on their own turf. For months leading up to MFD3, something  has been bothering me about the discreet topic of “analytics” as collectively presented by the industry- but I haven’t been able to nail down my unease until this past week.

And with the help of an email I received on the trip back east after Mobility Field Day was over.

Email Subject Line: fixing the wifi sucks problem

That was the subject in the email, sent by an employee of one of the companies that presented on their analytics solution at MFD3 (Nyansa, Cisco, Aruba Networks, Fortinet, and Mist Systems all presented on their own analytics platforms). The sender of this email knew enough about me to do a little ego stroking, but not enough to know that only a matter of hours earlier I was interacting with his company’s top folks, or that I’ve already had an extensive eval with the product he’s pitching at my own site. No matter… a polite “no thanks” and I was on my way. But his email did ring a bell in my brain, and for that I owe this person a thank you.

The subject line in that email set several dominoes of realization falling for me. For example-  at least some in the WLAN industry are working hard to plant seeds in our minds that “your WLAN sucks. You NEED us.” Once that hook is set, their work in pushing the fruits of their labor gets easier. The problem is, all of our networks don’t suck. Why? These are just some of the reasons:

  • Many of our wireless networks are well-designed by trained professionals
  • Those trained professionals often have a lot of experience, and wide-ranging portfolios of successful examples of their work
  • Many of our WLAN environments are well-instrumented with vendor-provided NMS systems, monitoring systems like Solar Winds and AKIPS, and log everything under the sun to syslog power-houses like Splunk
  • We often have strong operational policies that help keep wireless operations humming right
  • We use a wealth of metrics to monitor client satisfaction (and dis-satisfaction)

To put it another way: we’re not all just bumbling along like chuckleheads waiting for some Analytics Wizard in a Can to come along and scrape the dumbness off of our asses.

In all fairness, that’s not a global message that ALL vendors are conveying.  But it does make you do a double-take when you consider that a whole bunch of data science has gone into popping up a window that identifies a client that likely needs a driver update, when those of us who have been around awhile know how to identify a client that needs a driver update by alternate means.  Sure, “analytics” does a lot more, but it all comes as a trade-off (I’ll get into that in a minute) and can still leave you short on your biggest issues.

Like in my world, where the SINGLE BIGGEST problem since 2006, hands-down and frequently catastrophic, has been the buggy nature of my WLAN vendor’s code. Yet this vendor’s new analytics do nothing to identify when one of it’s own bugs has come to call. That intelligence would be a lot more useful than some of the other stuff “analytics” wants to show.

Trade-Offs Aplenty

I’m probably too deep into this article to say “I’m really not trying to be negative…” but I’ll hazard that offering anyways. Sitting in the conference rooms of Silicon Valley and hearing from many of the industry’s finest Analytics product’s management teams is impressive and its obvious that each believes passionately in their solutions. I’m not panning concepts like AI, machine learning, data mining, etc as being un-useful as I’d be an idiot to do so. But there is a lot of nuance to the whole paradigm to consider:

  • Money spent on analytics solutions is money diverted from elsewhere in the budget
  • Another information-rich dashboard to pour through takes time away from other taskings
  • Much of the information presented won’t be actionable, and you likely could have found it in tools you already have (depending on what tools you have)
  • Unlike RADIUS/NAC, DHCP/DNS, and other critical services, you don’t NEED Analytics. If you are so bad off that you do, you may want to audit who is doing your network and how

Despite being a bit on the pissy side here, I actually believe that any of the Analytics systems I saw this week could bring value to environments where they are used, in an “accessory” role.  My main concerns:

  • Price and recurrent revenue models for something that is essentially an accessory
  • How well these platforms scale in large, complicated environments
  • False alarms, excessive notifications for non-actionable events and factors
  • Being marketed at helpdesk environments where Tier 1 support staff have zero clue how to digest the alerts and everything becomes yet another frivolous trouble ticket
  •  That a vendor may re-tool their overall WLAN product line and architecture so that Analytics is no longer an accessory but a mandatory part of operations- at a fat price
  • Dollars spent on big analytics solutions might be better allocated to network design skills,  beefy syslog environments, or to writing RFPs to replace your current WLAN pain points once and for all
  • If 3rd party analytics have a place in an industry where each WLAN vendor is developing their own

If all of that could be reconciled to my liking, much of my skepticism would boil off. I will say after this last week at MFD3, both Aruba and Fortinet did a good job of conveying that analytics plays a support role, and that it’s not the spotlight technology in a network environment.

Have a look for yourself at Arista,  Aruba, Cisco, Fortinet, Mist and Nyansa telling their analytics stories, linked to from the MFD3 website.

Thanks for reading.