cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1349
Views
10
Helpful
8
Replies

Help with EIGRP calculation

Steph1963
Level 1
Level 1

Hi,

I am reviewing the Cisco TAC training for EIGRP and I cannot obtain the FD & RD for all the routes going through the router C. I first found that you have to consider the delay show in the diagram as 10 of usec everything going through router C does not match. Is there anybody who has figured this out?

http://www.cisco.com/E-Learning/bulk/subscribed/tac/cim/iprouting/eigrp/mod_frameset.htm

Thanks

Stéphane

Router A to Network A through Router B

Minimum Bandwidth: 128

Metric: (10000000/128 + 1000+100+100)*256 = 2030720

Feasible Distance for Router A

- Lowest calculated metric to each destination

170.170.1.0 via Router B: (10000000/128)+(1000)*256 = 2025600

170.170.3.0 via Router D: (10000000/128) + 1000+100)*256 = 20281600

Reported Distance for Router A

- Metric to destination as reported by a neighbor

170.170.3.0 from Router B: (10000000/10000+ 100)*256 = 281600

170.170.4.0 from Router B: (10000000/10000+ 100+100)*256 = 307200

Feasible Distance for 170.170.2.0 via Serial 1

(10000000/512 +1000)*256 = 5256000 (not 5025536 as specified in the show ip eigrp topolgy)

Router A to Network A through Router C

Minimum Bandwidth: 512

Metric (10000000/512 + (1000+1000+100)/10)*256 = 5307200 (not 5307136 as specified in the show eigrp topology)

1 Accepted Solution

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

Stephane,

Let's go over each value computed here, but before that, I need to advise you on an issue that is often not explained clearly enough: The Feasible Distance (FD) is not the current minimal distance to a destination. Rather, it is the minimal distance to a destination since the last time that route transitioned from active to passive state. Thus, the current minimal distance may be equal or higher than the FD for that destination. This depends very strongly on the events the network went through up to the moment when you display the topology table and check on these values. You can do a simple test: create a simple linear topology of two routers and have them both advertise their loopbacks using EIGRP. Then, on one router, increase the delay or decrease the bandwidth on the interface towards the second router. After you do that, have a look into the EIGRP topology table on the first router: the real metric of the path towards the loopback on the second router will increase as the result of worsening the path, however, the FD will stay the same.

Second, do not divide the delay values shown in the exhibit by 10. They are already indicated in tens of usecs. You will take them directly into the metric formula.

Okay, now to the computations.

Router A to Network A through Router B

Minimum bandwidth: 128

Total delay: 1000+100+100 = 1200

Distance: ((10**7)/128 + 1200) * 256 = 20307200, consistent with the exhibit

Reported Distance of Router B to Network A

Minimum bandwidth: 10000

Total delay: 100+100 = 200

Distance: ((10**7)/10000 + 200) * 256 = 307200, consistent with the exhibit

Router A to Network A through Router C

Minimum bandwidth: 512

Total delay: 1000+100+100 = 1200

Distance: ((10**7)/512 + 1200) * 256 = 5307136, consistent with the exhibit

Reported Distance of Router C to Network A

Minimum bandwidth: 512

Total delay: 100+100 = 200

Distance: ((10**7)/512 + 200) * 256 = 5051136, inconsistent with the exhibit

Router A to Network 170.170.3.0/24 through Router C

Minimum bandwidth: 512

Total delay: 1000+100+100 = 1200

Distance: ((10**7)/512 + 1200) * 256 = 5307136, inconsistent with the exhibit

Reported Distance of Router C to Network 170.170.3.0/24

Minimum bandwidth: 512

Total delay: 100+100 = 200

Distance: ((10**7)/512 + 200) * 256 = 5051136, inconsistent with the exhibit

Router A to Network 170.170.3.0/24 through Router B

Minimum bandwidth: 128

Total delay: 1000+100 = 1100

Distance: ((10**7)/128 + 1100) * 256 = 20281600, consistent with the exhibit

Reported Distance of Router B to Network 170.170.3.0/24

Minimum bandwidth: 10000

Total delay: 100

Distance: ((10**7)/10000 + 100) * 256 = 281600, consistent with the exhibit

The exhibit seems to contain 3 errors in the computation. The errors are as follows:

  1. The alleged reported distance of router C to network A is computed using the minimum bandwidth of 10000 instead of 512
  2. The alleged distance of router A to network 170.170.3.0/24 via router C is computed as if the network 170.170.3.0/24 was directly connected to router C.
  3. The alleged reported distance of router C to network 170.170.3.0/24 via router C is also computed as if that network was directly connecter to router C.

Can you follow all of this? Is it understandable for you? Please ask further!

Best regards,

Peter

View solution in original post

8 Replies 8

Peter Paluch
Cisco Employee
Cisco Employee

Stephane,

Let's go over each value computed here, but before that, I need to advise you on an issue that is often not explained clearly enough: The Feasible Distance (FD) is not the current minimal distance to a destination. Rather, it is the minimal distance to a destination since the last time that route transitioned from active to passive state. Thus, the current minimal distance may be equal or higher than the FD for that destination. This depends very strongly on the events the network went through up to the moment when you display the topology table and check on these values. You can do a simple test: create a simple linear topology of two routers and have them both advertise their loopbacks using EIGRP. Then, on one router, increase the delay or decrease the bandwidth on the interface towards the second router. After you do that, have a look into the EIGRP topology table on the first router: the real metric of the path towards the loopback on the second router will increase as the result of worsening the path, however, the FD will stay the same.

Second, do not divide the delay values shown in the exhibit by 10. They are already indicated in tens of usecs. You will take them directly into the metric formula.

Okay, now to the computations.

Router A to Network A through Router B

Minimum bandwidth: 128

Total delay: 1000+100+100 = 1200

Distance: ((10**7)/128 + 1200) * 256 = 20307200, consistent with the exhibit

Reported Distance of Router B to Network A

Minimum bandwidth: 10000

Total delay: 100+100 = 200

Distance: ((10**7)/10000 + 200) * 256 = 307200, consistent with the exhibit

Router A to Network A through Router C

Minimum bandwidth: 512

Total delay: 1000+100+100 = 1200

Distance: ((10**7)/512 + 1200) * 256 = 5307136, consistent with the exhibit

Reported Distance of Router C to Network A

Minimum bandwidth: 512

Total delay: 100+100 = 200

Distance: ((10**7)/512 + 200) * 256 = 5051136, inconsistent with the exhibit

Router A to Network 170.170.3.0/24 through Router C

Minimum bandwidth: 512

Total delay: 1000+100+100 = 1200

Distance: ((10**7)/512 + 1200) * 256 = 5307136, inconsistent with the exhibit

Reported Distance of Router C to Network 170.170.3.0/24

Minimum bandwidth: 512

Total delay: 100+100 = 200

Distance: ((10**7)/512 + 200) * 256 = 5051136, inconsistent with the exhibit

Router A to Network 170.170.3.0/24 through Router B

Minimum bandwidth: 128

Total delay: 1000+100 = 1100

Distance: ((10**7)/128 + 1100) * 256 = 20281600, consistent with the exhibit

Reported Distance of Router B to Network 170.170.3.0/24

Minimum bandwidth: 10000

Total delay: 100

Distance: ((10**7)/10000 + 100) * 256 = 281600, consistent with the exhibit

The exhibit seems to contain 3 errors in the computation. The errors are as follows:

  1. The alleged reported distance of router C to network A is computed using the minimum bandwidth of 10000 instead of 512
  2. The alleged distance of router A to network 170.170.3.0/24 via router C is computed as if the network 170.170.3.0/24 was directly connected to router C.
  3. The alleged reported distance of router C to network 170.170.3.0/24 via router C is also computed as if that network was directly connecter to router C.

Can you follow all of this? Is it understandable for you? Please ask further!

Best regards,

Peter

Hi,

Thanks for your very valuable input.

It makes sense that the alleged reported distance of router C to network A is computed using the minimum bandwidth of 10000 instead of 512.

I am not to sure about the network 170.170.3.0/24 directly connected to router C.I attached a drawing to make sure that I have understand what you said. The part that I am not sure is the fact that the metric for router A to router C does not match the exhibit:

Router A to Router C: 10*10^7/512+1000/10 = 50025600 not like the exibhit (5025536). Could this be another possible error on the exhibit.

Question:

Can we assume that the only case where a path whose reported distance is greater than the feasible distance is because:

The feasible distance could possibly be through this router, causing a loop.

The neighbor has a very high reporting distance on an alternate route because of slow link in comparison with the best path to the given destination.

Question:

What is the logic behind sending an EIGRP summary route with a NULL0 value.

Thanks again for your help

Stephane

Hi Stephane,

to your metric calculation question:

One important comment:

"Cisco routers do not perform floating point math, so at each stage in the calculation, you need to round down to the nearest integer to properly calculate the metrics."

(see http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094cb7.shtml#eigrpmetrics for details.)

So in your case of  Router A to Router C subnet:

10^7/512=19531,25

19531+1000/10  = 19631

19631*256=5025536

The same value as reported in your exhibit :-)

I hope the answers to your other questions might be found in the same document (see the link above), read the

"Deciding if a Path is Loop-Free" and "Summarization" sections carefully.

HTH,

Milan

Milan,

You have a very good point in rounding down the individual factors in the EIGRP metric formula! I knew about that but I must admit that I originally did not explicitely take care of that in my computations in my previous reply. Fortunately, I've done the computations in Python and it automatically performed integer arithmetics Nevertheless, this is of utmost importance! Thank you very much, this deserves a rating!

However, I do not completely agree with your computation. You suggested the following sequence of steps:

So in your case of  Router A to Router C subnet:

10^7/512=19531,25

19531+1000/10  = 19631

19631*256=5025536

The same value as reported in your exhibit :-)

I suppose you are talking about the directly connected network between routers A and C (the 170.170.2.0/24). What I disagree here with is the delay factor. You calculated it as 1000/10. Why? I understand that the delay in EIGRP is given as the count of "tens of microseconds" and if your delay are given in microseconds, you have to divide it by 10 to yield the value directly used by EIGRP. However, there is no indication of what are the units in the exhibit and I maintain that the values in the exhibit are already recomputed to the "tens of microseconds" units.

After all, let's ask a real IOS to help us

R1(config)#interface Serial1/0
R1(config-if)#ip address 192.0.2.1 255.255.255.0
R1(config-if)#bandwidth 512
R1(config-if)#delay 1000
R1(config-if)#no shutdown
R1(config-if)#router eigrp 1
R1(config-router)#network 192.0.2.1 0.0.0.0
R1(config-router)#do show ip eigrp topology

IP-EIGRP Topology Table for AS(1)/ID(192.0.2.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 192.0.2.0/24, 1 successors, FD is 5255936
        via Connected, Serial1/0

R1(config-router)#do show ip eigrp topology 192.0.2.0
IP-EIGRP (AS 1): Topology entry for 192.0.2.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 5255936
  Routing Descriptor Blocks:
  0.0.0.0 (Serial1/0), from Connected, Send flag is 0x0
      Composite metric is (5255936/0), Route is Internal
      Vector metric:
        Minimum bandwidth is 512 Kbit
        Total delay is 10000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 0

Okay, let's try to compute the metric:

Minimum bandwidth: 512

Total delay: 1000 units of "tens of microseconds" (who the hell invented this horrible unit? )

Distance: (floor((10**7)/512) + 1000) * 256 = (19531 + 1000) * 256 = 5255936 - just as displayed by the IOS

The exhibit is plain wrong, or at least, strongly inconsistent.

Best regards,

Peter

Hi Peter,

yes, I was talking about the directly connected network between routers A and C (the 170.170.2.0/24).

My understanding of the original diagram was the delay was 1000 microseconds, which gave the exact metric value.

(There was no show command output displaying the delay with no doubts.)

I agree "tens of microseconds" is a stupid unit :-))

BR,

Milan

Hi Stephane,

Lots of ideas in your post. Let's go over them step by step.

It makes sense that the alleged reported distance of router C to
network A is computed using the minimum bandwidth of 10000 instead of
512.

Really? To me it does not Look, the router C must first send its data through the serial link to the router D, and the serial link is not capable of handling data in excess of 512 Kbps. The router D then directly connects to the Network A which is obviously a 10Mbit Ethernet. Now, in my opinion, the minimum bandwidth (or the bottleneck) along the route from router C to Network A is the serial link between routers C and D with its bandwidth of 512 Kbps. Do you think otherwise?

I am not to sure about the network 170.170.3.0/24 directly connected
to router C.I attached a drawing to make sure that I have understand
what you said. The part that I am not sure is the fact that the metric
for router A to router C does not match the exhibit:

Router
A to Router C: 10*10^7/512+1000/10 = 50025600 not like the exibhit
(5025536). Could this be another possible error on the exhibit.

Well, regarding the distance from Router A to the network 170.170.2.0/24 which interconnects routers A and C, it is also wrong. I have provided an example of its computation in my reply to Milan Kulik's excellent post above and I have confirmed it using a real IOS. Have a look at it. Nevertheless, what is a source of confusion here is that it is not clear whether the delay units should or should not be divided by 10. But the exhibit seems to be inconsistent: if some metrics can be computed correctly with the delay being divided by 10, other metrics can be computed correctly with leaving the delay as indicated. In my opinion, the entire exhibit is simply wrong and in urgent need of correction.

Can we assume that the only case where a path whose reported distance is greater than the feasible distance is because:

The feasible distance could possibly be through this router, causing a loop.

The
neighbor has a very high reporting distance on an alternate route
because of slow link in comparison with the best path to the given
destination.

Yes, you got it very correct. There are actually three reasons why a router can report a distance that is higher to our own feasible distance:

  1. The router is using us or a sequence of routers that would eventually loop back to us.
  2. The neighbor is using an alternate route whose total metric simply happens to be greater than our feasible distance. We cannot be sure whether the path is indeed looped or if it is simply so much worse than our own. That is why there is the active state and the diffusing computation taking place if we need to find a new successor.
  3. In case of topology changes when distances increase.

What is the logic behind sending an EIGRP summary route with a NULL0 value.

Imagine you have a router A summarizing four networks, 192.168.0.0/24 - 192.168.3.0/24 into a single supernet 192.168.0.0/22, and sending this summary route to neighbor B. Also, imagine that the router A has a default route pointing at router B.

Now assume that the network 192.168.1.0/24 gets disconnected from Router A. Router A does not know anymore about it. Router B, on the other hand, does not see any difference because the only route it receives from Router A is the summary route 192.168.0.0/22. And now assume that the router B receives a packet towards 192.168.1.x. According to B's routing table, the packet should be sent to A. However, the A does not have the matching network in its routing table anymore, and the only routing entry that matches this destination is the default route pointing back to B. In other words, a routing loop would be formed.

This is where the "Null0" route comes in. We call it a discard route. The discard route makes sure that all packets that are destined to a non-existent component of a summary route are dropped, instead of sending them somewhere outside where they could be misrouted or even looped. The routing table is searched from the most specific subnets to least specific subnets, so the ordering would be as follows:

192.168.0.0/24

192.168.1.0/24

192.168.3.0/24

192.168.4.0/24

192.168.0.0/22

0.0.0.0/0

Notice that by the very virtue of summary address, it is always less specific than its components, and will be tried only after all known components have been searched and did not match.

Looking forward to reading your thoughts on all this.

Best regards,

Peter

Hi Peter,

After doing these calculation over and over, can only came to the same solution:


1) Cisco routers do not perform floating point math, so at each stage in the calculation, you need to round down to the nearest integer to properly calculate the metrics. This seems to be absolutely correct.
2) I agree with you, some metrics are calculated with a delay divided by 10 and some others withouth dividing by 10. It seems at least inconsistent. Your demonstration on the IOS was quite convincing, the metric is calculated by dividing the delay by 10.

Your explantion on the reasons why a router can report a distance that is higher to our own feasible distance and on the summary route were perfectly clear.

Many, many, many thanks for your great help
Stephane

Stephane,

You are heartily welcome. Just a quick remark:

Your demonstration on the IOS was quite convincing, the metric is calculated by dividing the delay by 10.

This statement is correct if you are taking the delay in microseconds (the show ip eigrp topology detail shows the delay in microseconds as well). However, the delay command itself is in tens of microseconds, and as such, its value is taken directly into the metric formula - without dividing it.

Best regards,

Peter

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco