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.

Wednesday, April 9, 2014

Scanning internal resources for Heartbleed:

Often I get tapped to look at or figure out things not directly related to the mobility space.  Today was one of those days, as we had a number of customer inquiring about Heartbleed, or CVE-2014-0160.  I won't go into a lot of detail about the mechanics of the vulnerability, but I have been pretty concerned with how do I know if my <insert linux based appliance i don't control> is vulnerable.

For public facing sites, there are a number of scanners, the one I use is over at  I tested a number of the cloud sites I use and found that one of my cloud wifi sites is/was affected.  But then the question came around of how to I determine if my internal resources were affected.

Monday, March 10, 2014

Aerohive Hivemanager: A System of Control

So you will never win an argument with an @Aerohive agent employee about controllers.  I've discussed with them how there are some things (a lot really) that HiveManager does that is a function that controllers do.  "Management Plane!" they scream in unison.  No-one who has faced an @Aerohive agent employee with the word controller has lived.  We are survived by not mentioning controllers around them, but sooner or later someone is going to have to fight them.

Well, this isn't the matrix Neo, but what @Aerohive does with their HiveManager product is implement a system of control.  That system is designed to turn this:

into this:

*EDIT: This is a joke. I'm not saying that HiveManager is a WLC.

Poor Abby, she gave me lots of fodder with her recent blog : What Is a WLAN Controller
It's a good article, well written and she articulates her point clearly, although I don't agree with most of it.  Please don't take this as an attack on your blog, but I think that the good ol' WLC will be around for a long time no matter how much the cooperative control marketing gets thrown around.

But Abby does try to define exactly what a wireless LAN controller is.  Something I challenged her to define.  And I did warn you #ItsATrap

Oxford Dictionary:

She goes on to define what she calls a wireless LAN controller, but i think she misses a lot.  Her definition is: "A wireless LAN controller is a device that directs or regulates traffic on the wireless network..."  I'm truncating her definition.  Not because I want to be snarky, but because you cannot define a WLAN controller by a vendor that sells WLAN controllers.

I actually find her definition pretty weak.  A WLC does a LOT more than directing and regulating wireless traffic.  I would say a better definition would be "A WLAN Controller directs or regulates the operation of a Wireless LAN."  While the distinction is small, a WLC is much more than the regulation of wireless traffic.  You could even say that a WLC is a collection of multiple "System of Control." A WLC also regulates what a wireless AP can or can't do based on its features. I'm going to take a discussion that I've had with Abby and other @Aerohive guys around their BR series of routers/APs.

Did you know that a BR200 can operate as just an AP/Switch?  Bet you didn't.  That's because it isn't supported by @Aerohive.   Now the BR100 does this and is supported.  So what I did was take the config that my HMOL pushed down to my BR100 (Thanks @Aerohive for providing me with one for attending #WLPC) and applied those same commands to my BR200 and Voila, an AP with a swiitch.  All the commands are documented in their CLI Reference guides but they are supposedly not supported because HiveManager does not support this on the BR200 platform.

The moral of this story is that HiveManager, a supposed "Network Management System" regulates what an AP can or can't do.  I would say that it is not a NMS because it regulates and/or directs what can or cannot be configured on the equipment.  And once you configure things via the CLI, 
forget about managing it with HiveManager.  Especially if you configure something that isn't possible with HM.  Here's another example:

When trying to configure a port-forward on a BR200, I ran across the limitation that HMOL will only allow you to forward a port that is directly connected to the BR200 (the BR200 is the L3 interface for).  I was trying to setup connectivity from my BR200 over to my home lab, and wanted to forward a port across a L3 routed link to my console server.  No dice, HMOL pukes when trying to configure this.  But if you configure the port-forward from the CLI of the BR200, it works, and works well (although likely unsupported).

There you have it, HiveManager, while not a controller, is certainly a system of control.  I'll tell you something else, even with a WLC not always do you "HAVE TO" have a NMS.  I can deploy a WLC in a small network and configure and operate it without deploying the NMS.  And while I'm sure you *could* deploy @Aerohive gear without HM or HMOL, it would be easier to try to rescue Morpheus from a military-controller building being held by three agents.  I believe even the @Aerohive team-members would suggest spinning up a temporary version of HiveManager to get the initial config implemented.

P.S. Please don't take this as "I don't like Aerohive equipment."  The hardware is what you would expect from an enterprise equipment manufacturer.  It's been great in the lab and my 330 has been driving my wife's wireless network for over a year with very few issues.  The BR200 and 100 have been also been good, but the lack of support in HMOL for features has left a bitter taste in my mouth especially around HiveManager.  I really think @Aerohive needs to take a hard look at Hivemanager and follow the philosophy of "As simple as possible, but no simplier."  Right now, the biggest thing holding back @Aerohive is HiveManager.

After a lengthy and good discussion on twitter, I thought i would clarify that I'm not saying that HM is a controller.  It is fun to make correlations between HM and functions that common WLCs perform.  When I say control, I do not mean a control plane.  I just mean that the HM exerts control over the equipment.  While it doesn't participate in the control plane, limiting what you can do on the equipment in my book is defined as control.
Evernote helps you remember everything and get organized effortlessly. Download Evernote.