Enabling Load Sensitivity on EIGRP with K2

[john.laham]

Let's assume that we enable K2, which makes the route metric (in the EIGRP topology table) rely on the link's load as well as the bandwidth and delay factors. Isn't it quite possible that this will lead to a case of route flapping?

The way I see it is that:

1. We have a successor route to a certain destination
2. As it starts to get loaded it's metric will increase (i.e. gets worse)
3. Eventually it will no longer be considered as a successor but rather a feasible successor (probably).
4. Likewise the feasible successor will be promoted to becoming the successor route.
5. Same thing happens again; the new successor route starts to get loaded and it's metric increases.
6. At this point the new successor route's metric gets worse, while the load on the previous successor (which is now a feasible successor) gets better, and then they switch again.

So isn't it possible that this (at a high frequency) would lead to a the routes flapping?

Unfortunately I do not have the hardware available in a lab to test this out with considerable loads on the network to create such a scenario. I am just trying to figure out the mechanics behind enabling the other non-default K-values.

[sergiudaniluk]

Hello,

Correct me if I am wrong, but from what i know EIGRP updates are send out only when there is a topology change (for example a route being added of being removed). 

So, considering what I said earlier, when a metric is being calculated for a specific route where k2 (load) is enabled, it will take in calculus the load of the interface at that specific time. The metric will remain the same even if the load changes. If at a certain time there is a topology change in the network the metric will be recalculated using the load of the interface at that specific time.

Best regards,

Sergiu. 

[john.laham]

Hey Sergiu, thanks for your reply. I think you're right that yes, EIGRP will only send out updates with a topology change, but I am not focusing on/concerned with the updates being sent out, as I am with the values changing within the EIGRP topology table on the router itself, and how it affects the RIB.

But the other point that you make is quite interesting, where you say that the metric is being calculated at the specific time of "creation" of the route. Are you sure about this point? Do you have any references you can direct me to?

[sergiudaniluk · Accepted solution]

Hello again,

Well I made a simulation to verify if indeed load changes or not the metric of a route in EIGRP.

The topology:

R1:

R1#sh ip protocols 
*** IP Routing is NSF aware ***

Routing Protocol is "eigrp 1"
  EIGRP-IPv4 Protocol for AS(1)
    Metric weight K1=1, K2=1, K3=1, K4=0, K5=0
    NSF-aware route hold timer is 240
    Router-ID: 10.0.0.1
    Topology : 0 (base) 
      Active Timer: 3 min
      Distance: internal 90 external 170
      Maximum path: 4
      Maximum hopcount 100
      Maximum metric variance 1

  Automatic Summarization: disabled
  Maximum path: 4
  Routing for Networks:
    0.0.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    10.0.0.254            90      00:00:09
 

R1# sh ip route 

D        20.0.0.0 [90/30820] via 10.0.0.254, 00:02:16, FastEthernet2/0

R1#sh interfaces fa 2/0
FastEthernet2/0 is up, line protocol is up 
  Hardware is i82543 (Livengood), address is ca01.1f48.0038 (bia ca01.1f48.0038)
  Internet address is 10.0.0.1/24
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec, 
     reliability 255/255, txload 1/255, rxload 1/255

I tried to change the load so I pinged from R1 to R4 and in the same time from R3 to R1:

R1#ping 20.0.0.1 repeat 1000 size 1400 
Type escape sequence to abort.
Sending 1000, 1400-byte ICMP Echos to 20.0.0.1, timeout is 2 seconds:
!!!.!!!!!!!!!..!!!!!!!!!!!!!!.!!!!!!!!!!.!.!!!.!.!!!!!!!!!!!!!!!!!!!!.
!!!!!!!!!!!!.!!!!!!!!!!!!!.!.!.!!!.!!!!.!!!!!!!!!!!!!!!!!!!.!!!!.!!!!!
!!.!!!.!.!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!.!!!!!!!!!.!.!.!.!!!!!!.!!!
!!!!!!!!!!!!.!!!.!!!!!!!!!!!!!!!!!!.!.!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!
!!!.!!!.!!!!!!!.!...!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!.!!!!!!!!!.!!!!..!!!
!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!.!.!!!!!!!!.!!!!!!!!!!!!.!
!!!!!!!!!!!.!!!!!!!!!!!!.!.!!!!!!!!!!.!!.!!!!!!!!!.!!.!!!!!!!!!.!!!!!!
!!!!..!!.!!!!!!!!!.!!.!!!!!!!!!.!!.!!!!!!!!!.
Success rate is 87 percent (466/535), round-trip min/avg/max = 44/93/184 ms

R3#ping 10.0.0.1 repeat 1000 size 1000
Type escape sequence to abort.
Sending 1000, 1000-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!
!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!.
!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!
!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!.!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!
!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!.!!!!
!!!!!!!.!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!.!!!!!!.!!!!!!!!!!!!.!!!.!!!!!!
!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!
Success rate is 96 percent (967/1000), round-trip min/avg/max = 12/81/156 ms

After almost 2 minutes:

R1#sh ip route 
      20.0.0.0/24 is subnetted, 1 subnets
D        20.0.0.0 [90/30820] via 10.0.0.254, 00:12:14, FastEthernet2/0

So indeed no metric changes.

I also searched in CCNP Route 300-101 (Kevin Wallace) but I didn't find anything related to load (except that Cisco strongly recommends against using link load and link reliability in the EIGRP metric calculation), BUT maybe this will help:

EIGRP routing updates are triggered only by a change in network topology (interface up/down event, IP addressing change or configured bandwidth/delay change) and not by change in interface load or reliability. The load/reliability numbers are thus a snapshot taken at the moment of the topology change and should be ignored.

Source: http://blog.ipspace.net/2009/06/eigrp-load-and-reliability-metrics.html

Best regards,

Sergiu

[john.laham]

Thanks a million Sergiu, your answer was spot on. I just find it kind of weird that they would factor in a variable such as load, which is a very dynamic metric, yet only measure it at a given time... kind of defies the point. Then again, they do recommend that you stick to the default metric values.

Thanks again! :-)

[sergiudaniluk]

You are more than welcome, I'm glad I was able to help.

To be sincere, I also thought a lot of times why Cisco would include such a factor in metric calculation. The only answer that I find it plausible is for backward compatibility with IGRP.  

If you find anything else let me know. I am very curious! 

Kind regards,

Sergiu

[john.laham]

To be completely honest, one of the factors that really intrigued me about EIGRP was the fact that it could take a variable as dynamic as interface load into its calculation.

My initial thought/understanding was that it is such a dynamic and adaptive protocol that it would be real-time load-sensitive. So that if for some reason a certain route, down a certain link, would get overloaded then the protocol would be smart enough to replace it with a route less congested in real-time.

I actually just got started studying for my CCIE, so I might actually come by some clarification down the line. I will definitely let you know in case anything comes up.

Cheers. :-)

[Richard Burts]

As part of your studies you should look into Performance Routing. This is a relatively new addition to the routing alternatives and does give you a way to change routing based on the load of links.

HTH

Rick

[john.laham]

Hey Richard, thanks for the tip. I actually came across PfR a few days ago, however I only took a very quick look at it, and figured I'd be coming back to it soon. I kind of dismissed it at first, as it seemed to be targeted mostly for WAN applications. I will definitely be revisiting it (soon) as part of my studies. :-)