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.

CCDE – The CCDE Mindset
Tagged on:         

7 thoughts on “CCDE – The CCDE Mindset

  • January 26, 2017 at 12:24 am

    I think people tend to forget that all protocols and methods, whether they are generally considered “good” or “bad”, were invented to solve a particular problem, and usually it was some sort of business problem. I’ve never understood people who refuse to reconsider protocols that they’ve either had a bad experience with in the past or simply dismissed out of hand without having a proper base of knowledge in place.

    I see this happening a lot right now with SD-WAN. Some people refuse to give up their slower MPLS links because the Internet provides no guarantees or QoS. But common broadband links today are generally many times more reliable than they were 10 years ago. People like this are basing their experience on something that happened many years ago, and have not kept up with the times. It has been my experience that most private WAN circuits, in general, seem to be no more and no less reliable than today’s broadband connections.

    Of course there is something to be said for past experience bringing a person to where they are now, but at the same time, they should not let past experience hold them back from the future.

    Thank you for writing this.

    • January 26, 2017 at 9:41 am

      Thanks, Jed!

      Internet circuits today are very reliable. As we move away from traditional telephony to conferencing apps such as Skype the requirement to do QoS lessens.

      There are still valid use cases for MPLS but most businesses would be fine with running Internet only. At least moving to hybrid would be a big win for many businesses that currently do dual MPLS.

  • January 26, 2017 at 4:10 am

    Great post Daniel. I agree with all your points. I always found that being able to defend ANY technology (in a general sense) by finding legitimate use-cases was an excellent mental exercise during my studies.

    • January 26, 2017 at 9:39 am

      Thanks, Nick! I think one of the reasons you passed in your first attempt was that you had an open mind and wasn’t afraid to explore “strange” designs.

  • Pingback:Worth Reading: The CCDE Mindset - 'net work

  • February 3, 2017 at 11:14 am

    Great post. You’re speaking out of my soul. Especially in case of topics regarding MPLS vs. VPN over Internet as an alternative solution.

  • February 28, 2017 at 9:29 am

    Great insight Daniel! Whether you’re studying for CCDE or just developing your design style, the best all round solutions for real customers will always come out of experience, pragmatism and compromise, not out of vendors’ validated designs 🙂


Leave a Reply

Your email address will not be published. Required fields are marked *