CCDA Design – Key Things I learned

Following on from a recent CCNA Security pass I decided while I was in the swing of things to keep going with my studies and work towards the CCDA Design qualification which thankfully I passed. From my perspective this was a slightly more difficult exam than the CCNA R&S and the CCNA Security exams due to the breadth of material covered and the level of knowledge needed for each area however this isn’t always a bad thing – the purpose of qualifications is to demonstrate your knowledge and expertise in a particular field and if it were too easy then the qualification would become quickly devalued!

The CCDA qualification covers more of the why, rather than the how, Cisco recommends things the way they do and details further some new design concepts that are not part of the main CCNA Routing and Switching pathway. These topics include:

  • Planning for new infrastructure projects including requirements gathering and reporting on the pre and post deployment network metrics
  • Design considerations, methodologies and objectives
  • Wireless network design, mainly focusing on Wireless LAN Controllers (WLCs)
  • Designing voice networks including QoS requirements
  • Network virtualisation technologies including NX-OS
  • Ensuring quality of service, capacity, security and performance

The material itself wasn’t too taxing to learn with much of it being a revisit to CCNA R&S and Security topics however some additional learning was required on the Cisco Campus Enterprise Architecture and its individual components as well as the areas not usually covered in the routing and switching track.

There is no requirement to learn any IOS commands in the material however I did find it useful to lab up some of the concepts just to cement my understanding of how it fitted together. For my lab I used two 3560G switches, a pair of Cisco 5505 ASAs and a 887VA router which allowed most but not all of the concepts to be covered.

The main areas that benefited me during my studying were the:

  • Top down vs. bottom up methodologies
    • Top down
      • Define the upper layers (application, presentation, session) first then what infrastructure is needed at lower layers to support it
      • Takes longer but provides a tailored design to specific goals of business

      Bottom up

      • Quickly respond to specific requirement
      • Uses previous experience
      • May miss some business requirements that could impact negatively on the proposed design
      • High probability of failure
    • Bottom up
      • Quickly respond to specific requirement
      • Uses previous experience
      • May miss some business requirements that could impact negatively on the proposed design
      • High probability of failure
  • Enterprise Architecture
    • Introduction of additional modules over the standard 3-layer campus architecture taught in the CCNA R&S sylabus
    • Modules include enterprise edge, service provider edge and remote
    • Provides scalability, adaptability and aids troubleshooting
  • Layer 3 / routed access layer
    • Provides faster convergence
    • Fully utilises all available uplinks (as opposed to STP)
    • A very good post on this is over at packetlife.net

2018-03-30 14_56_26-Start

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s