OK, consider this scenario. You have a large network of IGRP routers. You have routers A and B who each have a metric of, say, 10 to a given destination (I am going to use simple values for the metrics of IGRP to make things easy). Routers A and B are also directly connected, and the link between them has a metric of 1. Router A sends an update to B that the destination has a metric of 10, and router B adds the value of the link to arrive at a total metric of 11. Therefore, router B has 2 ways to get to the destination, the first would be through the normal way (through the path that has a metric of 10) and the other through router A (which has a metric of 11). Vice versa is also true with respect to router A. When you configure variance of larger than 1, then both paths will be entered into the route table.
If this is the case, then you can see that some packets can bounce around. For example, router A may, through unequal load-balancing, send some of the dest packets to B, and then B will, again through unequal balancing, send some of those packets back to A, etc. Yes, the number of packets sent the 'wrong way' decreases exponentially but the point is that there is still some bouncing around. The only way I can see that this would not happen is if a router would compare the metric of a received route (before the cost of the link is added) to the metric that the router is currently holding for that route, and if it is equal to or greater than that value, the route is rejected unconditionally for unequal balancing. This would be something similar to what the whole EIGRP successor algorithm accomplishes. Does anybody know for a fact whether this is in the IGRP algorithm? ""Priscilla Oppenheimer"" wrote in message news:[EMAIL PROTECTED] > nwo wrote: > > > > It occurs to me that I do not understand how IGRP unequal load > > balancing > > works. > > > > Yes, I understand what the commands are, and I am well aware of > > the > > intricacies involved in fast-switching and CEF. So please > > don't respond by > > telling me to configure 'variance' or stuff like that. I > > already know all > > that. > > > > What I don't understand is this. A fundamental part of EIGRP > > unequal load > > balancing is the concept of the feasible successor, where > > routes of unequal > > metric to a particular destination will be considered only if > > the > > corresponding neighbor is a feasible successor for the > > destination in > > question. This is in order to prevent the problem of packets > > being sent to > > to a router that is actually further away from the destination > > than the > > sending router is to that destination. > > > > Yet, I am aware of no such safeguards in IGRP. IGRP has no > > such concept of > > I don't think such a safeguard is necessary. A router running even a simple > distance-vector protocol like IGRP knows the metric of its neighbors because > the neighbors report it in update packets. The router can add routes to the > routing table based on this information alone and knowledge of the variance > and maximum-paths values. It would be a broken protocol indeed if it added > routes that included a next-hop neighbor that was farther away. > > The business of feasible successors, unique to EIGRP, helps maintain the > routing table when changes happen, such as when a directly connected link > fails or when update or queries arrive. I don't know if it's used for load > balancing though. It wouldn't need to be. > > If you have a URL that explains what feasible successor has to do with load > balancing, please send it. Thanks. But I would probably still say that it's > not necessary for load balancing to work. > > > a topology table with neighbor's advertised distances and > > whatnot. > > Therefore it seems that packets could easily be forwarded away > > from the > > destination. > > Not if the distance-vector protocol is working correctly. > > > Furthermore, it would seem to me that packets > > could actually > > bounce back and forth between 2 routers for awhile. > > Once again, not if the distance-vector protocol is working correctly, unless > I'm missing something. > > Priscilla > > > > > > Please say it ain't so. Yet I am unaware of any construct > > within IGRP that > > would prevent it from being so. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=66727&t=66727 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
