Author Archives: networkingnerd

Unknown's avatar

About networkingnerd

Tom Hollingsworth, CCIE #29213, is a former network engineer and current organizer for Tech Field Day. Tom has been in the IT industry since 2002, and has been a nerd since he first drew breath.

Why Do You Still Blog?

Posted on by
2

After recording an excellent session on social media at Cisco Live with The Network Collective (@NetCollectivePC), I started thinking about blogging and where it stands in the grand scheme of information sharing. With the rise of podcasting and video blogging now in full swing, I was even asked by my friend Michael Stump “Do you see blogging as a dying form of content?” For obvious reasons, I said “no”, but I wanted to explain two major reasons why.

Needle In A Haystack

One of the major reasons why I still blog through written form is searchability. When I started blogging almost seven years ago I wanted to create a place where I could put down my thoughts about topics and share them with everyone. More by accident than design, many of those thoughts became popular topics of conversation. Even today, some of my posts are being used to help people figure out problems and address issues that aren’t well documented in other places.

But why? How can posts many years old still be relevant to audiences today? Because of searching. Use of Google, DuckDuckGo, and even Bing allow people to search for specific error messages or topics and find things that I’ve written down. That’s because text on posts is easily indexed by web crawlers. Even when my posts are excerpted on other sites it just drives more people back to my blog to find my content. The power of being able to find something can’t be understated.

But what about audio and video content? How can it be searched? Sure, you can write down show notes. But show notes are like network and systems documentation. At first, they’re very detailed and useful. But after time passes, they are essentially the bare minimum necessary to be able to move on. That makes it difficult to search for specific content inside of an episode. In fact, the show notes from most podcast episodes would be content for two blogs!

Additionally, the banter and discussion during the episode are hard to capture in text format. If the show notes mention that the guests spend 3-4 minutes talking about some topic, realize that most people speak in conversation at around 125 words per minute (wpm). With two guests debating the topic for 4 minutes, that’s 500 words or more on a topic! How can you capture the essence of the discussion in a single line show note with perhaps one or two links to outside material? Blogs allow all of that to be tracked, indexed, and referenced at a later date without needed to scrub through the audio to find out exactly what was said.

Can I Have Your Attention, Please?

If you’ve been reading along to this point so far, you know that I prefer writing my thoughts out. That is, if you’ve been paying attention. I also prefer reading words instead of podcasts for the most part. Why? Well, that has to do with my full and undivided attention.

When I’m reading something, I’m using my active reading skills. I’m focused the content in front of me. I use my attention to absorb the words and concepts. It does take a lot of concentration to do this. Since part of my job is reading blogs it’s easy for me to set aside time to do this task. But it does take away from other things that I’m doing. I often find myself shutting out other conversation or ignoring things going on around me while I try to digest new topics or evaluate someone’s opinion on a subject.

Conversely, when is the last time you actively listened to a podcast? I mean, you sat down with a pair of headphones and really listened to it? Not just put it on in the background and casually listened to the discussion while you went on with work or something else. I’d bet the answer is that you frequently find yourself splitting your attention. I know I do it. I even split my focus when I’m recording podcasts if they aren’t on video. It’s very easy to lose track of what’s going on without a visual focus point.

Podcasts are active. They project the conversation you. Likewise, the consumers of podcasts are passive. They aren’t seeking knowledge. They are being fed knowledge via an audio (or video) stream. But written words aren’t that aggressive. They require someone to consume them actively. You don’t accidentally click on a link and find yourself full of knowledge ten minutes later without having put in the effort to read what was on the page. You can’t read blog posts without paying attention. If you do, you find yourself missing the point and reading them all over again to find out what you missed in the first place.

Tom’s Take

I love to write. I never did when I was in school or when I was first starting out in technology, but as time has worn on, I find myself growing to love using a keyboard to share what’s in my brain. I’ve recorded podcasts and videos as well, but I keep coming back to the written word. I like the ability to have other people find my content useful years after the fact via a search or a referral. I also enjoy the idea that people are focused on what I’m saying and ingesting it actively instead of having it fed to them via a speaker or headphones. Maybe it’s because I use other media, like TV and music, to provide background noise to focus as I write and do other things. At the end of the day, I blog because it’s the method of communication I most prefer to consume.

Not The Cisco of John Chambers Anymore

Posted on by
5

I just got back from Cisco Live 2017 last night and I had a blast at the show. There was a lot of discussion about new architectures, new licensing models, and of course, Tech Field Day Extra. However, one of the most interesting topics went largely under the radar. I think we’re fully in the transition of Cisco away from being the Company of John Chambers.

Steering A Tall Ship

John Chambers wasn’t the first CEO of Cisco. But he’s the one that most people would recognize. He transformed the company into the juggernaut that it is today. He watched Cisco ascend to the leader in the networking space and helped it transform into a company that embraced voice, security, and even servers and compute as new business models.

John’s Cisco is a very unique animal. It’s not a single company. It’s a collection of many independent companies with their own structures and goals all competing with each other for resources. If John decided that UCS was more important to his goals this quarter, he shifted some of the support assets to focus on that business unit. It was a featured product, complete with healthy discounts to encourage user adoption.

Product lines that didn’t perform as well were usually shown the door or swept under the rug. Even larger, well-publicized acquisitions tended to disappear under the spotlight of harsh criticism. Flip Video, Cius, and even Umi are not only lackluster products, but I bet you even forgot about one or two of them. John didn’t like highlighting failures any more than any of us, but the failures were often highlighted in spite of their stellar up-front marketing and sudden disappearance.

You can’t run the ship forever, though. Eventually, John knew he would need to step down. He had courted many, many heirs apparent in his time at Cisco. There were literally a dozen or more people inside the organization that saw themselves as the next CEO of the company. And when the time came to name his successor, Chuck Robbins was not the first name on a lot of lists. But his ascension to the throne of the networking powerhouse is turning heads.

Turning The Tall Ship

By all accounts, Cisco is a company in transition. Beset on all sides by cheaper merchant silicon, an industry shift to software-focused architecture, and several upstart companies featuring the best and brightest Cisco talent from years past. Cisco is facing multiple challenges that would have been singularly laughable a decade ago.

Part of this challenge comes from the reliance on the hardware model that John Chambers so proudly touted. John loves hardware. There’s margin in hardware. Hardware occupies space. It reminds people of the importance of things. And hardware eventually needs to be replaced. These all speak to the model of a company like the old IBM run by Tom Watson.

But Chuck Robbins sees Cisco differently. His push toward software is turning the ship away from dwindling hardware margins. The Intuitive Network architecture is setting Cisco up to rely more on software innovation than ever before. These are the kinds of organizational shifts that we’ve seen IBM go through as they focused on becoming more aligned with the direction of the industry. But these massive changes aren’t the only things that show how Cisco has transformed.

John Chambers loved the idea of having many, many business units. They were like sworn vassals pledging their loyalty to a distant king. The more voices showing the allegiance, the better. And those vassals could be courted as the possible successor to the throne should the prove worthy. So, when Chuck ascended to the head of the table, he showed his distaste for the vassal approach. He quietly allowed his competitors for the top job to exit gracefully on their terms. That’s not uncommon in situations where the throne is hotly contested.

Chuck also started collapsing those dozens of business units into organizational structure that makes sense. Not marketing wrappers, but real changes. Where before Networking and Security were two ships passing the night, they now run under the control of one person, David Goeckeler. The old Cisco system would have had two or more people reporting back to Chambers. Now, Robbins has one person to talk to about the direction of both of these key pillars of Cisco’s product lines.

A curious appearance of the shift in organizational focus was visible at Cisco Live 2017. In years past, a vice president has served as “host” for the event. They introduce the keynotes and give statistics about the attendance and other key facts. They also did the “interview” of the celebrity keynote speaker on Thursday. This year, there was no host. Chuck came on stage for his keynote without introduction. He did his speech and closed the session without anyone else on stage aside from his guests. On Thursday, he was the one interviewing the celebrity speaker, Brian Cranston.

It may not sound like much, but all of these little things add up to a very interesting change in Cisco’s organization. Chuck Robbins is going to take a much different role than Chambers. He’s going to be closer to the products. He’s going to be more involved in decisions. He’s going to be the one driving the ship rather than waiting for someone to execute decisions he’s suggested. Will that be enough to help Cisco keep their position in the networking space? Only time will tell.

Tom’s Take

I’ve said before that in the sports world, you never want to be the coach that follows the legend. Everything you do will be scrutinized through their lens and compared negatively. Some very good people can emerge from the shadow of their predecessor, but most are doomed to spend very good years being compared unfairly to the myth of the past.

At first, it looked like Chuck Robbins was headed down the same path. But with the major internal changes, the focus on software instead of hardware, and his more hands-on approach to management, I think we’re quickly going to find ourselves speaking of Cisco in the same way we refer to IBM today as “Not Tom Watson’s IBM”. I hope that the Cisco of Chuck Robbins succeeds and thrives so that in the future people will refer not to Chuck Robbins as the successor of John Chambers but instead refer to John Chambers as the guy who came before the Great Chuck Robbins.

Subscription Defined Networking

Posted on by
4

Cisco’s big announcement this week ahead of Cisco Live was their new Intent-based Networking push. This new portfolio does include new switching platforms in the guise of the Catalyst 9000 series, but the majority of the innovation is coming in the software layer. Articles released so far tout the ability of the network to sense context, provide additional security based on advanced heuristics, and more. But the one thing that seems to be getting little publicity is the way you’re going to be paying for software going forward.

The Bottom Line

Cisco licensing has always been an all-or-nothing affair for the most part. You buy a switch and you have two options – basic L2 switching or everything the switch supports. Routers are similar. Through the early 15.x releases, Cisco routers could be loaded with an advanced image that ran every service imaginable. Those early 15.x releases gave us some attempts at role-based licensing for packet, voice, and security device routers. However, those efforts were rolled back due to customer response.

Shockingly, voice licensing has been the most progressive part of Cisco’s licensing model for a while now. CallManager 4.x didn’t even bother. Hook things up and they work. 5.x through 9.x used Device License Units (DLUs) to help normalize the cost of expensive phones versus their cheaper lobby and break room brethren. But even this model soon gave way to the current Unified Licensing models that attempt to bundle phones with software applications to mimic how people actually communicate in today’s offices.

So where does that leave Cisco? Should they charge for every little thing you could want when you purchase the device? Or should Cisco leave it wide open to the world and give users the right to decide how best to use their software? If John Chambers had still been in charge of Cisco, I know the answer would have been very similar to what we’ve seen in the past. Uncle John hated the idea of software revenue cannibalizing their hardware sales. Like many stalwarts of the IT industry, Chambers believed that hardware was king and software was an afterthought.

Pay As You Go

But Chuck Robbins has different ideas. Alongside the new capabilities of Cisco’s Intuitive Network plan they have also introduced a software subscription model. Now, if you want to use all these awesome new features for the future of the network according to Cisco you are going to pay for them. And you’re going to pay every year you use them.

It’s not that radical of a shift in mindset if you look at the market today. Cable subscriptions are going away in favor of specialized subscriptions to specific content. Custom box companies will charge you a monthly fee to ship you random (and not-so-random) items. You can even set up a subscription to buy essential items from Amazon and Walmart and have them shipped to your home regularly.

People don’t mind paying for things that they use regularly. And moving the cost model away from capital expenditure (CapEx) to an operational expenditure (OpEx) model makes all the sense in the world for Cisco. Studies from industry companies like Infinity Research have said that Infrastructure as a Service (Iaas) growth is going to be around 46% over the next 5 years. That growth money is coming from organizations shift CapEx budget to OpEx budget. For traditional vendors like Cisco, EMC, and Dell, it’s increasingly important for them to capture that budget revenue as it moves into a new pool designed to be spent a month or year at a time instead of once every five to seven years.

The end goal for Cisco is to replace those somewhat frequent hardware expenditures with more regular revenue streams from OpEx budgets. If you’re nodding your head and saying, “That’s pretty obvious…” you are likely from the crowd that couldn’t understand why Cisco kept doubling down on bigger, badder switching during the formative years of SDN. Cisco’s revenue model has always looked a lot like IBM and EMC. They need to sell more boxes more frequently to hit targets. However, SDN is moving the innovation away from the hardware, where Cisco is comfortable, and into the software, where Cisco has struggled as of late.

Software development doesn’t happen in a vacuum. It doesn’t occur because you give away features designed to entice customers into buying a Nexus 9000 instead of a Nexus 6000. Software development only happens when people are paying money for the things you are developing. Sometimes that means that you get bonus features that they figure out in the process of making the main feature. But it surely means that the people focused on making the software want to get it right the first time instead of having to ship endless patches to make it work right eventually. Because if your entire revenue model comes from software, it had better be good software that people want to buy and continue to pay for.

Tom’s Take

I think Chuck Robbins is dragging Cisco into the future kicking and screaming. He’s streamlined the organization by getting rid of the multitude of “pretenders to the throne” and tightening up the rest of the organization from a collection of competing business units into a logically organized group of product lines that can be marketed. The shift toward a forward-looking software strategy built on recurring revenue that isn’t dependent on hardware is the master stroke. If you ever had any doubts about what kind of ship Chuck was going to sail, this is your indicator.

In seven years, we’re not going to be talking about Cisco in the same way we did before. Much like we don’t talk about IBM like we used to. The IBM that exists today bears little resemblance to Tom Watson’s company of the past. I think that the Cisco of the future will bear the same superficial resemblance to John Chamber’s Cisco as well. And that’s for the better.

Don’t Build Big Data With Bad Data

Posted on by
1

I was at Pure Accelerate 2017 this week and I saw some very interesting things around big data and the impact that high speed flash storage is going to have. Storage vendors serving that market are starting to include analytics capabilities on the box in an effort to provide extra value. But what happens when these advances cause issues in the training of algorithms?

Garbage In, Garbage Out

One story that came out of a conversation was about training a system to recognize people. In the process of training the system, the users imported a large number of faces in order to help the system start the process of differentiating individuals. The data set they started with? A collection of male headshots from the Screen Actors Guild. By the time the users caught the mistake, the algorithm had already proven that it had issues telling the difference between test subjects of particular ethnicities. After scrapping the data set and using some different diverse data sources, the system started performing much better.

This started me thinking about the quality of the data that we are importing into machine learning and artificial intelligence systems. The old computer adage of “garbage in, garbage out” is never more apt today than it has been in history. Before, bad inputs caused data to be suspect when extracted. Now, inputting bad data into a system designed to make decisions can have even more far-reaching consequences.

Look at all the systems that we’re programming today to be more AI-like. We’ve got self-driving cars that need massive data inputs to help navigate roads at speed. We have network monitoring systems that take analytics data and use it to predict things like component failures. We even have these systems running the background of popular apps that provide us news and other crucial information.

What if the inputs into the system cause it to become corrupted or somehow compromised? You’ve probably heard the story about how importing UrbanDictionary into Watson caused it to start cursing constantly. These kinds of stories highlight how important the quality of data being used for the basis of AI/ML systems can be.

Think of a future when self-driving cars are being programmed with failsafes to avoid living things in the roadway. Suppose that the car has been programmed to avoid humans and other large animals like horses and cows. But, during the import of the small animal data set, the table for dogs isn’t imported for some reason. Now, what would happen if the car encountered a dog in the road? Would it make the right decision to avoid the animal? Would the outline of the dog trigger a subroutine that helped it make the right decision? Or would the car not be able to tell what a dog was and do something horrible?

Do You See What I See?

After some chatting with my friend Ryan Adzima, he taught me a bit about how facial recognition systems work. I had always assumed that these systems could differentiate on things like colors. So it could tell a blond woman from a brunette, for instance. But Ryan told me that it’s actually very difficult for a system to tell fine colors apart.

Instead, systems try to create contrast in the colors of the picture so that certain features stand out. Those features have a grid overlaid on them and then those grids are compared and contrasted. That’s the fastest way for a system to discern between individuals. It makes sense considering how CPU-bound things are today and the lack of high definition cameras to capture information for the system.

But, we also must realize that we have to improve data collection for our AI/ML systems in order to ensure that the systems are receiving good data to make decisions. We need to build validation models into our systems and checks to make sure the data looks and sounds sane at the point of input. These are the kinds of things that take time and careful consideration when planning to ensure they don’t become a hinderance to the system. If the very safeguards we put in place to keep data correct end up causing problems, we’re going to create a system that falls apart before it can do what it was designed to do.

Tom’s Take

I thought the story about the AI training was a bit humorous, but it does belie a huge issue with computer systems going forward. We need to be absolutely sure of the veracity of our data as we begin using it to train systems to think for themselves. Sure, teaching a Jeopardy-winning system to curse is one thing. But if we teach a system to be racist or murderous because of what information we give it to make decisions, we will have programmed a new life form to exhibit the worst of us instead of the best.

CCIE Continuing Education – Learn Your Way To Recertification

Posted on by
6

It looks like one of the best (or worst) kept secrets about the CCIE has finally come to pass. This week, Cisco announced that there is a new program in place to recertify your CCIE without the need to continually retake the written exam. How is this going to measure up?

The Learning Train

The idea behind continual recertification is very simple. Rather than shut down what you’ve got going on every 18 months to spend time studying for an exam, Cisco is giving current CCIEs and CCDEs the option of applying credit from educational sessions toward recertifying their credentials.
This is very similar to the way that it works in for a doctor or a lawyer. There are courses that you can take that provide a certain number of “points” for a given class. When you accumulate 100 points in a two year span, you can apply those points to recertification.
The credits are good for a maximum of three years from the date earned. You can’t carry them over between recertification periods or bank them in case your certification expires. Once you use the points to recert, you start back up the treadmill again.

We’ll Do It Live!

One of the more interesting pieces to come out of the CCIE/CCDE CPE process is the emphasis on sessions as Cisco Live. Each of the sessions, from one hour breakout to 8-hour Techtorial and labs have a point value assigned. You can earn up to 70 points at Cisco Live every year through this method.
This is huge because it places a focus back on sessions at Cisco Live. A lot of networking professionals that I’ve spoken to recently have questioned the need to come to sessions during Cisco Live. Many are more interested in the DevNet zone as opposed to traditional learning sessions. Still others are buying a social pass and coming to chat with peers instead.
Now, Cisco has made sessions at Cisco Live matter to CCIEs. You get more points for harder sessions. Or longer in-depth dives into Technologies that are up and coming. You could easily recertify with very little effort every second year at Cisco Live.
Additionally, the program includes the flexibility to offer different types of continuing credit. Perhaps it’s for filling out surveys of importance to product teams. Or for tackling a new technology in an in-person instructor format. The possibilities are unlimited and should keep current and Emeritus CCIEs happy.

Tom’s Take

I’m thrilled these changes are finally implemented. CCIEs can finally join the ranks of other professionals in the world. I’ve been talking about getting this done for four years at this point, so hats off to Yusuf and his team. Let’s keep the steam rolling forward and getting more learning opportunities on the list to help get more CCIEs recertified.

How To Make Mistakes

Posted on by
Reply

We all make mistakes. We type the wrong command. We use the wrong verb tense in an article. We leave out a critical step when explaining a process. It’s something that happens all the time. It’s avoidable through careful planning, but how do you handle things when the avoidable becomes unavoidable?

Making Amends, Not Mistakes

Once a mistake is out in the open and noticeable, it’s done. You can’t pretend it didn’t happen or that it’s not affecting things. That’s when you need to own up to what happened and fix it. Sometimes that’s not always easy. Even the best person is reticent to admit to being fallible. So the process for fixing a mistake isn’t always easy. But it is important.

  1. Realize You’ve Made A Mistake – As amazing as it sounds, this is sometimes the hardest part of the deal. It’s easy to see that you’ve typed in the wrong command to a router and that the output isn’t what you were expecting. But what about those errors you don’t immediately catch. How about hearing the incorrect name at a dinner party and calling someone by the wrong name for an entire night? Or incorrectly spelling or pronouncing a word for years because you never knew it was wrong. Often, the hardest part of the mistake is realizing you’ve made it. Hopefully, someone will point it out to you in a way that doesn’t immediately put you on the defensive.
  2. Apologizing Specifically For The Mistake – I’m rather tough on my kids when it comes to apologizing for their mistakes. Instead of a simple, “I’m sorry”, they have to apologize specifically for what they did wrong. For example, “I’m sorry for hitting my sister with the inflatable baseball bat after you told me not to swing it.” Why am I so tough? Because putting the action in the apology helps reinforce what happened and why is was wrong or was a mistake. The next time you make a mistake and have to apologize to a manager or a customer, try wording the apology with inclusion of what happened. “I’m sorry I typed in the wrong OSPF command and cause the routing table to disappear.” You’d be surprised how receptive people are to finding out what the mistake was.
  3. Create A Plan Of Remediation – Okay, you admitted what you did wrong. Now, how are you going to fix it? That’s the last part of realizing your mistake. You did something wrong and you admitted it. It’s time to figure out how to not do it again. In the case of incorrect commands, it’s as simple as typing the right command in this time. But in the case of other things, like systemic behaviors, it’s more important to realize that you may need to do something repeatedly to correct the behavior. If you’re constantly using “on-premise” incorrectly, it may take some practice before you’re using it as intended.

Each of these steps is important. You can’t fix the mistake until you realize you’ve made it, apologized for it, and planned on how to fix it.

Tom’s Take

Mistakes will happen. How you overcome them says a lot about your character. The worst thing in the world is a person that believes they are completely infallible. These kinds of people never think they’ve done anything wrong, so they don’t know that they still have much to learn. Experience is what you get when you don’t get what you want. And the best source of experience is mistakes. The key to learning from them is simple: recognize, apologize, and prioritize the fix. If you can manage all of those things, you have the chance to grow and learn.

It’s Not The Size of Your Conference Community

Posted on by
1

CLUS2016Tweetup

Where do you get the most enjoyment from your conference attendance? Do you like going to sessions and learning about new things? Do you enjoy more of the social aspect of meeting friends and networking with your peers? Maybe it’s something else entirely?

It’s The Big Show

When you look at shows like Cisco Live, VMworld, or Interop ITX, there’s a lot going on. There are diverse education tracks attended by thousands of people. You could go to Interop and bounce from a big data session into a security session, followed by a cloud panel. You could attend Cisco Live and never talk about networking. You could go to VMworld and only talk about networking. There are lots of opportunities to talk about a variety of things.

But these conferences are huge. Cisco and VMware both take up the entire Mandalay Bay Convention Center in Las Vegas. When in San Francisco, both of these events dwarf the Moscone Center and have to spread out into the surrounding hotels. That means it’s easy to get lost or be overlooked. I’ve been to Cisco Live before and never bumped into people I know from my area that said they were going, even when we were at the same party. There are tens of thousands of people roaming the halls.

That means that these conferences only work well if you can carve out your own community. Cisco Live has certainly done that over the years. There’s a community of a few hundred folks that are active on social media and have really changed the direction of the way Cisco engages with the community. VMworld has their various user groups as well as VMUnderground constantly pushing the envelope and creating more organic community engagement.

You Think You Know Me

The flip side is the smaller boutique conferences that have sprung up in recent years. These take a single aspect of a technology and build around it. You get a very laser-focused event with a smaller subset of attendees based on similar interests. It’s a great way to instantly get massive community involvement around an idea. Maybe it’s Monitorama. Or perhaps it’s OSCon. Or even GopherCon. You can see how these smaller communities are united around a singular subject and have great buy in.

However, the critical mass needed to make a boutique conference happen is much greater per person. Cisco Live and VMworld are going to happen every year. There are no less than 10,000 – 15,000 people that would come to either no matter what. Even if 50% of last year’s attendees decided to stay home this year, the conference would happen.

On the flip side, if 50% of the DockerCon or OpenStack Summit attendees stayed home next year, you’d see mass panic in the community. People would start questioning why you’re putting on a show for 2,500 – 3,000 users. It’s one thing to do it when you’re small and just getting started. But to put on a show for those numbers now would be a huge decision point and things would need to be discussed to see what happens going forward.

Cisco Live and VMworld are fun because of their communities. But boutique conferences exist because of their communities. It’s important to realize that and drastic changes in a smaller conference community have huge ripples throughout the conference. Two hundred Twitter users don’t have much impact on the message at Cisco Live. But two hundred angry users at DockerCon can make massive changes happen. Each member of the community is amplified the smaller the conference they attend.

Tom’s Take

Anyone that knows me knows that I love the community. I love seeing them grow and change and develop their own voice. It’s why I work for Tech Field Day. It’s why I go to Cisco Live every year. It’s why I’m happy to speak at VMUnderground events. But I also realize how important the community can be to smaller events. And how quickly things can fall apart when the community is fractured or divided. It’s critical for boutique conferences to harness the power of their communities to get off the ground. But you also have to recognize how important they are to you in the long run. You need to cultivate them and keep the focused on making everything better for everyone.

What Happened To The CCDE?

Posted on by
2

Studying for a big exam takes time and effort. I spent the better part of 3 years trying to get my CCIE with constant study and many, many attempts. And I was lucky that the CCIE Routing and Switching exam is offered 5 days a week across multiple sites in the world. But what happens when the rug gets pulled out from under your feet?

Not Appearing In This Testing Center

The Cisco Certified Design Expert (CCDE) is a very difficult exam. It takes all of the technical knowledge of the CCIE and bends it in a new direction. There are fun new twists like requirements determination, staged word problems, and whole new ways to make a practical design exam. Russ White made a monster of a thing all those years ago and the team that continues to build on the exam has set a pretty high bar for quality. So high, in fact, that gaining the coveted CCDE number with its unique styling is a huge deal for the majority of people I know that have it, even those with multiple CCIEs.

The CCDE is also only offered 3-4 times a year. The testing centers are specialized Pearson centers that can offer enhanced security. You don’t have to fly to RTP or San Jose for your exam, but you can’t exactly take it at the local community college either. It’s the kind of thing that you work toward and get ready for, not the kind of spur-of-the-moment sales test that you have to take today to certify on a new product.

So, what happens if the test gets canceled? Because that’s exactly what happened two weeks ago. All those signed up to take the May 17, 2017 edition of the exam were giving one week’s notice that the exam had been canceled. Confusion reigned everywhere. Why had Cisco done this? What was going to happen? Would it be rescheduled or would these candidates be forced to sit the August exam dates instead? What was going on? This was followed by lots of rumors and suggestions of impropriety.

According to people that should know, the February 2017 exam had a “statistically signification pass rate increase”. For those that don’t know, Cisco tracks the passing exam scores of all their tests. They have people trained in the art of building tests and setting a specific passing rate. And they keep an eye on it. When too many people start passing the exam, it’s a sign that the difficulty needs to be increased. When too few people are able to hit the mark, a decision needs to be made about reducing difficulty or examining why the pass rate is so low. Those are the kinds of decisions that are made every day when the data comes back about tests.

For larger exams like the CCDE and CCIE that have fewer test taking opportunities, the passing rate is a huge deal. If 50% of the people that take the CCIE pass, it doesn’t say very much for the “expert” status of the exam. Likewise, if only 0.5% of test takers pass the CCDE on a given attempt, it’s an indicator that the test is too hard or overly complex and less about skill demonstration and more about being “really, really tough”. The passing rate is a big deal to Cisco.

According to those reports, there was a huge spike in the passing rate for the February CCDE. Big enough to make Cisco shut down the May attempts to find out why. If you have a few percentage points variance in passing or failing rates now and then, it’s not a huge deal. But if you have a huge increase in the number of certified individuals for one of the most challenging exams ever created, you need to find out why. That’s why Cisco went into damage control mode for May and maybe even for August.

The Jenga Problem

So, if your still with me at this point, you’ve probably figured out that there’s a good possibility that someone got their hands on a copy of the CCDE exam. That’s why Cisco had to stop the most recent date in order to ensure that whatever is out in the wild isn’t going to cause issues with the exam passing rates going forward. It makes sense from a test giver perspective to plug the leak and ensure the integrity of the exam.

Yes, it does suck for the people that are taking the exam. That’s a lot of time and effort wasted. One of the things I kept hearing from people was, “Why doesn’t Cisco just change the test?” Sadly, changes to the CCDE are almost impossible at this point in the game.

Even written exams with hundreds of test bank questions are difficult to edit and refresh. I know because I’ve been involved the process for many of them in the past. Getting new things added and old things removed takes time, effort, and cooperation among many people on a team. Imagine the nightmare of trying to get that done for a test where every question is hand-crafted and consists of multiple parts. Where something that is involved in Question 2 of a scenario has an impact on Question 8.

Remember, exams like the CCIE and CCDE are infamous for word choices mattering a lot in the decision making process of the candidate. Changing any of the words is a huge deal. Now, think about having to change a question or two. Or a scenario or two out of four. Or a whole exam revision. Now, do it all in two weeks. You can see what the CCDE team was faced with and why they had to make the decision they did. Paying customers are angry, but the possibility that the integrity of a complicated exam is compromised is worth more to Cisco in the long run.

Tom’s Take

What’s going to happen? It’s difficult to say. Cisco has to find out what happened and stop it immediately. Then, they have to assess what can be done to salvage the exam as it exists today. Scenarios must be created to replace known bad versions. Evaluation of those new scenarios could take a while. And in the interim, Cisco can’t just shut down the testing and certification process. It would be the end of the CCDE and cause a huge backlash in the elite community that exists to spread the good word of Cisco throughout networking circles. Cisco isn’t acting from a position of confusion, but instead from a position of caution. The wrong step at the wrong time could be disastrous.

The Myth of The Greenest Field

Posted on by
2

A fun anecdote: I had to upgrade my home landline (I know, I know) from circuit switched to packet switched last week. I called the number I was told to call and I followed the upgrade procedure. I told them exactly what I wanted – the bare minimum necessary to move the phone circuit. No more. No less.

When the technician arrived to do the upgrade, he didn’t seem to know what was going on. Instead of giving me the replacement modem I asked for, he tried to give me their “upgraded, Cadillac model” home media gateway router. I told him that I didn’t need it. I had a perfectly good router/firewall. I had wireless in my house. I didn’t need this huge monstrosity. Yet, he persisted. No amount of explanation from me could make him understand I neither wanted or needed what he was trying to install.

Finally, I gave in. I let him finish his appointment and move on. Once he was gone, I disassembled the router and took it to the nearest cable company store. I walked in and explained exactly what I wanted and what I needed. It took the techs there less than five minutes to find my new device without the wireless or media gateway functionality. They provisioned it through their system and gave it to me. I plugged it in at home and everything worked just the way that it had before. No fuss.

The Field Isn’t Always Greener

Why is this story important? Because it should inform us at networking and systems professionals that there is no such thing as a truly greenfield deployment. Even the greenest field is just a covering for the brown dirt below. If you’re thinking to yourself, “But what about those really green installs with new sites or new organizations?” you obviously aren’t thinking about the total impact of what makes an install non-greenfield.

We tend to think of technology as the limiting factor in a deployment. How do we make the New Awesome System work with the Old Busted Stuff? How can we integrate the automated, orchestrated, programmable thingy with the old punchcard system that still requires people to manually touch things to work? When we try to decide how to make it all work together, our challenge is totally focused on the old tech.

But what if the tech isn’t the limiting factor? What if there are a whole host of other things that make this field of green a little harder to work with? What if it’s a completely new site but still requires a modem connection to process credit cards? What if the branch office computers have a mandate to run an anti-virus program and the branch bought all OS X or Linux machines? What if the completely new company wants you to setup a new office but only has $1000 budgeted for networking gear?

What Can Brown Do For You?

The key to a proper installation at a so-called “brownfield” site is to do your homework. You have to know before you ever walk in the door what is waiting for you. You have to have someone do a site evaluation. You need to know what tech is waiting for you and how it all works together. If the organization that you are doing the installation for can’t produce that information, you either need to sell them a service to do it for them or be prepared to walk away.

At the same time, you also need to account for all the other non-technical things that can crop up. You need to get buy in from management and IT for the project you’re doing. If not, you’re going to find that management and IT are going to use you as a scapegoat for every problem that has ever cropped up in the network. You’ll be a pariah before you ever flip a switch or plug in a cable. Ensuring that you have buy in at all levels is the key to ensuring that everyone is on the same page.

You also need to make sure that you’re setting proper expectations. What are people expecting from this installation? Are their assumptions about the outcome reasonable? Are you going to get stuck holding the bag when the New Awesome Thing fails to live up to the lofty goals it was sold on? Note that this isn’t always the “us vs. them” mentality of sales and engineering either. Sometimes a customer has it in their head that something is going to do a thing or act a certain way and there’s nothing you can do to dissuade the customer. You need to know what they are expecting before you ever try to install or configure a device.

Tom’s Take

Greenfield sites are the unicorn that is both mythical and alluring to us all. We want to believe that will one day not have to work under constraints and be free to set things up in a way that we want. Sadly, much like that unicorn, we all know that true greenfield sites will never truly exist. You’re always going to be working under some kind of constraint. Some kind of restriction. It’s not always technically in nature either. But proper planning and communication will prevent your brown grass deployment from becoming a quagmire of quicksand.

Cisco and Viptela – The Price of Development Debt

Posted on by
Reply

Cisco finally pulled themselves into the SD-WAN market by acquiring Viptela on Monday. Viptela was considered to be one of, if not the leading SD-WAN vendor in the market. That Cisco decided to pick them as an acquisition target isn’t completely surprising. But one might wonder why?

IWANna New Debt

Cisco’s premier strategy for SD-WAN up until last week was IWAN. This is their catch-all solution designed to take the various component pieces being offered by SD-WAN solutions and replicate them on Cisco hardware. IWAN has served as a vehicle for Cisco to push things like the APIC-EM solution, Cisco ONE licensing, and a variety of other enhanced technologies like NBAR and PfR.

Cisco has packaged these technologies together because they have spent a couple of decades building these protocols up to be the best at what they do in the industry. NBAR was the key to application QoS years ago. PfR and OER were the genesis of Cisco having the ability to intelligently route packets to destinations. These protocols have formed the cornerstone of their platform for many, many years.

So why is IWAN such a mess? If you have the best of breed technology built into a router that makes the packets fly across the Internet at lightning speeds how is it that companies like Viptela were eating Cisco’s lunch in the SD-WAN space? It’s because those same best-of-breed protocols are to blame for the jigsaw puzzle of IWAN.

If you are the product manager for a protocol like NBAR or PfR, you want it to be adopted by as many people as possible. Wide adoption guarantees you’re going to have a job tomorrow or even next year. The people working on EIGRP and OSPF are safe. But if you get left behind technologically, you’re in for rough seas. Just ask the folks that managed LANE. But if you can attach yourself to a movement that’s got some steam, you’re in the drivers seat.

At the same time, you want your protocol or product to be the best at what it does. And sometimes being the best means you don’t compromise. That’s great when you are the only thing running on the system. But when you’re trying to get protocols to work together to create something bigger, you often find that compromises are not just a good idea, they’re necessary. But how do you handle it when the product manager for NBAR and the product manager for IP SLA get into a screaming match over who is going to blink first?

Using existing protocols and products is a great idea because it means you don’t have to reinvent the wheel every time you design something. But, with that wheel comes the technical debt of development. Given the chance to reuse something that thousands, if not millions, of dollars of R&D has gone into, companies like Cisco will jump at the chance to get some more longevity out of a protocol.

Not Pokey, But Gumby

Now, lets look at a scrappy startup like Viptela. They have to build their protocols from the ground up. Maybe they have the opportunity of leveraging some open source projects or some basic protocol implementations to get off the ground. That means that they are starting from essentially square one. It also means they are starting off with very little technical and development debt.

When Viptela builds their application monitoring stack or their IPSec VPN stack, they aren’t trying to build the best protocol for every possible situation that could ever be encountered by a wide variety of customers. They are just trying to build a protocol that works. And not just a protocol that works on its own. They want a protocol that works with everything else they are building.

When you’re forced to do everything from scratch, you find that you avoid making some of the same choices that you were forced to make years ago. The lack of technical and development debt also means you can take a new direction with things. Don’t want to support pre-shared key IPSec VPNs? Don’t build it into the protocol. Don’t care to have some of the quirks of PfR? Build something different that meets your needs. You have complete control.

Flexibility is why SD-WAN vendors were able to dominate the market for the past two years. They were able to adapt and change quickly because they didn’t need to keep trying to make systems integrate on top the tech and dev debt they incurred during the product lifecycle. That lets them concentrate on features that customers want, not on trying to integrate features that management has decreed must be included because the product manager was convincing in the last QBR.

Tom’s Take

In the end, the acquisition of Viptela by Cisco was as much about reduction of technical and development debt in their SD-WAN offerings as it was trying to get ahead in the game. They needed something that could be used as-is without the need to rely on any internal development processes. I alluded to this during our Network Collective Off-The-Cuff show. Without the spin-out model available any longer, Cisco is going to have to start making tough decisions to get things like this done. Either those decisions are made via reduction of business units without integration or through larger dollar signs to acquire solutions to provide the cohesion they need.