EIGRP Equal Cost Metric Calculation- what am I missing?

Unanswered Question
Jan 5th, 2012
User Badges:

I am attempting to examine load balancing, both equal and unequal cost. But equal cost has thrown me a monkey wrench.

All the interfaces are WIC-2a/s, with no special configuration.

What I get at R1, when examining the equi-distance paths to the 10.100.23.0/29 network via the EIGRP topology table, is a displayed FD that isn't what I would expect.

First, here is my own scratch at the math:

R1 to R3: (256 * (10,000,000/128)) + (2000 * 256)

R1 to R3: (256 * 78125= 20,000,000) + (2000 * 256= 512000)

R1 to R3 metric is 20512000

R3 to <network>: (256 * (10,000,000/128)) + (2000 * 256)

Same thing... 20512000

Now, the EIGRP metric for the total path is lowest BW + cumulative delay, so that means:

20,000,000 + 1024000, equaling 21024000. That would be the FD from R1, with the RD or AD from R2 and R3 equalling 20512000. That is validated in the routing table:

#sho ip rou 10.100.23.0

Routing entry for 10.100.23.0/29

Known via "eigrp 1", distance 90, metric 21024000, type internal

Redistributing via eigrp 1

Last update from 10.100.13.3 on Serial0/0/0, 00:28:48 ago

Routing Descriptor Blocks:

10.100.13.3, from 10.100.13.3, 00:28:48 ago, via Serial0/0/0

Route metric is 21024000, traffic share count is 1

Total delay is 40000 microseconds, minimum bandwidth is 128 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 1

* 10.100.12.2, from 10.100.12.2, 00:28:48 ago, via Serial0/0/1

Route metric is 21024000, traffic share count is 1

Total delay is 40000 microseconds, minimum bandwidth is 128 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 1

R1#sho ip rou ei


10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks

D 10.3.1.0/24 [90/20640000] via 10.100.13.3, 00:29:20, Serial0/0/0

D 10.2.1.0/24 [90/20640000] via 10.100.12.2, 00:29:20, Serial0/0/1

D 10.100.23.0/29 [90/21024000] via 10.100.13.3, 00:29:20, Serial0/0/0

[90/21024000] via 10.100.12.2, 00:29:20, Serial0/0/1

D 192.168.0.0/22 [90/20640000] via 10.100.13.3, 00:29:20, Serial0/0/0

R1#

Here is where it is strange.

R1#sho ip eigrp topo 10.100.23.0/29

IP-EIGRP (AS 1): Topology entry for 10.100.23.0/29

State is Passive, Query origin flag is 1, 2 Successor(s), FD is

20514560

Routing Descriptor Blocks:

10.100.12.2 (Serial0/0/1), from 10.100.12.2, Send flag is 0x0

Composite metric is (21024000/20512000), Route is Internal

Vector metric:

Minimum bandwidth is 128 Kbit

Total delay is 40000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 1

10.100.13.3 (Serial0/0/0), from 10.100.13.3, Send flag is 0x0

Composite metric is (21024000/20512000), Route is Internal

Vector metric:

Minimum bandwidth is 128 Kbit

Total delay is 40000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 1

R1#

For the life of me I can not figure out why in the topology table the FD is listed as 20514560, while the FD/RD numbers in each routing descriptor block match what is displayed in the routing table.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
cadet alain Thu, 01/05/2012 - 07:18
User Badges:
  • Purple, 4500 points or more

Hi,


could you try clear ip eigrp nei and look at the topology table again.


Regards.


Alain

Peter Paluch Thu, 01/05/2012 - 07:35
User Badges:
  • Cisco Employee,

Hello Alain,


That will most probably help but what we see here is not a bug - on the contrary, we are seeing a completely correct EIGRP operation. See my next post.


It is a widely spread misunderstanding that a route has several FDs, one through each neighbor. That is wrong. Only a single FD value is kept for each route - simply the value of the lowest metric since the last time the route went from Active to Passive state. The metrics through each neighbor do not have any special names - they are simply resulting total metrics via particular neighbors.


Quite many textbooks on the subject get this wrong - including Networking Academy curricula, unfortunately.


Best regards,

Peter

Peter Paluch Thu, 01/05/2012 - 07:31
User Badges:
  • Cisco Employee,

Hello,


The FD is not the current lowest distance to a destination - that is a common misunderstanding. In reality, the FD is the lowest metric of the route since the last time the route went from Active to Passive state. In other words, it is a record of a historical minimum to a destination, with the history starting anwe each time the route goes from Active to Passive state. FD may be lower than the actual distance if the current distance has increased (for example, by increasing the interface delay or by lowering its bandwidth) without losing the current successor.


So what you see here is completely normal - it is simply an indication that you once were closer to the destination than you are now, but the increase in the metric did not cause you to enter the Active mode, so the FD was not reset and simply stayed at the previous minimum.


While the route is in Passive state, the FD may only decrease which is simply a result of its definition as being a minimum (or an infimum, if you will) of the distance to a particular destination. If the FD needs to be increased because no other neighbor satisfies the feasibility condition, the route will need to enter the Active state.


Best regards,

Peter

Ryan Newell Thu, 01/05/2012 - 07:47
User Badges:
  • Cisco Employee,

Concur. This is exepected behavior..R3 is connected directly to R5.


R3#show ip eigrp topology  172.16.55.36/30

IP-EIGRP (AS 35): Topology entry for 172.16.55.36/30

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 20514560

  Routing Descriptor Blocks:

  172.16.35.5 (FastEthernet0/1), from 172.16.35.5, Send flag is 0x0

      Composite metric is (20514560/20002560), Route is Internal

      Vector metric:

        Minimum bandwidth is 128 Kbit

        Total delay is 20100 microseconds

        Reliability is 255/255

        Load is 1/255

        Minimum MTU is 1500

        Hop count is 1


Simply by modifying the delay by 1990 we see the change in your routing table. As Peter stated modifying the bandwidth could also produce similiar results.


R5(config-if)#delay  10

R5(config-if)#delay 2000



R3#show ip eigrp topology  172.16.55.36/30

IP-EIGRP (AS 35): Topology entry for 172.16.55.36/30

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 20514560

  Routing Descriptor Blocks:

  172.16.35.5 (FastEthernet0/1), from 172.16.35.5, Send flag is 0x0

      Composite metric is (21024000/20512000), Route is Internal

      Vector metric:

        Minimum bandwidth is 128 Kbit

        Total delay is 40000 microseconds

        Reliability is 255/255

        Load is 1/255

        Minimum MTU is 1500

        Hop count is 1

Ryan Newell Thu, 01/05/2012 - 07:49
User Badges:
  • Cisco Employee,

R3#show ip eigrp topology  172.16.55.36/30

IP-EIGRP (AS 35): Topology entry for 172.16.55.36/30

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 20514560

  Routing Descriptor Blocks:

  172.16.35.5 (FastEthernet0/1), from 172.16.35.5, Send flag is 0x0

      Composite metric is (21024000/20512000), Route is Internal

      Vector metric:

        Minimum bandwidth is 128 Kbit

        Total delay is 40000 microseconds

        Reliability is 255/255

        Load is 1/255

        Minimum MTU is 1500

        Hop count is 1


I forced route to go from passive to active by resetting interface on R5..the FD updated.


R3#show ip eigrp topology  172.16.55.36/30

IP-EIGRP (AS 35): Topology entry for 172.16.55.36/30

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 21024000

  Routing Descriptor Blocks:

  172.16.35.5 (FastEthernet0/1), from 172.16.35.5, Send flag is 0x0

      Composite metric is (21024000/20512000), Route is Internal

      Vector metric:

        Minimum bandwidth is 128 Kbit

        Total delay is 40000 microseconds

        Reliability is 255/255

        Load is 1/255

        Minimum MTU is 1500

        Hop count is 1

JohnTylerPearce Thu, 01/05/2012 - 08:28
User Badges:
  • Silver, 250 points or more

Thanks for the great reply Peter. Let me see if I got this down correctly. Let's say we have a topology just like the one in the thread. Where A is the top of the trianle and B is left and C is right. Let's say B has an EIGRP Metric to route 3.3.3.3 which is on C. B's route to 3.3.3.3 from C is 500120, but when you look at the EIGRP topology table you notice that there is a route to the same destination but with a metric that has increased in value lets say 500500. Now, since the 500120 is the lowest metric since that specific route went from ACTIVE to PASSIVE, that's why you don't see the updated value of 500500? So in order to fix this I would have to cause the route to go from PASSIVE to ACTIVE and then ACTIVE to PASSIVE?

Ryan Newell Thu, 01/05/2012 - 10:23
User Badges:
  • Cisco Employee,

Yes, but there is another condition which can also change the the FD. As you know each time a metric is changed the update is forwarded to the neighbor. If the RD of this new route is lower then the "historically" FD then it will keep the current FD and update the toplogy entry. This is what is happening to the original poster. If the RD is higher then the current FD it will modify the route and add the new FD. The EIGRP event log reports this event as "FC not sat". Bear with me if will as I try to explain...


My test lab: R3 connected to R5. R5 with loopback network configured with 172.16.55.36/30. Using metrics similiar to original poster.


R3#show ip eigrp topology  172.16.55.36/30

IP-EIGRP (AS 35): Topology entry for 172.16.55.36/30

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 20514560

  Routing Descriptor Blocks:

  172.16.35.5 (FastEthernet0/1), from 172.16.35.5, Send flag is 0x0

      Composite metric is (20514560/20002560), Route is Internal

      Vector metric:

        Minimum bandwidth is 128 Kbit

        Total delay is 20100 microseconds



R5(config-if)#delay 2000


R3#


R3#show ip eigrp topology  172.16.55.36/30

IP-EIGRP (AS 35): Topology entry for 172.16.55.36/30

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 20514560

  Routing Descriptor Blocks:

  172.16.35.5 (FastEthernet0/1), from 172.16.35.5, Send flag is 0x0

      Composite metric is (21024000/20512000), Route is Internal

      Vector metric:

        Minimum bandwidth is 128 Kbit

        Total delay is 40000 microseconds


*Dec 12 02:03:49.102: %DUAL-6-EVENT: IP-EIGRP(0), 237  FC sat  nh/ndbmet: 172.16.35.5 20514560

*Dec 12 02:03:49.102: %DUAL-6-EVENT: IP-EIGRP(0), 238  FC sat  rdbmet/succmet: 21024000 20512000


EIGRP event log also reports the FC is sat or in other words the RD of this new route 20512000 is lower than historical FD 20514560.


If we change the delay so the RD is equal to or greater the the "historical" FD it will update the FD.


R5(config-if)#delay 2010


R3#show ip eigrp topology  172.16.55.36/30

IP-EIGRP (AS 35): Topology entry for 172.16.55.36/30

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 21026560

  Routing Descriptor Blocks:

  172.16.35.5 (FastEthernet0/1), from 172.16.35.5, Send flag is 0x0

      Composite metric is (21026560/20514560), Route is Internal

      Vector metric:

        Minimum bandwidth is 128 Kbit

        Total delay is 40100 microseconds




*Dec 12 02:08:37.250: %DUAL-6-EVENT: IP-EIGRP(0), 247  FC not sat Dmin/met: 21026560 21024000


The FC has not be meet because the RD 2051460 is equal to or greater than the FD. So the FD updates. Also as Peter noted and I have also tested, changing the route from passive to active by reseting the loopback interface will cause the FD to update.

Peter Paluch Thu, 01/05/2012 - 15:13
User Badges:
  • Cisco Employee,

Hi Ryan,


A nice experiment you have done. Please allow me a few comments.


You wrote:


As you know each time a metric is changed the update is forwarded to the  neighbor. If the RD of this new route is lower then the "historically"  FD then it will keep the current FD and update the toplogy entry. This  is what is happening to the original poster. If the RD is higher then  the current FD it will modify the route and add the new FD.


I must admit I do not fully understand this description. However, let me restate a few basic principles, perhaps this will clarify the doubts. Correct me whenever you feel I am incorrect.


As I already indicated, the Feasible Distance, or FD, is a record of the smallest total metric towards a destination since the last time the route went from Active to Passive state and a new successor has been chosen. It is incorrect to talk about a "historical FD" as there is no such thing - we would be talking about "historical historical minimum of a metric". The FD itself is a historical minimum of the metric towards a destination. The FD is recorded for each known destination, and there is exactly one FD for each known destination. Also, the FD is a local variable - it is never advertised or carried in any EIGRP packets. In other words, the FD is an internal parameter necessary in EIGRP operations but it is not necessarily the current lowest metric.


There is an immediate important fact to the FD: because it is a record of the smallest total metric towards a destination, it is always permitted to decrease the FD if the current metric to a destination falls below the current value of the FD - the FD will simply adopt the value of the current metric. Remember, we are always keeping a record of the minimal metric. If the current metric falls below the current record, we simply update the record, i.e. the FD. This also means that the FD absolutely does not need to be identical to the current lowest metric. Once again, the current metric to a destination and the FD are two independent values - they may be identical but they also may differ.


Also note that the FD is a record of the total minimal distance to a destination. It is not equal just to a historically lowest Reported Distance as received from a neighbor, rather, it is a record of the the lowest total distance from the local router to a particular destination.


The FD is a crucial component to the Feasibility Condition (FC). The FC says: "If the neighbor is closer to the destination than we have ever been, it is guaranteed to be not on a routing loop", or in short, a neighbor for which the relation RD < FD holds is a loop-free neighbor.


However, during network operation, a situation may arise when the FD has fallen so low that when a next topology change takes place and the RD of the current successor increases to or above the value of the current FD, the neighbor that provides the next lowest total metric to the destination does not meet the FC, or there is no neighbor at all that would satisfy the FC. That does not necessarily mean that there is no route to the destination - it just means that the local router has currently no guarantee that choosing any of its neighbors would provide a guaranteed loop-free route. This is the situation when the route needs to enter the Active state, the local router will send out queries, expect replies, and only after receiving all replies, the route will be put back to Passive state, the router will be allowed to choose the neighbor providing the lowest total distance as the new successor and reset the FD to this current lowest total distance, even if it is higher than the previous value. In other words, if a need arises to increase the FD, the only way to do it is to perform a diffusing computation using queries and replies. If a route stays in Passive state, it is not possible to increase the FD, and conversely, if the FD does not need to be increased, the route does not need to enter the Active state.


To sum it up - the FD is a record of the minimal metric to a destination. It can always decrease if the current distance to the destination falls below the current value of the FD. If, however, the current successor route fails and either the router providing the next lowest total distance does not meet the FC, or there is no router at all that would meet the FC, then the route will enter the Active state and a diffusing computation will take place. After receiving all replies, the route will be put back to Passive state and the FD will be reset (i.e. increased) to the new lowest total metric which is available.


Now, to the experiment Ryan performed:


*Dec 12 02:03:49.102: %DUAL-6-EVENT: IP-EIGRP(0), 237  FC sat  nh/ndbmet: 172.16.35.5 20514560

*Dec 12 02:03:49.102: %DUAL-6-EVENT: IP-EIGRP(0), 238  FC sat  rdbmet/succmet: 21024000 20512000


EIGRP  event log also reports the FC is sat or in other words the RD of this  new route 20512000 is lower than historical FD 20514560.


Once again, there is no concept of "historical FD". There is just the FD, or the historical minimum. What was demonstrated here is that when on R5 the metric was increased, the R3 noted this distance increase. However, the FC was not violated - while the RD increased, it did not increase to or above the value of FD. Therefore, although the metric worsened, the neighbor still passed the FC and was deemed as a feasible successor, and if it still provided the shortest path available, it was also deemed the successor. The route therefore remained in the Passive state, it never went into Active - we say that only a local computation on R3 took place.


If we change the delay so the RD is equal to or greater the the "historical" FD it will update the FD.


R5(config-if)#delay 2010


R3#show ip eigrp topology  172.16.55.36/30

IP-EIGRP (AS 35): Topology entry for 172.16.55.36/30

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 21026560

  Routing Descriptor Blocks:

  172.16.35.5 (FastEthernet0/1), from 172.16.35.5, Send flag is 0x0

      Composite metric is (21026560/20514560), Route is Internal

      Vector metric:

        Minimum bandwidth is 128 Kbit

        Total delay is 40100 microseconds




*Dec 12 02:08:37.250: %DUAL-6-EVENT: IP-EIGRP(0), 247  FC not sat Dmin/met: 21026560 21024000


Here, the metric on R5 was increased so much that on R3, this increased metric reported from R5 no longer met the FC. However, in order for R3 to be allowed to increase the FD, it had to enter the Active state for this network and reset the FD only after receiving all replies and putting the network back to Passive state. The debug eigrp fsm should prove that.


This all may be quite confusing - please feel welcome to ask further!


Best regards,

Peter

Ryan Newell Thu, 01/05/2012 - 15:53
User Badges:
  • Cisco Employee,

Hi Paul,


  Okay so my issue is I used some terms incorrectly and my logic at the end omiited a one step. Besides that I think we are saying the same thing and hopefully the EIGRP event messages told a clearer story than my botched explanation..at least I hope : ) I will work through your comments...


I must admit I do not fully understand this description. However, let me restate a few basic principles, perhaps this will clarify the doubts. Correct me whenever you feel I am incorrect.


As I already indicated, the Feasible Distance, or FD, is a record of the smallest total metric towards a destination since the last time the route went from Active to Passive state and a new successor has been chosen. It is incorrect to talk about a "historical FD" as there is no such thing - we would be talking about "historical historical minimum of a metric". The FD itself is a historical minimum of the metric towards a destination. The FD is recorded for each known destination, and there is exactly one FD for each known destination. Also, the FD is a local variable - it is never advertised or carried in any EIGRP packets. In other words, the FD is an internal parameter necessary in EIGRP operations but it is not necessarily the current lowest metric.



I agree. I was using miscorrectly using the term "historical" FD to represent the fact the local router stores the lowest FD to a destination. Also agree with comment regarding FD not being advertised, as it is a local computation. The RD is advertised with the new route and this is the parameter used locally to check the FC of the new route. If the RD of the new route reported by R5 (in my example) meets FC then the FD previously recorded locally on R3 does not change. If the RD reported by the new route does not meet the FC then the FD on R3 is updated.


 Once again, the current metric to a destination and the FD are two independent values - they may be identical but they also may differ.


Also note that the FD is a record of the total minimal distance to a destination. It is not equal just to a historically lowest Reported Distance as received from a neighbor, rather, it is a record of the the lowest total distance from the local router to a particular destination.


No problem here!


 

The FD is a crucial component to the Feasibility Condition (FC). The FC says: "If the neighbor is closer to the destination than we have ever been, it is guaranteed to be not on a routing loop", or in short, a neighbor for which the relation RD < FD holds is a loop-free neighbor.


However, during network operation, a situation may arise when the FD has fallen so low that when a next topology change takes place and the RD of the current successor increases to or above the value of the current FD, the neighbor that provides the next lowest total metric to the destination does not meet the FC, or there is no neighbor at all that would satisfy the FC. That does not necessarily mean that there is no route to the destination - it just means that the local router has currently no guarantee that choosing any of its neighbors would provide a guaranteed loop-free route. This is the situation when the route needs to enter the Active state, the local router will send out queries, expect replies, and only after receiving all replies, the route will be put back to Passive state, the router will be allowed to choose the neighbor providing the lowest total distance as the new successor and reset the FD to this current lowest total distance, even if it is higher than the previous value. In other words, if a need arises to increase the FD, the only way to do it is to perform a diffusing computation using queries and replies. If a route stays in Passive state, it is not possible to increase the FD, and conversely, if the FD does not need to be increased, the route does not need to enter the Active state.


To sum it up - the FD is a record of the minimal metric to a destination. It can always decrease if the current distance to the destination falls below the current value of the FD. If, however, the current successor route fails and either the router providing the next lowest total distance does not meet the FC, or there is no router at all that would meet the FC, then the route will enter the Active state and a diffusing computation will take place. After receiving all replies, the route will be put back to Passive state and the FD will be reset (i.e. increased) to the new lowest total metric which is available.


Now, to the experiment Ryan performed:


*Dec 12 02:03:49.102: %DUAL-6-EVENT: IP-EIGRP(0), 237  FC sat  nh/ndbmet: 172.16.35.5 20514560

*Dec 12 02:03:49.102: %DUAL-6-EVENT: IP-EIGRP(0), 238  FC sat  rdbmet/succmet: 21024000 20512000


EIGRP  event log also reports the FC is sat or in other words the RD of this  new route 20512000 is lower than historical FD 20514560.


Once again, there is no concept of "historical FD". There is just the FD, or the historical minimum. What was demonstrated here is that when on R5 the metric was increased, the R3 noted this distance increase. However, the FC was not violated - while the RD increased, it did not increase to or above the value of FD. Therefore, although the metric worsened, the neighbor still passed the FC and was deemed as a feasible successor, and if it still provided the shortest path available, it was also deemed the successor. The route therefore remained in the Passive state, it never went into Active - we say that only a local computation on R3 took place.


If we change the delay so the RD is equal to or greater the the "historical" FD it will update the FD.


R5(config-if)#delay 2010


R3#show ip eigrp topology  172.16.55.36/30

IP-EIGRP (AS 35): Topology entry for 172.16.55.36/30

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 21026560

  Routing Descriptor Blocks:

  172.16.35.5 (FastEthernet0/1), from 172.16.35.5, Send flag is 0x0

      Composite metric is (21026560/20514560), Route is Internal

      Vector metric:

        Minimum bandwidth is 128 Kbit

        Total delay is 40100 microseconds




*Dec 12 02:08:37.250: %DUAL-6-EVENT: IP-EIGRP(0), 247  FC not sat Dmin/met: 21026560 21024000


Here, the metric on R5 was increased so much that on R3, this increased metric reported from R5 no longer met the FC. However, in order for R3 to be allowed to increase the FD, it had to enter the Active state for this network and reset the FD only after receiving all replies and putting the network back to Passive state. The debug eigrp fsm should prove that.


This all may be quite confusing - please feel welcome to ask further!


Best regards,

Peter

Agree with your explanation. EIGRP event 237 and 238 show that the FC is meet and therefore the FD is not updated. As you state the router performed a local computation. My terms where wrong but my logic matched until your last paragraph. Where I went wrong was I incorrectly assumed R3 simply updated the FD. But as you stated what is really happening is the route went active because the RD of R5 no longer meet the FC. I will perform a debug eigrp fsm as you have suggested.


Thanks for your time!

Ryan

Peter Paluch Thu, 01/05/2012 - 16:13
User Badges:
  • Cisco Employee,

Hi Ryan,


Please allow me first to assure you that I am not catching for words or being a nitpicker just for the sake of it. It has just been my experience that using an imprecise or free terminology with EIGRP ultimately leads to misunderstanding of its operations, and as there are many misconceptions being spread about EIGRP even in semi-official or official materials, I am trying to put some things straight. Please consider also my further remarks just as being faithtful to that intention, and I honestly appreciate your knowledge of EIGRP operations!


I agree. I was using miscorrectly using the term "historical" FD to  represent the fact the local router stores the lowest FD to a  destination.


Again, it would be incorrect to talk about "the lowest FD", as for any destination, there is only a single FD. Correctly, we should say: "The local router stores the lowest known metric to a destination as the FD." It is often suggested that the FD is the total metric through a particular neighbor (i.e. the sum of RD of that neighbor plus the cost of the link towards it) and that there are multiple FDs for a particular destination, one for each neighbor. However, that suggestion is incorrect.


If the RD reported by the new route does not meet the FC then the FD on R3 is updated. 


To be completely precise, this is not always true. Think of a route having a successor and a feasible successor, both obviously meeting the FC with the current value of FD. If the current successor sends an update whose RD does not meet the FC and the feasible successor provides a route with the next lowest metric, it will become the new successor - however, the FD will not be updated because it does not need to.


But as you stated what is really happening is the route went active because the RD of R5 no longer meet the FC.


... and the router that provides the next overall shortest route does not pass the FC check. Otherwise, only a local computation would take place.


Best regards,

Peter

Ryan Newell Thu, 01/05/2012 - 16:23
User Badges:
  • Cisco Employee,

Agree, only serves to make things more difficult when free terminology is used.

Again, it would be incorrect to talk about "the lowest FD", as for any destination, there is only a single FD. Correctly, we should say: "The local router stores the lowest known metric to a destination as the FD." It is often suggested that the FD is the total metric through a particular neighbor (i.e. the sum of RD of that neighbor plus the cost of the link towards it) and that there are multiple FDs for a particular destination, one for each neighbor. However, that suggestion is incorrect.




Concur.


To be completely precise, this is not always true. Think of a route having a successor and a feasible successor, both obviously meeting the FC with the current value of FD. If the current successor sends an update whose RD does not meet the FC and the feasible successor provides a route with the next lowest metric, it will become the new successor - however, the FD will not be updated because it does not need to.


Again concur. I was only speaking to the lab scenario but I appreciate your completeness.


Thanks again for your time! Your desire to not losely use terms and correctly state the facts has left a lasting impression.


Thanks,

Ryan

Peter Paluch Thu, 01/05/2012 - 16:26
User Badges:
  • Cisco Employee,

Hello Ryan,


Thanks again for your time! Your desire to not losely use terms and correctly state the facts has left a lasting impression. 


I am honored! And about that lasting impression... uh-oh, I hope it's not a negative one


Once again, thank you for joining this thread. I hope you'll be able to join more often!


Best regards,

Peter

Actions

This Discussion

Related Content