## Classic Metrics

EIGRP carries the following values in the EIGRP advertisements:- Bandwidth
- Delay
- Reliability = ratio (expressed as x/255) of frames successfully arriving / frames sent
- Load = ratio (expressed as x/255) of interface load as measured by
*Txload* - MTU
- Hop Count (default max 100 but can be as high as 255)

**MTU and Hop Count are NOT USED in metric calculations.**

### Metric calculation

In general, EIGRP takes the**WORST CASE**of the 'classic' metrics that go to make up the composite metric value. Each metric component is carried separately in the EIGRP messages, and the composite is calculated in each router according to the metric formula.

Worst case metrics mean:

- Bandwidth = MIN (BW along the path)
- Delay = SUM (Delay along the path)
- Reliability = MIN (Reliability along the path)
- Load = MAX (Txload along the path)

*Txload*is calculated as an average value. They are both relics of IGRP, retained for reasons of backward compatibility, and are not particularly useful.

Delay is also used to indicate an unavailable route as an INFINITE METRIC of 16,777,215 (24 bits of all 1's), used in Split Horizon w/ Posioned Reverse and Route Poisoning. Delay is represented in 10s of microseconds by the metric value.

### Composite metric formula and K values

K values are constants used to weight the metric calculation and can take the values 1-255. Since is it imperative that all routers calculate the composite metric in the same way, these must match on every router in the EIGRP autonomous system. Any routers with mis-matching K values cannot form an adjacency.\[CM = (K_1 . BW_{inv} + \frac{K_2 . BW_{inv}}{256 - Load_{Max}} + 256 . K_3 . \sum Delay ). (\frac {K_5}{K_4 + Reliability_{Min}})\]

\[BW_{inv} = \frac{256 . 10^7}{BW_{min}}\]

N.B. The formula is

**conditional**, and IF K5=0, then the entire final term \(\frac {K_5}{K_4 + Reliability_{Min}}\) is evaluated to 1. [See EIGRP RFC Draft 0.3 section 5.5.3]

Default K values of K1, K3 = 1 and K2, K4, K5 = 0 lead to a simplification of the formula to:

\[CM = BW_{inv} + 256\sum Delay\]

Delay and BW are multiplied by 256 to convert the IGRP 24 bit metric to an EIGRP 32 bit metric.

## Wide Metrics

EIGRP has found itself, like other protocols, in the position that its metrics have fallen behind the pace of technological advances.The BW metric, in the classic form, is unable to make any distinction between interfaces with BW of 10Gbps or more, or with a delay of less than 10 microseconds (delay metric of 1). Also, rounding errors in successively de-scaling and then scaling the metric components for composite metric calculations lead to a loss of resolution.

Unfortunately, this has meant that the affected metrics, although doing the same function as before, have had to be re-named and the formulae for calculation modified in order to distinguish from the classic metrics.

### Throughput [Bandwidth]

Throughput is the Wide metric replacing the Bandwidth metric (scaled by 256), with a new calculation of:\[T_{min} = \frac{65536 . 10^7}{BW_{min}}\]

### Latency [Delay]

Latency is the Wide metric replacing the Delay metric, and is calculated using the following formula:\[La = \frac{65536 . IntDelay}{10^6}\] (where IntDelay is in

**picoseconds (1x\(10^{-12}\)s**)

IntDelay is calculated differently based on whether or not

*bandwidth*and

*delay*are manually set, and on the native speed of the interface as follows:

####
1Gbps and lower without *bandwidth* and *delay* commands

IntDelay = The IOS default delay converted to **picoseconds**

####
Over 1Gbps without *bandwidth* and *delay* commands

IntDelay = \(10^{13}\) / BW####
WITH *bandwidth* command

IntDelay = The IOS default delay converted to **picoseconds**

####
WITH *delay* command

IntDelay = configured delay value x \(10^7\) (i.e. configured delay value in picoseconds)### Extended metrics

Three extended metrics are defined for future use, but are not currently supported:- Jitter
- Energy
- Quiescent Energy

The updated Wide Metric is as follows:

\[WM = (K_1 . T_{min} + \frac{K_2 . T_{min}}{256 - Load_{Max}} + K_3 . \sum La + K_6 . ExtM ). (\frac {K_5}{K_4 + Reliability_{Min}})\]

### RIB compatibility

Since the wide metric can possibly result in a value wider than 32 bits, this must be downscaled before the route can be installed in the RIB since the RIB can only support 32 bits. This does not influence EIGRP in any way, it is simply so that the RIB can have a valid metric value for the best path that is handed down to the RIB.This is done by dividing the wide metric by the value (default 128 with the possible values of 1-255) configured in the

*metric rib-scale*EIGRP command.

## Metric 'tweaking'

Bandwidth should**NEVER**be modified in an attempt to modify path selection, since it is used in many other IOS functions (e.g. QoS); instead DELAY should be adjusted, as it has no other function in IOS than in EIGRP metric calculations, and it is additive so can be guaranteed to affect the composite metric and hence the best-path selection.

## No comments:

## Post a Comment