K metric values, etc

[marcel.felix]

Just the facts. Mate

Why do the K values indicate, see page 461 of the Cisco Cert book BSCI 642-801

K1 Bandwidth

K2 Loading

K3 Delay

K4 Reliability

K5 MTU

CCNP BSCI Exam book By C Gough

Then, when configuring the default-metric is it

(page 636)

Bandwidth

Delay

Reliability

Loading

MTU

WHY, WHY, WHY, it just seems that whoever wrote the scrip for the default metric did not review the K value sequence. I am taking the BSCI for the 3rd time, i can really see why people are having a hard time passing this Exam, the Cisco cert book has 1 page on NAT and the test has a number of questions that the cert book does not even cover.

I find the book has a few of errors, which makes it a bit a pain when studing for the exam.

[amitsin]

Here is the sequence of the K-Values

bandwidth, delay, reliability, load, and MTU

it should be same always.

[marcel.felix]

I know what you are indicating,

K1, K3, K2, K4 & K5

What i indicating was, that the order of the K Values is not in a simple order of 1 thur 5 as you might think.

I do understand that Bandwidth & Delay are the two constants that are used for the composite metric. Which is why it is K1 then K3.

I guess when you are tryng to remember a lot sequences and configurations, it can throw you.

Just like Page 504 of the BSCI cert book which indicates frame-relay configuration, the example indicates

routerA(config-if)#frame-relay encapsulation

Now, thats new to me, my routers only respond to encapsulation frame-relay.

[ruwhite]

For a simple reason.... I wasn't around when the K values were designed, or the CLI (Dino wrote this stuff about 2 years before I came to cisco, I think it was, or something like that), but I've been working on EIGRP for about 6 years now, so I've been asked this a couple of times. :-)

The reason is simpler than it seems. When the formula was written, the K values were assigned as they appear in the (original) formula itself. So, this much makes sense--read the formula left to right, and just use "1," "2" in each of the inserted variables.

When the CLI was written, things were a little different. They assumed not many people would mess with anything other than bandwidth and delay, so they put those first. You could, technically, make the rest 0, and it has no impact on anything if you're using the default K values. I think the original intent was to make it so you only had to enter the values you have K calues set for, but this didn't work too well, so you have to put all of them in.

So, as you can see, it's because the two different orders have to do with the two different situations where you use the metrics.

Further than this, the listing of "K1 == bandwidth, K2 == load," etc, really isn't true. The real formula is:

metric = [K1*bandwidth + (K2*bandwidth)/(256 - load) + K3*delay] * [K5/(reliability + K4)]

At least the last time I checked in the code (?). So, in reality, K4 and K5 both impact reliability, K1 is only related to bandwith, load isn't factored by itself, etc. There's no one-to-one correlation, as far as I know.

As a bonus, I'll give you one other piece of trivia you didn't ask for. Why the multiply by 256??? Because IGRP uses 24 bit metrics. They wanted EIGRP to use 32 bit metrics, but also wanted to be able to convert from EIGRP to IGRP metrics easily. 2^8 just happens to be 256 (shift left 8 bits), so simply multiplying an IGRP metric by 256 gives you the equivalent EIGRP metrics, and dividing an EIGRP metric by 256 (right shift 8 bits) gives you the equivalent IGRP metric.

:-)

Russ.W