ccie blog

Classic EIGRP Metric Calculation

I’ve hated this formula and avoided it for about 5 years. I just buckled down and figured it out, and actually it’s pretty easy providing we are using default K values K1=1 and K3=1 (i.e. BW and Delay,) are used for the metric. The entire metric formula can actually just become BW + Delay. Bare with me, see the math below:


The actual formula is below

Metric=[K1* BW + (K2*BW)/(256*load) + K3 * Delay]

Since K2 = 0, this means the whole line of (K2*BW)/(256*load) can be completely removed (because 0 divided by anything is 0). So the formula becomes

Metric= K1*BW + K3*Delay

Since K1=1 and K3=1, the formula can be simplified again to

Metric= BW + Delay


So that’s it. Although there is a catch, which is how all the exam questions always try and catch you out. In the EIGRP metric calculation, the BW is not actually the BW & the delay is not actually the delay. How annoying is that? See below

  • Bandwidth = Inverse lowest bandwidth along a path in Kbps x 10^7 * 256.
  • Delay = Lowest cumulative delay along the path x 256

My first question was, what the heck is inverse bandwidth? Actually it just means 1/BW.  Let do a real life example of the calculation then. Take a look at the show output below, we will calculate how EIGRP came up with the metric as being 28160 for this network.

UKINTR1#sh ip eigrp topology
EIGRP-IPv4 Topology Entry for AS(100)/ID( for
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 28160
  Descriptor Blocks: (GigabitEthernet0/1), from Connected, Send flag is 0x0
      Composite metric is (28160/0), route is Internal
      Vector metric:
        Minimum bandwidth is 100000 Kbit
        Total delay is 100 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 0
        Originating router is

So we simplified the metric formula to BW + Delay. We’ve only got 2 values to work out, so let’s start by working out the bandwidth.

Bandwidth = Inverse lowest bandwidth along a path in Kbps x 10^7 x 256.
Bandwidth = 1/100000 x 10^7 x 256
Bandwidth = 25600

Now lets work out the delay

Delay = Lowest cumulative delay along the path x 256
Delay = 10 x 256 (remember delay is in “Tens of Microseconds”, whereas the output above shows only microseconds).
Delay = 2560

Now lets put this into the Metric

Metric = BW + Delay
Metric = 25600 + 2560
Metric = 28160


This post will discuss Link Control Protocol (LCP),  Challenge Handshake Authentication Protocol (CHAP), and Point-to-Point Protocol (PPP).

Read the rest of this entry »

RSTP Synchronization – A detailed guide

I got bored with reading stuff that doesn’t go into enough detail about the RSTP synchronization process on the web, so I’m making my own guide and notes about it.  I’m going to start by identifying the port states and roles, then go through the RSTP synchronization process and explain how they are used.

RSTP port states and roles

Port Roles

  • Root port
  • Designated port
  • Edge port
  • Alternate port
  • Backup port

Port States

  • Discarding
  • Learning
  • Forwarding


RSTP Synchronization Process

I’m going use the topology below to go through the synchronization process.


Read the rest of this entry »

Spanning-Tree Backbonefast

This is a 6 minute video that talks in detail about how backbone fast works and how it can reduce convergence time with spanning-tree


In this lab I’m going to go over the config for an MPLS VPN.


Read the rest of this entry »

EIGRP Leak-Map

The leak-map just allows you to advertise a specific prefix within the range of a summary advertisement, as well as the summary itself. We can see in the diagram below that we are advertising the network out to R5 & R6, however, we are also advertising the network out to R5 using a leak-map.

EIGRP Leak-Map

I’ve configured everything but the leak-map so far. Basically all routers just have EIGRP 100 running & auto-summary disabled. R3 has been configured to summarise out to R5 & R6. Below is the current routing tables of both R5 and R6.
Read the rest of this entry »

EIGRP Query Scoping Using Summarisation

I didn’t understand how this worked, so I took a practical example and put it in for testing. In the diagram below on R3 I’ll advertise a summary route to R5 and R6. From there we’ll shutdown interfaces to the network, and see how the query scope is limited from this summarisation.

EIGRP Query Scoping Using Summarisation

Read the rest of this entry »

EIGRP Redistribution Problem

I was reading a Cisco 360 article (BRKRST-3330) and spotted a cool problem I’ve not run into with regards to redistribution. In the topology below, R2 is learning the external EIGRP route, but R1 is not.

EIGRP - Redisribution Problem

Read the rest of this entry »

Does VTP transparent mode relay VTP advertisements or not (All Scenarios Tested)?

Does VTP transparent mode relay VTP advertisements or not (All Scenarios Tested)?

There has been a lot of controversy about the VTP transparent mode switch, on whether or not it relays VTP information. In the Cisco documentation there is a completely incorrect statement that has caused excessive confusion throughout the networking community. This statement is:

  • “In VTP version 1, a VTP transparent switch inspects VTP messages for the domain name and version and forwards a message only if the version and domain name match. Because VTP version 2 supports only one domain, it forwards VTP messages in transparent mode without inspecting the version and domain name.”

Both statements are invalid.  In short; for all scenarios, regardless of VTP version, only the VTP domain names need to match.  The VTP version can be different on the transparent switch, but as long as the domain name is the same, the switch will relay the VTP advertisements as we will see in my testing below. I’m about to use the network below to start my testing. All switches will be put in VTP version 1. Sw1 & Sw3 will be configured as a server, and Sw2 will be configured as transparent mode.


Read the rest of this entry »

IPv6 Neighbor Discovery Protocol (NDP)

The NDP was the most confusing thing for me to understand. I think it’s down to the fact that NDP covers a lot of things. For example, when I was learning, I assumed that the neighbor discovery protocol just involved the exchange of neighbor solicitation & neighbor advertisement messages. However, the way router discovery (router solicitation & router advertisements), or Duplicate Address Detection (DAD) works comes down to the neighbor discovery protocol. There’s currently a total of nine main functions of NDP, as listed below (each function is discussed in more detail further down this post):

The Neighbor Discovery Protocol (NDP) is responsible for:

  • Router discovery
  • Prefix discovery
  • Parameter discovery
  • Address Autoconfiguration
  • Address resolution
  • Next-hop determination
  • Neighbor unreachability detection
  • Duplicate address detection
  • Redirect
Read the rest of this entry »