EIGRP best topology

PM77 · ‎08-28-2009

Hi to all,

I have some questions about the topology in the attached file. As you can see I have a ring topology between three buildings, but the routers E and F have only 1 successor (and no feasible successor)to reach respectively the network a and b. This will cause the beginning of the query process in the case of loosing the successor router.

Is there a particular tuning on the DLY parameter to optimize the eigrp protocol (in order to have 1 sucessor and 1 feasible successor for each destination network)? Whitch is the best topology design?

Thanks in advance

PM

Peter Paluch · ‎08-28-2009

Hello,

First of all, the topology depiction you have included in your report here is very nice. Thanks for that, it made the learning of your requirement a lot easier.

One correction to the exhibit, though: the FD columns as you have it in your picture is not really the FD. It is only the complete distance through a particular neighbor. The FD is a single number for each destination network, not for a destination and a particular neighbor.

That being said, I would like to ask you if you have any problems with the current state of things - that the routers E and F generate a query if they loose the successor to networks A and B. It is generally not a good approach to tinker with metrics to make a router appear as a feasible successor. The feasible successor idea in EIGRP is a nice byproduct of the principles behind it (mostly of the feasibility condition) but you should not forcibly try to make routers see themselves as feasible successors. In your particular topology, for E going to network A, the router F must report its distance (the RD) lower than your FD to appear as feasible successor. That would necessitate lowering the delays and/or increasing the bandwidth settings somewhere on links behind the router F - i.e. on links F/D, D/C and C/B. The problem is that this modification will influence all routes and all shortest path calculations. We could concoct a set of EIGRP metrics that would make the F to appear as feasible successor for the network A but we could quite easily mess up other routing. This is just not the way things are done.

Also, note that if the router E looses a successor to network A, it would be the router A. It would query the router F who will not be affected by this query because it has a different successor than E. Therefore, the F will immediately provide a reply and won't propagate the query further. So after one query/reply, the E can update its routing table and start pointing to the router F. That's absolutely not that bad :-)

I would like to hear your opinion on this.

Best regards,

Peter

PM77 · ‎08-28-2009

Hi Peter,

tks a lot for your reply! With this topology somethimes I received SIA messages (stuck-in-active and peer restarted)from some routers and I'm investigating in deep on the eigrp topology, but I don't know if this is caused by "no feasible successor" in the routing table.

In any case my worry is that I could experience loosing of packets during the eigrp query process (this can affect UDP application like real time protocol). Coming back on my topology if router E looses its successor A to reach network a, it would query to F. Router F will query to its neighbour D because it received the query from its successor for network a. At this point router D will reply to router F with the new route (and router F to E). This process in the worst case could take the hold timers!

Regards

Pompeo

Peter Paluch · ‎08-28-2009

Hello Pompeo,

You are welcome. Regarding the SIA messages, that's not good. SIA status is generated when for a query you do not receive a reply for 3 minutes. In that case, the neighborship is reset. There are several issues that can create a SIA status but often, transmission problems on links or congestion situations are responsible. Please check these links for more information about SIA and its troubleshooting:

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008010f016.shtml

http://www.cisco.com/application/vnd.ms-powerpoint/en/us/guest/tech/tk207/c1482/cdccont_0900aecd801e4aab.ppt

Having a feasible successor would probably make the SIA problem appear less often but it is only a workaround. However, the SIA is a problem I would pursue intensively because it indicates a deeper problem somewhere in your network.

Of course, during a routing table update, some packets may get lost. However, do not expect that having a feasible successor will protect you against packet losses. There is always some time involved between the moment the successor is no longer valid and the moment you detect it. During this time period, you will most certainly lose packets and having a feasible successor will not help you in any way.

Note that there are no hold timers in EIGRP. There is just the Active timer that is set to 3 minutes by default. However, an EIGRP router does not have any reason to delay sending a reply after it has received all answers itself. According to the exhibit, your network is rather simple and I do not see any reason for a diffusing computation to end in more than roughly hundreds of milliseconds once started.

Best regards,

Peter