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 دقیقه مطالعه · آخرین به‌روزرسانی ۴ مهر ۱۴۰۵

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.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه