your example is fair. I haven't seen many real example of load balancing. in the case you're describing you can simply change the metrics on one of the routers 'secondary' link to the other router. this would prevent it from passing anything it received from the one router back to itself. yes the way you've created the example things would 'loop' between them, but as an experienced cisco person, you've recognized the misconfiguration and have avoid the conflict in this setup.
I can come up with dozens of normal operation scenarios where if put together in such a manner (which taken alone work fine), would fall apart because they were assembled without a perspective on the greater network. its like me wondering about the validity of marriage if the possibility exists that could marry my own sister. its a possibilty if I can think of the right scenario, but with this knowledge in mind, I can be on the lookout for anyone that resembles me a bit too closely. scott ""nwo"" wrote in message news:[EMAIL PROTECTED] > 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=66795&t=66795 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
