As much as I love to call out a vendor on marketing nonsense, Ramesh Prabagaran, Director of Product Management at Cisco, made some compelling marketing statements about SD-WAN at Networking Field Day 19. In particular he said:
Deploying the new Cisco 9800-CL wireless controller is fast and easy, and by using the built-in workflows, a new wireless network can be deployed in only a few minutes. In this post, I’ll review how to deploy the virtual wireless LAN controller in VMware ESXi and stand up a very simple WLAN. We’ll also take a look at some potential gotchas and some noteworthy differences between how the new WLC is configured compared to the AireOS WLC.
A phrase that really bothers me is “not my problem.” Usually I hear it in conversation with someone who learns of a problem but immediately seeks to absolve himself of any responsibility for the cause or responsibility to help.
I believe a networking professional, whether in pre-sales or working in the field, should have a deep understanding of networking concepts and strong technical experience. But also important are the soft skills necessary to build trust with customers, encourage strong relationships with account managers, and develop camaraderie and collaboration among teams. The words “not my problem” undermine those relationships and therefore shouldn’t be on the lips of a networking professional, let alone any sort of professional.
Only a few years ago, Cisco tried their hand at a converged access wireless platform with, among other devices, the Cisco 5760 Wireless LAN Controller. To this day, I have nightmares about that box. It wasn’t fully functional, and it had huge code issues. Today, in spite of AireOS being a stable, highly functional, and well-known WLC platform, Cisco is trying it again with a range of WLCs in the 9300 and 9800 series.
However, will this brave attempt prove to have the same fate as the 5760?
This week I taught my last class as a part-time adjunct instructor at a community college. I’ve been there for six years – 12 consecutive semesters. Each term, alongside the actual curriculum, I incorporated my work experiences and lessons learned about the reality of working in IT. Making the class meaningful from a real-world perspective was very important to me.
For my very last class, I chose not to cover anything in the textbook or any of the bullets on the syllabus. Instead, I introduced my students to systems and network automation. What may seem old news to you and me was brand-new to my class, and I don’t believe this is the exception.
Recently I upgraded a customer’s wireless controllers to the latest Cisco 5520 WLCs, but because their environment had a mix of brand new access points and somewhat old ones, I had to use an outdated version of code that resulted in some weird client issues on the new APs.
As part of a larger Cisco Firepower project, I had to install the Firepower Management Console for a customer recently. I was using FMC version 6.2.3, and the customer was running ESXi 6.5. I’ve had issues deploying OVFs in ESXi 6.5 before, but this one required some new adjustments I’ve never had to make in order to get FMC to install.
I know a few engineers who get down on themselves for not being part of certain online networking conversations or not being part of particular slack groups. I like to be reasonably transparent with my friends, so it’s been humbling to have folks be transparent in kind and share that struggle with me.
I had to deal with an issue with a wireless network guest portal for a customer recently that had me and TAC stumped for a month. The splash page seemed to load fully, but there was always a small spinning circle in the center suggesting something on the page didn’t quite finish loading. It resulted in end-users seeing an intermittent but frequent error when they connected to the guest wireless getting the redirect URL to the guest portal page on Cisco Identity Services Engine 2.3. The error was
[ 400 ] Bad Request,The request is invalid due to malformed syntax or invalid data
and here’s what I did to troubleshoot and eventually fix it.
Working for a VAR means that I’m quickly moving from customer to customer, from project to project, and from technology to technology. Often there’s an expectation that I’m able to configure anything and everything on the fly, and with little to no knowledge of a customer’s network. However, moving at this pace and having to touch so many technologies means that I’m sometimes working with tech I’m only vaguely familiar with and without enough hours to dig into training.
Recently I was in the midst of setting up a simple two node Cisco ISE 184.108.40.2068 cluster and got to the stage when I registered the secondary node through the GUI of the primary. At that point, things wouldn’t work.
I’ve been an active part of the networking community on social media for only a few years. Before that I was a passive consumer of tweets, blogs, and videos. A previous manager inspired me to be more active, and very quickly after engaging directly with bloggers, podcasters, and engineers, the value of being an active participant became very clear to me.
I’ve been doing quite a few wireless networking projects lately, and often that also means Cisco ISE, Prime, location services, and that sort of thing. I really enjoy it, but it’s a funny story how my heart changed from loathing wireless projects to looking forward to them.
I spent about a year completely focused on network security, and one thing I learned was that spending all my time focused on securing the perimeter to the neglect of intra-LAN traffic was a recipe for disaster.
Most of the traffic in our data centers is east-west, with only a small fraction actually being northbound out to the rest of the world. The cost of massive firewall appliance clusters operating at line-rate is astronomical, and it doesn’t make sense to punt traffic all over the place if there’s a better way.
Locating a wireless client in real time and viewing its location history in Cisco Prime Infrastructure is a little bit different with CMX than with MSE. In this post we’ll walk through the few steps to locate a wireless client among all your maps and then view its location history.
Servers, especially Linux servers, have been managed programmatically for years. Today, it goes almost without saying that a decent IT department is running Chef, Ansible, or some other tool to manage their servers as pools of resources.
What strikes me as odd is that this didn’t catch on in the network side of the house. Of course, there are always exceptions. A look at networking forums from years ago will showcase a few ambitious engineers arguing over using Expect or Perl scripts to manage their switches, but this was the exception in the networking industry, not the norm.
At Networking Field Day 17, several vendors that have long embraced network programmability turned their gaze from the data center to enterprise networking, and it seems as if networking may be finally ready to catch up to what we’ve been doing with servers for decades.
When I was a new high school English teacher I sat through a class on grammar my department chair taught to her 7th graders explaining a preposition is a word that describes anywhere a mouse can go. I’ve never forgotten that.
A few years later I changed careers to IT and found some very helpful mnemonic devices and acronyms that helped me remember various aspects of networking.
Here are a few that I used over the years:
Oh no. Pings stopped.
A cold breeze raised the hair on the back of my neck while I stood motionless in front of rack 5 in aisle 7. I much preferred standing in the hot aisle, but this is where the KVM console was. The screen flickered as I adjusted the angle of the monitor. This thing was ancient, but at least I had something to work with.
Last night I tweeted the question:
It was Sunday night, so I didn’t get an overwhelming number of responses, but I did get more than a few.