CLNS/IS-IS discrepancy(?) on C9K interswitch links

[andy!doesnt!like!uucp]

i wouldnt ever notice it unless parsing local logs on 2 C9K switches in SDA Fabric for the reason of some interfaces flapping.
Message-block:
Jul 25 13:01:06.457: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/1/1, changed state to up
Jul 25 13:01:07.252: %CLNS-3-INTF_MTU_TOO_SMALL: Interface Te1/1/1 MTU 1400 smaller than lsp-mtu 1492
Jul 25 13:01:07.376: %BFD-6-BFD_SESS_CREATED: BFD-SYSLOG: bfd_session_created, neigh X.Y.Z.W proc:ISIS, idb:TenGigabitEthernet1/1/1 handle:9 act
Jul 25 13:01:08.161: %CLNS-5-ADJCHANGE: ISIS: Adjacency to EN0001 (TenGigabitEthernet1/1/1) Up, new adjacency
in below output each interswitch IS-IS facing port indicates that "yes it is"
EN0001 L2 TeX/Y/Z X.Y.Z.W UP 22 24
Area Address(es): 49.0001.0010
SNPA: ****.****.5ef4
State Changed: 01:08:50
Format: Phase V
Remote TID: 0
Local TID: 0
Interface name: TenGigabitEthernet1/1/1
Neighbor Circuit Id: 36
Remote BFD Support:TLV (MTID:0, IPV4)
BFD enabled: (MTID:0, ipv4)
Adj sync: Full
Link mtu: 1400 Smaller than lsp-mtu: 1492
I conclude that CLNS LSPs will be dropped which may be a problem in big SDA Fabric sites. Any clues on this?

[andy!doesnt!like!uucp]

found some clues here:
https://community.cisco.com/t5/xr-os-and-platforms/is-is-clns-mtu/td-p/1949312#:~:text=Indirectly%2C%20clns%2Dmtu%20needs%20to%20be%20greater%20than%20or%20equal%20to%20the%20maximum%20size%20LSP%20that%20any%20IS%20in%20the%20area/domain%20may%20gen....
as well as how to arrange it to "compliant" state, but why SDA doesnt care about it?
@jedolphi any clues?

[Giuseppe Larosa]

Hello @andy!doesnt!like!uucp ,

>> I conclude that CLNS LSPs will be dropped which may be a problem in big SDA Fabric sites. 

I remember from some old threads may be including @Harold Ritter  that IS-IS LSP may be "fragmented" inside multiple IS-IS PDUs if this is true you should be fine otherwise you need to increase the MTU on all links to values like 9000 bytes that is what I would expect from the SD Access control plane.

Hope to help

Giuseppe

[andy!doesnt!like!uucp]

tnx Giuseppe, will try do find confirmation to it. Otherwise having DNAC inconsistently automating IS-IS would be n issue :0)
UPD. Found this (tnx again to @Giuseppe Larosa :0) : Fragmentation in IS-IS - Cisco Community . 
Interesting that participants were discussing impact on LSP PDU by interface's MTU (with 9K+ in fabric not n issue at all) whilst switch with message in original post looks more worrying about CLNS MTU on the interface... need to drill more on it.

[Giuseppe Larosa]

Hello @andy!doesnt!like!uucp ,

I have written in that thread more then 15 years ago !

>>

an IS-IS LSP can be "fragmented" but only by the LSP owner/originator.

the LSP PDU format includes a field called LSP ID.

An LSP-ID is made of the following fields

system-id. 1 byte that says if originator is a node or a pseudonode (0x00 if router) a byte called LSP number and a 4byte Sequence number.

>>>> the byte called LSP number allows to carry information of a single LSP within multiple IS-IS PDUs each with incremental LSP number field.

so there is no critical MTU problem for LSP.

and :

>>

I understand now what you mean: once the LSP has leaved the originator node it cannot be fragmented by any other node : or it is able to travel over the network topology (LSP flooding) or it will be lost counting as a giant.

Hope to help

Giuseppe

Add tags

[Giuseppe Larosa]

I understand now what you mean: once the LSP has leaved the originator node it cannot be fragmented by any other node : or it is able to travel over the network topology (LSP flooding) or it will be lost counting as a giant.

Hope to help

Giuseppe

[jedolphi]

Hi guys, I've checked with ISIS SME and he's confirmed that CLI "clns mtu 1400" can create trouble flooding full size LSPs (1492 byte) if there's no lsp-mtu or no L3 interface MTU to lower L3 payload, and of course in SDA we never set low L3 interface MTU. In practice I haven't seen this config cause issues, but it should be corrected in case of future issues. Let me look into it some more and get back.

[jedolphi · Accepted solution]

Fixed in 2.3.7.5 and later. The fix will push "clns mtu 1492" instead of 1400. For underlays provisioned prior to 2.3.7.5 the CLI will need to be added manually e.g. template, etc. Thanks.