CCDE – The CCDE Mindset

This post was written to help CCDE candidates get into the right mindset but is very applicable to network architects and network engineers in general.

We humans tend to have a lot of bias. Sometimes it’s based on experience but often it’s based on how pure a technology is or a bad implementation of a protocol. Often we don’t reevaluate our opinion so if we had a STP incident in the past, STP becomes inherently bad for all future.

Preparing for the CCDE from a technology standpoint is relatively easy compared to getting into the right mindset and getting enough exposure to network designs. Don’t get me wrong, it’s a technically difficult exam but the number of candidates taking the exam that have the right knowledge level of technology are far higher than the number of people actually passing the exam. I have seen this time and time again.

Because we have this bias we immediately base our feeling and design based on our feelings or previous experience without taking the business requirements and technical constraints into consideration.Yes, maybe MPLS was the best answer to the question from a technical standpoint but maybe there was a constraint that only IP forwarding is allowed. Yes, route reflection may have been the most scalable answer but the business requirement was to use optimal forwarding at all times. These are examples of when a candidate selects what they believe to be the best technical answer, and often rightfully so but that is not what this exam, nor network design in general is about. It’s about providing the best solution and design based on the requirements and constraints of the business.

Let me give some examples of where we have a bias and why that may be wrong.

NAT is not a security tool – NAT isn’t a security tool but putting something behind NAT does have security implications. It destroys end to end connectivity which we consider to be bad but from a security perspective this is what lessens the attack vector.

NAT is pure evil – I don’t like to use NAT more than necessary but there are cases where NAT is required such as network merger scenarios with overlapping subnets. There are also use cases where you want to force traffic flows to follow a certain path, NAT is useful in that case as well.

All L2 is bad – Naturally L3 is the preferred option for most designs but if the business has a requirement for L2 we have to provide L2 in the best way that is available such as leveraging OTV to transport frames between two sites.

If you want to become a better CCDE candidate and/or network architect/engineer I challenge you to do the following. For the technologies you consider to be “bad” such as NAT and GRE, try to think of 2-3 positive aspects of using these technologies/protocols. For the technologies you consider to be good such as MPLS and route reflection, try to think of 2-3 negative aspects of using these technologies/protocols. When you start thinking about the technologies from a more objective perspective without involving your bias, then you have taken a large step towards becoming a better CCDE candidate and network architect/engineer. If you then also learn how to interpret business requirements and constraints and map them onto the questions asked you will be on the right path to passing the CCDE exam.

I hope this post is useful both for you on the journey towards the CCDE but also for anyone that wants to have a better understanding of network design.