As part of the netlab development process, I run almost 200 integration tests on more than 20 platforms (over a dozen operating systems), and the amount of weirdness I discover is unbelievable.

Today’s special: Junos is failing the IS-IS metrics test.

The test is trivial:

• The device under test is connected to two IS-IS routers (X1 and X2)
• It has a low metric configured on the link with X1 and a high metric configured on the link with X2

The validation process is equally trivial:

• Check for IS-IS adjacencies (just to be on the safe side)
• Check for prefixes in the IS-IS database (just to verify they’re there)¹
• Check the cost of the IS-IS prefixes.

That last bit was failing on Junos.

Here’s the relevant IS-IS Junos config²:

protocols {
    isis {
        interface ge-0/0/0.0 {
            level 1 metric 17;
            level 2 metric 17;
            point-to-point;
        }
        interface ge-0/0/1.0 {
            level 1 metric 80000;
            level 2 metric 80000;
            point-to-point;
        }
        interface lo0.0;
    }
}

Here’s how the test is failing:

[c_x1_l1]   Check level-1 cost X2 => X1 [ node(s): x1 ]
[FAIL]      Node x1: Invalid cost for prefix 10.0.0.3/32: expected 150010 found 70073

[c_x1_l2]   Check level-2 cost X2 => X1 [ node(s): x1 ]
[FAIL]      Node x1: Invalid cost for prefix 10.0.0.3/32: expected 150010 found 70063

The routing table on X1 does contain an unexpectedly low metric (considering the metric on the incoming link is 70000)³.

I>* 10.0.0.1/32 [115/70000] via 10.1.0.1, eth1, weight 1, 00:01:51
I>* 10.0.0.3/32 [115/70073] via 10.1.0.1, eth1, weight 1, 00:01:51
I   10.1.0.0/30 [115/70017] via 10.1.0.1, eth1 inactive, weight 1, 00:01:51
I>* 10.1.0.4/30 [115/70063] via 10.1.0.1, eth1, weight 1, 00:01:51

Next step: look at the IS-IS LSP originated by the Junos device:

IS-IS Level-1 link-state database:
LSP ID                  PduLen  SeqNumber   Chksum  Holdtime  ATT/P/OL
dut.00-00                 239   0x00000004  0xc224     905    0/0/0
  Protocols Supported: IPv4, IPv6
  Area Address: 49.0001
  IS Reachability: 0000.0000.0002.00 (Metric: 17)
  IS Reachability: 0000.0000.0003.00 (Metric: 63)
  Hostname: dut
  TE Router ID: 10.0.0.1
  Router Capability: 10.0.0.1 , D:0, S:0
  Extended Reachability: 0000.0000.0002.00 (Metric: 17)
    Link Local  ID: 342
    Link Remote ID: 0
    Local Interface IP Address(es): 10.1.0.1
    Remote Interface IP Address(es): 10.1.0.2
  Extended Reachability: 0000.0000.0003.00 (Metric: 63)
    Link Local  ID: 343
    Link Remote ID: 0
    Local Interface IP Address(es): 10.1.0.5
    Remote Interface IP Address(es): 10.1.0.6
  IP Reachability: 10.1.0.0/30 (Metric: 17)
  IP Reachability: 10.0.0.1/32 (Metric: 0)
  IP Reachability: 10.1.0.4/30 (Metric: 63)
  IPv4 Interface Address: 10.0.0.1
  Extended IP Reachability: 10.1.0.0/30 (Metric: 17)
  Extended IP Reachability: 10.0.0.1/32 (Metric: 0)
  Extended IP Reachability: 10.1.0.4/30 (Metric: 63)

Like most other vendors, Junos uses transitional IS-IS metrics⁴ by default in 2025 even though the wide metrics were standardized in an RFC in 2004 (more details).

Unlike any other vendor I’ve seen so far, Junos does not complain when you enter metrics larger than 63 on a device still using narrow metrics but silently changes the narrow (IP Reachability) and the wide (Extended IP Reachability) metric to 63. Good job guys!⁵

Anyway, you have to configure wide-metrics-only on level-1 and level-2, and suddenly, everything works as expected.

isis {
    interface ge-0/0/0.0 {
        level 1 metric 17;
        level 2 metric 17;
        point-to-point;
    }
    interface ge-0/0/1.0 {
        level 1 metric 80000;
        level 2 metric 80000;
        point-to-point;
    }
    interface lo0.0;
    level 1 wide-metrics-only;
    level 2 wide-metrics-only;
}