Hands-On Lab: Configuring Multi-Level IS-IS (Level 1 and Level 2)

This hands-on lab extends the previous single-area IS-IS topology into a Level 1/Level 2 hierarchy, designating one router as an L1/L2 border, and verifying route leaking between levels mirrors OSPF's inter-area behavior covered earlier in this series.

IS-IS Level 1 and Level 2 HierarchyL1/L2 Border RouterIS-IS Route Leaking

~4 min read · Updated Sep 26, 2026

Lab Objective

Reconfigure the previous lab's topology into a two-level IS-IS hierarchy, with R1 as a Level 1-only router, R3 as a Level 2-only router, and R2 as an L1/L2 border router, verifying routes propagate correctly between levels and comparing this design against OSPF's area hierarchy.

Lab Purpose

The previous lab used a flat single-level design for simplicity. IS-IS's actual hierarchical model — Level 1 (intra-area) and Level 2 (inter-area, forming the backbone) — parallels OSPF's Area 0 backbone concept covered extensively earlier in this series, but with IS-IS's L1/L2 border router role conceptually equivalent to an OSPF ABR, though implemented differently.

Lab Topology

R1 (Level 1 only, Area 49.0001)
  ---- R2 (L1/L2 border) ----
  R3 (Level 2 only, backbone)

Same physical topology and addressing as
the previous lab

Task 1: Reconfigure R1 as Level 1 Only

Restrict R1's IS-IS process to Level 1 only.

Task 2: Reconfigure R3 as Level 2 Only

Restrict R3's IS-IS process to Level 2 only.

Task 3: Leave R2 as Both Level 1 and Level 2

Confirm R2 remains a full L1/L2 router by default, acting as the border between the two levels.

Task 4: Verify R1 Only Forms a Level 1 Adjacency

Confirm R1's neighbor relationship with R2 is now Level 1 only.

Task 5: Verify R1 Receives a Default Route Rather Than Specific External Routes

Confirm R1, as a Level 1-only router, receives a default route toward R2 for reaching Level 2 destinations, rather than specific routes to R3's LAN.

Solution and Verification

R1(config)# router isis
R1(config-router)# is-type level-1

-- Restricts R1 to Level 1 only -- it will
-- no longer attempt Level 2 adjacencies
-- or maintain Level 2 topology information
-- at all

R3(config)# router isis
R3(config-router)# is-type level-2-only

-- R3 becomes Level 2 only, analogous to a
-- router existing purely within OSPF's
-- Area 0 backbone with no other area
-- membership

-- R2 requires no change -- "is-type
-- level-1-2" is the default, making it
-- simultaneously a Level 1 router (toward
-- R1) and a Level 2 router (toward R3),
-- exactly the dual role an OSPF ABR plays
-- between an area and Area 0

R1# show clns neighbors

System Id      Interface   State  Type  Holdtime
0000.0000.0002 Se0/0/0     Up     L1     28
-- Type now shows L1 only, whereas the
-- previous lab's flat design showed L2

R2# show clns neighbors

System Id      Interface   State  Type  Holdtime
0000.0000.0001 Se0/0/0     Up     L1     29
0000.0000.0003 Se0/0/1     Up     L2     26
-- R2 simultaneously maintains an L1
-- adjacency toward R1 and an L2 adjacency
-- toward R3 -- confirming its dual-level
-- border role

R1# show ip route isis

i*L1  0.0.0.0/0 [115/10] via 10.10.10.2, Serial0/0/0
-- R1 receives only a default route from
-- R2, NOT a specific route to R3's LAN --
-- this default route ("i*L1", the L1
-- default toward the nearest L1/L2 border
-- router) is IS-IS's mechanism for
-- reaching everything outside the local
-- Level 1 area, conceptually mirroring
-- how a totally stubby OSPF area receives
-- only a default route rather than
-- specific inter-area routes

R1# ping 192.168.13.1

!!!!!
Success rate is 100 percent (5/5)
-- Despite having no specific route,
-- connectivity to R3's LAN succeeds via
-- the default route toward R2

Key Takeaway

A Level 1-only IS-IS router automatically receives a default route toward its nearest L1/L2 border router rather than learning every specific external route individually — this default behavior parallels a totally stubby OSPF area's default route covered earlier in this series, but IS-IS does this automatically by design rather than requiring an explicit configuration command like OSPF's stub no-summary keyword.

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