I learned something today that now seems obvious. IS-IS LSP Authentication only impacts the trust of the Link State Packet itself, not IS-IS neighbor maintenance. Neighbor adjacency authentication is a separate function in IS-IS. Neighbors will still form if LSP authentication is mismatched but the LSP content will not be published to the Link State Database (LSDB). LSP authentication can be configured without neighbor authentication.

In this article, I’ll demonstrate this utilizing a subset of the topology below. I’ll start by verifying the existing LSP authentication and then breaking authentication to verify that the expected LSPs are deleted from the LSDB. The neighbor adjacency should remain up while LSP authentication is broken. Routers Grey_XR1 and Grey_XE5 will be used for demonstration.

Let’s start by taking a high-level overview of IS-IS configuration on both routers. Grey_XR5 is configured with LSP authentication with the password directly in the IS-IS configuration. In my opinion, the IOS-XR configuration for LSP authentication makes it clearer that only LSPs are authenticated, instead of Hello packets.

The IOS-XE router uses an MD5 key chain that is applied to the IS-IS configuration as shown.

Grey_XE5 has a loopback interface with the configuration below participating in IS-IS routing. This loopback address will be viewed from Grey_XR1 before and after breaking LSP authentication.

The output below confirms that Grey_XR1 has an IS-IS neighbor for XE5, and that XR1 accepted XE5’s LSP, and installed a route to 10.128.250.1/32 into the routing table. The IS-IS database output also confirms that XR1 is using HMAC-MD5 authentication.

Now that we’ve validated everything is working, I am going to break LSP authentication on router Grey_XE5 by changing the key-string. This should cause XR1 (and all other routers in the IS-IS domain) to distrust XE5’s LSPs. We should see the route to 10.128.250.1/32 go away on XR1.

And now we wait. The LSDB entries will not be flushed until the hold time expires. We can see the timer count down by refreshing the LSDB output periodically, underlined in red.

After the timer finally expired, the LSDB entry and route from Grey_XE5 are deleted.

Despite the LSDB entry and route being deleted, the neighbor adjacency between XR1 and XE5 is still up. An interesting point is that the neighbor output switched from displaying the hostname to displaying the System ID field of XE5’s NET address. The change in the displayed system name is explained next.

The hostname is communicated in the IS-IS LSP, not in the hello. Since we’ve broken LSP authentication, the router is unable to display the neighbor’s hostname. The system ID from the Hello Packet must be used instead. LSP Packet from XE5 shown below.

IS-IS Hello (IIH) shown below displaying the system ID (sender of the PDU) we saw previously in the neighbor table.