17 mins read

ISIS Metric – 1st trap of Narrow and Wide metrics

1. Intro

The ISIS Metric topic will have 3 parts:

  • 1st part – in this post we will cover the unexpected impact of using both Narrow and Wide by default
  • 2nd part – in the next one we will see the unexpected impact of configuring wide-metrics-only
  • 3rd part – and finally we will cover the differences between IPv4 and IPv6 related to this metric topic

2. The ISIS metric defaults

A quick review of the ISIS metric defaults:

  • metric 10 for all interfaces except lo0 / metric 0 for loopback interface.
  • by default there is no automatic calculation for IS-IS (unlike OSPF, in which the default link metric is calculated automatically based on bandwidth). 
  • we have two metric types: Narrow and Wide.
  • Wide metrics or Narrow metrics can be set on a per-level basis.
  • Narrow:
    • range: 1 through 63
    • total path metric: 1023 (10 bits)
    • TLVs:
      • 2 (IS Reachability),
      • 128 (IP Internal Reachability),
      • 130 (IP External Reachability).
    • such a low range and low total path metric can be a limitation in many scenarios (e.g. large networks, traffic engineering, etc.).
  • Wide:
    • range: 1 through 16,777,215 (24 bits)
    • total path metric: 4,294,967,295 (32 bits)
    • TLVs:
      • 22 (Extended IS Reachability),
      • 135 (Extended IP Reachability)
      • 236 (IPv6 Reachability)
    • range and low total path metric is no longer a limitation with wide metrics, but still has hidden impacts as we will see in this and next post.
  • By default Junos uses a combination of both Narrow and Wide metrics, and this can be a trap, and create a lot of confusion if not properly understood. Let’s cover this in the next chapter.

3. The unexpected impact of using both Narrow and Wide by default

As already mentioned, Junos uses a combination of both Narrow and Wide metrics. But why use both? Well, the advantage of having such an approach is offers compatibility by default between the two options, and this can help with when transitioning from the old Narrow metric to the new Wide metric.

When we are saying that both Narrow and Wide metrics are being used, it means that routers will generate both narrow and wide TLVs by default, meaning all metric related TLVs will be generated by the router: 2, 128, 130, 22 and 135.

But, Narrow has a maximum link metric of 63, while Wide has a maximum link metric of 16,777,215, this is a problem. For example, what happens if I configure an interrace/link metric of 1000? The Narrow TLVs will not be able to advertise the 1000 metric because the maximum they support is 63.

Instead of advertising metric 1000, the router will actually advertise metric 63 on both Narrow and Wide TLVs. Probably Juniper decided that there must be some consistency between the two metric types to avoid a total mess, and this way is less confusing that a potential alternate approach.

Be warned. As already mentioned, with the defaults, you can configure a higher metric, like 1000 in our example, Junos will accept the CLI command with no warning, and silently advertise the maximum narrow metric 63 instead.

Because of this default behaviour, it is common practice to use only Wide metrics, and this way we will get rid of the limitation that we just mentioned. Configure the wide-metrics-only knob to achieve this.

This is also mentioned in the official documentation: “By default, Junos OS supports the sending and receiving of wide metrics. Junos OS allows a maximum metric value of 63 and generates both pairs of TLVs. To configure IS-IS to generate only the new pair of TLVs and thus to allow the wider range of metric values, you must include the  wide-metrics-only statement in the IS-IS configuration.

We mentioned what TLVs will be generated by the routers, but we should probably also mention explicitly, that once generated, regardless of the configuration, ISIS will read and process both narrow and wide related TLVs.

You will find questions about this in your Juniper certification exams, but this is also important in real life scenarios where this must be understood to avoid confusion.

4. A practical example

Let’s observe all of this in our test topology, find it next:

We can see that 3 routers area already using the wide-metric-only knob, while R3 and R5 still have the default configuration.

Let’s observe the configuration of the R1 and R5 routers:

We can see in our topology that our scenario is a mixed one, where R1, R2 and R4 are using Wide metrics only, while R3 and R5 are using the default (both narrow and wide). The next output demonstrates that there is compatibility in a mixed setup like this. Observe the metrics from R5 to R1:

Maybe not obvious if you are not used with this output, but we can see in the ISIS database that the R1 is using the wide metric TLVs, as indicated by the IP extended prefix TLV type:

This is more obvious if we look at the Wireshark capture:

If we check the same on R5, we can see that it is using both Narrow and Wide TLVs:

And the Wireshark capture for the R5 LSP packet:

Let’s change the Metric on R5-to-R3 link to 1000, and observe the impact on the CLI level and in the Wireshark capture. Even if we configured metric 1000, the router is silently using metric 63 instead:

5. Conclusion

For the ability to migrate, both Narrow and Wide metrics are on by default, however the Wide metrics are just reflecting the values low values of Narrow metrics (limited to max 63).

In the next post we will see wide-metrics-only configured on R3 and R5, and all links will have metric 1000, so the total metric form R5 to R1 will be 4000. But in the same time, we will also see the other different big impact of configuring wide-metrics-only.


External Resources: