EIGRP Operation/Convergence Questions

[kfarrington]

Guys and Girls, Long winded one here, but is (I think) quite cool if it is worked out.

Please could all look at this fully meshed network topology : (Also, a couple of points before I start)

The reason I ask this question is that I have a network with redundant links, and see many topo table entries and am trying to work out the exact deterministic flow, of EIGRP before I try and work out what I have. Sorry if this is a long thread, but feel it vitally important to understand this.

The way I understand this (and am not sure the way EIGRP Spilt horizon with poison reverse will work fully with this so have made an assumption at the end which if correct, I can factor in, but if anyone wants to add comments inline in regards to EIGRP Spilt horizon with poison reverse, please do)

Also, think I am getting a little confused in regards to topology table updates, and routing updates. I assume a routing update is just the passing of a topology table entry from one routers topology table to its neighbours topology table and then a local computation is performed (not DUAL) and compares the best metric(s) to put into the local routing table. (if a new topology table entry comes in, with a better metric, no dual is run, eigrp just updates the RT)

Assume network 10/8 comes in for the very first time into EIGRP.

Step 1

-- R1 and R2 will both receive an update (input event) for network 10.

-- R1 and R2 will add the delay metric to the RD and put this into their topology table.

-- R1 puts this entry into the RT as is only entry for network 10. R2 does the same.

No dual has run on R1 and R2 - only a local computation that has created a successor

Step 2

-- R1 now sends "its topology entry" to R2, R3 and R4. R2, now sends "his topology entry" to R1, R3 and R4. Does routing update = Sending of topology table entry

-- R2 received R1s topology entry and has beaten his current FD, so this entry becomes the new FD and new entry goes into RT

-- R1 received R2s topology entry and has NOT beaten FD so just remains in routers topology table. RT remains the same.

Still no dual has run on R1 and R2

Step 3

-- R3 now receives two topology entries (can I call these updates??), one from R1 and one from R2. (or does it received two entries from each as R1 and R2 now have two entries each for network 10? Or I assume just the best topology entry gets passed along - PLEASE CONFIRM) R3 selects the path thru R1

-- R4 does receives the same (assuming it only receives the best topology entries from each router R1 and R2) and selects R1 as best path.

-- Now R3 passes ONE(Best) topology table entry to R4,R5 and R6, but R4 has a better path via direct connection to R1 so entry is just stored in topo table

-- R4 now passes ONE(Best) topology table entry to R3,R5 and R6 and R3 has best path directly to R1 so just gets stored in the topo table.

Still no dual has run on R1, R2, R3 or R4

Step4

-- Now that R3 and R4 have both exchanged topology table entries (or updates) with each other - even though they are not the best path for each router to the destination, do, R3 and R4, send these topology table entries back to R1 and R2, as well as R5 and R6?

Step 5.

-- R5 now receives the topology entries from R3,R4 and selects both as the best patch

-- R6 Does the same

-- R5 passes best route to R6 and R6 just stores it as it not lowest metric

-- R6 passes best route to R5 and R5 just stores it as it not lowest metric

Still no dual has run on R1 and R2

And the cycle continues.

Many thanks for the continued help from this forum, and one day, I will buy the beers as I always promise to :)

Kind regards,

Ken

[kfarrington]

Also addtionation test (put here and in diagram JPEG) as I ran out of space on the thread :)

So the main thing I would like to ask is :-

-- Is the above correct in terms of providing a deterministic calculation for each routers routing table and topology table?

-- Does EIGRP pass on only the best topology table entry it has to its neighbours?

-- If R3 received (as in the scenario in step 4) an update for network 10/8 say, from R1 and R2 let say at the same time, then a second later, received an update for 10/8 from R3, will R3 send an update (or this topology table entry) back to R1 and R2.

-- EIGRP Spilt horizon with poison reverse. So, assuming this, (in the later stages of step 3) when the R3 and R4 exchange updates for network 10 between them, if R3, sends R4 an update for network 10, R4 should never send an update back to R3 saying that network 10 can be reach thru him, and more so, send an update with a poisoned metric. IS THIS CORRECT?

-- Am I correct in stating that Dual has not run in this scenario?

Many thanks for the continued help from this forum, and one day, I will buy the beers as I always promise to :)

Kind regards,

Ken

[kfarrington]

please note error in last thread

If R3 received (as in the scenario in step 4) an update for network 10/8 say, from R1 and R2 let say at the same time, then a second later, received an update for 10/8 from R3, will R3 send an update (or this topology table entry) back to R1 and R2.

should read

If R3 received (as in the scenario in step 4) an update for network 10/8 say, from R1 and R2 let say at the same time, then a second later, received an update for 10/8 from **R4**, will R3 send an update (or this topology table entry) back to R1 and R2.

[sourabhagarwal]

hope this URL will answer to your queries on EIGRP.

http://www.cisco.com/warp/public/103/1.html

rate if it does ...

[kfarrington]

Im really sorry, but this does not awnser quite a few questions, as I have read this and have read lots of documentation and I am still falling short of some questions outline ion the thread.

Just one for example, statements such as :-

If the neighbor is advertising this destination, it must be using the route to forward packets. This is an important rule that distance vector protocols must follow.

True, but if an eigrp router receives an update to a path, which is not the best path, ie an entry that just gets stored in the topo and is not a sucessor, of FS, does that get advertised to neighbors?

and lots more questions?

I hope there is a way to go thru all of this and work it out deterministically

Many thx for the replay anyway.

Regards,

Ken

[mark.edwards]

Hi Ken, I won't try and answer all of your questions (as there are too many and very indepth) but according to DOC CD DUAL runs after each topology change (see below extract and link to DOC CD). In addition when I test by adding a network statement under EIGRP with "debug eigrp fsm" you can clearly see DUAL process is running.

In responce to your question about holding entries in the topology table, if a route does not pass the feasibility condition (ie Reported distance is less than feasible distance - see below link) then it will not appear in the topology table and therefore will not get passed on (this is my understanding).

http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094cb7.shtml#feasibleandreported

The DUAL finite state machine embodies the decision process for all route computations. It tracks all routes advertised by all neighbors. DUAL uses the distance information (known as a metric) to select efficient, loop-free paths. DUAL selects routes to be inserted into a routing table based on feasible successors. A successor is a neighboring router used for packet forwarding that has a least-cost path to a destination that is guaranteed not to be part of a routing loop. When there are no feasible successors but there are neighbors advertising the destination, a recomputation must occur. This is the process whereby a new successor is determined. The amount of time required to recompute the route affects the convergence time. Recomputation is processor-intensive; it is advantageous to avoid unneeded recomputation. When a topology change occurs, DUAL will test for feasible successors. If there are feasible successors, it will use any it finds in order to avoid unnecessary recomputation.

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcprt2/1cfeigrp.htm

[ruwhite · Accepted solution]

Answering your questions in the jpg.... Given the delays on the inbound side of R1 and R2 are the only "different" delays in the network.

1. EIGRP only sends it's "best" routes to its neighbors.

2. Assuming R3 receives updates from R1 and R2 at the same time, it will find R1 is the best path. It will then send an update to R2 with it's best metric, because the route through R2 is not installed in the routing table.

3. On receiving an update from R4, R3 would find R1 is still the better path, and just stick the new information in its local topo table. It would not send updates, because its best path has not changed.

4. EIGRP only split horizons on the interface which is actually installed in the routing table, not all "heard routes." Hence, if you have 7 equal cost paths, and 6 entries allowed in the routing table, EIGRP will send routing information about its best path to the 7th neighbor. EIGRP only uses poison reverse during initial neighbor route exchange.

5. Whether or not DUAL has run is a matter of opinion. We, internally, call the ordering of the topology table which results in finding S' and FS' DUAL. We call the active process the active process. In the original Garcia paper, these two were mixed, and both called part of DUAL, and some people tend to think of the active process only as DUAL. The way I call them, DUAL has run for each routing update received, since we have to order the topology table. Now, we might run a shortcut, which says that the new route is worse than our FS, so we don't care, but it's still DUAL.

Finally, I would comment on this network design.... This is generally not a good network design for any routing protocol. Triangles converge much faster than squares, and much faster than full mesh squares. If you think through the FS' and the query process, you'll find that this is just about one of the slowest converging topologies you can get (large rings are another really bad topology for convergence time), right now. A true full mesh would probably actually converge faster, I think.

In the end, the additional "9's" of resiliency added by the additional links probably won't (though you can't be certain until you do a real rigorous analysis) overcome the additional convergence time added to the network, and might actually result in more network downtime, rather than less.

:-)

Russ

[kfarrington]

Mark, Russ, Many thx for the replies. As always, very helpful

Russ,

In your last statment, YES, you have found what I am actually looking at. Too much redundancy in a network and what should be done to make convergence as effcient as possible.

I sometimes feel that working out convergence on a BGP, OSPF network quite easier than working out convergnce on EIGRP from a theory point of view, and I now want to take what you have explained away, work out theoretically this process, lab and compare it with difference topologies.

I may get back to you in a couple of days with some more questions on this. But agree very much, too much redundancy, is not the greatest thing in the world.

Many many thx once again, and all please keep up the excellent work on this forum :)

Kind regards,

Ken

[kfarrington]

Russ, I have put together a little spreadsheet showing the steps of convergence as I see them. If you would be so kind, or anyone else, just to confirm that this is accurate. Then I can go and play :)

Russ, Like I say mate, the help is really valued and sooo helpful, you donot believe.

(Please see attached)

Many kind regards,

Ken

[ruwhite]

I didn't get to spend a lot of time in it (time's at a premium), it seems okay, just glancing at it, and assuming the order of operations and metrics are as you lay them out in the spreadsheet.

:-)

Russ

[kfarrington]

As always - many thx. It is really good to know that this forum works so well :)

ps. just been reading the "advanced ip network design" sample chapter "redundancy" on safari, and there is some excellent stuff there.

Gonna go and order to look at this further.

Cheers fella,

Ken

[ruwhite]

The new version of that book is called "Optimal Routing Design...." I think we covered a lot more material the second time around.

:-)

Russ