Partial Wide-Metrics Deployment Breaks Narrow-Only Edge Reachability
An ISP backbone has core routers A and B and edge routers C and D. A connects to B over 10 Gbps, B connects to D over 10 Gbps, and A connects to D directly over 1 Gbps. C is an edge router connected to A and D over 1 Gbps links. All links are IS-IS level 2 and initially use narrow metrics with default metric 10 on every interface. The provider enables wide metrics on A and B and configures wide-metrics-only on their level-2 IS-IS instances. C and D remain narrow-only. Within one SPF cycle, C loses all prefixes reachable only through the core. C's adjacency to A is still Up, and C still receives A's LSPs, but C's route table no longer contains the core prefixes. D still has its directly connected and narrow-reachable prefixes. The provider wants a safe migration to wide metrics without another outage.
1. Explain why the adjacency remains Up while C loses the core prefixes. Include the relevant IS-IS TLV behavior.
Read the worked answer
The adjacency remains Up because IIH exchange is independent of metric style. A and B still send valid hellos, and C still forms an adjacency. The problem is in the LSP payload. With wide-metrics-only, A and B stop advertising the narrow metric TLVs, specifically the narrow IS neighbor and IP reachability information, and advertise only wide metric TLVs such as extended IS reachability and extended IP reachability. C is narrow-only, so it ignores the wide TLVs. C may still see the node identities if any narrow TLVs remain, but it cannot compute a path through A or B to the prefixes behind them. The prefixes are not marked unreachable; they simply never enter C's SPF calculation. This is why the route table is missing entries rather than showing a reject or a down adjacency. The failure is a metric-style interoperability problem, not a link or hello problem.
2. What migration sequence should have been used, and what SR OS configuration steps would you follow now to restore reachability and then move the whole backbone to wide metrics?
Read the worked answer
Never enable wide-metrics-only on a subset of routers. The safe sequence is to enable wide metric support on every router while still advertising narrow metrics, so each LSP carries both styles. Verify that every router can decode the wide TLVs and that paths are stable. Only then remove narrow metrics from all routers, ideally one maintenance window at a time with verification after each step. To recover now, first remove wide-metrics-only from A and B so they advertise narrow metrics again. On SR OS this means changing the level-2 metric style from wide-only back to a style that includes narrow metrics, then clearing the IS-IS adjacencies or waiting for LSP refresh. Confirm that C has the core prefixes again. Next, enable wide metrics on C and D without the only keyword, verify full reachability, and then set wide-metrics-only on all four routers. Before the final step, assign meaningful wide metric values to every interface, because wide metrics are not automatic bandwidth calculations. After the change, check that C's route to D's loopback prefers the intended 10 Gbps path rather than the direct 1 Gbps link.
3. Which verification commands and TLV checks would you use to confirm that every router is using the same metric style?
Read the worked answer
Use show router isis interface "<intf>" detail to see the configured metric style and interface metric on each router. Use show router isis database detail on C and inspect A's and B's LSPs: a wide-only LSP contains extended reachability TLVs but lacks the narrow IP reachability TLVs, while a dual-style LSP contains both. Confirm that C's LSP also contains the expected TLVs after it is migrated. Check show router isis routes and show router route-table on C for the core prefixes before and after each change. show router isis spf-log shows whether SPF is running and whether the topology is changing unexpectedly. If a router supports both styles, verify that its LSPs carry both narrow and wide information during the transition. Do not accept an adjacency Up state as proof of reachability; the LSP TLV check is the definitive test that all routers can interpret the same metric information.