CCDE Success: Understanding It and You

Overview

This post is about covering three key ideas in preparing to take the CCDE and how to validate those ideas through the use of scenarios . The ideas are being minimally qualified, being technically complete,  and being connected to the scenario. The ideas combine to provide success on the test.

Being Minimally Qualified

Being minimally qualified means understanding the necessary depth of knowledge that is needed on a topic. As an example, it is important to understand QoS, the models of it, how it can help (or hinder) a design, how to roll it out into a topology, how it can be deployed or leveraged in MPLS (both as a carrier and as a customer) and general best-practices in QoS. It is not necessary to know the configuration for any QoS feature. It is not necessary to know how certain platforms handle QoS or how one can best make use of hardware resources available in a platform for QoS. Given the number of topics covered by the test it is crucial to understand when you have learned enough – when your knowledge is deep enough that you can stop and move on. This is challenging as we commonly want to understand something “all the way down”. While this is admirable, even potentially achievable, you have to understand this is not the focus of the test nor is it required. To be minimally qualified, and pass, you need to know how it works, why it works, what the common best practice (BCOP) for it is and most critically, the decision points to deviate from BCOP. Stop when you can explain the why’s. You increase your qualification by studying and labbing so this step is generally a solo activity.

If you are not minimally qualified on a topic you will not grasp a question (or series of questions) as you do not know enough to answer effectively. You may be able to proceed in the scenario with contained impact however. If you are over qualified you will tend to be locked in analysis paralysis and/or stuck wanting additional details that are not relevant to the design but are relevant to deployment. You can be minimally qualified in one or more technologies without having all of them. When you have all of them you are at the next point.

Being Technically Complete

The CCDE has a large number of topics spread across nearly the breadth of networking. To be successful you have to know about things considered service provider and enterprise. You need to understand layer2 and layer3 concepts, how overlay and underlays work, how all the pieces of a design interact and support (or not) convergence and how things can be optimized. You have to know the general order of operations and any gotchas or caveats to deploy all the technologies too. In my study group we talked about knowing the breadth of all the topics and possessing sufficient depth (read: minimally qualified) as being technically complete. You reach technical completion when you feel you know enough about all the relevant technologies to pass the test. Technical completion is a combination of the work from minimal qualification plus interaction with a group. Often times studying alone will not provide you with an understanding of how the technologies interact. We often found we’d start asking questions on how something worked, a topic everyone said they felt they understood fine, and we’d then go off and do more research and learning.

You prove technical completion by using scenarios to validate your understanding and/or group discussions. If you cannot understand what the options are or why they are the options then you have not reached technical completion and need to go back and learn more. A lack of technical completion will generate an extended feeling of being lost in the scenario or general puzzlement – as you do not understand what is happening or why.

Being Connected to the Scenario

This is perhaps the most difficult of the three beings to obtain and to explain. Technical completion affords you sufficient technical strength to parse the information in the scenario, to see flaws in the design including technical constraints or technical strengths, and to evaluate ways to improve the network. “Connection” is about understanding the rest of the information to pull out requirements and business intentions. It is about noticing how they did their routing and how that supports their requirements. This part is the most challenging as you won’t be handed a bulleted list of requirements and constraints to work from, with clear prioritization for each of them, updated to reflect changing conditions. You will not be handed a network diagram with sticky notes pointing out flaws already known or issues found. You also cannot go ask for clarity around your understanding of the requirements. Connection is the feeling of seeing the tricks or gotchas built into the scenario (think: Matrix bullet-time) – you see the “customer” is using a separate ASN in one portion of their environment so routes from there will be eBGP and preferred over their IGP routes but this is only for a subset of routes and you’ll be asked about all routing to see if you catch this detail – that sort of thing. Everything just “clicks.” When you are connected to the scenario you will likely not experience significant time pressure to complete either. When you do not feel connected it will be a sensation of dead ends and searching through documents to validate details. You understand the atomized parts but do not see how they fit together and so do not know what the right answer is as you cannot connect your answer to the larger design arc. In the post-scenario evaluation you will see you missed the question due to a minor detail in some document they shared or similar gotchas. Connection is really two specific skills and they aren’t technical per se:

  • Reading comprehension – your ability to read and understand diagrams, exhibits and text. Specifically it is understanding how to pull out requirements and constraints when they are not necessarily clearly articulated.
  • Memorization – your ability to remember details about the environment that might be relevant – such as circuit sizes or types or leadership preferences for capital or operations expenditures.

Connection is where most people have the greatest issues as you cannot simply memorize details and regurgitate them. Failing to connect will also mean you start designing with the wrong set of requirements and constraints. Thus the effects will cascade throughout the scenario. You increase your skills here by simply doing more scenarios to better learn the wording and method of presenting requirements as well as memorizing key details in the scenario. Get as many scenarios as you can afford to work on honing this skill. This is the only one of the “beings” you can plausible correct while taking the test. If you are feeling disconnected you can pause, breath for a second and then go look up the details you are missing or re-read material. You will burn time doing so, of course.