This topic is to discuss the following lesson:
Thx Rene. Clear & Concise …
I tried the instance authentication but I keep seeing this message:
*Mar 1 00:07:13.255: %CLNS-4-AUTH_FAIL: ISIS: CSNP authentication failed
what could be missing in my configuration?
ip router isis
router isis
net 49.0012.0000.0000.0001.00
authentication mode md5
authentication key-chain cisco@123
log-adjacency-changes
interface FastEthernet0/0
ip address 192.168.12.1 255.255.255.0
ip router isis
duplex auto
speed auto
end
Hello Kacem
If you’re running this on GNS3 it could be an issue with the resources being allocated to dynamips. It has been known to create such error messages when the PC doesn’t have sufficient resources to provide for the emulator. This is especially the case when using MD5 as this takes up more resources.
Despite the error, is everything else working correctly? Are you getting a neighbor relationship and is the routing table being populated? If so, this seems to indicate that the issue is with resources.
If you’re sure your configs are correct, try to remove MD5 authentication and do clear text authentication and see if the error goes away.
I hope this has been helpful!
Laz
Hello, everyone.
I need someone to help me confirm this.
The passwords are mismatched yet P2 is still installing P4’s L2 routes which it shouldn’t…
How is this possible? Is this a bug in CML?
David
Hello David
Hmm, that’s interesting. The only thing I can think of is that P2 is still installing P4’s Level-2 routes because IS-IS domain/area authentication does not affect Hellos. On some IOS XE/CML images, received LSPs are not strictly validated unless explicit validation is enforced, so mismatched passwords can still result in accepted L2 LSPs.
This looks more like an image or platform-specific behavior rather than an IS-IS rule. If you want deterministic behavior where a mismatch blocks routing, use interface or Hello authentication or explicit LSP validation (or HMAC/MD5 key-chains). It looks like domain passwords alone are not sufficient to guarantee rejection.
This documentation may also prove useful:
I hope this has been helpful!
Laz
Hello Laz.
I accidentally figured it out and forgot to post, sorry.
I’ve changed the passwords after the adjacency went UP and the LSPs were exchanged. Which most likely means that the LSPs were still installed in the LSPDB and were waiting to expire, that’s why I also saw those routes since no one really poisoned that LSP, I believe.
David
Hello David
Ah I see, thanks for letting us know! This gives us more insight into how IS-IS operates. When you changed the IS-IS authentication password after the adjacency was up and LSPs were already exchanged, the adjacency did indeed drop because the routers could no longer authenticate Hello PDUs . Authentication failures prevent new Hello packets from being accepted.
However, previously received LSPs remained in the LSPDB because they were already validated and installed before the password change. They remain valid based on their aging timers, not on the current adjacency state.
No LSP purges were sent. Even if the neighbor tried, those purge packets would fail. IS-IS purges are just LSPs with remaining lifetime = 0, so if authentication is enabled and mismatched, any incoming LSP (including a purge) will be rejected. For this reason, routes persisted until LSP aging timed out. IS-IS LSPs have a default MaxAge of 1200 seconds or 20 minutes.
Now, the question I like to ask at this point is, why is it designed this way?
IS-IS separates or decouples adjacency maintenance (Hellos) from topology database maintenance (LSPs). Once LSPs are in the database, they persist based on their lifetime timers independent of adjacency state. Remember, IS-IS is built for stability and resiliency. This persistence or “maintaining the status quo” due to this decoupling is thus working as designed.
I hope this has been helpful!
Laz