Thanks Tshon and Kent, My point is that, using EIGRP routing protocol, for the same two routes, (in the given case R1->R2->R4, and R1->R3->R4), they are seen as equal paths for traffic from R1 to R4, but are not seen as equal for the traffic from R1 to R5. This is a litle bit unusual to me.
Using OSPF, this is not the case, I mean, if path R1->R2->R4 = R1 -> R3->R4 then R1->R2->R4->R5 = R1->R3->R4->R5. Your (Tshon's) recomendation is a good option. By using only Delay as metric, EIGRP turns back to work similarly as OSPF as long as traffic engineering is concerned. But Cisco always insists that EIGRP is more outstanding than OSPF , that means there must be a better way to get around this problem. The one given by Kent is probably more common. He recommended to use variance for making the two routes R1->R2->R4->R5 and R1->R3->R4->R5 to look roughly equally from Router R1 point of view. Yet, variance is a local solution and it only applies to a specific router. I am writing a software that models EIGRP routing protocol. As a result, it is difficult for the software to look at too many details of the "manual configuration" (like setting variance for a specific network). My objective is to find a suitable set of Delays so that the network performs best (least congested). My sofware modeling OSPF works fine and it gives quite a good result. By the way, OSPF does not neccesarily have to use bandwidth as a metric. It use WEIGHTS as metric. By default, it is recommended by Cisco, Cost = 10^8 / Bandwidth. But we can change the default weights without having to change the Bandwidths! And by my experience , and it is also proved by some other articles that Cisco recomended weights are not optimal. We can find a suitable set of OSPF weights to make the network perform much better (less congested, less bottleneck...) Tshon wrote: > > I'm not sure I understand your entire question. But, I hope > this > helps... you have to many formulas. > > What the recommendation states is that if you are running other > routing > protocols like ospf who > takes its decisions based on bandwidth statements then you > shouldn't > change them, because it > will also affect ospf. > > But here think about this you could change the K values for > Eigrp, to > only look at delay. > then adjust the delay for what you wish. > > Hans PHAM wrote: > > >Hi, > > > >By default EIGRP uses 2 metric: Bandwidth and Delay to > calculate routes. It > >is recomended that we should not change the Actual Bandwith, > but we can > >change the interface delay for the traffic enginering purposes. > > > >The metric is : Min Bandwidth + Cumulative Delay. > > > >This can end up with a problem of "route non-consiste1nce". > Here is my > >counter example: > > > > R2 > > / \ > > / \ > >R1 R4-----R5 > > \ / > > \ / > > R3 > > > > > >Link > >1-2 : Bandwidth = 10M, delay = 10ms > >2-4 : Bandwidth = 20M, delay = 5ms > >1-3 : Bandwidth = 20M, delay = 15ms > >3-4 : Bandwidth = 20M, delay = 5ms > > > >4-5 : Bandwidth = 10M, delay = 10ms > > > >The traffic from R1 to a network directly connected to R4 will > be load > >balance between routes R1-R2-R4 and R1-R3-R4. because the > Metric of the two > >routes are the same: > > > >R1-R2-R4 = Bandwidth (i.e. 10^7 / 10000) + Delay (i.e 1000 + > 500) = = 1000 > >+ 1000 + 500 = 2500 > > > >R1-R3-R4 = 500 + 1500 + 500 = 2500 > > > >However, traffic from R1 heading for R5 is not load-balanced > because the > >Metric R1-R2-R4-R5 is 3500 while the metric R1-R3-R4-R5 = 4000 > > > >that means all traffic from R1 -> R5 will go via R2 > > > >That's is a kind of inconcistence, which may lead to > bottleneck, and cause > >difficulty for traffic engineering. > > > >Could you please tell me if I am wrong or right ? > > > >If I am right, how we can overcome this problem. > > > > > >Thanks a lot. > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=38151&t=38043 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
