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.

Advertisements

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

The FCC.

Here in the states, we have a regulatory body called the Federal Communications Commission (FCC). As it pertains to the Wi-Fi world, they tell us what channels we can use how obnoxious we can be (strength) in those channels. We have what you would consider to be a ‘blanket rule’ that basically states ‘within a given number of frequencies, you can do anything you want as long as you limit yourself to a maximum power’. A very intentional byproduct of these rules is the relatively low cost of WiFi components. Since we don’t have to submit everything we operate to the FCC for validation, we have no ‘validation costs’ to pass onto our end users. In short, the FCC, as a regulatory body imposes rules and restrictions on our use of wireless frequencies in the name of the greater good. This generally works very well, creating the ecosystem of ‘small cell’ give and take that we live in today. You are given the choice to make your own determination if analog video cameras, microwave ovens, X-Box controllers, etc should take priority or if your Wi-Fi should. Political challenges aside, we’re masters of our own domain.

So what happens when someone does something outside the norm? What happens when someone violates the FCC specifications? What happens when someone fires up 10 watt outdoor analog video feed in 2.4GHz and points it at the broad side of a hospital?

As it turns out, someone recently did just that. I was asked to assist with locating what was being detected as a whole bunch of analog video cameras that hogging up all of Channel 1 in 2.4GHz along the broad side of a hospital. As you could imagine, with a good 100 or so Access Points all excluding channel 1 (due to interference) from their channel plan, this meant that a two channel plan was all that was left (6 and 11). After much sleuthing, we determined that the signal was traveling well in excess of 10 city blocks! In my book, that certainly fit the bill for ‘obnoxious’. With more than a little hesitancy, I went to the FCC web page for complaints and filed one.

We're concerned with Wi-Fi Jammers.

We’re concerned with Wi-Fi Jammers.

Once my complaint went off into oblivion, I’ll be honest with you, I didn’t expect to hear anything from them at all. Instead, a few weeks later, I got a letter in the mail with the usual FCC ‘devices must accept interference’ text that you’d expect from a Federal entity. I was heartened by the fact that I got a response however, and there was a ‘for more information call this number’. They offered, I did. The nice Federal employee took my call, listened to my acknowledgement of the letter, listened to my insistence the letter was insufficient, and listened to my complaint that there was something going on that the FCC clearly needed to get involved in. She thanked me for my time and stated that she would escalate my case. This was the last I personally heard from them.

I was fortunate enough to have some contacts near the building that we suspected was generating the noise. Sure enough, a couple of weeks later, they informed me that a FCC field agent showed up asking questions. Shortly thereafter, the video camera signatures stopped being detected, the channel cleared up, and things got back to normal at my customer.

The point of all of this is that you do have a friend in the FCC. They’re not the most communicative, timely, or ‘feel good’ organization I’ve ever worked with, but if you have no other choice, and you can prove reasonably that there is a strong need for them to get involved with a neighbor that being obnoxious, they will. Start to finish, once I engaged the FCC, it took roughly 2 months to get back to normal. Don’t expect them to be quick. Don’t expect them to believe you. Don’t expect them to understand what you’re saying. Do be patient. Do be persistent. Do be kind. You don’t want to make a Fed angry.

Here are some good times to engage the FCC:

  • You can prove beyond the shadow of a doubt that something beyond your sphere of influence is causing harmful interference to your Wi-Fi network.

Here are some good times to not engage the FCC:

  • Your ER department won’t buy new Microwave ovens
  • Your security team is installing analog video cameras
  • Your customers are bringing gaming consoles onto your property and using them
  • Your co-worker put a 20dBi antenna on a 200mW radio outside (although, this is a good way to get them called on you!)
  • You believe you have external interference, but don’t have a Spectrum Analyzer to prove it

If you need a Spectrum Analyzer, head on over to the MetaGeek folks and check out their Wi-Spy Mini or their Wi-Spy DBx for a good cost effective way to tackle interference issues. If they get too big, rest assured that Big Brother is out there – just a complaint form and a couple phone calls away…

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

MythBusters WiFi: Xirrus

I’ll be the first to admit that when I see something ‘out of the norm’ I shudder and have a knee-jerk reaction that is not always positive. There is so much success around the tried and true enterprise approach to wireless of using omni directional antennas that when you see someone intentionally deviate from it, it can be jarring to say the least! I’ve had the pleasure to be present at the Xirrus Wireless Field Day sessions for WFD5 and WFD6 and I can honestly say that they did a superb job of taking a contentious topic and addressing it head on. For those that are unfamiliar with the Xirrus product, their unique approach to wireless is to stack multiple Access Point radios into a single housing and use highly directional antennas to create an ‘Umbrella Corporation logo’ of coverage:

Image likely copyrighted by Capcom

(it should be noted that I do not believe that Xirrus is somehow evil, involved in genetic engineering, or otherwise a bad company – the logo is simply an easy way to represent a high degree of directionality from a centralized point)

Adding multiple radios into a single housing is not a unique approach. Most everyone on the market starts with two radios in their Access Points and you can even find a handful of three-radio solutions, but Xirrus takes this approach to the next level by stacking as many as 16 radios into a single Access Point! The challenge that other manufacturers do not need to address is overlap. In a standard two or three-radio approach, you typically operate one radio in 2.4GHz and the other in 5GHz (and for those rare 3rd radio guys, they usually stick that radio in monitor or listen-only mode). Tack some omni directional antennas on those bad boys and you’ve got yourself an AP! Xirrus however, intends to have multiple radios in a single AP operate on in the same frequency. This presents some challenges about the efficiency you can gain from having more than one radio in the same frequency in the same physical package (AP). At WFD5, there was much gnashing of teeth regarding how you accomplish this in one package. I’ll not go over the gory details, the video is posted here. Xirrus came back to WFD6 and brought with them their Director of RF Engineering, Avi Hartenstein and tacked the conversation head on.

My goal was simple with this post. I wanted to prove that directionality does exist in the Xirrus product once and for all. I was able to acquire a 4 radio array and decided that the best approach to visualize this purported phenomenon was to actually survey with an AP in an area with no obstructions (scientific, no?). I took the array, statically assigned one of the radios to a fixed channel, turned its power down to -15dBm (yes, they go *that* low!), and took it outside. The results speak for themselves:

 Umbrella logo likely copyrighted by Capcom

Ladies and gentlemen, you saw it here first (or maybe not) – the myth of the Xirrus wedge is real! You can see near the bottom of the image where the AP was placed (at random orientation). I peeled this wedge view out using Ekahau’s Site Survey application after quite a walk outside in the cold. This directionality is fairly easy to see even with my coarse sampling outside. It should be noted that it will be near impossible to visualize this dramatic of a wedge indoors however due to the prevalence of those pesky attenuators otherwise known as walls and furniture.

I’ve seen my fair share of wireless deployments, I know what I’m comfortable with, I know when I move outside of my comfort zone. An experience I reference often is an educational facility that was using directional patch antennas indoors on 10 ft ceilings pointed at the ground. While this is a startling design, when I dug deeper into their design methodology, I discovered that they surveyed using the exact model of antenna and AP that was deployed, correctly visualized the resultant zone of coverage, and validated that this met their applications need. While not a solution I would lead with, there was no fault with their design methodology or implementation, and the infrastructure operated as designed. When you tackle a Xirrus deployment, I would advocate the same approach: understand your needs (throughput, density, coverage, etc), and design to meet those needs using the gear you will be deploying. Survey what you deploy, deploy what you survey. In the Xirrus world, this presents a few design choices to consider:

1) Orientation of the AP.

The Xirrus array has a compass in it. Use this compass to determine the orientation of your array during the survey and ensure that when it gets deployed that this lines up correctly (use the logo on the housing if you need to).

2) Oversubscription.

You must pay close consideration to the number of uplinks to your array and balance this with your deployment expectations. Oversubscription is nothing new so don’t let this scare you – just be aware that you’re moving your uplinks (and potential bottlenecks) further up the line (closer to the AP). This is going to be particularly important as you consider updating your array to newer technologies such as 802.11ac.

3) Powering the Array

Ensure that you have made concessions for powering the array. This will likely require an external power injector but sourcing them along with the array should not be problematic.

4) Antennas change with the modules.

One of the most insightful things I learned from the WFD sessions are a reinforcement that the antenna is part of the radio module. When you replace that module, you replace the antennas that are a part of that module. This could potentially impact the RF of your deployment and will most assuredly change the visualization of your survey data.

Xirrus uses highly directional antennas in a unique way to extend the reach of a radio. This coupled with a low powered radio gives you a number of excellent design pieces for most any wifi environment or need. Pay close attention to the number of radios that you need, apply some logic and reason to your design (don’t expect 8 of your 16 radios to operate in 2.4GHz for example) and make sure your celling has sufficient mount points. The arrays can be weighty. 🙂

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? 🙂