Wide-Metric Migration Across a Two-Vendor Area
A nationwide network has 60 IS-IS Level 2 routers: 30 Nokia SR OS and 30 from another vendor. It has run narrow metrics since deployment, with a maximum link metric of 63. New 400G links must be preferred over existing 100G links by a ratio of 4:1, and the design also wants traffic-engineering metrics. The team enables wide metrics on three pilot Nokia routers with wide-metrics-only, leaving the other 57 unchanged. Adjacencies remain up, but routers throughout the network lose several prefixes reachable through the pilot routers, and some traffic detours via a pair of older 10G links. The pilot routers still show all prefixes in their own databases. The other vendor supports wide metrics but requires an explicit transition setting. The change window is four hours, and the customer allows no more than one brief reconvergence.
1. Why do adjacencies stay up while routes through the pilot routers disappear?
Read the worked answer
IS-IS adjacency formation depends on level, authentication, and hello parameters, not on metric style. With wide-metrics-only, the pilot routers advertise only wide metric TLVs (22 and 135) and stop sending narrow TLVs (2 and 128). A neighbor still running narrow-only cannot derive a metric for those links; it either ignores the wide TLVs or treats the adjacency as unusable for SPF, so prefixes whose only path is through a pilot router are not installed. The reverse direction can still work because a wide-capable router understands narrow TLVs, which explains asymmetric reachability. The pilot routers see everything because they can parse both formats. This is a classic transition mistake: wide-only should be the last step, not the first.
2. Give the migration sequence, including the other vendor, and the checkpoints that fit a four-hour window.
Read the worked answer
First, put every router into a transition state that advertises both narrow and wide metrics. On SR OS, leave wide-metrics-only disabled and enable wide metric support; on the other vendor, enable its explicit transition setting. Verify that each adjacency still forms and that routes are present with the old metrics, and spot-check the LSDB to confirm both 2/128 and 22/135 are present. Second, set the new wide metric values (for example 10 on 400G and 40 on 100G) and verify path selection while narrow metrics still exist as a fallback. Third, enable wide-only in waves, starting with the pilot routers and then groups of 10, checking route counts and traceroutes after each wave. Because only the final removal of narrow TLVs changes the metric, the reconvergence should be brief and limited to the wave. Keep a tested rollback per wave.
3. Once wide metrics are active, what values would you use for the 400G and 100G links, and what else must be consistent?
Read the worked answer
Wide metrics are 24-bit, so there is ample room. To get a 4:1 preference, use 10 for 400G and 40 for 100G; avoid 1 and 4 so that future 800G or 1.6T links can take 5 and 2 or 3 without renumbering. Set the metric symmetrically in both directions on each interface, because IS-IS metrics are per-interface and a mismatch creates asymmetric paths. Keep the metric style and values consistent within the Level 2 area, and remember that traffic-engineering metrics are separate from the IS-IS metric; do not expect the TE metric to influence normal SPF. Verify with show router isis interface and the route table that the 400G path is chosen, and check that any static or policy-based metric overrides do not distort the 4:1 ratio.