Filters:

  • Technologies

  • Instructors

  • Understanding EIGRP named mode wide-metric computation

    In a previous blog I discussed running EIGRP named mode in GNS3. In that blog, I promised to dig a little deeper into how the results of the computations were reached. I have published a couple of blogs which strive to display the classic formula in human friendly form. I will attempt the same thing in this blog. It is important to note that the wide metric formula I will be showing in this blog is for 1 Gigabit links and slower. The formula is adjusted for 10 Gig and above. I will leave that for a future blog.

    For instructor-led Cisco CCNA Certification Training, see our class schedule.

    First off, let’s take a look at the topology I built inside GNS3 (v1.3.9)

    001-topology-EIGRP-named-mode-wide-metric-computation

    Figure 1-Lab topology

    As figure 1 shows, R1, R2, and R3 are all connected using GigabitEthernet. The connection from R1 to R4 to R3 is FastEthernet.

    I have configured EIGRP named mode on all four routers, and neighbor relationships have formed where expected. The focus of attention here is the loopback interface hanging off R3. Clearly the least cost path from R1 to that destination is through R2. Let’s take a look at the routing table of R1 in our converged network:

    002-router-EIGRP-named-mode-wide-metric-computation

    Figure 2-Routing table of R1

    Notice that R1 knows about the 10.3.1.0 destination network and that the metric showing in the routing table is 16000. How does the router compute this number? Using the EIGRP metric calculation formula, of course! There are numerous web references to this formula, but an excellent Cisco reference can be found here. All the subtle nuances and reasonings as to why an updated formula is necessary and why 64 bit metrics are now a necessity can be found by reading from that webpage. I include a table from that source as figure 3:

    You may also like:  How MAC Addresses Are Assigned to Devices

    003-constants-EIGRP-named-mode-wide-metric-computation

    Figure 3-Constants used in EIGRP wide metric calculation

    Using the above table as a reference, let’s see if we can duplicate the router’s computation. I will abbreviate the names in the table in figure 3 to shrink to formula. Here is a guide to understanding my result:

    • ps = picoseconds (delay is counted in picoseconds [1 trillionth of a second]). Value obtained from actual network information.
    • EWS = EIGRP WIDE SCALE = 65,536
    • EDP = EIGRP DELAY PICO= 1,000,000
    • EBW = EIGRP BANDWIDTH = 10,000,000
    • mbw = Minimum bandwidth in path to destination. Value obtained from actual network information.

    The full formula, as in classic EIGRP, is more involved, but if the ‘K’ values are left at their default values, the formula (for 1Gig and slower) simplifies to the following:

     

    004-formula-EIGRP-named-mode-wide-metric-computation

    The first portion of the formula addresses the Delay aspect of EIGRP’s metric, and the second half addresses the Bandwidth portion.

    We now type the command which reveals the necessary numbers, shown in figure 4:

    005-topology-EIGRP-named-mode-wide-metric-computation

    Figure 4-Topology table of R1

    The metric using the GigabitEthernet path (the numbers in red boxes) is found thusly:

     

    006-topology-EIGRP-named-mode-wide-metric-computation

    Using the rib-scale of 128, we take the result from above and divide, obtaining:

    2048000 ÷128=16000

    Sure enough, refer back to figure 2 and you will see the number 16000 as the best path metric to the destination network, and therefore is installed in the routing table.

    If we want to check our consistency, let’s see what happens if we force R1 to use the FastEthernet path. Let’s kill the g2/0 interface on R2 and observe the result in R1’s routing table. We will use the blue numbers from figure 4 to make our prediction. If our math calculations are consistent, we should see the following result in R1’s newly converged routing table:

    You may also like:  Cisco IOS - The Difference Between Login and Login Local

     

    007-devide-by-128-factor-EIGRP-named-mode-wide-metric-computation

    Applying the rib-scale (divide by 128) factor to our result:

    19742720 ÷128=154240

    There is the prediction – 154240. Let’s see if that number appears in the routing table of R1:

    008-result-128-factor-EIGRP-named-mode-wide-metric-computation

    Figure 5-Routing table of R1

    How about that?! Sure enough, 154240 is the new metric once we disabled the path through R2.

    My goal here is to present the formula and the computations in a way that is easily followed by the human eye. I hope I have succeeded. As noted at the outset, this computation changes again in networks with links faster than 10 Gig, so if you are manually performing these computations and your results differ, verify that your link speeds fall within the constraints of this blog. Happy path manipulation!!

    If you have any comments or questions, please feel free to post them….
    Until next time.

    Mark Jacob
    Cisco and CompTIA Network + Instructor – Interface Technical Training
    Phoenix, AZ

    See what people are saying...

    1. Lachlan Falconer

      Many thanks, this was very helpful. There is a small mistake under Figure 4, working out the math of the successor route with FD 2048000. The second part of the equation (the delay) has one-too-many zeros on the bottom.

      I count 7 x zeros on top, and 7 on the bottom. It should be six on the bottom so you end up with 655360.

      Kind regards,
      Lachlan

    Share your thoughts...

    Please fill out the comment form below to post a reply.