Category Archives: CCDA

CCDA 200-310 at CBT Nuggets – Revised Outline

CCDA, , , ,

CCDA

The New CCDA Date:

In addition to the CCDA outline changing, I have a revised completion date. This course completes on 12/31/2015 just in time for the new year! As you can see below – the outline grew considerably based on author and student feedback. Remember, current subscribers can enjoy many of the Nuggets that are completed right now:

CCDA Link

The New and Improved CCDA Outline :

  1. Course Introduction
  2. Plan, Build, Manage
  3. The PPDIOO Network Lifecycle
  4. Characterizing the Existing Network
  5. IP SLA
  6. Top-Down Versus Bottom-Up
  7. Case Study: Top-Down Design
  8. Building a Modular Network
  9. Applying Modularity
  10. Campus Network Design
  11. Designing Enterprise Network Security
  12. Designing the Edge Module
  13. WAN Design
  14. Branch Design
  15. Data Center Design
  16. IP Addressing
  17. Routing Protocols
  18. Case Study: IGPs
  19. Case Study: BGP
  20. QoS
  21. Wireless
  22. Case Study: Wireless
  23. Collaboration
  24. Case Study: Collaboration
  25. SDN

EIGRP’s Composite Metric for CCDAs

CCDA, , , ,

An EIGRP Overview:

Are you like me? Are you intrigued by the Cisco invention of EIGRP? Here is an excellent text you should consider for your Holiday Reading List:
EIGRP for IP: Basic Operation and Configuration by Russ White and Alvaro Retana

It is always great to visit with Russ White each Cisco Live, and I have read many of his works. His text does a fine job clearing many of the misconceptions regarding the composite metric of EIGRP. Having taught this subject for decades now, I have seen so many students willing to argue on many of these points. Let’s review some of these here in this post.

The Merry Metric:

  • While we are taught since CCNA days that the EIGRP metric consists of 5 possible components – BW, Delay, Load, Reliability, and MTU; we realize when we look at the actual formula for the metric computation, MTU is actually NOT part of the metric. Why have we been taught this then? Cisco indicates that MTU is used as a tie-breaker in a situation that might require it. To review the actual formula that is used to compute the metric as well as other great information, click here.
  • Here is the basic formula – EIGRP Metric = 256*((K1*BW) + (K2*BW)/(256-Load) + (K3*Delay)*(K5/(Reliability + K4)))
  • Notice from the formula that the K (constant values) impact which components of the metric are actually considered. By default K1 is set to 1 and K3 is set to 1 to ensure that Bandwidth and Delay are utilized in the calculation. For example, if you wanted to make Bandwidth twice as significant in the calculation, you could set K1 to 2. The metric weights command is used for this manipulation. You should note that the metric weights command starts with a TOS parameter that should always be set to 0. Cisco never did fully implement this functionality.
  • The Bandwidth that affects the metric is taken from the bandwidth command used in interface configuration mode. Obviously, if you do not provide this value – the Cisco router will select a default based on the interface type.
  • The Delay value that affects the metric is taken from the delay command used in interface configuration mode. This value depends on the interface hardware type, e.g. it is lower for Ethernet but higher for Serial interfaces. Note how the Delay parameter allows you to influence EIGRP path selection decisions without the manipulation of the Bandwidth value. This is nice since other mechanisms could be relying heavily on the bandwidth setting. For example, EIGRP bandwidth pacing or absolute QoS reservation values for CBWFQ.
  • The actual metric value for a prefix is derived from the SUM of the delay values in the path, and the LOWEST bandwidth value along the path. This is yet another reason to use more predictive Delay manipulations to change EIGRP path preference.
EIGRP in the CCDA