All about DART

Yes, I’m writing a blog post on a connector. Just a connector. If you’re like me, you can appreciate the little things in life. This is one of those times that something little snuck past me and it wasn’t until now that I’m starting to fully appreciate it’s impact and importance. When Cisco launched their 2800/3800 APs, dual 5GHz was certainly at the top of the list of the most talked about features (see #MFD session here!). This came with some caveats (as all new features do) and using a separate set of antennas for the second 5GHz radio was the biggest. This is handled on the internal antenna models with an in-built extra set of antennas, but on the external antenna models, this presented a bit of a challenge. In the wide world of antenna connectors, in the Wi-Fi space, we commonly deal with RP-SMA, RP-TNC, and N-type connectors depending on your vendor and the deployment type. In the Cisco world, that’s RP-TNC for indoor APs. With a single, 4 element antenna today, that’s four connectors (or four, single element antennas). With two antennas, that drives the number of antenna connectors up to a whopping 8 cables you’re looking to have coming out of your AP! 8 cables, 8 connectors, it gets messy quick. Enter the DART connector:

All covered up!

All covered up!

DART revealed!

Inconspicuously located on the side of the AP, behind a little door, the new DART connector reveals itself in a complex looking array of pins and connectors in a tight external facing form factor. Here’s the interesting part though, this isn’t a new connector! In fact, it’s been shipping to the public for a little bit now in the form of the Cisco Hyperlocation module and antenna!

Hyperlocation with DART

Hyperlocation with DART

DART on Hyperlocation Exposed!

DART on Hyperlocation Exposed!

So, that’s all great and all, but what’s really *in* the DART connector? DART stands for Digital Analog Radio Termination and it does all of those wonderful things. Firstly, the analog antenna connectors that we use (so we don’t have 8 RP-TNC ports on our AP) are the 4 larger pins across the bottom of the connector.

Look at all those pins!

Look at all those pins!

When we use the DART to RP-TNC pig tail for backwards compatibility with shipping antennas, these are the connectors that map directly to the 4 RP-TNC connectors. In short, these are the 4 analog ports that carry the actual analog signal through the connector.

DART to RP-TNC Cable!

DART to RP-TNC Cable!

Fully assembled!

Fully assembled!

For existing RP-TNC based antennas

For existing RP-TNC based antennas

On the cable end!

On the cable end!

Which leave us with the extra 16 pins. Those are the ‘Digital’ piece of the DART connector and can be used for a variety of uses. Initially, this is used to identify the type of cable that is attached to the DART connector. For example, in the Hyperlocation module, this shows up on the AP details:

Circular Antenna

Circular Antenna

For the DART to RP-TNC connector, this is in the form of a simple resistor that maps two of the pins back to each other:

DART disassembled

DART disassembled

It’s easy to see that there’s quite a bit of left over functionality that could be used in a connector of this type. Today if we use very high gain antennas we have to have multiple models of APs (see the 3602p and 3702p). If we could identify the gain of the antenna by way of an automated mechanism, we could have the AP auto adjust itself to not exceed EIRP. Another potential use case is DART native versions of our existing antennas in a simple to use connector. Imagine not having to screw on connectors anymore! With a quick-connect antenna mechanism that auto-IDs the antenna capabilities to the AP, this could certainly be the new connector of choice for external antennas in the future!

With DART connector on edge.

With DART connector on edge.

Note the DART connector on the left.

Note the DART connector on the left.

10 reasons to take another look at 2015 Cisco Mobility

Let’s face it, Cisco is huge. They’re massive, and occasionally they get things wrong. If you’ve strayed away from Cisco in the past year (or longer) because of a specific issue or gap, it’s high time you took another look. The Cisco Mobility offerings today are a far cry from what they were just an easy year back. Here are 10 great reasons to go get reacquainted with the 2015 Cisco Mobility offerings:

1) 5520/8540 WLCs

The introduction of a Converged Access 60G solution highlighted the gaps in the WLC portfolio in the 20/40G of throughput range. Both of these new controllers (one 20G, one 40G capable) are based on the more mature AireOS codebase running 8.1 and later. While this doesn’t mark an EOS/EOL announcement for the 5508 (clocking in at 8G), it does give that 7 year old platform some good alternatives for lifecycle management.

2) Prime Infrastructure 2.2 then 3.0

Ever since WCS was taken over and moulded into the NCS then Prime Infrastructure products, it’s always bore the scars of a legacy mired in Adobe Flash performance issues. Couple that with a dramatic uptick in features and you’ve got a recipe for disaster. The new versions of Prime Infrastructure are actually performing as well as they should be starting at about the 2.2 version and the new UI of Prime Infrastructure 3.0 completely moves away from Flash and demonstrates a significant re-think of the product – including ‘Make a wish!’.

3) 802.11ac wave 2

Let’s not forget the fun stuff – APs and radios. With competitively positioned 802.11ac Wave 2 products, Cisco is staying in the lead of the latest and greatest standards. With impressive throughput numbers, multiple gigabit uplinks, and fancy new features like MU-MIMO, the 1830/1850 APs are clearly paving the way for the next generation of some pretty obviously numbered future platforms. The only question is, what does Cisco have in store for us next?


No, not the game – the new Hyper-Location Module and antenna array. Cisco is delivering on the promise that the industry made to us oh so many years ago about leveraging your WiFi network as a platform for tracking your enterprises assets. Touting down to 1 meter accuracy, this module for your AP3600/AP3700s will take your location fidelity ‘to the next level’.

5) Mobility Express

Those that don’t like having a bare metal controller and don’t see the need for controller based features (such as centralized data plane), we now have a ‘controller on the AP’ option! This allows us to focus on the smaller deployments without the extra cost and complexity (such as it is) for those customers. This isn’t a ‘one size fits all’ approach that we’ve seen in the past, but rather an evolution of a well thought out strategy to bring enterprise features to every market segment.

6) UI improvements

Along with the Mobility Express product, the ‘metal WLCs’ are sporting a new user interface and out of the box setup experience (Day 0 and Day 1 support). If you’ve felt the WLC interface was a bit dated in the past, go take a gander at the plethora of new graphs, charts, and actual usable data about your infrastructure – all without having to goto a larger NMS platform!

7) CMX Evolution

The MSE product is finally getting some legs under the advanced location pieces. This easy to deploy ‘for everyone’ product starts to bring some pretty insightful analytics to any sized deployment – all the way down to a ‘no maps required’ presence analytics and all the way up to a Hyperlocation enabled, social media engagement platform. With both on premises and cloud based offerings available, it really is very easy to start getting very insightful data out of any sized network.

8) CCIE Wireless version 3

The dated CCIE (Cisco Certified Internetwork Expert, Wireless) exam has been updated to include software and hardware platforms from this year. You can now tackle one of the industries most challenging certifications on contemporary labs that are actually relevant to solutions you’re deploying today!

9) UX domain APs

See my previous blog on the topic for a more in-depth look at the UX products, but for those buying and deploying APs spanning multiple countries, this is a pretty good way to reduce a ton of deployment and ordering complexities. By standardizing on a single SKU globally, you can make quick work of some of the logistics nightmares of the past.

10) Cisco ONE licensing

Yes, licensing is boring, complicated, and expensive. Cisco ONE addresses all three of those pain points in one easy go. With a ‘count the AP’ approach to licensing, you can now start to take advantage of all of the above products in an easy to consume, deploy, and license fashion – without breaking the bank. For example, if you wanted to replace your old WLC with a new one, in the past, you would end up repurchasing your AP licenses. In this model, all products start at 0 APs and you pick the size that’s right for you – at any scale. Pick the solutions you want to deploy: ISE, Prime Infrastructure, advanced location analytics, etc – and go! A significant departure from the traditional licensing model in Cisco-land.

I know that a ‘recap overview’ blog sometimes seems too lofty, but there really is a ton to see if you’ve been unplugged from the Cisco world over the past year or so. Take a deep breath and plunge back in at any level and you’ll find something new that wasn’t there before. The Cisco ship sometimes turns slowly and sometimes it’s easy to forget that there is innovation happening all over the mobility space in San Jose.

Disclaimer: I was part of the Wireless Field Day 8 delegation to Cisco where we learned about several of the above topics. For more information on Cisco’s appearance at WFD8, go check out the video!

The evolution that will start the revolution

You’ve heard it all before, evolutionary technology versus revolutionary technology. Everyone wants their newest technology to be revolutionary – expecting it to be life changing and a wide-sweeping, compelling reason to spend tons of money. This is rarely the case and more often than not marketing fluff to try and get you onto the next big thing. Occasionally we get such an unassuming technology announcement that fits squarely in the ‘no big deal’ from a speeds and feeds perspective that it’s easy to overlook. This is clearly the case with the recent multigigabit announcements from Cisco during Cisco Live, Milan. Multigigabit is a technology that allows your existing cabling to support speeds in excess of 1G, without having to make the jump all the way to significantly more costly 10G. Since we already have technology that address speeds and feeds above what we’re talking about here (how many 10G uplinks have you deployed recently?), it’s easy to overlook the impact this will bring to our daily lives. The ability to move to 2.5G and 5G link speeds without having to make the jump all the way to 10G will allow us to get improved link speeds without having to pay a premium for them. The expected cost increase is estimated to be anywhere from 0% to 15% according to the rumor mill which makes the 250% to 500% speed bump quite attractive!

802.11ac wave 2
The reason I’m taking about it is the fact that this brings with it the promise of addressing the 1G bottleneck that people have been gnashing their teeth over in the wireless space for the past couple of years. While we’ve been able to reasonably deflect the speeds and feeds conversation with 802.11ac wave 1 (speeds approaching 1G wired requirements), there has been no good way to move past that without having a two-cable conversation. The assumption up till now has been that 2x 1G links will be the way forward and many people have been running two copper runs out to their Access Points for the past several years in anticipation of this approach. 802.11ac wave 2 will undoubtedly break the 1G barrier in fairly short order with speeds being promised of (best case) 6,930Mbps PHY rate (about 4,900Mbps on the wire). Multigigabit solutions will allow us to address these concerns without having to invest in 10G links. Better yet, it will allow us to address these concerns without having to consume two 1G ports on our switches. Regardless of the solution you choose (1x 10G or 2x 1G), the cost for deploying a single Multigigabit link supporting up to 5G will be less at scale.

The other unassuming byproduct of this conversation is that Access Points require power to bring up all of those components. It will be nearly impossible to power up a 10G ethernet interface in an AP in the power budgets that we have today. By reducing the link speed requirements to 5G, we can save power at the edge device and still fit in modern negotiation. Multigigabit solutions today will provide PoE, PoE+, and UPoE to ensure that the wave 2 APs that we’re going to be hanging will have ample power for whatever they’re going to bring.

The Revolution
I predict that the incremental cost and intermediary speeds will allow us to start having conversations about the jump to 10G. Multigigabit solutions on Access Points, switch uplinks, and desktop and server nics will be the next big thing. Stackable solutions today promise backwards compatibility so you don’t have to rip and replace – just add a stack member and you’re good to go in that closet/IDF! Regardless of your future proofing plans, enabling faster wireless, or just ensuring that you’re not spending money after (can you believe it?) now legacy 1G infrastructure, make sure you’re having a conversation today about ethernet to bridge the gap to 10G.

For more information about the NBASE-T alliance, go here.
For the Cisco Live, Milan – Tech Field Day Extra event with Peter Jones, go here.

Avaya Wireless is all about SDN

After hearing about Avaya’s wireless portfolio recently, I kept coming back around to a common thread that seemed so entrenched in the core of their solution – SDN. Admittedly I’m not a Data Center or Applications kind of guy, but Avaya has an interesting take on positioning their wireless portfolio. Instead of focusing heavily on a unique set of hardware specific features in their Access Points, they focus on a ‘module enabled’ Software Defined Network strategy. Paul Unbehagen, Chief Architect at Avaya accurately describes SDN as meaning something different to everyone.

At its core, regardless of vendor or implementation, SDN is meant to ease network administration and orchestration by way of software (the S in SDN). Avaya enables this by way of software running on their hardware to create Fabric Attach (FA) Elements. These elements use FA Signaling as a way of communicating amongst each other. These modules running throughout your network (on Avaya hardware) automatically discover and become a part of your FA Core through the orchestration suite.

Avaya does this across their entire infrastructure portfolio which includes their core products, edge switching, and Wireless Access Points. These components all orchestrate together to automatically configure and allocate resources in your infrastructure as needed. In one example, they showed an Access Point coming online and auto-registering using Fabric Attach and magically the requisite VLANs for the wireless infrastructure were automatically provisioned on the uplink switch. It’s clear that Avaya has invested significant resources in enabling this FA functionality including going as far as proposing Fabric Attach as a standard to the IEEE but their messaging is clear – when you run an FA enabled network end to end, it ‘just works’.

It was interesting in hearing the Avaya story in their own words including their addressing some of the more interesting corner cases:

  • Running an FA network without FA enabled devices being attached – this is supported using standards based LLDP TLVs but will likely require more effort than having the FA ‘agent’ running natively on your device.
  • Running Avaya wireless on a non-FA infrastructure – this is supported, but Avaya doesn’t bring anything special to that story that someone else doesn’t already do. This is an interesting scenario that could be positioned for transition needs.

In short, Avaya has taken a link-layer protocol, customized it heavily and allowed it to ask for network resources in an orchestrated fashion. It remains to be seen if this meets everyones definition of SDN and is somewhat predicated on the ‘controller bottleneck myth’ that seems so pervasive in the wireless industry. I, for one, am very interested in seeing where this takes us over the next several years. Addressing distributed challenges at scale (such as provisioning resources) is a problem that has been solved in the wireless space for a long time – do it centralized and scale from the inside out. I look forward to seeing how (and if) Avaya can leverage this FA architecture across multiple platforms and vendors to create the foundational panacea that SDN promises.

Aruba wants you to stop buying the AP134-135. 3rd times the charm?

Earlier this month, Scott Calzia, Director, Product Marketing at Aruba posted an article deriding the announcement of an 802.11ac module from Cisco for their flagship Access Point – the 3602. I took umbrage at the article which lead to the following posts and replies between myself and Aruba Product Marketing Manager, Ozer at Aruba: My first postOzers replyMy next replyHis next reply, and now this post.

Before going any further, I certainly acknowledge that this threaded saga of post-reply-post-reply is a difficult one to follow and I believe that further discussion will likely take place on the No Strings Attached Show. There is a good deal of technical discussion and rabbit trailing in the threads between Oz and myself and I some of them are quite tangential but I’m trying to keep topics centered around the original post topics. I welcome further discussion about performance & feature sets that are outside of the original post and if you’d like to have something addressed in further detail, please leave me a comment in the section below! Having said that, it’s hard to thank someone of Ozers caliber for continuing to stay engaged without sounding trite or insincere. I (and many of my readers that prefer offline comments) genuinely appreciate the dialogue and open discussion. Keeping each other honest with an above board, fun and engaging conversation is exactly the point of this.

Onto the meat!

Alright I am back for round 2… I hope this does not last until round 15 :) I gotta tell you I love the “ding-ding” opening! I am glad that we can keep the discussion fun, engaging instead of using anger and personal attacks… Thanks again for accepting my reply, glad to have the discussion going. BTW, you type fast!

Your comment to Aruba blog…
I am assuming it is a side effect of web changes yesterday (new navigation and converging 3 blog pages into 1) but I will check shortly.

Sounds good! It looks like my original post is still ‘awaiting moderation’ but I look forward to having it approved – Mine get auto-approved, pending spam filtration so I’d be interested in hearing from Scott as well!

Regarding 2400…
small typo as you can guess: meant to refer to 2500 series controllers.

Well, that’s what I was thinking Scott meant in his first post. This means that the corrected statement would be (in reference to controllers that support the 3600):

So if you have older 2500, 4000, WiSM or WCS, it is that time to write your Cisco tax check again.

Sadly, this statement is also false since the 2500 WLC does indeed support the 3600. As a side note, the WCS release notes call out support for the 3600 as well. I’ve been asking for some time about clarification of code support for the controllers and how that meshes with the WCS/3600 support, but it does state it and I presume that since WCS supports code release 7.1, Cisco can claim 3600 support. Yes this is slightly ambiguous and not 100% clear but as the Aruba statement sits, it’s incorrect. Cisco isn’t perfect (there, I said it) but, at minimum, checking the release notes is a) easy to do since they don’t change locations and b) should be a requirement before declaring something is incompatible.

Alright back to tech…

Regarding 1250 series AP (since many commented on it)…
Almost a year after 1250 series, 1140 series was announced. I am not claiming that the AP actually physically failed (it obviously worked just fine after you managed to install it) – it was no longer the right AP to install for many, unless you are installing APs in a warehouse or similar challenging environments. Cisco’s promise of “modular AP is the way to go” was no longer. 1140 had better form factor, better price, did not need external antennas, better PoE efficiency. There was almost no reason to install 1250 series in a classroom or a carpeted office space after 1140 series was released. During that timeframe Aruba’s AP-124/125 series won many deals against Cisco 1250 series (support for PoE and better form-factor were big technical reasons) when we get the chance to sit at the table. Market demanded something better than 1250 series.

Well, I don’t think Cisco ever declared that ‘modular was the way to go (forever and ever)’. We all know that manufacturing efficiencies can be achieved with highly integrated component and if you’ll recall, the IEEE ratified the 802.11n spec during that first year – that’s the reason the 1142 came out in short order. The 1252 was a modular goto-market product that addressed a specific need and was very successful at it. Don’t get caught comparing Apples to Oranges here though, the 1252 and the 1142 are not positioned as competitors and the 1252 was still positioned as the de-facto 802.11n Access Point for external antenna support and extended operating ranges well after the 1142 was launched (as you rightly stated). The 1262 is the Access Point that ultimately replaced the 1252, not the 1142. If you needed an Access Point with flexible antenna options that operated in an environment up to 131F, the 1252 was your man. Admittedly, you may not have been at the table for deployments like that since Aruba doesn’t play well in extreme environments (over 122F for the Aruba 120/130), but I was and I continued to sell the 1252 in significant quantities well past the launch of the 1142. I didn’t realize that defending the 1252 was going to be such a popular topic! I suppose it’s easy to mis-construe the past to those that didn’t live it first-hand, but there you have it.

Of course, there is a trend with Cisco’s modular APs – great marketing for Cisco, brings in more dollars. I am just not convinced that it is the right thing for the customer. My humble opinion…

And you’re close to the point here. Yes, it’s good marketing, but it also fills a need (not just Ciscos coffers). It’s easy to beat up on the dog in front declaring missteps or some other ‘lack of vision’ as a defensive strategy, but the 801.11ac module fills a need that we’re seeing more and more in RFP responses and as a growing concern among enterprises. It’s investment protection and people want this today.

Let’s double click on Cisco’s investment protection….

Note that 1st gen 11ac AP does not go above 3 spatial streams (instead of up to 8 defined per 11ac standard) and does not support multi-user MIMO (which is really beneficial for the upcoming 11ac capable smartphones and tablets as you know). My guess is 2nd gen 11ac APs will have up to max of 5 spatial stream support… since putting 8 antennas in an AP may not be that great of an idea since folks want APs that can be carried by hand… alright let’s go through couple of investment scenarios.

Case#1: Case#2: Case#3: Case#4:

(Note: actual cases omitted for brevities sake, but are available in blog post comments here.) There are indeed numerous ways to slice and dice situations to the benefit (or not) of a particular manufacturer. The 802.11ac module is not intended to be the only 802.11ac Access Point Cisco will ever offer (obviously), nor is it intended to address 100% of each and every purchase requirements for every customer. It’s modularity is intended to bridge the gap to a new technology which is why it was developed in the first place. Will it fit every customer? No. Are there customers today that want to make sure they have a low-cost way to move to 3SS 802.11n and upgrade to 802.11ac in the future? Yes. Scott seems to miss this point in his blog post. Aruba does not have a public facing 802.11ac option so it’s only natural that they’re defensive.

Having said that, there is a portion of your Cases that I’d like to address (and maybe move to another blog post-conversation-thread). ‘Spectrum Analysis’: Noise awareness has been available and considered in RRM calculations for a long time now but Cisco made the decision to develop the best available spectrum analysis capabilities into their solution. ‘Spectrum Analyzers’ that are coarse noise-floor analysis are less accurate and in Arubas case, require additional licenses. Are the licenses expensive? Not in small quantities, but ask any Aruba customer and they’ll complain about feature set licenses. That’s two things that Cisco does better than anyone – no featurset licenses and the best available spectrum analysis. Can you compromise on those features in your enterprise? Perhaps – that’s for you to know. Can I compromise on those features in my enterprise? No. I need the best and when I go hunting for an X-box controller, finding out that it was a transient bluetooth device after 3 hours of looking is unacceptable. This is the reason that Cisco differentiates this feature in it’s Access Points. Implementing ‘Spectrum Analysis’ without a discreet analyzer is less accurate. Cisco won’t put their name on that for a reason. In her article, Joanie Wexler, Network World, claims, “Indeed, Aruba product manager Peter Lane acknowledged about a 5% throughput drop in cases “where you’re maxing out the throughput of the APs already.” Aerohive’s Matt Gast, director of product management, estimated the performance hit as closer to 30%; however, he recommends turning it on only when there’s a problem.

Ok I think I just got the cross-eye that Scott was talking about in his blog… without having to use the OptiGrab! So investment protection argument by Cisco applies to the last case listed above. My educated guess is we will see more of #1, #2, #3 than #4. Again that’s my opinion… agree to disagree.

I suspect we’re heading down the ‘agree to disagree’ path, but the fact remains, in the market today I have customers that have a vision. Their vision is to support tomorrows technology leveraging todays investments. The only manufacturer that has a solution is Cisco and Cisco is going to advertise the heck out of that since it’s a clear competitive differentiator. They’re going to take heat for it, they’re going to get beat up, they’re going to have it mis-represented to the needs of other manufacturers, but Cisco took a leap that no-one else did. Will Cisco sell modules? Yes. Will they be the only way to get 802.11ac? No. There will always be bigger and better on the horizon? Yes. Those that do proper lifecycle management of their infrastructure can leverage this product to future-proof their investment.

FCC link and conversation omitted because:

This is an interesting point and since I work for a Cisco partner under NDA, I can’t discuss this until products ship and are publicly announced. I hope you understand. 🙂

Aruba performance tests…
We do not have Android tablets to replace iPads – no reason to – we have 100+ iPads in the TME labs.

As may be the case, but there is a huge discrepancy in your ‘internal tests’:

You claim to be file transfers to iPads, but don’t list them in your ‘Clients used for testing’. (continued below)

No change in video resolution for Aruba WLAN compared to Cisco WLAN

Aruba uses Active Transcoding in their tests. Cisco does not. This has the net effect of reducing the resolution of the stream for every client and is a mis-representation of the Aruba test. Cisco tackled this head on using the full resolution streams and shined. Aruba changed the parameters and represented it as the same tests. (continued below)

– it is the same exact infrastructure, testbed. Again no reason to. Enabling and disabling RF scanning, IDS, spectrum/CleanAir does not make any difference for either vendors.

I’d love to tackle this first hand. In the interest of full-disclosure, I have an AP-135 and attempted to enable spectrum analysis, but was unable to since at the time it wasn’t supported in ‘Instant’ configuration. I look forward to seeing this development come to market unless of course you want to get me an Aruba 200 controller (and licenses) to play with. 🙂 If it doesn’t impact the performance of the tests, turn them on and prove it to us (continued below)!

Aruba TMEs ran those tests for weeks. We should talk about “maximizing airtime” in another opportunity – Aruba’s RF engineering focuses on this topic nowadays than ever. For instance, a test for you to consider running on Cisco WLAN… start with 5 smartphones on 11n 2.4GHz radio. Record TCP download throughput. Repeat with 10, 15, 20 smartphones. Then add TCP upload traffic into the mix and record total throughput. Results are interesting.

Would love to discuss this more, but as you pointed out, we should tackle that in a separate thread – this is getting long winded as it is! 🙂

Miercom = independent… really? Cisco TMEs run these tests in their labs, publish it on the website URL that you shared and it just happens that a separate set of engineers who work for Miercom happened to run the same set of tests – not less or more – and come up with exactly the same set of test results. Independently. Without being paid any consulting fees by Cisco. Really? :) I firmly believe that something like Network World Clear Choice test reports are independent – and I cannot see how Miercom follows the same model.

(this is the continuation you were looking for) The reason I suggest a Miercom report instead of publishing ‘internal Aruha test results’ is that Arubas tests seem fraught with inconsistencies and, in my book, this calls into question the validity of their test process and results. Put another way, how can we be sure your data is accurate if you’re testing iPads without listing them as clients and pulling shady transcoding  shenanigans, calling it the same as full-resolution media streams. Is that an extreme opinion? Perhaps, but independent reporting should clean up those rough edges and level the playing field.

NSA podcast show is a great idea! Let’s do it. I will email Blake.

ps. Happy to chat about ISRs and ISE more down the road!

Deal on both fronts! Looking forward to visiting Aruba during Wireless Tech Field Day 3!


Post Script:

Several folks have either outright asked offline or insinuated a handful of statements about this thread which I’d like to address:

You’re just flanning the flames for readership to make money. I do not monitize my blog with ads. I do not make revenue from it in any way shape or form and pay for it out of my own pocket.

You’re being spoon-fed responses by Cisco. I am not. My blog is mine and mine alone. My thoughts are my own and (with the exception below) are not generated by anyone else. If I get data from other sources, I will do my best to list those sources clearly.

You work for a Cisco reseller and have ‘the inside scoop’ which sways your opinions. Well, yes. I do indeed work for one of the largest Cisco resellers in the US. This does give me insight and access to hardware that others may not have and since it does, I do consider myself ‘up on the solution’. My employer does not endorse or influence my blog with the exception of discussing NDA information. I am bound by my employer to not discuss NDA information outside of the scope of the agreement and I continue to abide by that.

Aruba wants you to stop buying the AP134-135. Round 2.

Aruba recently posted a rather snarky post about the technological shortsightedness and irrelevance of 802.11ac upgradability of todays wireless infrastructures. This original post (mirrored here) admittedly ruffled my feathers on several fronts so I wrote this response. If you haven’t read these, I encourage you to go do that now.

Aruba product marketing manager, Ozer (@ozwifi) replied to my reply. Before we get to the meat of this post, in the interest of full-disclosure, this post has no direct ties to the Wireless Tech Field day events hosted by Gestalt IT. I have been selected as a delegate for the upcoming Wireless Tech Field Day event that Aruba (among others) has sponsored in the past. As a Tech Field Day delegate I have been given access to hardware and solutions from the event sponsors to utilize as I see fit. At the time of this writing, Aruba is not currently listed as a sponsor of the WFD3 event, but we certainly welcome them and look forward to their involvement!

Ding Ding!

Hey Sam,

It is @ozwifi here. It is not uncommon that we get on each other’s nerves in the Wi-Fi industry and by the tone of your reply I am guessing that’s exactly what we did. But you gotta admit, there are no personal attacks in the blog entry since it is delivering an educated technical opinion.

Oz! Good to hear from you. I apologize for the rather public response to your post, but this seemed the fairest way to address this in its entirety. To the audience at large, I apologize for the broken up, threaded reply and will do my best to make it as cohesive as possible. You are indeed correct that it’s not uncommon to get on each others nerves and you are spot on that this one hit home for me. Perhaps I shouldn’t be so personally vested in industry vision, but I’m sure it’s one of many faults that I have. 🙂  You are correct that there are no personal attacks in the Aruba post and I hope that no one believes that my reply was somehow a personal attack on the Aruba team – infact the only team I mentioned explicitly was the executive team and I certainly don’t hope they *actually* jump off the top of the tallest building in San Jose. That would not be pretty or professional and was merely a ‘leaping’ analogy. Regarding the blog post being an ‘educated technical opinion’, I do take exception to this being an educated technical opinion. It doesn’t sound educated whatsoever and I think that Aruba’s shortsightedness regarding 802.11ac is rampant in the article. Also, I’m still interested in just what the heck a 2400 is…

Poking fun at Aruba’s #1 competitor in the WLAN space with a bit of humour. You have to meet with the author, Scott, during the next WFD – he is not that bad of a person as you might think. So there is really not much to be ashamed of since we are not proposing the kidnapping of new born puppies.

Indeed I look forward to meeting him in person and we look forward to Aruba participating in another lively discussion this year! Also for the record, I wholeheartedly disagree with kidnapping new born puppies.

Before we talk tech – please leave your comments on our website.

I did indeed leave exactly my reply on the Aruba website and as of now, the post has not been approved and is not present in your comments section. To contrast, your post to my replies section was almost immediately approved. I welcome the conversation and look forward to Aruba being more transparent about their comments in the future.

First we do not have many people leaving comments, so we can use some. Second we are not that evil – look at our YouTube channel… anyone can say whatever they want. Unless it is personal attacks of course, cause that’s just not cool.

Alright, let’s talk tech.

Here is where Aruba stands:
1. We believe that dedicated AP hardware is going to provide the best coverage & capacity. Best antenna choices, speeds & feeds optimized for 11ac. If it was such a great thing to install modules on an AP in terms of either of these two, many WLAN vendors including us would have jumped on the bandwagon.

There will always be advances in technology and I believe that most any new solution will ultimately outperform legacy solutions. We see this time and again in the industry and this is a byproduct of Moore’s law. The 802.11ac module is about investment protection. The message from Aruba is clear: either a) don’t buy a 3SS  AP today and wait till the 802.11ac AP comes out in the future or b) buy two Access Points (3SS today and 802.11ac tomorrow). Cisco has an option that addresses this concern head on. Aruba does not.

2. Since we are a WLAN company, you will not be too far off in assuming that we will an 11ac AP available down the road. That’s a given. I cannot tell you when, what, how since the info is still very much confidential and shared under NDA.

Of course! This adherence to an NDA is critical in our industry and competitive speculation beyond NDA is what Aruba is good at. This is FUD until you can empirically prove otherwise (more on this later).

3. We are obviously not going to stop promoting AP-130 series product line. We educate our customers regarding the benefits of first gen 11ac and second gen 11ac all day everyday. We do not hide information or try to corner them into buying 130 series. That will be very wrong. Upgrading to dedicated 11ac AP from Aruba 11n will require same process that folks are used to performing during the last 10 years – climb the ladder, plug out AP, plug in AP. As opposed to Cisco, we are not proposing a change in this process. There are no hidden costs here.

I have every expectation that Cisco will not only have a dedicated 1-st gen 802.11ac Access Point in the future, but will also have a 2nd gen and whatever comes after that. The market is always evolving. Cisco’s message today is that the price of two Access Points from Aruba is more than the 3600 + a 1st gen 802.11ac module. Again, investment protection. The costs that Cisco is addressing with this module are not hidden. They are outright and Cisco is head-on tackling this proactively. Aruba is behind the 8-ball and does not offer investment protection. If I were an Aruba customer, I’d not buy new Access Points today because there is no low-cost upgrade path to 802.11ac in the future. Either that or write your check out to ‘Aruba Catalog of Compromise’. ‘Aruba Catalog of Shortsightedness’? ‘Aruba Catalog of Technical Irrelevance’? ‘Aruba Catalog of FUD’? I don’t know – pick one, they all work for me.

Here are my comments on your responses for what they are worth. I am guessing that we will agree to disagree at the end of it… although I hope I can provide more color commentary and that you will find them useful. Again, I am trying to talk tech here not disagreeing with the fact that 3600 11ac module is good marketing.

Oz, I 100% agree with everything you said here and am speechless that we’re so in sync! 🙂

1250 series: Folks invested in the platform found out later that there was no need for this modular AP since moving from draft 2.0 of the standard to the ratified version did not require an hardware upgrade.

We see this time and again with the Cisco product lineup. The radio modularity in the 1220s was upgrade investment protection for 802.11G. The radio modularity in the 1252s was upgrade investment protection for 802.11n. The radio modularity in the 3600 is upgrade investment protection for 802.11ac. There is a trend here.

Cisco’s predictions were wrong.

No, infact Cisco’s predictions were right! They took a ‘best guess’ at the hardware that it would take to support the finally ratified specification and there was never a module released because it was never needed. No hardware changes required was a win-win for Cisco customers.

It was a 5-pound AP

Auxiliary boat anchor, yes. It was heavy. Don’t beat up on it because it was big-boned. It needed that modularity. It’s mommy told it so.

with no dual-radio support 802.3af (if you rememeber, Cisco was claiming at the time that 11n APs will not be able to support 802.3af).

Unfortunately, you’re wrong here. The 1252 does indeed support 802.11n on both radios utilizing 802.3af. Quit spreading flat out lies.

I believe that 1250 series was mostly about marketing, capturing attention and not so much about delivering best of breed Wi-Fi technology. Given that the product line lived only about a year, on this side of the fence we think that our predictions about those first generation of 11n APs were the right ones.

1 year, huh? I show final date of support for the 1252 as early 2017. My memory isn’t all that clear on the 1252 launch date, but it was first supported in WLC code which has a release date of March 21, 2011. My math is a bit fuzzy on this one, but 2011 to 2017 seems a much larger window than 1 year.

Difficult to deploy: Here is the Cisco process… Install 3600 today. Wait 8 months. Buy 11ac modules. Climb up the ladder. Unscrew the mounting bracket. Take the AP down. Install module. Climb up the ladder. Screw back the mounting bracket.

The vast majority of the installations I see are ‘snap in’ mount. I don’t recall how the Aruba 130 mount bracket works, but palming the butt of an AP to snap it out of place and snapping a module in seems pretty straightforward to me.

Cisco *will* come up with their dedicated 11ac AP hardware that’s based on Marvell chipset, as opposed Broadcom running inside the 11ac module for the 3600.

I do not have technical documentation about the chipset in the 802.11ac module from Cisco. This would be the first time Cisco has used Broadcom in an infrastructure device and would certainly be a departure from their M.O. Having said that, if you have NDA insight into the hardware diagram and working structure of the AP, I believe this would be covered by NDA and subject to change. Either way, you’re speculating or sharing data that is NDA and is subject to change. We’ll have to agree to disagree until the module comes out and we can take it apart and do performance testing with it.

With that upgrade, that’s three trips to the ceiling. And when the 2nd gen 11ac AP comes out, you do it again. That’s four. We cannot call this simple as opposed to difficult.

I still have 1252s in place today. They service a need for many of my customers that simply need to support 802.11n. I foresee that the 802.11ac module will support 1st gen 802.11ac needs for a long time. Aruba has no products today that can be purchased and upgraded later. Again, upgrade investment protection.

CPU speeds: Here is the thought process. Aruba AP-135 beats Cisco 3600 in peak performance. Whether it is pure 3×3:3 MIMO laptops, UDP or TCP traffic flows, or a mix of smartphones, tablets, laptops… that’s what we see using Cisco release 7.2 and Aruba release Aruba product managers prefer not to use AP-135 CPU and memory subsystems for an 11ac AP per our interviews in order to be able to deliver the best peak 11ac performance. This tells me that Cisco product managers have to think the same way since AP-135 outperforms Cisco 3600. Using your argument, although looking at it from a different angle, how can we be sure that Cisco 3600 plus an 11ac module will deliver greater performance than a dedicated 11ac AP hardware?

We can’t until it’s out and available. Regarding your other performance claims, I welcome those head-on and would encourage readers to visit Aruba has addressed these performance tests inconclusively (performing iPad throughput tests with Android devices, transcoding their video down to lower bit rates, and disabling recommended enterprise feature sets such as spectrum analysis and IDS). When will we see Aruba engage a 3rd party like Miercom to do independently validated performance tests instead of continuing to poke and prod at Cisco? Let’s back your claims up independently. As an aside, I welcome the performance claims of existing hardware but it’s off-topic for this thread.

Inconsistent RF and feature set: 3600 will run two separate Wi-Fi chipsets from two different vendors: Broadcom and Marvell. Why on earth would I want to do this if I want uniform features and functionality across my 2.4GHz and 5GHz radios? No AP that was built for enterprise WLANs ever had this design. I am sure there was a good reason behind it.

Adressed above.

Upgrades: Cisco 3600 requires 7.2 release, which requires latest generation of Cisco controllers and NCS management instead of WCS management. We are just making it more apparent for those who care, although Cisco release notes clearly state these facts as well. The tradition of having to upgrade something in your network whenever there is a new WLAN product or solution from Cisco is really what gets on our nerves. For instance ISE… BYOD solution that requires me to upgrade from ISR to ISR G2… why would I want to touch my branch router if there is an employee owned iPad connecting to my network? Some of this stuff just does not make sense to us and we have just watched this episode way too many times … hence it is a reflex motion… we do not miss an opportunity to remind folks of what they need to be careful about.

I’d like to hear more about your ISR concerns. I’m not sure where the mindset of routers being upgraded to support your iPad comes from. The iPad is not a wired device. Are you referring to the AP801/802 module? Both of those are integrated into the ISR and fully supported in 7.2 code. If you have a switch that supports ISE, there is no need to replace the router between the switch and the Access Point. Although, I always liked the idea of cabling my iPad to my ISR router…

Alright my apologies for the long comment post, tried to do my best to keep it short. I hope you can give me a chance to respond by accepting my comments.

Your comments are always welcome (despite being shunned on the Aruba post comments) and I apologize again for the threaded response. If you’ve read this far, I formally invite Oz (and Scott for that matter) to come onto the No Strings Attached Show and discuss Arubas stance on 802.11ac. I look forward with taking more about this in a forum more conducive to back and forth dialogue.

See you at WFD3.

 I as well as the entire WFD3 delegate team most certainly look forward to Arubas participation. I recall last year being lively and look forward to it!


Wireless Tech Field 2 – Recap and first looks

This past week, I attended the Gestalt IT Wireless Tech Field 2 event hosted by several leaders of the wireless industry in San Jose, CA. The Tech Field day events are an opportunity for vendors and manufacturers to get in front of a highly focused group of delegates to tell their own story, on their own playing field. The Wireless specific event is the brainchild of Steven Foskett and Jennifer Huber and I consider myself privileged to have been able to participate in this very prestigious event – now for the second time! This event was sponsored by industry leaders in the wireless space – Aerohive, Meraki, MetaGeek, Ekahau, Aruba, HP, and Ruckus (in order of visit). The delegates for the event were given the opportunity to meet with these companies, in many instances at their home offices, to share first hand their stories and visions for what they feel is the market drivers in the wireless space as well as their respective visions for what the future of wireless is going to bring. This post will be the first of several as I dive into each of our sessions with many of the vendors and share my take on the vendors, their products, and how I perceive them to fit ‘in the industry’.

This Wireless Tech Field day was preceded by the first wireless symposium where members of the industry and media were invited to participate in an open discussion on the future of wireless with a focus in particular on upcoming technologies 802.11ac/ad (gigabit WiFi), 802.11u (Hotspot 2.0), and Bring Your Own Device (BYOD) technologies. Devin Akin (Aerohive), Carlos Gomez (Aruba), Paul Congdon (HP Labs), and GT Hill (Ruckus) treated us to their vision of how these topics will shape and form the foreseeable future in the wireless industry. I’ll also be exploring these various topics in upcoming blog posts, so consider that a teaser! 🙂

Each of the sponsors of the WFD event each brought something special or different to the table. I think one of the most important things I learned during the event is that, when given the opportunity, each manufacturer tells a compelling story when given the opportunity to. I consider myself a fairly impartial technologist so it was refreshing to be able to receive these messages in their native, or ‘best case’ format highlighting the various strengths that each company has to offer:

Aerohive continues on their self-proclaimed mission to rid the world of controllers. Aerohive is rolling along with their ‘protocols are free’ mantra to bring solutions rapidly to market in a low-cost, easy to deploy fashion. Their cooperative control architecture enables many of the features of a centralized controller based solution and they are extending this into the routing world with the introduction of the BR-100 branch edge router. This device is managed ‘by the cloud’ – by either using the Hive Manager Online solution that is hosted by Aerohive or hosting your own ‘private cloud’ instance of the rapidly evolving NMS.

Meraki, to be perfectly frank, was perceived by many of the delegates as the ‘underdog’ of the event and many of us had some pretty negative preconceptions of who they were and what they do. I think it’s safe to say that Meraki portrayed a strong showing overall and rapidly showed the room at large that they’re clearly more than a niche player in the wireless space. They showed off their NMS platform and gave us some ‘under the hood’ insights into their operations overall. The way Meraki is able to manage and aggregate data from the vast (that word seems woefully insufficient) deployment of edge Access Points was staggering.

MetaGeek once again showed off to the TFD delegates. Last year at the first TFD event, they stole the show by showing off their low cost – feature rich PC based spectrum analyzer product. This year, demonstrating the agility that is impossible in a larger organization, they showed off their extension of ‘wireless visualization’ products – Eye P.A. This play on a TLA stems from their ‘eyeball’ view of Packet Analysis. As an organization that is clearly focused on getting information to a place that its easy to understand, they presented (showed off?) a pre-release version of this product. It’s safe to say that all of the delegates were blown away by the unique and innovative show of application development. MetaGeek has sprung up from seemingly nowhere to make a name for themselves in a technology that is exciting and that knows no growth boundaries.

Ekahau came to the table with their site survey product ESS (Ekahau Site Survey), the mobile version of their vision for tablet-based site surveys, and their tags. As an avid user of competing site survey products, I can clearly see that I’ll be rethinking my overall approach to performing the most important part of a wireless deployment – the site survey. I look forward to some hands on time with their android tablet compatible piece of this software. This is clearly a place that the major competitors are deficient in and Ekahau stands to be the first to market with an exciting product. Almost running out of time at the event, we got a very quick overview of their RTLS tag for wifi based deployments. As a side note to the Ekahau team directly, you have enough exciting things to talk about that maybe next time two sessions would be appropriate. 🙂

Aruba brought out the big guns during their sessions showing off their Aruba Instant product – essentially a wireless controller running on an AP. Those of you familiar with the now all-but-defunct WDS can consider this WDS in a fully automated, steroid enhanced feature set enabling rapid deployments of premise-based and managed lightweight deployments. After a good discussion regarding Spectrum Analysis, we dove off into the BYOD deep end with a realtime display of managing guest devices including a strong iOS MDM application utilizing products from their recent Amigopod acquisition.

HP gave the delegates a good overview of their 3×3:3 wireless Access Points including their newly launched outdoor product the MSM-466R. They also showed off their newest member of their controller line the MSM720 including some fervently discussed licensing features such as a discreet ‘advanced feature set’ as well as the ability to pool AP licenses across controllers.

Ruckus closed out the event with us by bringing a deep dive discussion regarding their approach to RF management. Ruckus gets top marks for their no holds barred approach to interacting with the delegates. Future sponsors of the event can take a page from their book – using a combination of geek + relevance to the table. Hands down, Ruckus had the room enthralled by the discussions and philosophies surround their approach to the market – no small feat for the last sponsor of the event.

Needless to say, the WFD event was exciting, exhausting, fun, and educational for everyone involved. As a delegate, I received a variety of products and marketing swag from the vendors with the understanding that I’m under no obligation to do anything with it that I don’t want to. The opinions that I intend to express from evaluating and trying out these products are my own and I’m also under no obligation to be positive or sway my opinion based on any gifts, equipment, or swag I have received. I look forward to digging deeper into these manufacturers and sharing what I feel and offering my honest, direct opinions on them. I hope you’ll stay tuned for future posts where I discuss the event, sponsors and products!