Nokia SR OS IS-IS Configuration with the MD-CLI

IS-IS is the interior gateway protocol of choice in most service provider and large data centre fabrics, and on Nokia SR OS it is configured through the model-driven CLI with a strict hierarchy: /configure router "Base" isis 0. That hierarchy trips up engineers arriving from Junos or IOS, because almost nothing is configured at the global level — network entity title, level capability, and interface parameters each live in their own context, and the interface must be bound to the IS-IS instance explicitly. This guide walks through a complete SR OS IS-IS configuration with MD-CLI, including the level and route leaking decisions that most often cause unexpected behaviour.

Router Levels and the NET

SR OS supports Level 1, Level 2, and Level 1/2 routers, and the default level capability is level-1/2. That default means a router will form both L1 and L2 adjacencies unless you change it, which is rarely what a leaf-spine fabric wants. To make a router strictly Level 2, you must explicitly change the level capability at the global level or per interface; there is no implicit demotion.

The network entity title (NET) is the IS-IS equivalent of a router ID and is mandatory. It is written as an area address followed by a system ID and the NSEL byte, which is always 00:

49.0011.2181.1201.4005.00

Read it as: area 49.0011, system ID 2181.1201.4005, NSEL 00. The system ID must be unique per router and identical in length across the domain — this is off by one character more often than any other typo in IS-IS.

Step 1 - Enable the IS-IS Instance

A:admin@PE1# configure router "Base" isis 0
A:admin@PE1>config>router>isis# admin-state enable
A:admin@PE1>config>router>isis# level-capability level-2
A:admin@PE1>config>router>isis# area-address [49.0011]
A:admin@PE1>config>router>isis# system-id 2181.1201.4005

If the router must also carry an IPv4 router ID for BGP next-hop resolution, set it under the router rather than under IS-IS:

A:admin@PE1# configure router "Base" router-id 10.0.0.1

Step 2 - Attach and Tune Interfaces

Each IS-IS interface is configured under its own context, then bound to the instance. The interface context is where timers, metrics, and per-interface level capability live:

A:admin@PE1# configure router "Base" interface "to-P2" port 1/1/1:100
A:admin@PE1# configure router "Base" interface "to-P2" ipv4 primary address 10.0.0.1 prefix-length 30
A:admin@PE1>config>router>if# isis 0 interface-type point-to-point
A:admin@PE1>config>router>if>isis# admin-state enable
A:admin@PE1>config>router>if>isis# level 2
A:admin@PE1>config>router>if>isis# metric 100
A:admin@PE1>config>router>if>isis# hello-interval 3
A:admin@PE1>config>router>if>isis# hello-multiplier 3

Point-to-point interface type is important on fabric links: it makes SR OS form a two-way adjacency immediately instead of running the LAN designated-IS election, which removes a whole class of intermittent adjacency problems. Hello interval 3 with multiplier 3 gives a 9 second hold time — a reasonable middle ground between convergence speed and stability.

Enable BFD where fast failure detection is required, since IS-IS hello timers alone cannot get you below a few hundred milliseconds safely:

A:admin@PE1>config>router>if>isis# bfd-liveness true

Step 3 - Wide Metrics, MTU, and Timers

The old narrow metric style caps link cost at 63 and cannot express modern fabric costs. Enable wide metrics at the global level:

A:admin@PE1>config>router>isis# wide-metrics-only true
A:admin@PE1>config>router>isis# transport lsp-mtu-size 1492

SR OS lets you tune SPF and LSP generation behaviour so that a burst of topology changes does not cause repeated full SPF runs. The defaults are usually adequate, but on a large fabric the sensible shape is a short initial wait with a bounded maximum:

A:admin@PE1>config>router>isis# spf initial-wait 1000 second-wait 1000 max-wait 10000
A:admin@PE1>config>router>isis# lsp-generation initial-wait 1000 second-wait 1000 max-wait 5000

Step 4 - Route Leaking Between Levels

In a two-level domain, Level 1 routers learn only their own area plus a default route from the nearest L2-attached router. Nokia implements route leaking per RFC 2966, so specific inter-area prefixes can be redistributed into Level 1 when a default route is not acceptable:

A:admin@PE1>config>router>isis# inter-level-propagation-policies level1-to-level2

Use leaking sparingly. Every leaked prefix adds L1 LSP content that must be flooded within the area, and a fabric that leaks hundreds of prefixes is usually a design that should have been flat Level 2 to begin with.

Verification

SR OS operational commands are grouped under show router isis. Work through them from the outside in:

A:admin@PE1# show router isis adjacency
A:admin@PE1# show router isis adjacency detail
A:admin@PE1# show router isis interface "to-P2"
A:admin@PE1# show router isis database
A:admin@PE1# show router isis status
A:admin@PE1# show router route-table protocol isis
A:admin@PE1# show router isis statistics

Reading the adjacency state

Start with show router isis adjacency. If the expected neighbour is missing, check at the interface level: level mismatches (interface at level 1, remote at level 2), authentication mismatches, and MTU mismatches are the three causes that account for nearly every case. The detail variant shows the hold time remaining and the last state change, which tells you whether the adjacency is flapping rather than simply absent.

Adjacencies up but no routes

If adjacencies are up but routes are missing, look at the database and then the route table. An empty route table with a full database usually means the prefix is not in an LSP being flooded to you, or an export policy is blocking redistribution of the connected prefix.

Operational Notes

• Set the level capability explicitly — the default level-1/2 will form adjacencies you did not intend.
• Use point-to-point interface type on fabric links to skip designated-IS election entirely.
• Enable wide metrics before assigning any metric above 63.
• Keep the system ID length identical across every router in the domain.
• SR OS configuration is committed declaratively: use compare before commit so a mistyped interface is caught before it takes effect.

Related reading: our Nokia SR OS MD-CLI commit workflow guide, the SR-MPLS versus SRv6 comparison, and the TI-LFA fast reroute configuration article.

原文链接：https://infocenter.nokia.com/public/7750SR212R1A/topic/com.sr.unicast/html/isis_config.html