Thursday, November 20, 2014

Hallway Design Nightmares Part2: TXPower

One of the effects of the hallway design is that Radio Resource Management (RRM) frequently doesn't work as expected.  It's not that it doesn't work, it's just that hallway designs significantly limit the perspective of how APs see each other, which is primarily how RRM determines what it should be doing.  Given that all the APs in the hall generally see each other at or about the same level, they all have a very similar view of the network.  For illustration purposes, I've mocked up an imaginary residence hall.  A specific hall that I visited recently was build with concrete walls.  We will talk about some of the things I saw, and how they apply to this generic sample floor.

For this example, I've place 3 APs where the black dots are.  Let's also assume that this is the 2nd floor in a 3 story building.

Hallway Design Nightmares Part 1: Introduction

A lot of people know that Hallways designs are a bit of a pet peeve of mine.  My opinion is that they do not work, and beyond moving the APs out of the hall, you cannot fix them.  But the reality is that moving APs and existing infrastructure can be really expensive, time consuming and difficult to get management to buy off on.  This means that you probably will have to live with some of your existing hallway designs for the foreseeable future.

In this series, my aim is to explore the options available to improving performance of a hallway design.  As an engineer working for a Cisco Gold Partner, I'm going to talk about some of the tools available in the Cisco Unified Wireless Network (CUWN) to help deal with these designs.

I'll leave this short intro post with the following advise:
Don't put APs in the hallway.
Put APs as close to clients as you can get them.
Think about how RRM works, and incorporate that into your designs
Don't put APs in the hallway, PLEASE!

Monday, October 6, 2014

Avaya: Building the Shortest Path Bridge

It's been... well a while since Avaya presented at #WFD7 and I find myself thinking once or twice a day about SPB networks and how someone (maybe even me) might build a campus network using this technology.

Tuesday, September 2, 2014

Airtight and Scrape: An Interesting Social Wifi Use Case

Social Wifi is one of those polarizing topics where people are either "Meh, I don't care," or "OMG, NOOOOO!"

At the latest Wireless Field Day, I had the pleasure of meeting Drew Lentz (@Wirelessnerd) who I've interacted with over Twitter for a couple years.  At Airtight, he was presenting Scrape, an application and use case for social Wi-Fi.  There's a lot to like about Scrape.  One is that you trade your social media information for a better experience.

Monday, August 4, 2014

Teaser: Project Rawrbox - My idea for remote wireless diagnostics

So I'm sure everyone has noticed that the blog has quieted down a bit since #WFD6.  I could tell you that work's been busy, that I've completed my CCIE-W (#43153), but those are excuses.  I will put some more focus into the blog for the next few months as I wrap up some things in the real world.

What I can tell you is that I have been working on an new project that I hope to complete in the next few months.  I had hoped to have it ready to show off to the other delegates at #WFD7, but it's not going to make it.

The idea behind the project is simple.  A wireless diagnostic rig that I can ship to a remote site and perform basic packet captures, performance data and maybe even specturm analysis for under $250 USD.  The goal is to publish the software as an RPI image and give others the ability to use some of the tools I've built to create their own rigs.  The plans, software and image will be published for the community once it's finished.

Today the hardware looks something like this:

Raspberry PI B+ running latest Raspbian
High Performance MicroSD Card (Lexar)
3x USB Pigtails (2x RH, 1x LH)
3x USB Wifi Adapters (currently evaluating)
Pelican Case
TP Link PoE Splitter
Miscellaneous usb and power cables.

Currently I have a number of Python scripts to automate the packet capture process, uploading of files to both an FTP server and Cloudshark and am working the task scheduler right now.  I have support for AutoSSH for remote management.  Eventually there will be a web interface to simplify the operations, and a setup script to personalize the image to your environment.

There are some hardware limitations with the RPI hardware, but I'm hopeful that I can overcome most of these to get this project published soon.

Thanks for your patience and you'll see more on this soon.

Why SDN is coming to a wireless network near you

We are literally days away from the 7th installment of Wireless Field Day.  I'm really hoping (borderline begging) to hear a couple vendors talk about their Software Defined Network (SDN) solutions.  Now before you hop on the "Shut-up about SDN" bandwagon, here's why I see this as a hot topic right now.

I see SDN changing the way we build networks, and not just in the datacenter.  In the past we built large L2 networks and we eventually hit scaling limitations.  Then we started building routed networks, which solved the scalability problems, and introduced a whole new set of challenges around management of L2 domains, L2 adjacency requirements and troubleshooting routing protocols.

With SDN, the possibility arises where we could have the best of both worlds, and hopefully not the worst of both.  I believe that we will start building underlay L3 networks between our core and access layers, and all the L2 will exist as a dynamic overlay on top.

And since a lot of wireless vendors already have a tunneled overlays for their wireless traffic, the question is not IF SDN will be coming to a wireless network near you, but when, and how will that look.  Just the idea of having VXLAN dynamic overlays for your wireless clients, gets me all excited.  And with VTEP support being baked into silicon for switches, there are a lot of possibilities for new and innovative solutions to emerge.

I hope you will all join in on the Wireless Field Day experience this week, there will be some great discussions, both around SDN and other mobility topic.  All the sessions will be streamed live over at the

Sunday, July 13, 2014

Thoughts on Eliminating VLANs at the Access-Layer Edge

There's a lot of talk in the industry about getting away from VLAN segmentation and relying on stateful firewalls at our access-layer edge to govern control over what users have access to.  This is a great idea, it solves issues with IPv6 and it simplifies network design.  But there are some significant challenges that make it a no-go for today's enterprise networks.  Most vendors are touting their "stateful" firewalls in the AP and edge switches solves those challenges. But I find the current generation of these solutions inadequate to solve this issue in enterprise networks.

Issue #1: I need your identity at more places that the access-layer edge
Web Content Filtering is a great example of needing your identity elsewhere in the network.  In a restrictive corporate environment, there are Active Directory integration that help solve these problems, but what about non domain devices?  What about organizations with the Internet of Everything?

I've seen solutions from Radius Accounting integration to agents on Domain Controllers, but these are usually point solutions and I personally have not had good luck with these nor are they widely supported.  Also they are single device specific, so you can't send it to multiple devices for determining identity.  Datacenter firewalls are another place where this falls apart.  How do I write an ACL based off your identity when I may or may not have your identity.  The solution inevitably leads to more identity verification: Captive Web Portals, VPN clients, etc.

Issue #2: Scalability of ACLs
Anyone who has tried to write complex ACLs to govern what a client can or can't get to, can tell you that ACLs get very unwieldy very quickly.  You CANNOT effectively write ACLs for every resource and port that every potential client should be able to get to.  It's also not effective as these ACLs take up precious TCAM space in our network equipment.

The solution to this problem is an identity exchange.  Cisco has a pair of technologies called SGT and SXP with ISE or ACS (part of their TrustSec solution) that attempts to solve this problem.  Instead of filtering traffic with ACLs on ingress to the network, they identify identity at the edge and pass that identity information to the rest of the network and filter packets on egress of the network.  Both protocols are Cisco proprietary, but the idea is sound.  While I'm not a fan of having to have special hardware to pass this info around the network, the idea of a central identity repository that all devices have access to solves the issue of having to filter all packets at the access-layer edge, we allow the rest of the network to share in this burden and create a solution that scales.

Jake's Opinion:
Personally, I don't think we will see single VLAN designs be successful for quite some time.  The wide variety of firewalls, web content filtering, lack of network-wide identity and complex nature of BYOD policies really prevent us from completely abstracting out the devices IP addressing.  My hope is that with the upcoming SDN-apocalypse that we will see SDN solutions providing ways to distribute identity throughout the network and get us closer than ever to the simplified access layer edge that so many vendors are suggesting today.