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:

DORA – DHCP process of Discover, Offer, Request, Acknowledge

Please Do Not Throw Sausage Pizza Away – OSI model in order starting with layer 1: physical, data-link, network, transport, session, presentation, and application

All People Seem To Need Data Processing – OSI model in order going backwards starting at layer 7: application, presentation, session, transport, network, data-link, physical

Big Dogs Really Like Me – the order of K values in EIGRP: bandwidth, delay, reliability, load, MTU

Every Alley Cat Eats Watery Noodles In Doors – ordered list of syslog messages: emergency, alert, critical, error, warning, notification, informational, debugging

Routing Networks Is Indeed A Great New Learning Initiative – an ordered list of OSPFv3 LSA types: router, network, inter-area prefix, inter-area router, AS external, group membership LSA, Type-7 NSSA, link LSA, intra-area prefix

We Love Oranges As Oranges Mean Pure Refreshment – a technically incomplete but still helpful way to remember ordered BGP best path selection: weight, local preference, origin, AS-path, origin-type, MED, path, router-ID

Please feel free to add to this list in the comments – I’d love to learn more!

Thanks,

Phil

After that, I kept going back to tweak it. Then, instead of moving on to the next task, I looked for things I could do that required I write another script. I became kind of hooked on getting better writing Python. I’m still pretty bad, but I’m spending quite a bit of time every day trying to improve.

At the same time, I’ve been studying for the CCIE on and off for almost three years, in earnest for the last year. There’s very little more satisfying to a network engineer than configuring a solution, testing connectivity, and getting back !!!!!

But lately, putzing around with lines of Python code until I finally get it to run without errors has been almost equally satisfying.

The thing is, when I go to work every day I’m seeing practical examples of how knowing how to write a simple script is as helpful to me as deep networking knowledge. My experience has been that once BGP neighbors relationships are formed, OSPF adjacencies are in the Full state, and traffic takes the correct path across my WAN, I’m not wiggling those proverbial wires much any more. Instead, I find myself incorporating sysadmin skills and simple programming to get day 2 and beyond tasks done.

I don’t work for a VAR anymore, so I don’t have the opportunity to finish one big WAN project then jump to the next for a different customer. Instead I have to find a way to add value with what I have in front of me, or in other words, make the network (and network security in particular) more robust, easier to manage, and automated.

About 18 months ago I chatted with Jon Langemak about this very thing. He explained how it was difficult for him to shift from a CCIE focus to his current focus in the automation and DevOps world, but how it was needful because it was how he could add value in the context in which he worked. Basically, he looked around and identified where he could be most useful, and then he went for it. That conversation has stuck with me ever since.

I’ve reaped tremendous rewards and seen incredible opportunities as a result of earning a variety of technical certifications, most of them from Cisco. But for some reason, the opportunities that present themselves to me nowadays don’t lend themselves to going from project to project configuring ASRs or replacing switch stacks in IDFs. I’ve done that before, and a big part of me really wants to do that again. Instead, the opportunities that come my way have less to do with configuring boxes and more to do with automation, creating better workflows, and aligning technology with business.

I’m not sure what to do with all this right now. In my mind, the natural progression for a network engineer is to get the next level certification, which for me is the CCIE, and then work on bigger and more complex technical projects. I know that’s still the natural progression for many engineers out there, but it’s not what’s happening in my life right now, even though I want it to be.

I’m not commenting on the industry here, and this isn’t another blog post about how network engineering is changing. These are the observations of my personal journey with the CCIE and with my current dayjob.

So where can I add value, and what opportunities are right in front of me that will help me grow? Well, for me, that means finding ways to automate tasks, collect large amounts of information from the network, find meaning in it, and use whatever methods I can to make network devices and the security posture of my organization more stable and consistent.

It also means creating professional writing, casting long-term vision for the area I’m responsible for, and being an available resource that can speak to the overall picture of the network rather than focus on one router at a time.

Though I’m still going through CCIE labs regularly and taking breaks to re-watch an INE video on various topics, I’m also spending just as much time improving my ability to write in Python using resources like Code Academy and Learn Python the Hard Way.

This doesn’t mean that my networking knowledge is now useless. In fact, it forms the foundation for everything I’m working on. I believe that the CCIE is still extremely relevant, and many of my friends in the networking community are working on higher level networking projects daily that require that sort of knowledge. But that’s simply not what’s been happening in my life lately, no matter how much I’d like it to be or how hard I try to make it happen.

So I feel I’m at a crossroads – probably how Jon felt a few years ago. Maybe it’s more of a transition or career evolution, I really don’t know. At first, it was absolutely terrifying to confront. But now, rather than continue to kick against the goads, I’m open to what seems to be developing naturally.

Thanks,

Phil

My thoughts aren’t based on a formal research study, so please keep that in mind.

Over the last 18 months or so I’ve had more than a couple conversations with friends and acquaintances who believe the CCIE is not as relevant or meaningful in this new age of software defined networking and community-driven technology. The conversation usually centered around trends such as SDN, automation, open standards, and a community-driven networking development model.

The argument I’ve heard has several premises:

First, current trends in networking require network engineers develop new skills other than those found in Cisco certification curricula. Therefore, the CCIE in and of itself is less valuable.

Second, the CCIE certification is more Cisco-centric than it used to be. This means it is intrinsically less valuable as a validation of fundamental networking skills.

Third, we’re fast approaching the 60,000 mark of CCIE numbers making the certification more ubiquitous than it’s ever been.

Fourth, the proliferation of open standards in networking precludes vendor lock-in making any vendor-specific certification obsolete.

Yesterday, I tweeted this:

What I’ve found is that that I’m not the only one who thinks this way. I had a couple good interchanges with folks including this comment from Daniel Dib (@danieldibswe):

I also put the question out there for my CCIE study group and got a variety of responses that centered around a central theme captured succinctly by Nick Russo (@nickrusso42518):

Current trends in networking require network engineers develop new non-Cisco skills, but hasn’t that always been the case? The most successful network engineers are those who have solid networking chops but also know a thing or two about Windows Server, Linux, VMware, project management and how to write a paragraph. Today we can add Python and Ansible to the list. For the vast majority of networking jobs, all of these skills are and always have been important; therefore, the need for engineers to develop programming skills doesn’t diminish the value of the CCIE.

Most networks I’ve worked on were Cisco-centric. Even during my short time working on GE’s infrastructure, all I did was work on Cisco gear. Maybe we need more vendors in the mix, but that’s not really the point I’m trying to make. Most networks run Cisco equipment, so it doesn’t bother me that the CCIE exam is Cisco-centric. Furthermore, I feel that I have a reasonable grasp of networking concepts, and most of my formal training has been through certification pathways. Though the CCIE is certainly vendor-specific, studying for it has also helped me learn more deeply the fundamentals of networking apart from specific vendor technology.

I don’t care too much what the current CCIE number is up to. Not all people who’ve earned it are still actually in the workforce, and of those that are, not all are practicing network engineers. Therefore I don’t believe the market is as flooded with CCIEs as some would suggest. This fast growing number of CCIEs is dispersed throughout the entire world which means there is currently little danger of CCIE saturation in a single geographic area. I understand the point that any certification has the potential to become so ubiquitous that it loses its value, but I don’t believe that’s where we are with the CCIE in 2016. Not even close.

Another friend in my CCIE study group, Katherine McNamara (@kmcnam1), explained that “the CCIE number used to crawl because there was only one kind of CCIE in the beginning, fewer testing centers, and fewer seats.”

In the early days of the CCIE certification, there was one track, very few testing centers and even fewer available seats for actual testing. As a result, the number increased slowly. Today there are multiple tracks, more testing centers, and a much greater awareness of the need for strong networking skills. To say that the number is too high or growing too fast is to suggest the climate for networking technology and the need for engineers with strong skills is the same now as it was in 1993.

The proliferation of open standards in networking doesn’t mean the CCIE is less useful and we all need to become developers in order to get a job. This just means that engineers need to adapt and learn some new skills. Logically, the need to learn Python doesn’t undermine the validity or relevance of the CCIE just like the need for a roofer to learn Excel to better manage his business doesn’t undermine his skills as a roofer. Ultimately this is a straw-man argument that presupposes that a CCIE knows little outside routing and switching. Sure, there are specialists who focus in on a specific technology, but generally speaking I believe that great engineers have deep and broad skills.

Vendor lock-in is not necessarily a concern for me. I don’t think people are truly as concerned about it as they say they are. I think the actual argument is more a matter of bitterness than a logical conclusion. For example, in my naive experience, many of those who wax eloquent on vendor lock-in also subtly and sometimes overtly make fun of those not using a Mac. I know they’re not exactly the same thing, but it suggests that they don’t really have a problem with a little vendor lock-in.

I don’t live in Silicon Valley, New York City, London, or some other global center of commerce and technology. I live in a small city with very few extremely large companies. Hiring managers in my area are looking for candidates with solid networking skills represented by project experience spelled out on a resume. The vast majority of networks are not webscale infrastructures, so pay attention to the hiring managers of smaller and medium-sized businesses where most networking jobs can be found. Sure – the largest and most progressive companies may thumb their noses at resumes and instead ask to see GitHub contributions as a means of vetting a candidate,  but by and large this is simply not the case.

In the last two years I made a few job changes to increase my income. That means I have a lot of interviewing experience in my recent past. Every company I spoke with except one encouraged if not required I pursue the CCIE, and all but one said they’d pay for it. Never once was I asked for my GitHub information or a portfolio of open source projects. I’m not speaking against that sort of hiring process; I’m simply observing that it’s not the method espoused by the majority of companies. Maybe it will be one day soon, but it isn’t today.

Often, the arguments I’ve heard about the decreasing value of the CCIE were made by current CCIEs. These are people who have reaped incredible rewards for earning their number. This doesn’t logically negate the argument, of course, but it doesn’t sit well with me at all.

My early background is in academia, and I have a deep appreciation for formal, traditional education. I don’t value the CCIE over a college education or over real-world experience, and I’m aware that Cisco has developed vendor-specific certifications in large part to guarantee their strong presence in the marketplace. However, I disagree that the CCIE itself is becoming increasingly irrelevant or meaningless.

For us plebeians living in smaller cities and working on networks serving only a few thousand end-users, it still opens doors, and it still provides a convenient pedagogical framework to learn networking.

The CCIE is not becoming irrelevant.