Why Enterprise Wireless Networks Got it Right

Why Enterprise Wireless Networks Got it Right

I wanted to post some 802.11 wireless usage numbers and device breakdowns. These are two week University usage numbers in August of 2012. This period is right before students return so I wanted a baseline to capture the diff when students 25,000+ students come back with the ever growing amount of 802.11 wireless enabled BYOD hidden in pockets and purses. Apple is 50%+ in all categories other than total traffic by vendor where is is slightly less ~%45, which I would speculate is due to so many of those devices being mobile devices that would likely consume less traffic or more mobile optimized traffic loads. Most of these numbers will likely come close to doubling in the next few weeks has been pretty typical over the past few years.

Before the Pictures

While I love to look at aggregate data like this, this post was not to point out that Apple dominates in this demographic. The purpose of this post is to exemplify in what I believe to be, the desperate need for a centralized approach to managing medium and large scale enterprise networks. I am so used to people parroting entrenched enterprise networking vendors explain all of the reasons why centralization would never work I don’t bat an eyelash anymore. All the while the same manufacturing naysayers are making huge profits on centralized 802.11 wireless delivery. The fastest growing space in the average medium to large campus network is wireless with a centralized controller. Collapsing forwarding and RF management into one or more centrally managed and orchestrated Borgs has been the only thing that has kept large scale 802.11 Ethernet deployments coming close to a functional service.

“The idea that one generic controller will be able to control every forwarding decision on a plethora of network types is seductive, but in the end unlikely.  The idea that many applications on many types of controllers can integrate and optimize local forwarding decisions is compelling and well grounded in history.” – History as a guide to SDN’s coming evolutionhttp://blogs.cisco.com/getyourbuildon/history-as-a-guide-to-sdns-coming-evolution/

I learned long ago to never say never. I agree we should learn from history and I am quite fond of trying to not make the same mistake too often (rarely successful). I recall a company that said the same very thing about the wireless market needing to stay distributed and was one of the last to adjust products to reflect that centralization in 802.11 had won hands down.

 It’s the Management Stupid

Down the road, when we reflect on this period, for networking to even contemplate staying the course in a completely distributed decentralized fashion (within an administrative domain), will sound just as unmanageable as someone today saying x86 virtualization and wireless centralization is inferior to standalone and decentralized. The Internet will always be decentralized and as it likely should be by virtue of crossing administrative domains, but that doesn’t mean we need to model the Internet in our internal administrative domains to have functioning serviceable networks. We can achieve distributed failure, state distribution and loop free topologies just as the wireless technologies have proven without the use of Inter-AS protocols and architectures.

SDN Can Solve the Edge Problems

Core networking gear is not something we touch daily, tag in swap, pop, done. My buddy Murphy McCauley at UC-Berkeley describes it as simply solving the problem of the edge. I think thats spot on from enterprises to service providers. I am putting my money on evolution as opposed to another decade of proprietary hardware, software and APIs. SDN will solve many of the edge problems that keep the network “in the way” of IT and business. At the top of my problem list is management (not this management, lol my favorite post of the week had to plug it) To name a few of the many challenges both technical and more often than not operational in the Enterprise is, flipping Vlans, managing what few features should be there, multi-tenancy, provisioning/de-provisioning, security/QOS policy and capacity planning. Along the way we may actually learn to do something with value with the vast amounts of data we let die as the logs rollover with no one ever having any analytics to have touched it. In the meantime we can look to the wireless market and technology drivers who saw the need to manage client RF along with the litany of operational issues and thank them for providing an innovative roadmap.

On to the Pictures!

Figure 1. (14-day 8/12) Aggregate usage for a campus zone.

Figure 2. (14-day 8/12) 802.11 client 802.11 wireless device summary by vendor.

Figure 3. (14-day 8/12) 802.11 client session time by vendor.

Figure 4. (14-day 8/12) 802.11 client sessions by vendor.

Figure 5. (14-day 8/12) 802.11 client traffic by vendor.

Figure 6. (14-day 8/12) 802.11 client breakdown by vendor

I would love to be able to compile neat breakdowns like this with the gear and software we already purchase from wireline products. Someday maybe. Exciting and fun times to say the least, get involved!