The Thinking Network (Installment 5): IS-IS Routing & The Network Underlay

Architecture Overview: Phase 5 (The Underlay)

• Objective: Establish the foundational routing underlay required for upper-level autonomous control.
• Core Technologies: IS-IS (Intermediate System to Intermediate System), Link-State Routing Protocols, Nokia SR Linux.
• The Goal: Establish IS-IS adjacencies and distribute loopback reachability across all four nodes, providing the stable underlay that BGP sessions and EVPN services depend on.

The Underlay

The containers are running. The NOS has finished initializing. The diamond fabric exists as a physical fact - four routers, eight virtual links, a management network, a telemetry stack.

None of it can route a packet yet.

The routers know their own addresses. They do not know how to reach each other. A packet leaving srl1 destined for srl4 has no path. Not because the physical connection is missing - the links exist. Because the network has not yet learned its own shape.

IS-IS is how it learns.

What IS-IS Is

IS-IS (Intermediate System to Intermediate System) is a link-state routing protocol. It has been running carrier backbone networks since the 1980s and still operates under a significant portion of the internet core today. It is one of the oldest and most resilient routing protocols in existence.

The way it works is essentially a conversation. Each router tells its neighbors what it can see. Those neighbors tell their neighbors. The information floods through the network until every router has a complete picture of the whole topology. That picture is the link-state database.

From that shared database, each router independently runs Dijkstra's algorithm to calculate the shortest path to every other node. It is not magic. It is just math.

Imagine the network from the perspective of srl1 trying to reach srl4. srl1 looks at its map and evaluates the cost of every possible path. Path A goes through srl2. The link to srl2 has a metric cost of 10, and the next hop to srl4 costs 10, making the total cost 20. Path B goes through srl3. It also consists of two 10-cost links, totaling 20.

Dijkstra's algorithm strictly selects the lowest number. In our diamond fabric, both paths cost exactly 20. Because there is a mathematical tie, IS-IS does exactly what modern routing protocols are designed to do. It installs both paths into the routing table and enables Equal-Cost Multi-Path (ECMP) routing. Traffic splits evenly across both sides of the diamond.

The Blind Spot and the AI Objective

This distributed, mathematical intelligence is what makes IS-IS incredibly resilient. Every node calculates its own table from the same shared information. If a physical link fails, the routers immediately detect the loss, flood updated information and recalculate. Convergence happens in seconds without any human intervention.

Dijkstra only understands static link metrics. It is completely blind to real-time network performance. If Path A starts experiencing microbursts, buffer bloat, or rising latency, IS-IS does not care. As long as the physical link remains up, the metric cost remains 20. The protocol will happily continue sending fifty percent of your traffic straight into a degraded path.

To overcome this, the AI layer sits above the base routing protocol. The AI does not need to manage basic connectivity or physical link failures because IS-IS handles that perfectly. Instead, it monitors telemetry, predicts latency degradation before it causes a service impact, and forcefully steers traffic away from the impacted path by manipulating the BGP overlay.

IS-IS provides the stable, self-healing foundation. The AI provides the intelligence to override the math when the math is no longer enough.

What IS-IS Does Not Do

IS-IS routes within a single administrative domain. It knows the shape of this network - these four nodes, these eight links. It does not carry service routes. It does not carry VPN information. It does not distribute BGP prefixes.

That is BGP's job. But BGP sessions in this lab use loopback IP addresses as their source - which means BGP cannot form until IS-IS has distributed those loopbacks across the network. IS-IS is the foundation BGP stands on.

Configuring IS-IS by Hand

If there were no automation in this lab - no Python scripts, no startup configs - this is what you would type into each node's CLI to bring IS-IS up.

SR Linux uses a candidate/commit model. Changes are staged and then committed atomically. Nothing takes effect until you commit.

srl1:

--{ candidate }--[ ]--
A:srl1# set / network-instance default protocols isis instance 1 admin-state enable
A:srl1# set / network-instance default protocols isis instance 1 net [ 49.0001.0000.0000.0001.00 ]
A:srl1# set / network-instance default protocols isis instance 1 level-capability L2
A:srl1# set / network-instance default protocols isis instance 1 interface system0.0 passive true ipv4-unicast admin-state enable
A:srl1# set / network-instance default protocols isis instance 1 interface ethernet-1/1.0 circuit-type point-to-point ipv4-unicast admin-state enable
A:srl1# set / network-instance default protocols isis instance 1 interface ethernet-1/2.0 circuit-type point-to-point ipv4-unicast admin-state enable
A:srl1# commit stay

srl2:

A:srl2# set / network-instance default protocols isis instance 1 admin-state enable
A:srl2# set / network-instance default protocols isis instance 1 net [ 49.0001.0000.0000.0002.00 ]
A:srl2# set / network-instance default protocols isis instance 1 level-capability L2
A:srl2# set / network-instance default protocols isis instance 1 interface system0.0 passive true ipv4-unicast admin-state enable
A:srl2# set / network-instance default protocols isis instance 1 interface ethernet-1/1.0 circuit-type point-to-point ipv4-unicast admin-state enable
A:srl2# set / network-instance default protocols isis instance 1 interface ethernet-1/2.0 circuit-type point-to-point ipv4-unicast admin-state enable
A:srl2# commit stay

srl3:

A:srl3# set / network-instance default protocols isis instance 1 admin-state enable
A:srl3# set / network-instance default protocols isis instance 1 net [ 49.0001.0000.0000.0003.00 ]
A:srl3# set / network-instance default protocols isis instance 1 level-capability L2
A:srl3# set / network-instance default protocols isis instance 1 interface system0.0 passive true ipv4-unicast admin-state enable
A:srl3# set / network-instance default protocols isis instance 1 interface ethernet-1/1.0 circuit-type point-to-point ipv4-unicast admin-state enable
A:srl3# set / network-instance default protocols isis instance 1 interface ethernet-1/2.0 circuit-type point-to-point ipv4-unicast admin-state enable
A:srl3# commit stay

srl4:

A:srl4# set / network-instance default protocols isis instance 1 admin-state enable
A:srl4# set / network-instance default protocols isis instance 1 net [ 49.0001.0000.0000.0004.00 ]
A:srl4# set / network-instance default protocols isis instance 1 level-capability L2
A:srl4# set / network-instance default protocols isis instance 1 interface system0.0 passive true ipv4-unicast admin-state enable
A:srl4# set / network-instance default protocols isis instance 1 interface ethernet-1/1.0 circuit-type point-to-point ipv4-unicast admin-state enable
A:srl4# set / network-instance default protocols isis instance 1 interface ethernet-1/2.0 circuit-type point-to-point ipv4-unicast admin-state enable
A:srl4# commit stay

Four nodes. Seven commands each. One value changing between them.

The NET ID - Network Entity Title - encodes each node's identity. 49.0001.0000.0000.0001.00 means area 49.0001, system ID 0000.0000.0001. The system ID derives from the site ID using the same pattern the Python script uses. Site 1 is 0000.0000.0001. Site 4 is 0000.0000.0004. Consistent and never ambiguous.

level-capability L2 configures Level 2 routing only - backbone behavior. There are no Level 1 areas in this lab.

passive true on system0.0 means IS-IS advertises that loopback address into the domain but does not try to form adjacencies on it. The loopback is a destination, not a link.

circuit-type point-to-point on the ethernet interfaces - two routers, one wire. No DR/BDR election. Clean.

What the Startup Config Does Instead

The Python script generates these commands into a .cfg file for each node at Phase 2. When ContainerLab deploys the container at Phase 3, SR Linux loads that file at boot. IS-IS starts configured, without any manual input.

The NET ID generation in the script:

net_id = f"49.0001.0000.0000.000{sid}.00"

Site 1 produces 49.0001.0000.0000.0001.00. Site 4 produces 49.0001.0000.0000.0004.00. The rest of the IS-IS configuration is identical across all four nodes. The script writes it once and applies it four times with the correct site-specific values substituted.

Verification

After the nodes initialize:

docker exec clab-nbl-diamond-v1-srl1 sr_cli \
  -c "show network-instance default protocols isis adjacency"

+----------------+--------------------+-------+---------------+-------+
| Interface Name | Neighbor System Id | Level |  Ip Address   | State |
+================+====================+=======+===============+=======+
| ethernet-1/1.0 | 0000.0000.0002     | L2    | 172.254.254.2 | up    |
| ethernet-1/2.0 | 0000.0000.0003     | L2    | 172.254.254.6 | up    |
+----------------+--------------------+---------+-------------+-------+
Adjacency Count: 2

srl1 sees srl2 on ethernet-1/1 and srl3 on ethernet-1/2. Both Level 2. Both up.

The route table shows what IS-IS has learned:

Prefix               Route Type   Metric   Next-Hop(s)
172.2.255.255/32     isis         10       172.254.254.2(ethernet-1/1.0)
172.3.255.255/32     isis         10       172.254.254.6(ethernet-1/2.0)
172.4.255.255/32     isis         20       172.254.254.2(ethernet-1/1.0)

srl1 knows where every other loopback is. The path to srl4 goes through srl2 - Path A, metric 20, two hops. The network has learned its own shape.

The IS-IS database:

| 2 | 0000.0000.0001.00-00 | 8 | 1165 |
| 2 | 0000.0000.0002.00-00 | 7 | 588  |
| 2 | 0000.0000.0003.00-00 | 8 | 1114 |
| 2 | 0000.0000.0004.00-00 | 7 | 1068 |
LSP Count: 4

Four LSPs. One per node. The topology has been flooded. Every router holds the same database.

Why This Matters for the AI Layer

The AI layer does not touch IS-IS. It never modifies IS-IS configuration. IS-IS runs, converges, and maintains itself without any instruction from the intelligence layer above it.

What IS-IS gives the AI is a stable, self-healing foundation. Link fails - IS-IS reroutes. Node recovers - IS-IS re-converges. The AI does not manage these events. It assumes the underlay is working and focuses on the BGP control plane, which is the actual lever it pulls when it needs to steer traffic.

IS-IS is not the interesting part of this series. It is the necessary part. The next installment builds the layer the AI will actually reach into.

Next installment: The Overlay. BGP forms a full mesh across the underlay. The control plane is complete. The AI's lever is installed.