Hands-On Lab: Configuring Basic IS-IS Routing

This hands-on lab configures IS-IS between three routers using a single-area Level 2 design, verifying adjacencies form, routes are exchanged, and comparing IS-IS's NET addressing and terminology against the OSPF configuration approach covered earlier in this series.

IS-IS ConfigurationNET AddressingLevel 2 Adjacency

~4 min read · Updated Sep 26, 2026

Lab Objective

Configure IS-IS on three routers using NET addresses and Level 2 routing, verify adjacencies form correctly, confirm routes propagate across the topology, and compare the configuration approach and terminology against OSPF, covered extensively earlier in this series.

Lab Purpose

IS-IS, unlike OSPF, was not derived from an IP-native design — it originated as an OSI protocol adapted to route IP, which shows up directly in its NET addressing scheme and terminology (Level 1/Level 2 instead of areas, System ID instead of Router ID). Despite these differences, it accomplishes the same link-state routing goals as OSPF and remains common in large service provider networks.

Lab Topology

R1 ---- Serial0/0/0 ---- R2 ---- Serial0/0/1 ---- R3

R1: 10.10.10.1/30, LAN 192.168.11.0/24
R2: 10.10.10.2/30 and 10.20.20.1/30
R3: 10.20.20.2/30, LAN 192.168.13.0/24

NET addresses:
R1: 49.0001.0000.0000.0001.00
R2: 49.0001.0000.0000.0002.00
R3: 49.0001.0000.0000.0003.00

Task 1: Configure Basic Addressing

Configure all interfaces shown, including each router's LAN.

Task 2: Enable IS-IS and Configure the NET Address

Enable IS-IS on all three routers, assigning each its own NET address.

Task 3: Enable IS-IS on the Relevant Interfaces

Activate IS-IS directly on each router's interfaces, similar in structure to how OSPFv3 was activated per-interface earlier in this series.

Task 4: Verify IS-IS Adjacencies

Confirm neighbor relationships form between R1-R2 and R2-R3.

Task 5: Verify Route Exchange

Confirm R1 learns R3's LAN and vice versa, despite no direct connection between them.

Solution and Verification

R1(config)# interface serial0/0/0
R1(config-if)# ip address 10.10.10.1 255.255.255.252
R1(config-if)# no shutdown
R1(config-if)# exit
R1(config)# interface gigabitethernet0/0
R1(config-if)# ip address 192.168.11.1 255.255.255.0
R1(config-if)# no shutdown

R2(config)# interface serial0/0/0
R2(config-if)# ip address 10.10.10.2 255.255.255.252
R2(config-if)# clock rate 64000
R2(config-if)# no shutdown
R2(config-if)# exit
R2(config)# interface serial0/0/1
R2(config-if)# ip address 10.20.20.1 255.255.255.252
R2(config-if)# clock rate 64000
R2(config-if)# no shutdown

R3(config)# interface serial0/0/1
R3(config-if)# ip address 10.20.20.2 255.255.255.252
R3(config-if)# no shutdown
R3(config-if)# exit
R3(config)# interface gigabitethernet0/0
R3(config-if)# ip address 192.168.13.1 255.255.255.0
R3(config-if)# no shutdown

R1(config)# router isis
R1(config-router)# net 49.0001.0000.0000.0001.00

-- The NET's structure: 49 (area, private
-- addressing convention similar to RFC
-- 1918 for IP) . 0001 (area ID) .
-- 0000.0000.0001 (System ID, analogous to
-- OSPF's Router ID but 6 bytes) . 00
-- (NSEL, always 00 for a router)

R2(config)# router isis
R2(config-router)# net 49.0001.0000.0000.0002.00

R3(config)# router isis
R3(config-router)# net 49.0001.0000.0000.0003.00

R1(config)# interface serial0/0/0
R1(config-if)# ip router isis
R1(config-if)# exit
R1(config)# interface gigabitethernet0/0
R1(config-if)# ip router isis

-- Like OSPFv3's per-interface activation
-- covered earlier in this series, IS-IS
-- uses "ip router isis" directly on each
-- interface rather than a network
-- statement inside router configuration
-- mode

R2(config)# interface serial0/0/0
R2(config-if)# ip router isis
R2(config-if)# exit
R2(config)# interface serial0/0/1
R2(config-if)# ip router isis

R3(config)# interface serial0/0/1
R3(config-if)# ip router isis
R3(config-if)# exit
R3(config)# interface gigabitethernet0/0
R3(config-if)# ip router isis

R1# show clns neighbors

System Id      Interface   State  Type  Holdtime
0000.0000.0002 Se0/0/0     Up     L2     27
-- Neighbor identified by System ID rather
-- than an IP-based Router ID, and shown
-- as Level 2 (L2) since this lab uses a
-- single-area design

R1# show ip route isis

i L2  192.168.13.0/24 [115/20] via 10.10.10.2, Serial0/0/0
-- R1 learned R3's LAN, prefixed with "i"
-- for IS-IS (analogous to OSPF's "O") and
-- "L2" indicating a Level 2 route, with
-- administrative distance 115

Key Takeaway

IS-IS's NET address and System ID replace OSPF's Router ID conceptually but with a fundamentally different, OSI-derived format — despite this surface-level unfamiliarity, the underlying link-state mechanics (flooding, SPF calculation, adjacency formation) closely parallel OSPF's own behavior covered extensively earlier in this series, making IS-IS approachable once the terminology mapping is understood rather than requiring an entirely new mental model.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring EIGRP Stub Routing

This hands-on lab configures a branch router as an EIGRP stub, verifying it advertises only its own connected and summary routes while the hub router correctly avoids querying the stub during a topology change elsewhere in the network.

Continue

Hands-On Lab: Configuring EIGRP Named Mode

This hands-on lab reconfigures a classic EIGRP setup into EIGRP named mode, organizing address-family and interface-specific configuration into a more structured hierarchy, and verifies functional equivalence with the classic configuration style used throughout earlier EIGRP labs in this series.

Continue

Hands-On Lab: Configuring ERSPAN Across a Routed Network

This hands-on lab configures Encapsulated RSPAN (ERSPAN) to mirror traffic across a Layer 3-routed network rather than a single Layer 2 trunk, extending the RSPAN concept from the previous lab beyond the boundaries of a single VLAN or switched domain.

Continue

Hands-On Lab: Configuring RSPAN Across Switches

This hands-on lab configures Remote SPAN (RSPAN) using a dedicated RSPAN VLAN carried across a trunk, allowing traffic mirrored on one switch to be monitored by a capture device connected to an entirely different switch, extending the local SPAN concept covered in an earlier lab across the network.

Continue

Hands-On Lab: Configuring In-Service Software Upgrade (ISSU) on a Stack

This hands-on lab performs an In-Service Software Upgrade across a StackWise stack, upgrading each member's IOS image one at a time while the stack continues forwarding traffic throughout, verifying zero downtime compared to the disruptive reload approach used in earlier IOS upgrade labs.

Continue

Hands-On Lab: Configuring Cisco Catalyst StackWise Traditional Stacking

This hands-on lab configures traditional Catalyst stacking (StackWise) across three switches using stack cables, contrasting its single-tier, chassis-proximity requirement against the StackWise Virtual pair covered in the previous lab, which allows switches to be located much farther apart.

Continue