Hi, K1 relates to BW. K2 relates to BW, Load. K3 relates to Delay. K4, K5 relates to Reliability. MTU is just used for "tie-break"
HTH, But Nguyen. On Tue, Aug 11, 2009 at 3:55 PM, Dale Shaw <[email protected]<dale.shaw%[email protected]> > wrote: > Hi, > > On Tue, Aug 11, 2009 at 6:47 PM, Jowi Nkwe (JM)<[email protected]> > wrote: > > > > Please clarify this, what is the correct EIGRP K values > > representation. That is K1, K2, K3, K4, K5, I know they represent > > bandwith, dealy, load, mtu, reliability... But please confirm the > > following > > K1 = ...... > > K2 = ...... > > K3 = ...... > > K4 = ...... > > K5 = ...... > > > > I've searched the doccd, but this is not explicitly indicated as such. > > Metric weight command under EIGRP process does not offer much help. > > From the DocCD (command reference for 'metric weights (EIGRP)'): > > "If k5 equals 0, the composite EIGRP metric is computed according to > the following formula: > metric = [k1 * bandwidth + (k2 * bandwidth)/(256 - load) + k3 * delay] > > "If k5 does not equal zero, an additional operation is performed: > metric = metric * [k5/(reliability + k4)] > > So the weights don't strictly map one-to-one with the 5 elements > mentioned -- bandwidth, delay, load, reliability and MTU. > > In fact, MTU values, while tracked along a path, are not actually used > in the composite metric calculation at all -- k5 might seem to map to > MTU because that's what the context-sensitive CLI help indicates, but > you can see that the actual MTU value is not used in the above > calculation. > > Using the default weights, the formula is effectively simplified to: > > 256 * (10,000,000 / BANDWIDTH_IN_KBPS(min)) + 256 * (DELAY_IN_uSEC(sum) / > 10) > > e.g. if the minimum end-to-end bandwidth is 100Kbps and the total > end-to-end delay (in microseconds) is 124000, the composite metric is: > > 256 * (10,000,000 / 100) = 25600000 + > 256 * (124000 / 10) = 3174400 = > 28774400 > > The first 'metric weights' parameter -- ToS -- > is always zero. An original design goal was for EIGRP to be able to do > Type of Service routing, but this was never implemented. > > cheers, > Dale > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
