Troubleshooting IS-IS Routing for Carrier Network Backbones: Configuration, Compatibility & Error Resolving

Overview & Thematic Scope

IS-IS remains the interior gateway protocol of choice for tier-1 carrier backbones and large-scale service provider networks due to its protocol-agnostic design, hierarchical scalability, and resilience under churn. This troubleshooting-focused FAQ addresses the most common configuration pitfalls, compatibility considerations, and error-resolution workflows that network engineers encounter when deploying or maintaining IS-IS in carrier backbone environments.

Frequently Asked Questions

Q1: What is the correct NET address format for a carrier backbone IS-IS router, and how do I avoid System ID collisions?

The NET (Network Entity Title) must follow the format Area ID + System ID + NSEL (00), with the System ID being exactly 6 bytes and globally unique within the IS-IS domain. For carrier backbones, a common practice is to derive the System ID from the router’s Loopback0 IPv4 address padded to 12 hex digits (e.g., loopback 10.0.0.1 becomes System ID 0100.0000.0001), while the Area ID uses the private AFI 49 followed by a structured area number such as 0001. A typical complete NET for a backbone router looks like 49.0001.0100.0000.0001.00. Collisions occur when two routers share the same 6-byte System ID; since IS-IS does not automatically detect this in all cases, you must audit NET assignments during provisioning and after any loopback renumbering.

Q2: Should carrier backbone interfaces be configured as Level-1, Level-2, or Level-1-2, and what causes adjacency formation to fail between levels?

Carrier backbone core links should be configured as Level-2 only, while edge-facing interfaces may use Level-1-2 if connecting to a non-backbone area. IS-IS adjacency formation fails when the configured levels are incompatible—a Level-1-only router cannot form an adjacency with a Level-2-only router, and Level-1 adjacencies additionally require matching Area IDs. For backbone stability, explicitly set is-type level-2-only on core routers and disable Level-1 processing on backbone interfaces. If adjacencies remain stuck in Init state, verify that hello padding, authentication credentials, and network type (broadcast vs. point-to-point) match on both sides.

Q3: Why must I enable wide metrics on carrier backbone IS-IS interfaces, and what breaks if I leave narrow metrics enabled?

Wide metrics (32-bit) must be enabled on all carrier backbone IS-IS interfaces because narrow metrics (6-bit, max 63) cannot support Traffic Engineering, Segment Routing, or modern high-bandwidth link cost differentiation. Without wide metrics, you lose the ability to advertise TE extensions, Flex-Algo link attributes, and adjacency SIDs required for SR-MPLS. Configuration varies by vendor: on Cisco IOS XR use metric-style wide under the IS-IS address-family; on Junos apply level 2 wide-metrics-only under the IS-IS instance. If you migrate an existing narrow-metric backbone to wide metrics, ensure all routers in the Level-2 domain support the change simultaneously to avoid metric interpretation mismatches.

Q4: How do I troubleshoot IS-IS adjacency flaps on point-to-point backbone links?

Adjacency flaps on backbone P2P links most commonly stem from hello timer mismatches, MTU discrepancies, or one-way link failures that IS-IS hellos cannot detect quickly. Verify hello intervals and multipliers match on both sides (default hello 10s, hold 30s for P2P), and confirm that interface MTU is consistent—IS-IS does not fragment its PDUs, so an MTU mismatch will silently drop LSPs even after adjacency forms. Enable Bidirectional Forwarding Detection (BFD) with aggressive timers (e.g., 300ms interval × 3 multiplier) to detect sub-second link degradation before IS-IS hold timers expire, and check interface error counters for physical-layer CRC or input errors that cause intermittent hello loss.

Q5: What is the correct order of operations for integrating Segment Routing into an existing IS-IS backbone without causing traffic disruption?

Enable Segment Routing under IS-IS only after wide metrics are confirmed operational on all backbone interfaces and Loopback0 is reachable via the IGP. The sequence is: (1) verify metric-style wide is active; (2) assign a unique SRGB (Segment Routing Global Block) that does not overlap with any existing MPLS label ranges; (3) configure the node SID index on Loopback0 under the IS-IS instance; (4) enable SR-MPLS globally; (5) verify prefix SIDs are advertised in LSPs via show isis database detail. Do not enable SR-TE policies or Flex-Algo until all nodes confirm consistent SID advertisements—partial SR deployment can cause forwarding loops when some routers impose labels and others do not.

Q6: How can I accelerate IS-IS convergence in a carrier backbone without causing microloops during reconvergence?

Use IS-IS fast convergence features including LSP generation timers, PRC (Partial Route Calculation) interval tuning, and specifically microloop avoidance with post-convergence path delay. On modern platforms, enable spf-options microloop-avoidance post-convergence-path delay 5000 (5 seconds) so that routers temporarily forward traffic along the pre-failure path while SPF converges, preventing transient loops that cause packet loss during reconvergence. Combine this with BFD-triggered fast detection and TI-LFA (Topology Independent Loop-Free Alternate) where Segment Routing is deployed to achieve sub-50ms protection on primary backbone links.

Q7: What IS-IS authentication method should I use to secure backbone adjacencies, and how do I migrate from plaintext to cryptographic authentication without an outage?

Use HMAC-SHA-256 cryptographic authentication for both Level-1 and Level-2 IIH (hello) PDUs and LSPs on all backbone interfaces. Plaintext authentication is trivially spoofable and should never be used on carrier infrastructure. To migrate without dropping adjacencies, configure the new authentication key as an additional valid key on all routers first, verify that all adjacencies remain up and authenticated with the new key, then remove the old plaintext or weaker key from all nodes. On Cisco IOS XR, use interface … address-family … authentication key-chain … hmac-sha-256; on Junos, apply authentication-type hmac-sha-256 and authentication-key-chain under the IS-IS interface level.

Q8: How do I verify that IS-IS is correctly advertising Loopback prefixes and Segment Routing SIDs after a configuration change?

After any Loopback or SR configuration change, verify SID advertisement by examining the local LSP for the relevant TLV entries. On Cisco IOS XR, run show isis database verbose | include SID or show isis segment-routing prefix-sid; on Junos, use show isis database extensive | match “SRGB|Prefix-SID”; on FRRouting, use show isis database detail and look for the Extended IP Reachability TLV with SID sub-TLV. If the Loopback prefix appears without a SID, confirm that segment-routing mpls is enabled under the IS-IS instance, that the SRGB is configured, and that the Loopback interface is not marked passive if your platform requires active participation for SID advertisement.