Cisconinja’s Blog

Testing EIGRP metric with non-default K-values

Posted by Andy on September 6, 2009

In this post we will look at how changing EIGRP K-values from their defaults effects the metric calculation and how it effects when updates are sent.  The topology and configurations for this example are shown below:

EIGRP Topology

R1:
interface Loopback0
 ip address 10.1.1.1 255.255.255.0
!
interface Serial0/0
 ip address 10.0.12.1 255.255.255.0
!
router eigrp 1
 passive-interface Loopback0
 network 10.0.0.0
 metric weights 0 1 1 1 1 1

R2:
interface FastEthernet0/0
 ip address 10.2.2.2 255.255.255.0
!
interface Serial0/0
 bandwidth 100
 ip address 10.0.12.2 255.255.255.0
 load-interval 30
!
interface Serial0/1
 ip address 10.0.23.2 255.255.255.0
 load-interval 30
!
router eigrp 1
 passive-interface FastEthernet0/0
 network 10.0.0.0
 metric weights 0 1 1 1 1 1

R3:
interface Serial0/0
 ip address 10.0.23.3 255.255.255.0
 load-interval 30
!
router eigrp 1
 network 10.0.0.0
 metric weights 0 1 1 1 1 1

Each of the K-values has been set to 1 on all routers.  The bandwidth of the R1-R2 link has also been lowered to 100k on R2.

The EIGRP metric is calculated as:

Metric = ((k1 * BW) + ((k2 * BW)/(256 – load)) + (k3 * delay)) * (k5 / (reliability + k4))

BW = 256 * (10^7 / interface BW in kbps)

load = txload on the interface

delay = 256 * interface delay in tens of microseconds

reliability = reliability rating on the interface

Of the 4 metric components, only the delay is added at each hop.  The other 3 (BW, load, reliability) use the worst value of any single link in the path.  When calculating the composite metric, each individual component is rounded down.   For example, loopback interfaces have a default bandwidth of 8 Gbps:

1-R1-BW

R1 therefore calculates the bandwidth as 10^7 / (8 * 10^6).  The bandwidth value is rounded down (from 1.25 to 1) before being multiplied by 256, and the value carried for BW in the route TLV is 256 (instead of 320, if the rounding had occurred after):

1-R1-BW-Wireshark

When the calculation is reversed, the result is that as far as R1’s topolgy table and any neighbors that R1 is advertising the route to are concerned, the BW is 10 Gbps, as shown in the topology table on R1:

1-R1-Metric

A similar method of rounding occurs for each of the other components.  Loopback interfaces have a default delay of 5000 microseconds and the reliability and load on the interface are 255 and 1 respectively.  The overall calculated metric on R1 is:

Metric = ((1 * 256) + ((1 * 256)/(256 – 1)) + (1 * 128,000)) * (1 / (255 + 1))

= (256 + 1 + 128000) / 256

= 128,257 / 256

=  501

The load component was rounded down (from 256/255 to 1) prior to being multiplied by (k5 / (reliability + k4)) and the final metric was again rounded down (from 501.0039 to 501).  R2’s calculation works the same way:

Metric = ((1 * 25,600,000) + ((1 * 25,600,000)/(256 – 1)) + (1 * 640,000)) * (1 / (255 + 1))

= (25,600,000 + 100,392 + 640,000) / 256

= 26,340,392 / 256

= 102,892

1-R2-Metric

R3 computes the metric as:

Metric = ((1 * 25,600,000) + ((1 * 25,600,000)/(256 – 1)) + (1 * 1,152,000)) * (1 / (255 + 1))

= (25,600,000 + 100,392 + 1,152,000) / 256

= 26,852,392 / 256

= 104,892

1-R3-Metric

As you can see, only the delay increased when R2 advertised the route to R3 (by 20,000 microseconds, the default on a serial interface) since the other 3 values only use the worst value in the path and the BW, load, and reliability on the R2-R3 link from R3’s perspective are either better than or equal to the worst values that were advertised by R2.

 

And now for the main point of this example, to show how including load and reliability in the equation effects updates being sent.  Many sources incorrectly say that including load and reliability in the equation is not recommended because it will cause updates to be sent frequently when the load and/or reliability change.  The actual behavior is that EIGRP advertises the route only at the start of the adjacency or after an event that causes updates to be resent, with whatever the current worst load and reliability rating along the path are.  In many cases this could be even worse than if updates were frequently sent to update the load and reliability ratings, because the load and/or reliability can change dramatically after an update has been sent and neighboring routers continue to assume the original load/reliability values that were advertised before the change.  To demonstrate this, we will add an additional router, R4, with links to R1 and R3:

EIGRP Topology3

 

R1:
interface Serial0/2
 ip address 10.0.14.1 255.255.255.0
 load-interval 30

R3:
interface Serial0/1
 ip address 10.0.34.3 255.255.255.0
 load-interval 30

R4:
interface Serial0/0
 bandwidth 100
 ip address 10.0.14.4 255.255.255.0
 load-interval 30
 delay 2001
!
interface Serial0/1
 ip address 10.0.34.4 255.255.255.0
 load-interval 30
!
router eigrp 1
 network 10.0.0.0
 metric weights 0 1 1 1 1 1

The bandwidth on the R1-R4 link is configured as 100k like the R1-R2 link and the delay as 20,010 microseconds to make the path through R2 preferred by R3.  R3 keeps the path through R4 as an FS but since unequal cost load balancing is not configured, R3 will only use the original link to reach R1:

3-R3-ShowTopology

3-R3-RouteTable

Next, we will use a host on the 10.2.2.0/24 subnet connected to R2 to send approximately 96kbps of traffic to R1 (for more information on the method of generating traffic, see WFQ tests):

flood.pl --port=1000 --size=1496 --delay=125 10.1.1.1

All traffic is sent out S0/0 on R2 and the txload increases to 234:

3-R2-Load

After several minutes, R2 still has not updated the metric in it’s topology and also has not sent an update to R3:

4-R2-ShowTopology

4-R3-ShowTopology

4-R3-RouteTable

Although the R1-R2 link is almost entirely saturated and R3 would have a better path through R4, it is unaware of this because updates are not sent to dynamically update the load and reliability.  Next we will clear the R1-R2 adjacency, causing updates to be resent (clearing the R2 to R3 adjacency would not refresh the load value, because R2 simply sends R3 the same information about 10.1.1.0/24 that already exists in it’s routing table):

R2#clear ip eigrp neighbors 10.0.12.1

R2 receives an update from R1 and records the higher of the received load value (1) and the load of the receiving link (232).  R2 then sends an update to R3 and R3 records the higher of the received load value (232) and the receiving link (1).  R3’s metric for 10.1.1.0/24 through R2 is now higher than through R4, so R3 now uses the path through R4 instead:

5-R3-ShowTopology

5-R3-RouteTable

Note: The FD of the successor on R3 in the topology table as well as the metric in the route table show 104,893, while the FD listed in the topology table for the route on the third line says 104,892 (the original FD of the route through R2).  I think this happens whenever the router is able to switch to an FS for a route without having to go active – the route table and FD through the successor show the new value but the overall FD for the route shows the original FD for the route.

Let’s check the topology table on R2:

5-R2-ShowTopology

That’s strange, R2 and R3 both show the correct load value but the FD at R2 doesn’t match the AD that R3 calculated through R2.  Using the formula, the FD at R2 should be:

Metric = ((1 * 25,600,000) + ((1 * 25,600,000)/(256 – 232)) + (1 * 640,000)) * (1 / (255 + 1))

= (25,600,000 + 1,066,666 + 640,000) / 256

= 27,306,666 / 256

= 106,666

R3 calculated the AD correctly for R2 and also calculated it’s own FD of 108,666 through R2 correctly.  Looking back at the previous topology table on R2 we can see that the metric hasn’t changed at all on R2 – R2 is still calculating the metric as if there is a load of 1.  It appears that although R2 records the higher of the two load values (the one in the received update and the one on the receiving interface) and also advertises the higher one to R3, it only uses the one in the received update for it’s own calculation.  I can’t figure out why this would be desirable since a saturated link between R1 and R2 effects R2 just as much as R3 or any other upstream routers, but there are already enough reasons not to use load or reliability in a production network anyway.

 

As one last test, we will stop the traffic generator.  After a few seconds the interface load is updated on R2 and drops back to 1:

6-R2-Load

Like before, R2 does not dynamically refresh the load value in it’s own topology table or send updates to it’s neighbors.  R3 continues to use the route through R4 to reach 10.1.1.0/24 until something causes updates to be resent between R1 and R2:

6-R3-RouteTable

Advertisements

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

 
%d bloggers like this: