Saturday, January 16, 2016

CCIE "GAP Analysis"

I am in the beginning stages of CCIE preparation and recently had the opportunity to work on a lab scenario with three senior network architects - all current CCIEs.  I'll spare you the details and just say my performance (and troubleshooting approach) in this particular lab fell far short of what I would have liked.

So why is that?  On a daily basis, I design networks.  I perform network assessments and network remediations.  I scale existing networks.  I troubleshoot persistent network issues, at times down to the packet level.  I do all of this quite well.  I work with junior members of my team and explain various networking technologies.  Yet when my feet were held to the fire in a lab scenario, I faltered.

I've put in a tremendous amount of effort over the past few years to master networking fundamentals, and throughout this process, I have earned a number of relevant certifications.  I have read well over a dozen Cisco Press books front to back, I and took the time to process what I read.  I studied using video training materials from multiple sources (including INE whenever possible - I highly recommend Brian McGahan's content).  I built an extensive lab environment (see here).  I configured the relevant technologies, broke them, and troubleshot them.  I implement the bulk of these technologies in production, many of them on a regular basis.

So, again, why did I fall short in a lab scenario?  In an effort to strengthen my weak points and prepare for my CCIE, I've done a high very high level "gap analysis."

Configuration vs. Troubleshooting


There are many technologies I configure on a regular basis but don't often have to troubleshoot outside of a lab scenario.  And quite frankly, I haven't done many troubleshooting labs in the past year since I earned my CCNP.  My responsibilities shifted more to the design side of things, and troubleshooting why an OSPF adjacency won't form isn't something I often do.  In hindsight, I should have kept the momentum going after earning my CCNP and continued with CCIE prep.  At this point, I'm going to have to circle back to solidify some CCNP level topics.

Understanding vs. Execution


I have a solid understanding of a wide variety of technologies.  I could explain many of them at a low level during a quick trip to the whiteboard.  This is a useful skill to have.  However, this doesn't mean I can configure or troubleshoot these technologies on demand.  When it comes to recalling the relevant configuration, show, or debug commands for some of these technologies, I come up up short and have to use reference material.  Conceptual understanding does not equal the ability to configure or troubleshoot a technology on the fly.

Reliance on References


I have developed a lot of my own work notes and reference materials, some of which are posted on this blog.  When writing new configurations, I tend to rely upon known good configurations and references that I wrote.  I have always seen this as being efficient and scalable; why do the same work twice?  However, I now realize this is also a crutch that is going to hold me back as I prepare for the CCIE.

Spread too thin


I tend to spread myself a bit too thin.  I started writing about this here, and then I decided this topic warrants a blog post of its own:
Habits vs. Goals.

Next steps...


To be successful in my CCIE prep, I need to get back to basics and hit the CLI.  In an effort to stay on track and solidify my own understanding of various technologies, I am going to be writing a series of blog posts that corresponds to the CCIE R&S v5 blueprint.  Stay tuned for more.

No comments:

Post a Comment