RE: EIGRP Metric and Route inconcistence [7:38043]

] 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

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

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

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 :

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 :

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