Section 5.3. Metric Types

5.3. Metric Types

Both OSPF and IS-IS use a dimensionless metric that is best named cost. The metric is assigned to every interface on which the protocol runs, either administratively or by some default value, and is essential for determining the shortest path between any two nodes. When evaluating the route from some source A to some destination Z, the cost of the route is the sum of the costs of all outgoing router interfaces from A to Z.

5.3.1. OSPF Metrics

RFC 2328 and its predecessors do not specify or suggest a default interface cost for OSPF, other than that it must be greater than 0. That leaves the potential for implementations to vary widely in their default value. Fortunately, many vendors have copied Cisco Systems' method for determining default costs, thereby creating a reasonable consistency across vendors.

This method, rather than having a single default for all interfaces, calculates the cost by dividing 100Mbps by the interface bandwidth. So, for example, a 10Mbps Ethernet interface will have a cost of 100/10 = 10, and a 56kbps link will have a cost of 100000/56 = 1,785 (fractional values are ignored). This 100Mbps constant is called the reference bandwidth.

The problem with the costing algorithm is that it was invented in the days when 100Mbps was a very high-bandwidth link. Any interface bandwidth of 100Mbps yields a cost of 1, the lowest cost possible. When a bandwidth greater than 100Mbps is used, the result of this calculation is rounded up to 1. But modern large-scale networks routinely use links with greater bandwidth, and even in smaller networks it is not unusual to find 1G Ethernet links. To compensate for the realities of modern networks, the reference bandwidth is configurable to a higher value.

You can set the interface manually rather than use the automatic costing algorithm. If your network is large, it is usually wise to develop a well thought-out costing plan that realistically reflects your ideas about traffic behavior, and use this plan to administratively assign interface costs. Manually assigned costs might be based, for example, on line-of-sight or wire/fiber distance between sites.

The metric assigned to prefixes within an area is 16 bits long. Prefixes that are outside of an areaeither somewhere else within the OSPF domain or external to the OSPF domainare given a 24-bit metric when they are advertised into the area. The rationale for this is that the path to an external destination is likely to be longer, and therefore of a higher cost, and can require a larger size metric.

When an external prefix is advertised into the OSPF domain, there can be no assumption that any metric externally assigned to it will be meaningful to OSPF. So the prefix is assigned a metric by the ASBR that advertises it into the domain. This metric assignment is specified as a part of the routing policy configuration on the ASBR that redistributes the prefix.

The metric assigned to external prefixes can be one of two types:

• Type 1 External (E1) metrics take into account both the cost assigned by the ASBR and the cost to the ASBR.

• Type 2 External (E2) metrics remain just the cost assigned by the ASBR, and do not change as the prefix is advertised through the OSPF domain.

Figure 5.13 illustrates how E1 and E2 metrics differ. ASBRs 1 and 2 both are advertising a route to external prefix 192.168.1/24, but ASBR1 assigns a cost of 10 to the prefix and ASBR2 assigns a cost of 5. The router on the left has paths to both ASBRs, but the cost of the path to ASBR1 is 20, whereas the cost to ASBR2 is 30. If the two ASBRs make the assigned cost of the external prefix E1, the cost of the route to the prefix through ASBR1 is 30 (20 + 10) whereas the cost of the route to the prefix through ASBR2 is 35 (30 + 5). The route through ASBR1 is chosen as the lower-cost route.

Figure 5.13. The choice of route to the external prefix 192.168.1/24 depends on whether the two ASBRs assign their costs as E1 or E2 metrics.

If the ASBRs make the assigned costs E2 metrics, the costs of the paths to the ASBRs is not taken into consideration when choosing the shortest route to the destination. As a result, the router on the left sees the cost of the route through ASBR1 as 10 and the cost of the route through ASBR2 as 5. The route through ASBR2 then has the lower cost and is chosen.

The availability of these two external metric types gives you flexibility in choosing how to reach external destinations. If you always want to choose the closest exit out of the OSPF domain, use E1. However, in most cases, choosing the ASBR that is "closest" to the external destination is more important, either for financial or performance reasons. In this case, E2 metrics are used.

E1 and E2 metrics can both exist in an OSPF domain, and can even be assigned to the same prefix by different ASBRs. Therefore, there are two rules for managing conflicts:

• If one ASBR advertises a prefix with an E1 metric and another ASBR advertises the same prefix with an E2 metric, the E1 metric takes precedence.

• If two ASBRs advertise the same prefix with the same E2 cost, the cost of the internal paths to the ASBRs is considered and the route through the lowest-cost ASBR is chosen.

5.3.2. IS-IS Metrics

There is quite a bit of divergence between the IS-IS metrics prescribed by ISO 10589 and the IS-IS metrics used in real-life networks. ISO 10589 specifies four different 6-bit metric fields that can be assigned to an IS-IS interface:

• A default metric, which must be understood by every router in the IS-IS domain. The dimension of this metric is undefined, and can represent whatever you want it to represent. In practice it normally represents interface cost, the same as the OSPF metric.

• A delay metric, which represents the transit delay of the attached link.

• An expense metric, which represents the monetary cost of using the attached link.

• An error metric, which represents the probability of encountering errors on the networkin other words, a measure of the relative reliability of the link.

The use of the default metric is mandatory, and the other three metrics are optional. The idea behind these four metrics is to provide a rudimentary (by today's standards) QoS-based traffic engineering capability. A router performs separate SPF calculations for each of the supported metrics, to derive separate routes based on each of the metrics.

No commercial IS-IS implementation supports the three optional metrics. Aside from the potential impact on router performance and memory of running separate SPF calculations for each metric and recording the multiple resulting routes, no user demand for such a scheme has arisen to warrant vendor support. Only the default metric is used.

Both Juniper Networks and Cisco Systems routers set the IS-IS metric to a default value of 10 for all interfaces. You should have a good costing plan for your IS-IS network that reflects the realities of your link types and physical architecture. Leaving all metrics at the default values means that IS-IS will choose its routes based on the least number of router hops.

Associated with the 6-bit IS-IS metric is an internal/external (I/E) bit. This bit distinguishes whether the prefix is located internally to the IS-IS domain or external to the domain.

The 6-bit metric width means that the range of metric values that can be assigned to an interface is 0 through 63. Part of the original thinking behind this small metric value was that the SPF algorithm would be more efficient and require fewer processor cycles. But with modern routers, this concern is unfounded. And in larger networks, there is a concern that such a limited range does not provide enough metric granularity (64 possible values versus OSPF's 65,535 possible values). To alleviate this concern, an extension to IS-IS is now supported by many implementations that allows for a 32-bit metric field. To distinguish which metrics routers support, the original 6-bit metrics are called narrow metrics, and the 32-bit metrics are called wide metrics. The TLV that supports wide metrics, the Extended IP Reachability TLV, is described in Section 5.5.8.

Wide and Narrow IS-IS Metrics in Multi-Vendor Networks

Although several router vendors support wide metrics (primarily those that sell to carriers or that support traffic engineering), it seems that they all support them a bit differently. For example, Cisco Systems routers default to narrow only but can be configured to support wide only (meTRic-style wide) or both narrow and wide (metric-style wide transition). Juniper Networks, on the other hand, defaults to both narrow and wide metrics but can be configured for wide only (wide-metrics-only). A difference still exists, however, because when a Cisco router is configured for either narrow only or wide only, it is limited to generating and receiving only that metric type. When a Juniper router is configured for wide only, it generates only that type but still accepts both narrow and wide metrics.

Then there is Avici Systems, which can be configured to support narrow only (use-metric-style narrow), wide only (use-metric-style wide), support both but prefer narrow (use-metric-style prefer-narrow), or support both but prefer wide (use-metric-style prefer-wide). Avici's default is narrow only.

The point is that in a multivendor network, if you want to use wide metrics be sure you understand each of your vendors' procedures for both generating and receiving metrics. Manuals are not always clear, so talk to engineers from each of your vendors.