Hands-On Lab: Configuring IS-IS Authentication

This hands-on lab configures MD5 authentication on an IS-IS interface, verifying the adjacency requires a matching password and observing the resulting failure when passwords are mismatched, mirroring the OSPF and EIGRP authentication labs covered earlier in this series.

IS-IS MD5 AuthenticationHello AuthenticationInterface-Level Password

~3 min read · Updated Sep 26, 2026

Lab Objective

Configure MD5 authentication on an IS-IS-enabled interface between two routers, verify the adjacency remains stable when passwords match, then introduce a mismatch and observe the resulting adjacency failure.

Lab Purpose

Just as with the OSPF and EIGRP authentication labs covered earlier in this series, IS-IS without authentication allows any device sending properly formatted IS-IS hellos on a shared segment to potentially form an unauthorized adjacency. IS-IS authentication follows a syntax distinct from both prior protocols, worth understanding on its own terms.

Lab Topology

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

Same topology as the multi-level IS-IS lab,
focusing on the R2-R3 Level 2 adjacency

Task 1: Verify the Current Healthy Adjacency

Confirm R2 and R3 show an active Level 2 IS-IS adjacency before adding authentication.

Task 2: Configure MD5 Authentication on R2's Interface

Enable IS-IS hello authentication on R2's interface with a specific key.

Task 3: Configure Matching Authentication on R3's Interface

Enable the identical key on R3's corresponding interface.

Task 4: Verify the Adjacency Remains Stable

Confirm the adjacency is unaffected, since both keys match.

Task 5: Introduce a Key Mismatch and Verify Failure

Change R3's key to a different value and observe the resulting adjacency loss.

Solution and Verification

R2# show clns neighbors

System Id      Interface   State  Type  Holdtime
0000.0000.0003 Se0/0/1     Up     L2     28

R2(config)# interface serial0/0/1
R2(config-if)# isis authentication mode md5
R2(config-if)# isis authentication key-chain ISIS-AUTH
R2(config-if)# exit
R2(config)# key chain ISIS-AUTH
R2(config-keychain)# key 1
R2(config-keychain-key)# key-string IsisKey2026

-- IS-IS, like EIGRP covered earlier in
-- this series, uses a key chain rather
-- than a directly configured password as
-- OSPF's ip ospf message-digest-key does

R3(config)# interface serial0/0/1
R3(config-if)# isis authentication mode md5
R3(config-if)# isis authentication key-chain ISIS-AUTH
R3(config-if)# exit
R3(config)# key chain ISIS-AUTH
R3(config-keychain)# key 1
R3(config-keychain-key)# key-string IsisKey2026

R2# show clns neighbors

System Id      Interface   State  Type  Holdtime
0000.0000.0003 Se0/0/1     Up     L2     29
-- Adjacency remains Up, since both sides
-- now share the identical key

R3(config)# key chain ISIS-AUTH
R3(config-keychain)# key 1
R3(config-keychain-key)# key-string DifferentKey999

R2# show clns neighbors

-- (neighbor entry eventually disappears
--  once the hold timer expires, since
--  authentication now fails on every
--  subsequent hello)

R2# debug isis adj-packets

ISIS-Adj: Rejecting L2 IIH from
0000.0000.0003, auth failed
-- The debug output explicitly names the
-- cause -- an authentication failure --
-- rather than a vague or generic
-- adjacency-down symptom

R3(config)# key chain ISIS-AUTH
R3(config-keychain)# key 1
R3(config-keychain-key)# key-string IsisKey2026

R2# show clns neighbors

System Id      Interface   State  Type  Holdtime
0000.0000.0003 Se0/0/1     Up     L2     30
-- Adjacency recovers once the keys match again

Key Takeaway

IS-IS authentication, like EIGRP's, relies on a key chain as an intermediate configuration object rather than a directly configured password on the interface, distinguishing its syntax from OSPF's approach covered earlier in this series — despite this syntactic difference across all three protocols, the underlying troubleshooting principle remains identical: a debug of the adjacency formation process will explicitly name an authentication mismatch rather than leaving the engineer to guess at a vague connectivity symptom.

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