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.

Power
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.

Advertisements

My wireless literally burns me.

WARNING: this post includes uncensored pictures of a potentially provocative area of my body. While not Rated R (or even PG-13) you are hereby warned to avert your eyes if you believe that you may be even mildly offended or worse, intrigued.

When I was younger I had a lighter leak in my pocket. Unbeknownst to me, lighter fluid leaked all over my upper thigh and by the time I realized it, I had a hand-sized chemical burn where my pocket normally rests on my thigh. After some time (and discarding an otherwise perfect pair of pants!) the irritation went away.

Fast forward to several years ago and I noticed a similar ‘irritation’ forming on both of my upper thighs underneath my pockets. Since I’m a fairly light skinned guy – not albino, but still pretty light and pretty susceptible to sunburns in general, I wrote it off as pocket irritation. I couldn’t find any reasonable rhyme or reason to the general pocket-sized redness and irritation that I was experiencing but didn’t pay it much attention. Being, what I consider a professional in my industry, I recently decided to ‘up my wardrobe’. As a reasonably tall fellow I opted for custom pants among other things and the particular pants that I received included a right-hand pocket-in-the-pocket that was a perfect fit for my wallet! (Follow me here) When I started wearing said new pants, I consistently kept my wallet in the small right pocket which had the side effect of keeping my left pocket as a perfect place for my phone! I started getting into the habit of keeping my phone in my left pocket even when I wasn’t dressed for work. Then one day I noticed, the light, even, and spread out irritation that I used to carry on on both of my upper thighs started getting really bad on my left side – immediately under where my phone fit and has completely disappeared on the right!

Now, I’ve been around the wireless industry for a while now and I’ve heard it all the way up to wireless gives me headaches, so I’m not one for conspiracy theories, but the skin irritation that has followed my phone (and cleared up where my phone no longer is!) has given me a good reason to re-consider the potential risks that may be involved in wireless networking. My phone has not gotten hot, so I’m left with assuming that the skin irritation I’m experiencing is being caused by nothing short of energy radiation burns (not radioactive, silly!). Maybe it’s WiFi, maybe it’s cellular, maybe it’s bluetooth? Does it matter?

Now, I’ve not been to a doctor to have my burns officially evaluated (trying to not get a ‘don’t stick your finger in your eye if it hurts opinion) but there is a clear correlation between the location of my phone and the burns and irritations I’m personally experiencing.

IMG_6008 FullSizeRender

Having said all of that, I’m curious what you, the reader thinks. What do you think about my burns that have clearly followed my phone? Are short-range, long term exposure issues real? I for one will be distancing myself from my device until my burns go away, and likely for some time to follow.

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.

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