Drag racing the bus

Picture it. You’re a school district transportation engineer. You’re in charge of purchasing a fleet of new school busses for your district. The big ones. The expensive ones. The ones that will last you for the foreseeable future. So, you call up Bus Vendor A, B, and C and inform them that you’re in the process of selecting a fleet of new school busses. The following week each vendor dutifully delivers their ‘bus of choice’ to be evaluated. You then grab your intern, put him at the midway point of the bus from ‘Vendor A’ and take it for a spin! You see how fast it goes from 0 to 60. You see how it corners. People hear tires screeching from all over the city as you and your one other occupant sling this bad boy around town ‘evaluating’ the bus. You then repeat the same process for ‘Vendor B’ and ‘Vendor C’. You aggregate your data. You correlated your data. You make pie charts about your data. You do ROI calculations on your data. You do comfort analysis on your data. You do handling analysis on your data. You made your ‘educated’ recommendation and purchased a fleet.

Day 1 of school rolls around and the first thing your brand spanking new fleet of school busses does is immediately do the one thing you neglected to test: they loaded up with kids and trudged along at 20 MPH safely around town. You start getting complaints. They don’t stop well. They don’t handle well. They don’t get good gas mileage. They bounce all over the place and your district has to send 2,000 kids to chiropractic care because you didn’t evaluate the bus under the conditions it’s going to be used in. Instead, you took it for a joy ride. You drag raced it. The one bus that went the fastest with a single guy in it, you bought. When you deployed it, it broke because you didn’t test it using real world scenarios.

Please, don’t drag race your evaluation Access Points. Test them like you’re going to operate them. That way you get a realistic view of how they’re going to behave in the real world. Do your self a favor. Stop joy riding your vendors gear and put it in the real world to test it.

This blog inspiration courtesy of @florwj . Go follow him. He’s awesome.

-Sam

Advertisements

Cisco releases new WLC UI, Changes default values (finally)

Cisco released WLC code version 7.6.120.0 which brings with it (among other things) a new User Interface for the 2504 WLC. When you use the new simplified setup, it also changes many of the default values that haven’t yet been enabled by default in the base code. The new default values are:

Aironet IE: Disabled
DHCP Address Assignment (Guest SSID): Enabled
Client Band Select: Enabled
Local HTTP and DHCP Profiling: Enabled
Guest ACL: Applied
CleanAir: Enabled
Event Driven RRM: Enabled
Event Driven RRM Sensitivity, 2.4GHz: Low
Event Driven RRM Sensitivity, 5GHz: Medium
Channel Bonding, 5GHz: Enabled
DCA Channel Width: 40MHz
mDNS Global Snooping: Enabled
Default mDNS profile: Add better printer support, Add HTTP
AVC (no Control, only Visibility): Enabled*
Management via Wireless Clients: Enabled
HTTP/HTTPS Access: Enabled
WebAuth Secure Web: Enabled
Virtual IP Address: 192.0.2.1
Multicast Address: Not configured
Mobility Domain Name: Name of employee SSID
RF Group Name: Default

*AVC stands for Application Visibility and Control. Control means remarking or blocking – for the purposes of the default setup, you’re inspecting only, Control is disabled and must be enabled manually. This also requires a current boot loader which should only be important if you’re setting up an older unit that’s been cleared.

You should note that to get these default values auto-set, you must use the new setup wizard – if you do the regular CLI setup of your controller, or if you just upgrade an existing controller without clearing it’s config, these are not set. You should also note that, for now at least, this only applies to the 2504 controller, not the 5508, WiSM2, 7510, 8510, or Virtual WLC platforms.

WPA/TKIP only going away in Cisco WLC release 8.0

Cisco is readying the next major release of their WLC code, version 8.0. At the advocation of the WFA, this will bring with it a very significant change in security capabilities that you may find impacting if you’re caught unaware. In an attempt to raise awareness, Cisco has approved an discussion of this change first mentioned here. Cisco, in accordance with the new WFA guidelines, will no longer be allowing an SSID configuration with WPA/TKIP only security. If you are currently using an SSID that has WPA/TKIP only security, your configuration will automatically be updated to enable WPA2/AES connectivity as well as WPA/TKIP. You may want to start validation testing now if you are currently supporting legacy devices on a WPA/TKIP only SSID today. The easiest way to ensure you’re not caught by this change is to enable WPA2/AES along with WPA/TKIP and check to make sure your devices still behave as expected. I have confirmed in the lab that this change will be automatic:

WPA-TKIP only configuration pre-8.0

WPA-TKIP only SSID configuration, Pre-8.0

WPA2-AES added post-update

Same SSID with WPA2/AES enabled post-update.

 

To summarize of the variety of allowed and disallowed potential configuration options you have available and if they’ll be supported in WLC 8.0:

WPA1-TKIP (Disallowed due to eliminating TKIP)
WPA1-AES (Allowed by Extension Policy)
WPA1-TKIP/AES (Disallowed since not used in conjunction with WPA2-AES)
WPA2-TKIP (Disallowed due to eliminating TKIP)
WPA2-AES (Certified and allowed)
WPA2-TKIP/AES (Disallowed due to WPA2-TKIP)
WPA1-TKIP + WPA2-TKIP (Disallowed – no AES support)
WPA1-TKIP + WPA2-AES (Certified and allowed)
WPA1-TKIP + WPA2-TKIP/AES (Disallowed due to WPA2-TKIP)
WPA1-AES + WPA2-TKIP (Disallowed due to WPA2-TKIP)
WPA1-AES + WPA2-AES (Allowed by Extension Policy)
WPA1-AES + WPA2-TKIP/AES (Disallowed due to WPA2-TKIP)
WPA1-TKIP/AES + WPA2-TKIP (Disallowed due to WPA2-TKIP)
WPA1-TKIP/AES + WPA2-AES (Allowed by Extension Policy)
WPA1-TKIP/AES + WPA2-TKIP/AES (Disallowed due to WPA2-TKIP)

Other SSIDs and security configurations are not impacted, including Open SSIDs, any SSID that currently has AES enabled, and WEP SSIDs.

 

UPDATE: Due to user feedback, Cisco and the WFA finally settled on making the above restrictions in the GUI only. If you still have a business need for a WPA/TKIP SSID, you can configure it from the CLI. If you were building an SSID on a Cisco WLC with an ID of 6, you would use the following commands for example:

config wlan create 6 TKIP-ONLY
config wlan security wpa wpa2 disable 6
config wlan security wpa wpa1 enable 6
config wlan security wpa wpa1 ciphers tkip enable 6

Using the show commands you can validate that this configuration took at the CLI:

show wlan 6

Wi-Fi Protected Access (WPA/WPA2)…………. Enabled
WPA (SSN IE)…………………………. Enabled
TKIP Cipher……………………….. Enabled
AES Cipher………………………… Disabled
WPA2 (RSN IE)………………………… Disabled

Meraki: The bolt on Cloud that wasn’t

When Cisco acquired Meraki last year, there was much confusion. Being ‘down in the trenches’ I struggled as much as the next guy trying to wrap my head around the acquisition and I believe I have a good handle on it. Others not so much. I regularly consult with customers that are just as confused today as they were last year. Cloud is such an over used buzz word and so many vendors are trying to jump on the buzzword bandwagon de jour that it’s easy to get lost admist the jargon and solutions, much less the technical merits or differences in the platforms. I’m here to offer some advice on the strategy and perhaps a perspective on the acquisition that you haven’t yet considered. First some advice:

Don’t purchase Meraki Access Points. You read that right. Don’t do it. Also, don’t purchase Meraki switches. For that matter, don’t buy the Meraki firewall either. If you purchase a Meraki Access Point, a Meraki switch, or a Meraki firewall, you’re not buying an Access Point, you’re not buying a switch, you’re not buying a firewall. You’re buying ‘The Cloud’. When you consider purchasing infrastructure equipment that is ‘Cloud Enabled’, this should be a purchase that lines up with your organizations Cloud Strategy first and foremost. Don’t have a Cloud Strategy? Don’t be so sure. There are a few questions to ask yourself before you jump to that conclusion. Does your organization use DropBox? Salesforce.com? Office 365? Webex or Goto Meeting? Google Mail? All of these are examples of Cloud Applications. If you use these, someone, somewhere in your organization has made the determination to embrace services from ‘The Cloud’. Understand this strategy. Understand what this enables. Understand what this means to your data and where your data lives. Then (and only then) should you consider purchasing ‘Cloud Managed Infrastructure devices’.

Let’s be frank about it, there’s nothing special about the hardware in a Meraki Access Point. There’s nothing special about the hardware in a Meraki Switch, nothing special about the hardware in a Meraki firewall. When you purchase Meraki equipment, this gear is purpose built to be Cloud Managed with features driven by that Cloud Management. When you make a Meraki purchase, purchase an end-to-end Cloud-enabled infrastructure. If it’s right for one component, it’s right for all of them. If it’s not right for all of them, it’s not right for any of them.

Now some perspective. Everyone is talking about Cloud. Everyone wants in on the Cloud action. Everyone is ‘bolting on’ Cloud to their existing products in some fashion or another. When Cisco purchased Meraki, they made a decision to not ‘bolt on’. They decided to pick the one organization that understood Cloud from bottom to top and embrace that strategy despite the fact that there was some hardware overlap. The Meraki acquisition wasn’t about Access Points, switches, or firewalls. It was about finding the one organization that was never built for ‘on premises’ management and this shines through in every aspect of their products. Others tout ‘free protocols’, ‘cloud provisioning’, or a variety of other nonsense but at the end of the day, these are bolt-on solutions that are all afterthoughts. I would encourage you to revisit the Meraki product portfolio but when you do, ask yourself the following questions:

  • What are my existing Cloud Applications?
  • How do I rely on ‘the Cloud’ today?
  • Do I want to leverage that existing strategy in my infrastructure?
  • Do I want a solution that is built from the ground up around ‘the Cloud’ with a no-compromises featureset or do I want to deal with someone bolting on features to their existing ‘heavy gear’?

Then go buy a Meraki AP.

Bridging networks on a VM

So, you’ve got your shiny new Mac and you’re in that ‘in-between’ time where you’re running a VM to support all of your Windows needs. You decide that your VM needs to be connected to the same Layer 3 network as your physical box so you decide to change your VM network settings from ‘NAT’ to ‘Bridged’. This seemingly simple configuration change has some pretty significant ramifications in the Cisco wireless world however so you may be shocked to find out when you take your beloved Mac back to work that your VM stops getting an IP address! As it turns out, there is a feature enabled by default on a Cisco lightweight wireless infrastructure that is spelled out thusly:

In the controller software Release 5.2 or later releases, the controller enforces strict IP address-to-MAC address binding in client packets. The controller checks the IP address and MAC address in a packet, compares them to the addresses that are registered with the controller, and forwards the packet only if they both match. 

Since your Mac(intosh) uses a single adapter (your WLAN adapter) for the connection to the network, the controller only sees a single MAC address. This means that it will only let a single IP address talk on the network since it’s expecting a 1:1 mapping of MAC address to IP address. The quickest way around this is the following global command on your WLC:

config network ip-mac-binding disable

Which will remove this 1:1 mapping expectation. Don’t forget to save your config and you should be good to go with IP addresses issued via DHCP to both your real machine and the Virtual Machines living behind the bridged VM network!

It should also be noted that many ‘security appliances’ serving as your DHCP server will refuse to issue multiple IP addresses to a single MAC address, effectively recreating identical symptoms (a VM that get’s no IP address). As far as I know, there is no workaround aside from not using a security appliance for your DHCP server. This is believed to afflict both Palo Altos as well as ASAs and is likely to impact anything else under the guise of a ‘security appliance’. Your best bet is to try and put DHCP services on a real server (Windows DHCP or Linux ISC-DHCPD) or try running it in IOS on your next hop Catalyst switch. You *do* have a next-hop Catalyst switch, right? 🙂

Aruba just doesn’t get Investment Protection

This week, Cisco launched their modular 802.11ac Access Point, the AP3700. The FUD that started almost instantly was unbelievable. This petulant mud slinging is coming from from none other than our good buddies over at Aruba who are trying with all their might to convince all of their AP134/135 users to go buy a new Access Point. While this rip-and-replace mindset has boosted their volume sales over the past several years, I think it’s time that we all revisit what modularity means and why it’s good. We’ll get this bit out of the way first however since it seems to be a common misconception about modularity: Modularity is not only about 802.11ac, it is about investment protection. Aruba wants to spin this to convince you that you a) need to buy a new AP and b) while you’re at it, let’s try and sell you a controller! This slight of hand and misdirection is really in poor form and we should all take a moment to bring this conversation back to the real world. The 802.11ac wave 1 module is one of 4 modules, and one of two Cisco 802.11ac platforms to select from. No one is forcing you to purchase a module to get 802.11ac. Cisco has a ‘rip and replace’ option as well. If you’re okay with the rip and replace approach to 802.11ac (as an Aruba customer you should be used to this by now), by all means – let’s compare a head to head AP3700 against the AP-225 (I’d do this, but for some reason they’re reluctant to send me an AP-220) using clients that are available in a the real world today. By the way, wasn’t it Aruba just a few months back complaining about Cisco using Miercom and proving that the 5760 beats the stuffing out of the 7240 controller and that the AP3600 whomped all over the AP134/135?

Let’s recap the FUD: When the AP3600 was announced, Aruba predicted:

  • That modularity doesn’t work: FALSE – Modularity does work, and has worked since the Cisco 1220 (802.11b to 802.11g migration).
  • That Cisco won’t ship modules ever: FALSE – Cisco has shipped two modules and is on track to ship an additional two.
  • You’re better off buying a new AP: FALSE – well, maybe not false. If you’re an Aruba customer, you have no choice.

This last one is really the sticking point. Most of the customers I talk to can’t stomach a new AP upgrade every year. They’re more along the lines of 3 to 5 year refresh cycles. Realistically speaking, if my upgrade cycle hit last year I could have done one of two things:

  1. Purchased Aruba AP134/135s. This means that I cannot get any sort of 802.11ac without ripping and replacing.
  2. Purchased Cisco 3602s. This means that if I need it, I can deploy 802.11ac (wave 1 or wave 2!), monitor mode, or indoor cell DAS modules at a fraction of the price of a new AP.

At the end of the day, modularity is not intended to be a one size fits all approach to technology. It’s right for some people, it’s not right for others. When it comes down to it, you can either buy more Access Points, or less Access Points, and still get current technology. If you’re considering the Aruba platform today, I’d encourage you to ask the following questions:

  • What do I do with last years APs?
  • How do I get to 802.11ac wave 2 when it comes out?
  • How do I deploy indoor cell DAS leveraging my existing APs?
  • How do I do wIPS without buying a whole new overlay solution?
  • Why aren’t you comparing against the AP3700?

In the meantime, let’s keep Aruba pointed in the right direction shall we? The modular platform argument is one that Cisco battles time and again – look at all of the people that used to hate on the Catalyst 6k platform? They had nothing to compare so, certainly modularity was bad! Modular is good, investment protection is fiscally responsible, and flexibility means that I can get some of todays technology where I need it, when I need it without breaking the bank on forklifting my infrastructure. By the way, let’s do a speeds and feeds with an AP220 and an AP3700 and see how those bar charts look…

In short, it doesn’t matter who’s infrastructure gear you’re buying. Moore’s law means that there will always be a pie chart or bar graph trying to convince you to buy something shiny and new. Modularity is about getting some of that shiny new, without having to forklift your gear – investment protection.

The Unstoppable MetaGeek – now with CleanAir!

Rarely does such an organization come around that expresses it’s agility and prowess with as much regularity as MetaGeek. The most recently of which is their ability to use Chanalyzer Pro (their premium Spectrum Analyzer software) to talk to the Cognio chipset in a Cisco CleanAir Access Point. PC based Spectrum Analyzers have had a sordid history to say the least. Way back when, Cognio made what you would call ‘the best of the best’ PC based Spectrum Analyzer. This took the place of many of the bulkier, more expensive Spectrum Analyzers and proved to the world that a) it was important to get Layer 1 visibility for enterprise WLANs and b) that they could make it affordable for most services based partners. Everyone OEM’d the Cognio analyzer, AirMagnet, Fluke, and WildPackets. Along came Cisco. They purchased Cognio, killed off all of the OEM agreements, rolled the hardware into their Access Points, and started selling the Cognio product with the Cisco name on it (Cisco Spectrum Expert). Unfortunately, they didn’t do much with the CardBus product and let the non-AP components stale. The aging interface form factor left quite a few holes in the market and along came a few people here and there to make it all shake out like this (generally):

  • Cisco Spectrum Expert: Highest resolution, CleanAir AP and CardBus form factor, Cognio based
  • AirMagnet Spectrum XT: Middle resolution, USB form factor, bandspeed based
  • AP based Spectrum Analyzers: Low resolution, integrated into many APs, Atheros based
  • MetaGeek Wi-Spy: Low resolution, USB form factor, keyboard controller based

Ryan and team over at MetaGeek did an excellent job of using very affordable components to give us an alternative to the aging CardBus adapter and the newer, more expensive AirMagnet adapter. They were an awesome product for the money but never really achieved huge market penetration due to the fact that the Cognio and bandspeed products still offered higher resolution. With the Cognio hardware all locked up in the Cisco Access Points, it seemed inevitable that we’d never have a good way to access it. Imagine our surprise when at this years Cisco Live event, MetaGeek was there – showing off their integration between Chanalyzer and the CleanAir Access Points! Ladies and Gentlemen, this is the *exact* same Cognio hardware, high resolution Spectrum Analyzer goodness that we all know and love from the old days. When I first heard about this, there was much trepidation about MetaGeek perhaps not being able to address the ‘full power’ of the Cognio (ahem, CleanAir) chip in its rawest form, but I’m here to tell you, when compared side by side with a legacy CardBus based Cognio adapter, the data is identical! The user interface is the updated, Chanalyzer interface with all of the modern enhancements they’ve made over the years with the WiSpy products, but you’re using the high-fidelity data that Cognio gives us. Here’s how it works:

You can connect to a CleanAir AP that is autonomous or lightweight (registered to a WLC) and it can be either servicing clients or in dedicated ‘SE-Connect’ Mode. You get the highest resolution, widest image when it’s in this last mode so let’s start there. Log into your controller, select your AP from the wireless tab and change it from ‘local’ to ‘SE-Connect’. Click Apply and let the AP reboot and join back to the WLC.

Screen Shot 2013-08-12 at 9.02.03 PM

Once it’s joined back, select the AP again and you’ll find both the IP address of the AP and something called the NSI key:

Screen Shot 2013-08-12 at 9.08.06 PM

Lauch Chanalyzer Pro with CleanAir and goto the File Menu. Select the intuitive ‘Connect to a CleanAir AP:

Screen Shot 2013-08-12 at 9.12.25 PM

Once you do that, enter the values from the AP page that you previously saw including the IP address, NSI key and a friendly name for this AP:

Screen Shot 2013-08-12 at 9.13.07 PM

Once you’ve done that, mash the Connect button and you’ll start to see the familiar Chanalyzer Pro interface with all of the wonderful resolution we all grew so fond of all those years ago! For reference, I ran Chanalyzer Pro with CleanAir on the same machine at the same time as a Cisco Spectrum Expert instance (using the CardBus adapter). Aside from the waterfall flowing up in the Cisco product, and down in the Chanalyzer product, you’ll see striking similarities in the respective waterfall views:

Screen Shot 2013-08-12 at 9.21.24 PM

Screen Shot 2013-08-12 at 9.21.41 PM

and at the same time, getting all of the other awesome details out of the Cognio SaGE like interferer auto-classification and AirQuality Index. Proving once again that MetaGeek are the top kids on the block when it comes to innovation and integration – but don’t take my word for it, head on over to MetaGeek, grab yourself a copy and give it a spin!

Full Disclosure: As an delegate of the Wireless Field Day event, I was given a copy of Chanalyzer Pro with CleanAir to play with without promise or commitment to write anything – much less something positive. 🙂 MetaGeek is a regular supporter of the Tech Field day events and generally makes awesome products and is regularly engaged in Social Media – you should go follow them at @metageek and catch up on the NoStringsAttached Show where Blake Krone and I also talk with MetaGeek about Chanalyzer with CleanAir!