CCIE EI Design: The Best Network Is Not the Answer, the Traceable One Is

The design module is the part of the lab that engineers with a decade of configuration experience find hardest, and the reason is not difficulty. It is that the skill it asks for is the opposite of the one everything else rewards. Configuring a network well means knowing the correct answer and producing it. Designing one means recognising that three answers work, that the requirements favour one of them, and being able to say why.

There are no devices. There is a scenario, a set of documents describing an organisation and what it needs, and a fixed amount of time. Every answer comes from reading rather than from testing, and the thing being assessed is whether the choice follows from something the documents actually say.

This article covers what is structurally different about this module, how to read a requirements document, what makes one answer better than another when several would work, the trade-offs that recur, and why preparing for it by studying more technology does not help. It is written for the lab rather than for the written exam, and sits alongside the rest of the CCIE Enterprise Infrastructure lab certification track.

The design module removes the devices and with them the ability to verify by testing, so the only check available is whether each choice traces back to something the documents actually state.

What Is Structurally Different?

What changes without devices?

The verification loop. In every other context a decision can be checked by trying it, and being wrong costs a few minutes. Here the only check is whether the choice follows from the documents, which means re-reading rather than re-testing. That single difference changes how time should be spent, what a mistake costs, and what "finished" means — and the module is time-boxed separately, so time spent here is not available elsewhere.

A Deeper Dive into the Format

Reading replaces testing

Without a device, the source of truth is the scenario. That makes reading the primary activity rather than a preliminary to it, and it makes a careless first reading expensive in a way it never is when you can simply try something.

The practical consequence is that the first substantial block of time belongs to reading, twice, before any answer is formed. That feels unproductive and it is the highest-value thing available.

Time that cannot be borrowed

The modules are timed separately and moving on is not reversible. So a question left half-answered here cannot be returned to after finishing elsewhere, which is the opposite of the usual strategy of leaving the hard ones until the end.

That argues for answering everything at some level rather than perfecting some and abandoning others. An answer that is defensible and not optimal scores; an unanswered question does not.

Several answers work

Most design questions have more than one workable answer, which is uncomfortable for anyone used to configuration where a command is right or wrong. The assessment is not looking for the answer; it is looking for an answer that the stated requirements support.

That reframes the task. The question is not "what is the best design" in the abstract but "what does this organisation's situation point at", and those frequently differ.

THE SHIFT, IN ONE LINE

  Deployment:   What is the correct configuration?
  Design:       Which of these workable options do these
                requirements favour, and which sentence says so?

  If you cannot name the sentence, you have expressed a
  preference rather than made a design decision.

What the documents look like

An organisation, its sites, its applications, its constraints, its plans. Some of it matters, some of it constrains, some of it is there to be recognised as irrelevant. Separating those three is the work.

The constraining material is the most valuable and the easiest to skim past, because it is phrased as background rather than as a requirement. A sentence about existing equipment staying in place rules out whole categories of answer and does not announce that it is doing so.

The blueprint is the authority

The published topic list states what the module covers and how it is weighted. Every summary of it, including this one, is somebody's interpretation, and preparation planned from an interpretation inherits its errors.

Reading it directly takes ten minutes and is the first thing to do. It also settles questions about scope that otherwise consume preparation time on things that are not examined.

How Do You Read a Requirements Document?

What are you extracting?

Four categories. Stated requirements, which are binding and usually countable. Implied requirements, which follow from something stated without being stated themselves. Constraints, which rule options out and are frequently phrased as background. And irrelevant detail, which is there to be recognised and discarded. A first pass that produces a list under each heading is worth more than a first pass that produces an answer.

A Deeper Dive into Extraction

Stated requirements

The ones written as requirements: a number of users, a recovery time, a service that must be available, a compliance obligation. These are the easy category and the one everybody captures.

The discipline worth adding is writing each one down with the number attached, because a requirement remembered without its number becomes a vague sense that something needs to scale, which does not discriminate between options.

Implied requirements

Consequences of something stated. Two data centres implies a question about which is primary and what happens when one is lost. A stated recovery time implies a convergence budget. A mention of voice implies requirements about delay and variation that the document may never state.

This category is where most of the discriminating information lives, and extracting it is the difference between a reading that produces four requirements and one that produces twelve.

EXTRACTION, FOUR COLUMNS

  STATED              "4,000 users across 12 branches"
                      "recovery within 5 seconds for voice"
                      "must integrate with existing identity system"

  IMPLIED             voice    -> delay, variation, priority treatment
                      12 sites -> a summarisation boundary is available
                      5 s      -> rules out anything with slow detection

  CONSTRAINING        "the existing access switches are retained"
                      "the team is three people"
                      "no capital spend this year"

  IRRELEVANT          the company's industry, unless it implies compliance
                      the number of floors, unless it implies cabling

Constraints, which rule things out

Existing equipment retained. A team of a given size. A budget. A regulatory obligation. A migration window. Each removes options, and removing options is the fastest way to a defensible answer.

They are phrased as background because that is how organisations describe themselves. A sentence saying the operations team has three people is a statement about what the design may require them to run, and it is the one most often read as colour.

The material that is there to be discarded

Detail that constrains nothing. It exists partly for realism and partly to see whether it is treated as significant. Spending time on it is the cost; recognising it costs nothing.

The test is simple: does this sentence rule anything out or require anything? If not, it is context.

What is not said

The most useful reading question. A document that says nothing about a growth plan is a document describing a network that does not need to accommodate one. A document silent on a second site is not describing a design problem involving two.

Adding requirements the document does not state is the most common failure in this material, and it comes from designing the network you would build rather than the one described.

Ordering by discriminating power

Some requirements eliminate more options than others. A hard constraint on existing equipment may settle half the design immediately; a preference about management tooling settles very little.

Working through the high-discrimination ones first narrows the space fastest and means the remaining decisions are made among fewer options with more information.

ORDER BY HOW MUCH EACH ONE ELIMINATES

  1. Hard constraints        existing equipment, budget, compliance
  2. Numerical requirements  scale, convergence, availability
  3. Named technologies      "must support X"
  4. Preferences             "prefers", "would like", "ideally"

  Working top down means each decision is made with the
  space already narrowed by the one above it.

What Makes an Answer Right?

When several would work?

Traceability. The answer that can be justified by pointing at what the scenario says is better than the one that is technically superior in the abstract. That is not a scoring convention, it is what design means — a decision is a choice made for a reason, and a choice made without one is a preference. The practical test: for each element, name the sentence. If you cannot, it is decoration.

A Deeper Dive into Justification

Technically better is not the criterion

A more capable design that the organisation cannot operate, cannot afford, or does not need is worse than a simpler one that meets the requirements. That is uncomfortable for people who enjoy the technology and it is the central judgement being assessed.

The clearest form: a design with a feature nobody asked for has added operational cost and risk in exchange for nothing. That is a worse design, not a more thorough one.

The elimination argument

The strongest justification is usually negative. This option is ruled out by a constraint; that one by a numerical requirement; the remaining one is therefore the answer. Stating it that way is more convincing than asserting that the chosen option is good, and it demonstrates that the alternatives were considered.

It also survives disagreement about preferences, because it rests on what the document states rather than on judgement.

THE SHAPE OF A GOOD JUSTIFICATION

  Requirement:  "recovery within 5 seconds for voice traffic"
  Constraint:   "existing access switches are retained"

  Option A      ruled out: detection alone exceeds the budget
  Option B      ruled out: not supported on the retained switches
  Option C      meets both; costs more configuration on the
                distribution layer, which the requirement justifies

  Chosen: C, because of the two sentences above.

Naming what you gave up

Every choice costs something. Stating the cost demonstrates that the trade was understood rather than unnoticed, and it is the difference between a choice and a guess that happened to be right.

It also protects an answer that is arguably not optimal: an answer that names its own weakness and explains why the weakness is acceptable here is stronger than one that claims there is none.

The two-sentence answer

Choice, then reason, then cost. Three clauses. That is enough for most design questions and it is more useful than a paragraph that never quite commits.

Under time pressure this shape also produces answers faster, because it forces the reason to exist before the writing starts.

THREE CLAUSES, EVERY TIME

  "Use [X], because [the requirement that demands it].
   The cost is [what you gave up], which is acceptable
   because [the requirement that makes it acceptable]."

  Short, committed, and traceable. A paragraph that
  surveys the options without choosing scores nothing.

Committing

An answer that describes the options and does not choose has not answered. That is a genuine temptation when several work, and it is the wrong resolution — the module asks for a design, and a design is a set of decisions.

Where the requirements genuinely do not discriminate, choose the simpler option and say that the requirements do not distinguish them. That is a decision with a reason.

A worked example, end to end

The whole method fits into a page for any single decision, and seeing it once makes the shape obvious. The requirements come from the extraction, the elimination comes from comparing options against them, and the answer is three clauses.

The part worth noticing is how little of it is technology. The options are familiar and the work is entirely in deciding which of them the stated situation supports, which is the skill the module is assessing and the one that does not improve by learning another feature.

ONE DECISION, WORKED THROUGH

  Question:  how should the branch sites reach the data centre?

  From the extraction:
    STATED        "18 branches"  "voice recovery within 5 seconds"
    CONSTRAINING  "no capital spend this year"
                  "operations team of three"
    IMPLIED       voice -> needs priority treatment end to end
                  18 sites -> a hub-and-spoke shape is natural

  Options and elimination:
    Replace the branch routers        ruled out: no capital spend
    Full mesh between branches        ruled out: 18 sites, three staff
    Hub and spoke, dynamic tunnels    survives both constraints

  Answer:
    "Hub and spoke with dynamic branch-to-branch tunnels,
     because the estate is retained and the team is three people.
     The cost is that branch-to-branch traffic traverses the hub
     until a direct tunnel forms, which the requirements do not
     prohibit and which the recovery target is unaffected by."

Consistency across answers

A set of answers is a design, and the parts have to fit. An answer choosing one approach in one place and a conflicting one elsewhere is internally inconsistent, which is worse than either choice alone.

A final pass reading the answers as a whole catches this, and it is worth reserving time for. It is also where a misread requirement shows up, because an inconsistency usually means one of the two answers was based on a misunderstanding. Reading this once is not the same as being able to do it under time pressure, which is what repetition against realistic CCIE lab practice scenarios is for.

Which Trade-offs Recur?

What are the axes?

Six, and almost every scenario sits somewhere on several of them. Scale against simplicity. Convergence speed against stability. Redundancy against the number of states to understand. Standard technology against vendor capability. A gradual migration against a clean cut. And technical quality against whether the organisation can operate the result. Recognising which axes a scenario is about is most of the analysis.

A Deeper Dive into the Trade-offs

Scale against simplicity

Structure — areas, summarisation, hierarchy — costs configuration and understanding and buys the ability to grow. A network that will not grow gains nothing from it and pays the cost anyway.

The discriminating question is what the document says about growth. Silence on growth is information: it describes a network that does not need to accommodate it, and structure introduced anyway is unjustified.

Convergence against stability

Faster detection means reacting to conditions that would have cleared on their own. A design tuned for a recovery target on a transport that is not stable enough for it will move traffic repeatedly, which is worse than the slower recovery it replaced.

The document usually states a recovery target and describes the transport. Those two together decide this axis, and a stated target on an unreliable path is a signal that damping matters as much as speed.

MAPPING A REQUIREMENT ONTO AN AXIS

  "voice must recover within 5 seconds"
  "branches connect over consumer broadband"

  -> the target demands fast detection
  -> the transport punishes fast detection with flapping
  -> the answer is fast detection PLUS damping on recovery,
     and saying so is the point of the answer

Redundancy against comprehensibility

Every added path is another state the network can be in and another combination to reason about. A design with four paths has more failure combinations than anyone will test, and the untested ones are where the surprises are.

The question the document answers is what must survive. A stated availability requirement sets the floor; anything beyond it is complexity purchased with no requirement behind it.

Standard against vendor-specific

Vendor technology is frequently more capable and harder to leave. Standard technology is portable and sometimes cannot do what is needed.

The document decides this through statements about existing estate, procurement, or multi-vendor obligations. Where it says nothing, either is defensible and the justification carries the answer — which makes this a good axis on which to state the trade explicitly.

Migration approach

A gradual migration means a long period during which both designs exist, which is complexity and reversibility. A clean cut means a short intense change with little coexistence and no easy way back.

The deciding factors are the size of the change window the organisation can tolerate and its appetite for risk. Both are usually stated, and this axis is frequently the one a scenario is really about.

THE MIGRATION QUESTION, DECIDED BY TWO SENTENCES

  "the business tolerates one four-hour window per quarter"
  -> gradual. There is no window large enough for a cut.

  "the site is closing and moving to a new building"
  -> clean cut. There is no old network to coexist with.

  Read for the window and the appetite. Those decide it.

Operability

The axis that engineers weight least and organisations weight most. A design the team cannot run is a design that will be run badly, and a technically inferior design that the team operates competently produces a better network.

The document states this through team size, skills, existing tooling and support arrangements. A scenario mentioning a small team is a scenario in which the simpler option has a strong argument that has nothing to do with the technology.

How Should You Prepare Differently?

What actually helps?

Practising the reading, not the technology. Taking a scenario, extracting requirements into the four categories, and writing three-clause answers is the activity that maps onto the module. Studying another protocol does not, because the constraint is almost never that a candidate did not know an option existed — it is that the option chosen was not traceable to anything the scenario said.

A Deeper Dive into Preparation

Why more technology does not help

The technologies involved are the ones examined everywhere else in the certification, and somebody prepared for the rest of it knows them. The module is not testing whether they are known; it is testing whether a choice between them can be justified.

So preparation that consists of studying another feature is preparation for a different problem. It feels productive because it is measurable, which is part of why it happens.

What to practise instead

Find or write a scenario. Extract requirements into the four categories, timed. Produce three-clause answers for each decision. Then check every answer against the rule: can you cite the sentence?

Doing that a handful of times builds the habit that the module rewards, and it exposes the specific tendency — almost universal — to design the network you would build.

A PRACTICE LOOP THAT MAPS ONTO THE MODULE

  1. Read the scenario once, no notes.          (10 min)
  2. Read again, extracting into four columns.  (20 min)
  3. List the decisions the scenario requires.  (10 min)
  4. Three clauses each: choice, reason, cost.  (30 min)
  5. Check: cite a sentence for every element.  (10 min)
  6. Read all answers together for consistency. (10 min)

  Step 5 is where the learning is. It fails the first few times.

Using real projects

A design done at work is a scenario with a known outcome. Writing down what the requirements were, what was chosen and why, and then checking whether the reasons were requirements or preferences is a productive exercise and uncomfortable.

It is also the closest available approximation, because the constraints were real and the operability question was real.

Reading other people's designs critically

A published design document, read with the question "what requirement motivated this", trains the same muscle. Most contain elements nobody can justify, which is itself instructive.

The useful discipline is to write the justification you think the author had and then look for whether the document supports it. The gap between the two is what the module is assessing.

Time discipline

The module is time-boxed and not revisitable, so practising with a clock matters more than it does for material where the strategy is to leave hard items until the end.

The allocation that works: a substantial fraction on reading, the bulk on answering, and a reserved block at the end for the consistency pass. Running out of time before that final pass means a set of answers that may contradict each other.

A TIME SHAPE THAT LEAVES ROOM FOR THE LAST PASS

  Reading and extraction     ~25 percent
  Answering                  ~60 percent
  Consistency pass           ~15 percent, reserved

  The last block is the one that gets eaten, and it is the
  one that catches a misread requirement propagated into
  three answers.

The tendency to watch for

Designing what you would build and then finding requirements that agree. It is nearly universal, it feels like expertise, and it produces answers that are elaborate and untraceable.

The counter is mechanical: extract first, design second, and check every element against a sentence. The check catches it because the elaborate parts have no citation.

Working with someone else

The most effective practice available is to answer a scenario independently of a colleague and then compare. Two people reading the same document produce different extractions, and the differences are almost always requirements one of them read as background.

The argument that follows is the valuable part. Defending a choice to someone who chose differently forces the justification to exist and to rest on the document rather than on preference, which is exactly the skill being assessed. It also surfaces the unstated assumptions each of you brought, which is the thing neither of you can see alone. Where you both cite the same sentence and still disagree, the scenario genuinely does not discriminate and either answer is defensible — which is itself a useful thing to be able to recognise quickly.

What to read

The published topic list, first and directly. Design guidance from the vendor for the architectures involved, which is where the trade-offs are stated explicitly. And anything describing a real migration, because migration is the axis most scenarios turn on and the one least covered by technical study.

Beyond that, practice. The module rewards a habit, and habits come from repetition rather than from reading about them.

Blueprint framing

The CCIE Enterprise Infrastructure v1.1 lab includes a design module carrying a substantial share of the assessment, and the published topic list is the authoritative statement of its scope and weighting. Everything above is one reading of what that scope requires in practice; the list itself should be read directly.

Conclusion

This module removes the devices, and with them the ability to discover a misreading by testing. Reading becomes the work rather than the preparation for it, and the first substantial block of time belongs to reading twice before any answer is formed. It is also timed separately and not revisitable, which inverts the usual strategy: answer everything at a defensible level rather than perfecting some and abandoning others.

The extraction is four categories. Stated requirements, which everybody captures. Implied ones, which carry most of the discriminating information and have to be derived. Constraints, which eliminate options fastest and are phrased as background — the sentence about the size of the operations team is a design constraint, not colour. And material that is there to be discarded. What the document does not say is information too: silence about growth describes a network that does not need to accommodate it.

And the criterion is traceability rather than technical quality. An answer that can point at the sentence that motivated it is stronger than one that is more capable in the abstract, and an element with no citable requirement is cost purchased for nothing. Justify by elimination, name what you gave up, and commit — a fair survey of three options that never chooses one has not answered the question. The tendency to design the network you would build and then look for agreeing requirements is nearly universal, and the only reliable counter is mechanical: extract first, design second, and check every element against a sentence. More CCIE Enterprise Infrastructure material — labs, protocol breakdowns and study guides — is collected on the SPOTO CCIE site.

External Links

• RFC 3439 — Some Internet Architectural Guidelines and Philosophy
• RFC 1958 — Architectural Principles of the Internet
• RFC 3535 — Overview of the 2002 IAB Network Management Workshop
• RFC 2072 — Router Renumbering Guide
• RFC 7454 — BGP Operations and Security
• Cisco Learning Network — CCIE Enterprise Infrastructure

Reference Notes

1. RFC 3439 argues that complexity in network design carries costs that are frequently underestimated, and that added features increase the number of interactions that must be understood.
2. RFC 3439 describes the coupling between components as a source of unexpected behaviour, which is the basis of the trade-off between redundancy and comprehensibility.
3. RFC 1958 states the architectural principle that simplicity should be preferred where alternatives are otherwise equivalent.
4. RFC 3535 records operator-stated requirements for network management, including the value of being able to compare intended configuration against actual configuration.
5. RFC 3535 identifies operability concerns raised by operators as distinct from protocol capability, supporting the treatment of operability as a design requirement.
6. RFC 2072 describes the practical difficulties of renumbering a network, illustrating why migration approach is a design decision with long-lived consequences.
7. RFC 7454 provides operational guidance for BGP, distinguishing configurations that are technically valid from those that are operationally advisable.
8. Cisco design guidance for enterprise campus architectures describes hierarchical layering and the trade-offs between layer boundaries, convergence and operational complexity.
9. Cisco design guidance describes the relationship between failure detection speed and the stability of the underlying transport.
10. Cisco design guidance for migration to software-defined architectures describes coexistence approaches and the trade-off between gradual transition and a discrete cutover.
11. The CCIE Enterprise Infrastructure v1.1 lab comprises a design module and a deploy, operate and optimise module, assessed separately.
12. The CCIE Enterprise Infrastructure v1.1 unified exam topics are the authoritative statement of the scope and weighting of each domain, including the design module.