Content

| 7.3 |  | IS-IS Operation |
| 7.3.11 |  | IS-IS metrics |

The original IS-IS specification defines four different types of metrics. All routers support the default metric of cost. Delay, expense, and error are optional metrics. The delay metric measures transit delay, the expense metric measures the monetary cost of link utilization, and the error metric measures the residual error probability associated with a link.

The Cisco implementation uses cost only. If the optional metrics were implemented, there would be a link-state database for each metric and SPF would be run for each link-state database.

Default Metric
Some routing protocols calculate the link metric automatically based on bandwidth, OSPF, or bandwidth/delay, EIGRP. However, there is no automatic calculation for IS-IS. Using old-style metrics, an interface cost is between 1 and 63, a 6-bit metric value.

> Note: Try to avoid confusing the IS-IS metric range and default with the IS-IS priority range of 0 to 127 and default of 64.

All links use the metric of ten by default. The total cost to a destination is the sum of the costs on all outgoing interfaces along a particular path from the source to the destination. The least-cost paths are preferred. The total path metric was limited to 1023. This is the sum of all link metrics along a path between the calculating router and any other node or prefix. This small metric value proved insufficient for large networks and provided too little granularity for new features such as Traffic Engineering and other applications. This is especially true with high bandwidth links. Wide metrics are also required if route leaking is used.

Extended Metric
Cisco IOS software addresses this issue with the support of a 24-bit metric field called the wide metric. Using the new metric style, link metrics now have a maximum value of 16777215 (224 - 1) with a total path metric of 4261412864 (232 - 225). The wide metric formulation can be found in draft-ietf-isis-traffic-02.txt.

Deploying IS-IS in the IP network with wide metrics is recommended to enable finer granularity and to support applications such as Traffic Engineering. Running different metric styles within one network can cause a major problem. Link-state protocols calculate loop-free routes. This is because all routers, within one area, calculate their routing table based on the same link-state database. This principle is violated if some routers look at old narrow style, and some at new wider style TLVs. However, if the same interface cost is used for both the old and new style metrics, then SPF will compute a loop-free topology.