05-22-2015 02:49 AM - edited 03-08-2019 12:07 AM
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:
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.
Solved! Go to Solution.
05-24-2015 07:54 AM
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
05-24-2015 06:54 AM
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.
05-24-2015 07:11 AM
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?
05-24-2015 07:54 AM
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
05-24-2015 08:31 AM
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! :-)
05-24-2015 08:37 AM
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
05-24-2015 08:44 AM
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. :-)
05-24-2015 11:57 AM
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
05-25-2015 08:57 AM
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. :-)
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide