10.5 IS-IS Configuration, Metrics & Troubleshooting

IS-IS Configuration, Metrics & Troubleshooting

Implementing IS-IS in production Junos environments requires adherence to specific protocol prerequisites, understanding metric architectures, and correctly handling inter-level route propagation. Because IS-IS operates directly at Layer 2 within the ISO protocol family, Junos interfaces must be explicitly enabled for ISO processing before link-state communication can begin. This section details end-to-end Junos CLI configuration, modern wide metric deployment, Level 2 to Level 1 route leaking policies, and systematic troubleshooting methodologies.

---

1. Junos Configuration Prerequisites & Step-by-Step Implementation

To activate IS-IS on a Juniper device, four interdependent configuration tasks must be completed in order:

+---------------------------------------------------------------------------------------------------+
| JUNOS IS-IS CONFIGURATION WORKFLOW                                                                |
|                                                                                                   |
| 1. Enable 'family iso' on physical interfaces  Allows processing of Layer 2 LLC/IS-IS frames      |
| 2. Configure NET address on lo0.0              Defines System ID, Area ID, and router identity    |
| 3. Add interfaces under [edit protocols isis]  Enables protocol engine on transit links & lo0     |
| 4. Tune levels and passive interfaces          Disables unneeded levels and suppresses Hellos     |
+---------------------------------------------------------------------------------------------------+

Step 1: Enable family iso on Participating Interfaces

Because Junos interfaces process only explicitly configured protocol families, every physical or logical interface participating in IS-IS—including transit links and the loopback interface—must have family iso enabled:

[edit]
user@vSRX# set interfaces ge-0/0/0 unit 0 family inet address 10.0.12.1/24
user@vSRX# set interfaces ge-0/0/0 unit 0 family iso
user@vSRX# set interfaces ge-0/0/1 unit 0 family inet address 10.0.13.1/24
user@vSRX# set interfaces ge-0/0/1 unit 0 family iso

Step 2: Configure the Network Entity Title (NET) on lo0.0

The router's Network Entity Title (NET) must be configured under unit 0 of the loopback interface (lo0). The NET defines the router's Area ID and 6-octet System ID:

[edit]
user@vSRX# set interfaces lo0 unit 0 family inet address 10.255.0.1/32
user@vSRX# set interfaces lo0 unit 0 family iso address 49.0001.0102.5500.0001.00

Critical Gotcha: If family iso is omitted from lo0.0 or if no NET address is configured, the IS-IS protocol daemon (rpd) cannot establish a System ID or determine its local area. The IS-IS process will completely refuse to start, and no Hellos will be transmitted on any interface.

Step 3: Configure the IS-IS Protocol

Under [edit protocols isis], configure the participating transit interfaces and the loopback interface. The loopback interface should always be set to passive so its prefix is advertised in LSPs without sending unnecessary Hello PDUs:

[edit]
user@vSRX# set protocols isis interface ge-0/0/0.0
user@vSRX# set protocols isis interface ge-0/0/1.0
user@vSRX# set protocols isis interface lo0.0 passive

Step 4: Level Tuning (Restricting Adjacencies)

By default, Junos operates as Level 1 and Level 2 on all interfaces. If an interface connects purely to an internal Level 1 area, Level 2 should be explicitly disabled. Conversely, if an interface connects to the Level 2 backbone, Level 1 should be disabled:

[edit protocols isis]
user@vSRX# set interface ge-0/0/0.0 level 1 disable
user@vSRX# set interface ge-0/0/1.0 level 2 disable

---

2. IS-IS Metric Architectures: Narrow vs. Wide Metrics

Metric design is one of the most critical aspects of IS-IS engineering. The protocol supports two distinct metric encoding formats:

+---------------------------------------------------------------------------------------------------+
| METRIC ENCODING COMPARISON: NARROW VS. WIDE                                                       |
+-----------------------+-----------------------------------+---------------------------------------+
| ATTRIBUTE             | NARROW METRICS (Original ISO)     | WIDE METRICS (RFC 5305)               |
+-----------------------+-----------------------------------+---------------------------------------+
| Interface Metric Size | 6 bits (encoded values 0 to 63)          | 24 bits (0 to 16,777,215 encoded; maximum reserved)     |
| Maximum Path Metric   | 10 bits (Maximum Cost: 1023)      | 32-bit field (reserved limits constrain usable SPF metrics) |
| Default Junos Metric  | Fixed at 10 on all interfaces     | Fixed at 10 on all interfaces         |
| TLVs Utilized         | - TLV 2 (IS Neighbors)            | - TLV 22 (Extended IS Reachability)   |
|                       | - TLV 128 (IP Internal)           | - TLV 135 (Extended IP Reachability)  |
|                       | - TLV 130 (IP External)           |                                       |
| Traffic Engineering   | Unsupported                       | Supported (MPLS TE / RSVP-TE)         |
+-----------------------+-----------------------------------+---------------------------------------+

The Problem with Narrow Metrics

Under legacy narrow metrics, each interface metric is restricted to 6 bits (maximum value of 63), and the cumulative end-to-end path cost cannot exceed 1023. In modern multi-gigabit enterprise backbones, this creates severe scaling constraints: a 100 Gbps interface cannot be given a sufficiently lower cost than a 1 Gbps link without quickly exhausting the 1023 total path limit. Furthermore, narrow TLVs cannot carry sub-TLVs required for MPLS Traffic Engineering.

Migrating to Wide Metrics in Junos

Wide metrics use 24-bit link metrics and 32-bit path metrics, transported via TLV 22 (Extended IS Reachability) and TLV 135 (Extended IP Reachability). To enable wide metrics in Junos OS, configure wide-metrics-only under both levels:

[edit protocols isis]
user@vSRX# set level 1 wide-metrics-only
user@vSRX# set level 2 wide-metrics-only

Operational Gotcha: Metric Transition Incompatibility

Metric encoding affects LSP interpretation rather than Hello adjacency eligibility. A router restricted to legacy-only advertisements can have an Up adjacency yet lack usable topology/prefix information from a wide-only peer. Junos default behavior may advertise or accept more than one encoding, so do not equate “not configured wide-only” with “cannot read wide TLVs.” Inspect actual TLVs on both ends and plan compatible transitions.

3. Inter-Area Route Leaking & Loop Prevention

In standard IS-IS hierarchy, Level 1 areas operate similarly to OSPF Totally Stubby areas. An L1/L2 router does not advertise Level 2 routes down into Level 1. Instead, it sets the Attached (ATT) bit in its Level 1 LSP header. Internal Level 1 routers see the ATT bit and automatically install a default route (0.0.0.0/0) pointing toward the nearest L1/L2 router (based on lowest intra-area L1 metric).

+---------------------------------------------------------------------------------------------------+
| SUBOPTIMAL EXIT ROUTING WITHOUT ROUTE LEAKING                                                     |
|                                                                                                   |
|                            [10.200.0.0/16 Destination in L2]                                      |
|                                     /               \                                             |
|                               (Cost 10)           (Cost 100)                                      |
|                                   /                   \                                           |
|                         [Border R1 (L1/L2)]   [Border R2 (L1/L2)]                                 |
|                                   \                   /                                           |
|                               (Cost 50)           (Cost 5)                                        |
|                                     \               /                                             |
|                                    [Internal Router R3 (L1)]                                      |
|                                                                                                   |
|   Without Leaking: R3 picks R2 because L1 metric to R2 is 5 (vs 50 to R1).                        |
|                    Total Path Cost via R2 = 5 + 100 = 105 (Suboptimal!).                          |
|   With Leaking:    R3 knows R1 offers total cost 60 (50 + 10) vs R2 cost 105. R3 routes via R1.   |
+---------------------------------------------------------------------------------------------------+

Solving Suboptimal Routing with Route Leaking

When multiple L1/L2 routers connect an area to the backbone, default routing can cause suboptimal "tromboning" (as illustrated above). To solve this, specific Level 2 prefixes can be leaked down into Level 1 using a Junos export policy:

[edit policy-options]
user@vSRX# set policy-statement LEAK-L2-TO-L1 term LEAK from level 2
user@vSRX# set policy-statement LEAK-L2-TO-L1 term LEAK from route-filter 10.200.0.0/16 orlonger
user@vSRX# set policy-statement LEAK-L2-TO-L1 term LEAK then to level 1
user@vSRX# set policy-statement LEAK-L2-TO-L1 term LEAK then accept

[edit protocols isis]
user@vSRX# set export LEAK-L2-TO-L1

Loop Prevention: The Up/Down Bit

When an L1/L2 router leaks an L2 route into Level 1, what prevents another L1/L2 router in the same area from picking up that L1 route and advertising it back into Level 2, creating an infinite routing loop? RFC 5305 solves this through the Up/Down bit (the high-order flag in the prefix-control octet following the metric in TLV 135):

• When a route is originated in Level 1 or advertised from Level 1 up into Level 2, the bit is clear, 0 (Up).
• When an L1/L2 router leaks a route from Level 2 down into Level 1, it sets the bit to 1 (Down).
• Any L1/L2 router that receives an LSP with the Up/Down bit set to Down will never re-advertise that route back into Level 2. This permanently breaks the feedback loop.

---

4. Junos IS-IS Verification & Troubleshooting

Junos provides an extensive suite of operational commands to verify adjacencies, inspect the LSDB, and troubleshoot control-plane failures.

Verifying Adjacencies: show isis adjacency

user@vSRX> show isis adjacency
Interface             System         L State        Hold (secs) SNPA
ge-0/0/0.0            vSRX-Core2     2 Up                    27 00:05:86:71:0b:00
ge-0/0/1.0            vSRX-Branch1   1 Up                     8 00:05:86:71:0b:01

• Interface: Local logical interface.
• System: Hostname or System ID of the adjacent neighbor.
• L: Operational level of the adjacency (1, 2, or both).
• State: Must be Up. If stuck in Init, check for unidirectional traffic or Hello padding/MTU drops.
• Hold (secs): Countdown timer reset by incoming Hello packets.
• SNPA: Subnetwork Point of Attachment (MAC address on Ethernet).

Inspecting the Link-State Database: show isis database detail

user@vSRX> show isis database detail
IS-IS level 1 link-state database:
vSRX-Branch1.00-00 Sequence: 0x4, Checksum: 0x8a31, Lifetime: 1142 secs
   IP prefix: 10.255.0.3/32                     metric 10
   IS neighbor: vSRX-Core1.01                   metric 10
   IP extended prefix: 10.200.0.0/16            metric 10 up/down

IS-IS level 2 link-state database:
vSRX-Core1.00-00 Sequence: 0x8, Checksum: 0x4192, Lifetime: 1198 secs
   IP prefix: 10.255.0.1/32                     metric 10
   IS extended neighbor: vSRX-Core2.00          metric 10

• Notice IP extended prefix and IS extended neighbor: These indicate that wide metrics (TLVs 135 and 22) are active.
• The up/down keyword verifies that the prefix has the Up/Down bit set for loop prevention.

Mapping System IDs: show isis hostname

By default, IS-IS identifies routers by hexadecimal System IDs (e.g., 1921.6800.0001). Junos supports the Dynamic Hostname Exchange mechanism (RFC 5301, TLV 137), allowing routers to automatically map System IDs to human-readable hostnames:

user@vSRX> show isis hostname
System id                  Hostname             Type
0102.5500.0001             vSRX-Core1           Dynamic
0102.5500.0002             vSRX-Core2           Dynamic
0102.5500.0003             vSRX-Branch1         Dynamic

---

5. Troubleshooting Matrix & Common Failure Modes

Output note: Command output shown here is a schematic teaching example, not a captured device session. Field names and feature support depend on platform and Junos release.

Policy and Bounded Diagnostic Workflow

IS-IS export policy redistributes selected active routes into LSPs. An import policy instead controls local route installation; it does not prevent the received LSP from being flooded or change another router’s database. Match the source protocol and exact destination set, then use explicit accept/reject decisions. For inter-level leaking, match from level 2, select then to level 1, and verify the Down flag in Level 1 reachability.

Use ping and traceroute to the learned prefix to distinguish protocol success from data forwarding. Compare show isis adjacency detail, show isis interface detail, show isis database detail, show route protocol isis, and forwarding-table output. If these do not explain the fault, configure a bounded file under protocols isis traceoptions, select only relevant flags supported by that release, and correlate it with show log messages. Tracing has CPU/disk cost; disable it after collecting the needed evidence. An Up adjacency does not prove route policy accepted a prefix, and a visible LSP does not prove its route won in the RIB.

Official protocol reference checked 2026-10-18: RFC 5305, Extended IP Reachability and the Up/Down bit.

The metric field’s representable maximum is not a promise of a usable transit cost: RFC 5305 reserves the maximum extended link value to exclude a link from ordinary SPF, and bounds supported path calculation. Use the documented metric range for the intended purpose rather than configuring the largest integer simply because it fits the field.