There’s this guy I know. He works for Aerohive and works with the 802.11 working group. His name is Matthew Gast, and he writes books that make me lose sleep in search of further understanding. You may know him from the 802.11 Wireless Networks book and maybe even the more recent 802.11n: A Survival Guide book. That isn’t where I know him from. The first book of his that I read was this one:

In case you aren’t familiar with this book, your eyes are not deceiving you. That is a book on T1 circuits and it drove me insane for a brief period. Several years ago I was reading every technical book I could get my hands on in terms of networking. I had a subscription to Safari Books Online and I was plowing through title after title at rapid pace. Lunch hours, late nights, and weekends were spent absorbing as much as I could because I couldn’t stand the thought of not knowing about everything there was to know about networking. I was working a job where there were literally hundreds of T-1 circuits spread out across a nationwide network. Any additional information I could use in regards to those circuits would be beneficial and I would be able to converse with the service providers more on their level, which would help reduce the time spent troubleshooting.

And so it was that I summoned the powers of my Safari membership and began to read an entire book on the T1. My mind was exposed to things I was somewhat familiar with. Line coding and framing modes were terms I was used to muttering when asked about how the circuit was configured. B8ZS and ESF were the stock answer, but what did they really mean? That book on the T1 exposed me to the meat and potatoes of B8ZS and ESF. I could see the 1′s and 0′s clearly. I suddenly knew how circuit alarms were generated. I was able to comprehend why the serial interface on a router showed a bandwidth of 1536kbps instead of 1544kbps for a T1. It all made sense. So much sense that I went off the deep end.

I became obsessed with Extended Superframe. I wanted to read binary and find the framing bits vs the standard channel data. In turn, I became obsessed with the Ethernet frame as well. Reading raw hex in Wireshark, I would try to see where the Ethernet header was, the IP header, TCP header, etc. It was a wild and informative ride, but I finally had to come to the conclusion that nobody really cared about that stuff. You couldn’t talk to people about it because they just didn’t feel the need to know that level of detail. It’s one thing to talk about something like BGP in great detail. There are plenty of people that will gladly engage you in those kinds of discussions. It is a completely different kind of party where people want to discuss the finer points of B8ZS vs AMI or why ESF yields 1.544Mbps when you add all the 1′s and 0′s up. The ONLY people that are probably even remotely interested in that stuff are voice engineers. Even then, apart from understanding sampling rates, and why a DS0 is 64kbps, they probably don’t care about the rest.

I put that period of insanity behind me. I swore off the urge to obsess over the finer points of technology and wanted to just be a decent all-around network guy. The following years were full of routing, switching, wireless, load balancing, WAN optimization, monitoring, firewalls, and any other type of networking to be had. Nothing too crazy and nothing too deep.

Fast forward a few years and I had read a few more of Matthew’s books:

And then, about a month ago, I got my hands on an early release copy of his new book:

I read the entire thing, and for some reason, I had another “T1 episode”.

I’m currently on week 2 of layer 1 obsession as it relates to WiFi. Suddenly, I don’t feel competent in the realm of wireless until I can whiteboard every little thing that happens when the energy leaves the antenna on the AP and makes its way to the client or vice versa, and I am not even concerned with the higher layers yet. I find myself watching anything on YouTube that even remotely resembles RF fundamentals. I’ve got several books from different publishers on wireless communications that I have been skimming through, but I still want to know more. What I want is what I cannot have and that is to be able to see those little wireless waves travel through the air. I want to see that phase shift. I want to see the amplitude adjustment happen in a split second and be able to map a point on a  constellation diagram and know that the little dot that I just mapped is the binary equivalent of 01100101. Of course, that might be asking too much and how many customers would even be interested in that level of detail? It would probably weird them out if you started spouting off binary strings like you had a bad case of Tourette’s syndrome.

I hope Matthew’s next book will be a picture book. That would make it easier on me.

That led to a broader discussion around how we in the VAR world can verify that all the moving pieces work together and all potential problems are identified before any implementation or upgrade. This particular engineer had just come from a much larger environment where he had Spirent testing gear and plenty of spare hardware to test things before deployment. His contention was that you could really add more to the “value added” part of VAR if you could offer additional assurance around deployments and upgrades.

What Usually Happens?

If a client needs to upgrade their code on certain hardware, they typically have to rely on release notes and upgrade instructions from the vendor. Maybe there is a known bug list available for the version they are upgrading to. Maybe not. It depends on the vendor. They also might just update the code after the first update beyond the major release has been released. For example, platform X gets upgraded to ver 2.1 since it is the first update since ver 2.0. I’ve been in quite a few environments where the rule of thumb was not to upgrade any software until the first service pack or major patch had been released.

No matter the approach you take from the above choices, you are taking a risk that all will go well. If you are a large enough organization, or possibly tech focused, you might have a lab that has the same hardware as your production network. If so, you can actually do comprehensive testing, provided you actually have time to get that done. After all, you have meetings and conference calls to sit through right?

Current Testing State

From my sloppy and lazy research, which consisted of asking a question or two on Twitter and also reflecting on past experiences, I was able to determine a few things:

1) Vendors do extensive testing on their products. This may sometimes include other vendor hardware, but will probably not encompass anything more than the most common scenarios.

2) VARs will do testing on a case by case basis, but only the big ones are going to have the right gear to do that.

3) If you REALLY need to make sure, and you are a good enough customer, you can go out to a customer proof of concept center run by the vendor whose gear you are using and they can test various scenarios for you.

4) Just do the upgrade, call support if it breaks, and let the vendors slug it out with each other. After all, that’s why you pay them for maintenance and support.

What Could Happen?

Imagine a world where you could go to a VAR and ask them about potential problems with a code upgrade or a multi-vendor implementation project and they could tell you what you could realistically expect. I’m not talking about the “we’ve done this before and never had a major problem”. I’m talking about them being able to take your present network state and future network state and give you some concrete information around what your experience will be post-upgrade.

My initial thoughts were that a VAR could sink a pile of money into a lot of lab gear and start building out various tests and have engineers break things and fix them. Of course, that means those engineers aren’t out getting those ever so important services dollars from post-sales efforts, or they aren’t smooth-talking customers over fancy meals during pre-sales engagements. You have to be willing to take the loss on the testing engineers with the hope that you make the cost of their salaries back in fees from clients.

The particular client who filled me with this idea suggested that it might be better for a company to do this testing and then sell that information to VARs in some type of package deal. Perhaps along the lines of a subscription service similar to what a company may do with Gartner to gain access to their reports and analysts.

Plausible Scenario?

Customer ABC goes to VAR XYZ to get some advice on a planned code upgrade of their distribution switches. These switches run OSPF and have neighbor relationships with their firewalls as well as some routers. The switches, firewalls, and routers are from different manufacturers. Customer ABC just wants to make sure they can perform the upgrade without their network exploding. VAR XYZ has consulted the testing company, and they are able to provide them with information regarding those particular products and the code levels they are running and are going to run after the upgrade. VAR XYZ then passes this information along to the customer, who decides whether or not to proceed based on the test results.

Closing Thoughts

Is that a realistic endeavor? Could it be done and have credibility? I think so, provided there is no money coming from vendors. That just ruins it in terms of credibility. That isn’t to say that you can’t extract value from vendor sponsored tests. You can, but you must take that with a grain of salt.

Of course, any type of company doing the testing would require about a billion pages of legal mumbo jumbo to avoid getting sued. They would also have to have some pretty precise testing methodologies to ensure valid results. There’s also the issue of not being able to test every possible scenario and pre-package the results. You could develop the most popular configurations over time and test one-offs when requested.

What do you think about something like this being a reality in the IT industry? Would companies pay for that kind of data or is this not realistic?

If you are like me, you connect to a wide variety of wireless networks. Sometimes, you need to share the pre-shared key to a particular network, but don’t remember what it was. Your laptop just automatically connects to it without prompting you. There is a way to see what password is used for each wireless network you connect to using a pre-shared key for authorization. Using the following steps, you can recover the actual password used:

1. Open the “Keychain Access” program under one of the following methods:

A) Select”Applications” and then “Utilities”:

B) Select “Launchpad” from the dock, followed by “Other” and then “Keychain Access”.

***Note – I realize there are other ways to get to the Keychain Access program via the CLI and GUI. I chose the 2 methods that I thought were easiest to find.

2. Once the “Keychain Access” program opens, select the “login” keychain, and then select “Passwords” under the category section on the bottom left of the window.

3. Select the network you want to recover the pre-shared key from and either double-click it, or select it and hit return/enter.

4. The next screen you see, should look like this:

5. Check the “Show password:” box, and you should get prompted for additional access. This will look like the following 2 windows. It might only be a single window that prompts you. In any case, enter your account password you use to login to your Mac or the password you use for sudo/root access.

6. After successfully authenticating with your account password, you should see the plain text password in the “Show password:” field.

That’s all there is to it! Now you can share the PSK with another device or person.

I changed my mind though. I stopped thinking about it from an enterprise or large business perspective and started to think about it from a mid-market or SMB perspective. Then, it started to make sense and I started to get excited once again. Like a hormone raging teenager with bi-polar tendencies and no medication, I went from happiness, to dismay, and back to happiness.

What’s The Big Deal?

The fact that a wireless company just announced switches should not be earth shattering news. Aruba did it some time ago. Meraki did as well. Cisco and HP have always had them, but they do so much more than wireless, so it is hard to count them in that group.

I thought it was interesting when Meraki announced their switches, but that was because they were cloud managed, unlike Aruba’s switches. It had nothing to do with the hardware itself. Most access switches are boring. 24 or 48 ports of 10/100/1000 with some or all being PoE or PoE+. It doesn’t quite have the pull with the masses that it used to.

For larger networks, cloud managed switches aren’t a big deal. For smaller companies with distributed environments, it is a big deal.

Why Is It A Big Deal?

My sister has an Aerohive access point in her house. Nothing fancy. An older AP 110 model, so she can either run 5GHz or 2.4GHz, but not both at the same time. She had a smaller Netgear unit before switching to Aerohive, but that AP was not getting the job done. I gave the AP to my brother-in-law and told him to just plug it in to their Internet connection at home. I would do the rest without coming by their house. My sister texted me a day or two later while I was at home sitting on the couch and I remotely configured her AP, texted her the SSID and PSK and that was it. Later on, she had issues on 2.4GHz due to interference from the surrounding neighbors, so I switched her over to 5GHz, since all she needed was connectivity for her iPad. Problem solved, and I didn’t have to do more than about 10-15 minutes of work. I even used the remote spectrum analysis tool to figure out what was happening on the 2.4GHz band prior to shifting her to 5GHz.

Imagine that on a larger scale. What if I had a dozen locations that needed a single AP or a few AP’s? Using a cloud based management platform like Aerohive’s HiveManager Online(HMOL) means I don’t really have to even touch hardware before it gets sent to whatever location it will be operating at. As long as there is an Internet connection, I will be able to access that hardware remotely.

That’s great for wireless AP’s, but what about the other gear? My remote locations probably have a router and a switch. It is fairly common for the service provider to take care of the router for companies will little or no IT staff. It is one less thing they have to worry about. With Aerohive announcing switches, that run the HiveOS code that the AP’s do, guess what I am also able to do? You guessed it. Deploy switches without necessarily having to pre-configure them. All the interesting things I did on the AP’s from a security perspective, I can now do on the switch side. That may not seem like a big deal, but remember that in the mid-market or SMB space, this will help out tremendously.

In short, this is about time and resources. I don’t have to spend a lot of time staging equipment before sending it out via FedEx/UPS. I can ship it direct to the site and then remotely configure the gear. I also have the ability to monitor everything through HMOL. No separate management systems for wired and wireless. You can get this functionality with Cisco, HP, and Aruba, but it isn’t going to be as trouble-free and it will most likely cost a lot more. The one exception to Cisco being that they now own Meraki, and Meraki has switches and AP’s that are managed via the Internet in a similar manner to Aerohive’s HMOL platform. I can get similar functionality to what the larger networks are getting with their management/monitoring systems.

But Wait. There’s More!

It doesn’t end with the switches though. Aerohive has also announced Application Visibility and Control(AVC). If you follow the networking space, you know this has been a big deal for several years. On the firewall side, Palo Alto came out swinging a few years ago with a firewall that could peer into the network traffic and determine what applications were in use and let you filter based on that. You want to block Netflix? No problem. Want to allow Facebook timeline, but no games like Farmville? No problem.

Other vendors followed suit and released their own application aware capabilities. For all I know, they were working on it long before Palo Alto. Doesn’t really matter. Cisco, Juniper, Checkpoint, Palo Alto, and others have application visibility baked into their firewalls now. The wireless industry followed suit. First, it was Meraki. Then, Aruba and Cisco came out with their own application visibility solution. Now, Aerohive has announced theirs.

I could mention a bit about Aerohive’s AVC solution, but I would rather you just read my friend Chris’ post instead. I’ll simply add that AVC gives smaller customers insight that the larger ones probably already have. It levels the playing field. Expect to see more information about this in the near future from others.

Here are a few articles about this announcement from others:

Aerohive Is Switching Things Up – The Networking Nerd

Aerohive Launches Cloud Managed Switches - Lee Badman