Tag Archives: Cisco

How Does Ekahau ESS Stay Current For APs and Antennas?

EkahauSo I’m sitting on a bench at the mall, and this guy plops down on the other end. I can hear him sobbing a little. I’m thinking “poor bastard, must be a death in the family, or his wife split…” But then I hear his kid about 10 feet away say to a pal “my dad is a complete loser- he doesn’t even know how the world’s best Wi-Fi survey and planning tool gets updated for new APs and antennas!”

Then it hit me like a ton of bricks: I really don’t know how it happens, either. I’m a loser too!

But there’s a big difference between me and Sobby Bench Guy. He’s not a gonzo bloggist with a license to ask the tough questions. That’s my turf, and that’s just what I did to get my mind right on the topic. I put on my Interrogator Fez and went gunning for everyone’s favorite European guy, Jussi Kiviniemi. Sure, he’s Ekahau’s VP of Wi-Fi Tools, but I don’t mind running in those circles now and then. I grilled Dr. J pretty good, and he gave me what I was looking for. Read on.

Q. How long does it take to get a new WLAN AP or antenna added to ESS, once Ekahau
has the technical information?
Jussi: Depending on load & urgency, it takes 1 day to 3 weeks to get it done. It’ll be published in next sw release (sw updates about every 2 months).

Q. Does Ekahau have a strategy for retiring old APs or antennas from the software
Jussi: Good question. Not really. Happens organically through Wi-Fi vendor acquisitions. We actually should probably take out the 802.11b stuff if we haven’t already 😉

Q.  How does Ekahau find out about new APs/antennas from the major vendors?
Jussi: It varies. Today, they often send the new or upcoming stuff proactively. That’s good for their business too. If not, we ask. Often customers ask us, then we ask the vendor. 

Q.  Why is it advantageous for vendors to get their stuff into ESS?
Jussi: A lot of their partners use our tool (we are tool of choice for Cisco, Aruba, Aerohive,…). And they often want to design using the actual stuff as it is more accurate. 

Q.  What’s the oddest antenna you’ve seen in ESS?
Jussi: At first, the Xirrus arrays were different. I wish we had the planner already back in the Vivato days, that would have been interesting. Also, the Ventev floor mount stuff is refreshing. 

Q.  Any other thoughts on the topic of adding products to ESS?
Jussi: I highly encourage the public and vendors to contact us to tell us which APs or antennas they are missing. It’s a free service to add them. Twitter, web site form or wifidesign@ekahau.com all work. 

We also add things like multi-SSID MAC combining as one radio, and multiple radios into one physical AP.  This requires specs from vendors too. 

And there you have it. Just a little behind-the-scenes information on how a great tool stays fresh. I’ll echo Jussi’s last point: if you see something missing, give Ekahau a shout to get the program updated. ESS is huge tool in the WLAN industry’s toolbox, so keeping it current is a win for everyone.

Additional Resources:

 

A WLAN Doer Contemplates the Cisco/Apple Partnership

I’ve been in the wireless game with Cisco products since long before thin was in. These days, I support many thousands of access points and tens of thousands of Wi-Fi clients on those APs. At least half of those client devices are Apple products, and in some spaces in my environment, as many as 85% of all clients are Apple. Obviously, I hope for the best of outcomes from the new Cisco and Apple partnership, as my customers would benefit from those positive outcomes. There’s no meanness intended in what follows, just reflection on days past and what I hope comes of these two market leaders becoming more collaborative.

Code Counts as Much as Hardware

Cisco and Apple both put out beautiful hardware with premium price tags. Many purists who worship either or both companies have a hard time believing that anything defective could come in hardware that is so robustly built, pretty, and expensive. If my iDevice isn’t working, your network MUST be to blame. And if my WLAN is acting up, it must have been designed wrong because Cisco code isn’t cheap… and it comes from the market leader, by golly. Both Cisco and Apple are at the top of their games as measured by volume of devices in many large and small WLAN environments. And both frequently, too often, put out mediocre (or horrible) code that leaves people like me holding a bag full of smelly network pain.

In Cisco’s case, their WLAN controller code is just short of being chronically buggy, and a culture of “get it out the door and let our customers QA it!” seems to rule the product line. (Greg Ferro sums it up nicely in the opening paragraph of this article.) It’s not uncommon to spend days on the phone with TAC only to find out that randomly rebooting controllers or some oddball client behavior is actually a known bug.

For Apple, you never know what you’re going to get related to Wi-Fi behavior with OS and iOS upgrades and patches. Release notes are scant, and it seems that the Wi-Fi area of Apple devices is always being tinkered with back on the mothership. From a history of sticky-client behavior to curve-balls in how you are “allowed” to configure profiles to decidedly non-enterprise quality gimmicks like Bonjour, it has been an interesting ride administering business networks that have lots of Apple wireless clients on them. (This is not just me ranting, the Apple support forums are chock full of frustrations with Wi-Fi client behavior through the years.)

Features? What About Standards (and stability)?

Cisco networks also have to support a lot of non-Apple client devices. Making Apple’s consumer-centric AirPlay/Bonjour feature sets work in large business enterprises can be a nightmare. And though Cisco (and other vendors that do similar) mean well with mechanisms like band-steering and load balancing across APs, these enhancements cause their share of problems in the Wild West of widely varying client types found on big WLAN networks. It would be nice to see more focus on standards-based interoperability and feature sets rather than vendor-proprietary juju.

Looking Forward

I used to marvel a bit at Apple’s mastery of talking out of both sides of their corporate mouth when it came to their place under the network sun. Sometimes they were unequivocally not an Enterprise company, and sometimes they were. It seemed to depend on the audience, and how well their unyielding way of doing things fit into the general networking landscape where they were trying to gain specific market share. Now, with the Cisco alliance in play, Apple is emphatically stating that they are an Enterprise player. Hopefully, the company gives strong consideration to what that means to all of the users who love Apple gear but get frustrated because too much of the “Living Room, Single Class C Subnet Network” mentality is in play.

From the Cisco side, ideally my Wi-Fi vendor won’t skew their already frequently-frustrating code too far in the Apple direction at the expense of the rest of the client devices that have no use for Apple-specific features. Also ideally, Cisco would also find a way to end the code bug madness before it starts tweaking WLCs to do magic things for iDevices, lest bugs beget bugs.

This could be absolutely wonderful for environments like mine, or it could just be more of the same- but disappointingly amplified. I’m crossing fingers that both companies get it right…

In Cisco Prime Infrastructure, Let the Picture Tell a Radio Story

Say what you will about PI (and I say plenty, sometimes under my breath), there is a lot packed into this Network Management System. One of my favorite features for remotely characterizing how individual APs see each other may not be so obvious, so a quick show and tell is provided here.

The goal? Let me:

  • see a floorplan with APs on it
  • ask any one of those APs how it sees it’s neighbors from the radio perspective as they are all mounted
  • show me one band at a time
  • show me signal strengths of APs on the same floorplan, and NOT on the same floorplan

And as a bonus- show me a slew of radio specific data for any AP’s individual radios.

Before the run-through, a quick note on when I use this functionality… In areas where RRM is allowed to do it’s thing, this is a handy way to let the radios themselves tell you how they see their places in the RF world in relation to each other. Where RRM is over-ridden for whatever reason, this becomes one more sanity-check data point on whether you got the intra-AP power settings right. What this does NOT do- does not show you the system from client device perspective, and so is only part of the bigger picture. But is a handy one at that…

Got it? Then here we go.

  1. Monitor\Site Maps\specific building\specific floor

    Wash 1

  2. Select an AP, drill into one of it’s radios

    Wash 2

  3. Notice the radio details in table form. Good stuff, sure… now click into “View RX Neighbors”

    Wash 3

  4. The example AP is on 5th floor. It sees one other AP on the same floor, and two more from the floor below, at discreet strengths. You get a sense of propagation with this simple view through walls and floors if you know the power levels in play. Again, is one more place to gain a useful data point or two in complicated environments that gets beyond just heatmap juju.

    Wash 4

  5. Then there’s the click into all of the radio data available for a given interface

    Wash 5

  6. And behold- all of the RF stuff you might need for troubleshooting, contemplating RF changes, etc. (Yes, this info can also be accessed from Monitor AP path).

    Wash 6 Wash 8

Nothing earth-shaking here, but I’ve met enough fellow PI users that are either new to the platform or who just didn’t know about these features that sharing seemed prudent.

Thanks for reading!

It’s the Little Things… Hey Cisco Wireless!

When an administrative account is used to access a Cisco wireless controller, one of two things have happened. Either a legitimate admin has logged in to do config work or to view settings or whatever, or someone has gotten hold of an admin credential and your organization has bigger problems than simply protecting the pre-share key on PSK Wi-FI networks.

My question for Cisco: why can’t paying customers with proper admin credentials see their own PSK keys? Whatever “protection” is in play here is far outweighed by the nuisance of not being able to visually verify or recall what these keys are, says I.

No PSK show

You’ll notice there is no toggle to show the key. You either write it down somewhere, or do a lot of re-creating PSKs if the entered value gets lost. Sounds like maybe no big deal? I disagree. Given the dumbing down of client devices in the name of IoT and BYOD, PSK networks aren’t going away anytime soon and WLAN is only getting more popular. For some customers, hundreds of PSK networks are in play, so it can be a very big deal.

It’s time for Cisco to trust us to see our own PSK strings (and no, they don’t show in CLI, either) and to not worry that bogeymen might be standing behind us waiting to write these down.

I can’t recall another UI that doesn’t let you see the PSK. Here’s Meraki:

Meraki PSK

Whatta ya say, Cisco? Can we please get a view to our own PSK strings? Can we? 

Or am I off-base here? Please comment- and thanks for stopping by.

Beacon Baby Steps

As I put this blog together, I do so knowing that I risk the ridicule of those who have gotten a lot farther in both understanding beacons and using them for some real-world value proposition. Though I understand transmitters of all types very well and I’ve covered other beacon-related initiatives (like Aerohive’s integration of beacons in APs ) and done my share of reading on how beacons are gaining in popularity as building blocks in a number of applications, I’ll admit to really not “getting” them yet to any technical depth. But that is starting to change, as I’ll tell you about here. And as an added bonus to you, I get to drop a few names of really smart people that I have the privilege of interacting with on occasion.

Free Beacons!

Awhile back, Ryan Adzima turned me on to a beacon giveaway that netted me three of these. Not being one to pass up free cool stuff , I got my beacons- and they ended up sitting on a shelf almost a year (I basically didn’t know what the hell to do with them.)

Fast Forward- Renewed Interest

I follow a lot of industry goings on as a freelance analyst. It’s no secret that Location-Based Services/Analytics is a running topic du jour in the tech media, and many a WLAN vendor has announced their own beacon story- like Aruba and Cisco’s Meraki. Knowing that there’s a lot of buzz around beacons, I worked them into my daily Twitter #WIFIQ question on June 4. The conversation that ensued reminded me that I was overdue to play with my Qualcomm beacons.

What sparked me to get back on the path that Ryan Adzima started me down was conversation with AccessAgility’s Zaib Kaleem and Extreme Networks’ Mike Leibovitz. Zaib turned me on to some beacon-related apps, and Mike triggered my interest on proximity to beacons being used as one component in banking authentication. Newly energized (see what I did there?), I busted out my Qualcomm Gimbals and got busy gettin’ busy.

Time to Play

Laying hands on my three neglected Gimbals first brought back the clueless feeling I had when I first looked at them and put them on the shelf. But this time I wasn’t content to stay in the dark. I took the bold step of cracking each one open and getting the watch battery connected, then I found the Gimbal Management App in the Apple app store.

At first, the App couldn’t see my beacons! Gotta be dead batteries, I thought… but then I went to the Gimbal Manager site, recovered my long-forgotten password, and figured out that I needed to activate each beacon.Gimbal

I also needed to configure each and upgrade firmware, which was quite easy. (We’ll come back to the “configure” thing.) Bingo! They showed up in the iPhone app.beacons

At this point, I realized/reminded myself of a few basic important facts:

  • Until the beacons were added to my account online, they were dead to me despite being powered up. (Private is default, you can make them “public” so anyone can see them, btw.)
  • My online account and my iOS account are synced for beacon management.
  • The beacons report their battery strength and the ambient temperature, and the mobile app tells how strong each beacon is being received
  • Though I now have three live beacons that can be managed, I still don’t know what to really do with them… no use case, no business application to hook them to, etc.

Knowing that beacons are all about proximity and location, I embarked on a simple exercise. Down a long hallway with three pictures hanging on the wall, I put one beacon on each picture frame, then watched my app show signal strength for each as I walked the hall.hall

This seemed like a reasonable way to see what might go on behind the scenes at the signal level on a walking tour, or in a retail environment where different app events are triggered by a customer coming close to a beacon. Here, this is the view as I transitioned from Beacon 1 and got close to Beacon 2, with Beacon 3 at farthest point down the hall.
.beacons1

Big deal, right? To me, it is. That’s because yesterday, I had ZERO first-hand working knowledge of beacons. With this these simple steps, I now get the technology and how it’s managed at a very, very basic level. I feel like I get the foundation, and I do understand many of the big use cases for beacons. It’s that middle ground of real-world implementation that I have yet to learn. Baby steps…

Back to the beacon config thing. For such a simple device, there are infinite permutations for what you can do with them. I think this is what is so hard to wrap your head around, especially given that along the line you may have to do some coding (or steal somebody else’s code). Zooming in on the menu gives a sense of just how many directions you might go bringing beacon-based use cases to life:
beacon menu

So… I now know a little, and know that I still don’t understand really USING beacons despite understanding the scenarios where they are employed. But with what little I now have touched and brought to life, I do understand links like this and this a bit better. Still a long way to go though, but ya gotta start somewhere!

In Appreciation of White Box Guest Access

“Guest Access” means different things to different people, and organizations. Certainly if you’re a traveler using hotel or conference Wi-Fi, you have a general set of expectations and desires. If you’re a company or a school, the guest wireless service you provide is likely shaped by organizational policy. And for many of us, the guest environment also tends to act a s a catch-all for client devices that don’t fit on our secure WLANs- a place for “free passes” and MAC exceptions. But the devil is in the details, and I have found finding the right guest access feature set can be difficult.

What you WANT may not be what you can HAVE

Having designed a number of guest environments for large and small networks, I’m always astounded to engage a WLAN vendor on the topic and to find how far their guest offering is from what I’m looking for (more on that in a bit). Worse, seldom do I hear “what are your requirements?” as it tends to be more like “this is what we think everyone should want and accept”.

Simplicity? Fat chance… 

Guest access can also have a lot of moving parts, depending on how it’s implemented. Overall functionality tends to be broken up and scattered across access points, controllers, RADIUS servers, credential stores, web servers, and sometimes switches. It all has to click, or you have problems. And for me, despite the typical complexity of guest services, I still find myself frustrated at features that are not included.

What worked for my environments

Years ago, for my big honkin’ 3,000 AP environment (and our small branches alike), we arrived at a desired feature set that went more or less like this:

  • Our guest SSID would equal a single dedicated guest VLAN
  • 24-hour individual self-sponsoring is a must
  • Alternatively, ANYONE authorized to use our wired or secure wireless network could sponsor a guest
  • For self-sponsoring, a ten-digit mobile number capable of accepting a text must be provided and within seconds a password would be sent
  • For large events, a shared account could be generated
  • All accounts were time limited with role-granularity
  • The system would have easily configurable firewall rules and (generous) rate limiting capabilities
  • On the admin side, we could add MAC exceptions and login-bypass
  • The system would provide NAT to preserve public IP addresses
  • Reporting would be easy, as would user quarantine (rarely used)
  • ALL OF THIS WOULD HAPPEN UNDER ONE HOOD-VIA A SINGLE INTERFACE
  • A programmer would not be needed to stitch it all together
  • Ideally, it would have vendor support (for a number of reasons, open source not desirable)

Going back those several years, our WLAN vendor (Cisco) didn’t come close to being able provide what we wanted. In their defense, nor did any other market leaders at the time. We heard that Colubris Networks had a gateway that might fit the bill, but they had just been bought by HP and try as we might, we couldn’t locate anyone that could talk with us about what we were looking for.

Then we found Bluesocket (now Adtran) and their BSC Controllers. When I first contacted Bluesocket, we came to the mutual realization that they could do about 75% of what I wanted. They weren’t really initially open to developing the self-sponsored texting and “anyone authorized can sponsor a guest” features. So… we thanked each other for our time, and I kept searching. Then a week or so later Bluesocket called back, and said they were game for a bit of development, and saw the value in what would become a feature set that they were able to market to others. They were able to do everything I was looking for in a single, kick-ass box in a matter of hours.

What Bluesocket was able to deliver after actually listening to our requirements has been in play for us for lots of years. We’ve served thousands and thousands of guests with it, along with using it as a mechanism for supporting wonky devices like Google Glass (turn head, spit) that weren’t built with enterprise security support, and so can’t be on the WLANs we’d rather they used.

It’s been absolutely great, and I know of at least three other schools that pursued the same guest access model after experiencing ours.

Looking forward

Our old Bluesocket boxes are getting, well… old. They are appliances, and Adtran seemingly has no desire to virtualize what we need into an OVA or the like. In fact, on newer Adtran wireless products, what we appreciate about the BSC has been moved to Adtran APs that we’ll never buy, so the research for a suitable replacement starts again.

The thing is, we absolutely love what we get out of our aging guest solution, and in a perfect world, I’ll find a similar third-party, one-box bolt-on for our big Cisco WLAN. (I will give Cisco another chance to catch me up on how their native guest access services have improved, but I also know that my requirements are firm). I have also inquired to Adtran one last time about the possibility of somehow preserving this wonderful magic, but the silence thus far is pretty telling.

Which brings me to Meraki. The features I need for my guest environment are pretty much included in the WLAN side of the Meraki product line, and we use it with great success in our Meraki-enabled branch sites. But… to bolt the Meraki capability up to my Cisco WLAN in a way that would replace Bluesocket, I’d need the guest features made available in the Meraki MX security appliances and not just in the AP feature set. I’m hoping to get Meraki’s ear on this anyway, because guest access needs also do tend to pop up on the wired side occasionally, too. Right now, wired guest needs are a gap in the MX.

If Meraki can accommodate, a big MX would snap in nicely where my Bluesocket sits now for guest access. If not, I’ll have to consider things like pfSense, Packetfence and other one-offs that I’d rather not get into after being happy with a commercial solution. Or, I’ll have to rethink our requirements, which would really suck, as they really are what we consider requirements, not just nice-to-haves.

There will obviously be more to follow to this evolution.  I am curious if anyone else is facing a similar situation, and how you might be approaching it.

(Please- I’d love your comments, just don’t blast me with pointless “you should switch to vendor X for your WLAN!” type feedback.) 

AirMagnet Changes It Up- With a WLAN Security Overlay

(OK, so it’s a Performance and Security overlay…)

I was an AirMagnet fan long before Fluke Networks bought them. I’m sure that I’m not alone in appreciating the long line of excellent tools that have come from AirMagnet, from the software-based utilities to the likes of AirCheck. But for some reason I was also a bit surprised to get wind of Air Magnet Enterprise as a big old’ overlay- think AirTight for security, and 7Signal for performance.

First Impressions, Having Never Tried It

For me, Enterprise is just different from all of the AirMagnet tools that you can hold in your hand. It gives me a bit of discomfort, because there’s yet another server or two to upkeep as part of the solution. There are sensors to deploy that have to be kept up in parallel with installed APs. There’s yet another system to learn, while you learn to ignore those same functions that are part of the system you probably already own… These mushy feelings of concern have nothing to do with Air Magnet, but rather they come from having well  over a decade of running and managing many small and very large WLANs and suffering pain, a la:

  • Managing a WLAN is a lot of work, managing the boxes that manage the WLAN can suck
  • When you make a significant investment in the likes of CleanAir (or anybody’s native equivalent) it’s hard to get a clear read on what yet one more system will do for you as a delta, and how that delta is worth the usually steep accompanying price
  • Dashboards full of rogues and interference sources that you often can’t do anything about (thousands of ’em sometimes) because you are located in an urban setting become visual noise that get ignored
  • Auto-containment sounds nice- until you lay waste to a network switch or an important client after putting faith in a tool that promises not to do the bad thing that it just did
  • Trying to figure out how your WLAN security posture might be so deficient with your own vendor’s native capabilities (that you spent big, big coin on) that you still need an expensive overlay is a miserable task

But I realize that these are MY issues. Again, no reflection on AirMagnet (or 7Signal, or AirTight).

What immediately looks nice with Air Magnet Enterprise:

  • Can be set set up in VM
  • Uses a mix of pretty sweet looking hardware sensors and software agents
  • Transactional stuff feels like it might be 7Signal-esque
  • Hardware sensors can do wireless backhaul where wiring is difficult/cost prohibitive (yes!!)
  • Full-time security scanning versus APs that only do that as a small percentage of their operational time
  • Scales well for large environments
  • It’s Air Magnet- which implies maturity of feature set and good design (to me, at least)

It’s hard to say much more about it without trying a tool like this. And if you’re busy or don’t feel obvious performance or security pain, it’s hard to make the time or case for something as involved as an Enterprise trial done right. At the same time, WLAN is the preferred mode of access for a growing number of complicated environments with PCI/HIPPA/etc. concerns that are also likely BYOD hornets’ nests that might be distributed over a number of sites that aren’t easily covered by limited IT staff- and so I can picture a client base (but it’s likely to be a small fraction of the number of WLAN environments that have bought other AirMagnet products).

Personally, I’d love to see a major WLAN vendor or two completely scrap their own performance/security suites and partner with specialists like Air Magnet or 7 Signal for that side of the total solution.