Re: EIGRP Metric and Route inconcistence [7:38043]
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 / 1) + 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]
RE: EIGRP Metric and Route inconcistence [7:38043]
What your describing is fairly common and you can "fix" this by adjusting the delay metric of router interfaces in your path. In your example, you could adjust the delay between the routers so that the path metrics are equal. This is, as you note, the preferred approach with IGRP/EIGRP to manipulate metrics. One thing to note though is that by making the paths appear equal, you are, in fact, "lying" to the router R1. Since the real bw and delay are not equal, the router is doing what it should do, pick the path with the most preferred route based on these factors. If you have multiple routes with unequal cost, you can use the "variance" command in IGRP/EIGRP so that you can send a fraction of packets over the lesser preferred path. In your case, if you used the command "variance 2" under the EIGRP statement for R1, it would consider alternative, less preferred paths as long as they were less than or equal to (2*preferred path metric). The router would then send half as many packets along the less preferred path as the most preferred path. If you used "variance 3" it would use (3*preferred path metric) and send 1/3 as many packets, etc. etc. for any n value "variance n". In your scenario, using the variance command may be preferred since you may not want a less preferred path getting the same amount of packets as the most preferred path. Then again, since the delay values are so close, the paths may, for all practical purposes, be roughly equal in performance, so equal sharing of the paths may be better. That's something you would have to determine in practice, based on your particular network traffics characteristics. HTH, Kent -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 12, 2002 6:30 PM To: [EMAIL PROTECTED] Subject: EIGRP Metric and Route inconcistence [7:38043] 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 / 1) + 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=38118&t=38043 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: EIGRP Metric and Route inconcistence [7:38043]
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 / 1) + 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=38072&t=38043 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: EIGRP Metric and Route inconcistence [7:38043]
Hans PHAM wrote: Sorry for the bad figure, this is a better one .. .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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=38046&t=38043 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: EIGRP Metric and Route inconcistence [7:38043]
Hans PHAM wrote: Sorry for the bad figure, I draw again > 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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=38044&t=38043 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
EIGRP Metric and Route inconcistence [7:38043]
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 / 1) + 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=38043&t=38043 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
