IS-IS MTU Mismatch

IS-IS is a link-state routing protocol, it uses the concept of distributed map/database and local computation , each router originates an LSP to describes himself , this LSP carries links and topological information, reach router on the domain generates its own LSP and relays other routers LSPs untouched (With respect to the Level that the LSP originated in) this information is used to build up the distributed map, a local computation is then performed on the database to extract IP reachability information to formalize the forwarding plane.

What is the problem?

IS-IS is an extended protocol by nature, Initially it wasn't  carrying IP information, but it had adapted to do so, the extendability aspect of IS-IS came from the concept of  using TLVs (Type, Length, Value) which is theoretically allowing the IS-IS to carry any information, adding more and more TLVs to convey additional  information resulting in big messages, the exchanging of such big messages required a discovery mechanism to discovers the network MTU,  and prevent messages drops ( Due to MTU mismatch).

Neighboring and MTU Auto-Discovery
IS-IS uses hello messages as an auto-discovery mechanism to discover direct routers speaks IS-IS, so it was rational to extend the existing neighbor discovery mechanism to discover the MTU as well, and sure the extension came in flavor of new TLV known as Padding TLV (#8) which is added to the IS-IS Hello PDUs.

It's not matter what is the information on this TLV, However it's matter what it does.

IS-IS uses the Padding TLV as a tool to increase the hello message size up to the MTU that the receiving end will accept, so the hello message with the Padding TLV both formalizes the detection mechanism for MTU issues, however even if  MTU mismatch detected there is no corrective action will be taken to solve this issue, so it is  for detection only.

How it works?
When IS-IS enabled on an interface the router starts originating  hellos  to detect direct neighbors, these hellos are padded up to the maximum transmission unit of the outgoing interface which is rationally the value that the neighbor router will accept, so if there is any MTU mismatches these hellos will get dropped by the router who has lower MTU, it's fine to happen at such early stage before reaching the LSP exchange stage.

Detecting the MTU at early stage decrease the probability of dropping LSPs which results in LSDB inconsistency.

IOS and JunOS Padding TLV Implementations:
Both giants (Cisco and Juniper) supporting Padding TLV with different operation perspective, Cisco simply pads all hello messages before and after building the adjacency, this may seems good to detect network misconfiguration, but it  results in waste of bandwidth after builds the adjacency.

On the other hand Juniper uses a smart padding technique whereby only the initial hello messages are attached with the padding TLV to get the message size up to the maximum transmission unit of the interface which is 1492-bytes (According to Juniper Ethernet frame header), but once the adjacency goes up no more Padding TLVs will be attached to the generated hello messages which is rationally saves more control-plane  and data-plane resources.
(However Cisco IOS allows to disable hello padding, So only the first five hellos will be padded)

Example
R1 and R2 connected to each others via Gigabit interfaces and has IS-IS enabled on, After the adjacency between R1 and R2  successfully established  for some reason the the MTU is adjusted on R1 interface to 1550, so the next originated messages will be padded up to 1547-byte, R2 on the other side won't be able to process such large message hence this message will be dropped by R2, and sure missing hellos will cause in adjacency failure.

Hereunder an example for 2 routers R1 and R2, R1 is running IOS whereas R2 is running JUNOS  both are connected via Gigabit interfaces, R1 has MTU value 1550,and R2 has  MTU value 1500 (excluding the L2 headers),  so the hello messages generated by R1 with MTU 1547 will get dropped by R2, thus no adjacency will be established.

R1 (IOS)

R1#show log
Mar 22 10:12:06: ISIS-Adj: Rec L2 IIH from b0c6.9a23.7800 (Vlan1), cir  type L1L2, cir id 0000.0000.0001.00, length 48
Mar 22 10:12:06: ISIS-Adj: Sending L2 LAN IIH on Vlan1, length 1597
Mar 22 10:12:08: ISIS-Adj: Sending L1 LAN IIH on Vlan1, length 1597
Mar 22 10:12:09: ISIS-Adj: Rec L1 IIH from b0c6.9a23.7800 (Vlan1), cir  type L1L2, cir id 0000.0000.0001.00, length 48
Mar 22 10:12:09: ISIS-Adj: Sending L2 LAN IIH on Vlan1, length 1597
Mar 22 10:12:10: ISIS-Adj: Sending L1 LAN IIH on Vlan1, length 1597
Mar 22 10:12:12: ISIS-Adj: Sending L2 LAN IIH on Vlan1, length 1597
Mar 22 10:12:13: ISIS-Adj: Rec L2 IIH from b0c6.9a23.7800 (Vlan1), cir  type L1L2, cir id 0000.0000.0001.00, length 48
Mar 22 10:12:13: ISIS-Adj: Sending L1 LAN IIH on Vlan1, length 1597
Mar 22 10:12:15: ISIS-Adj: Sending L2 LAN IIH on Vlan1, length 1597
Mar 22 10:12:16: ISIS-Adj: Sending L1 LAN IIH on Vlan1, length 1597

R2 (JunOS)

mounir@R2> file show /var/log/isis1
Mar 22 10:18:39 trace_on: Tracing to "/var/log/isis1" started
Mar 22 10:18:39.118712 Sending L1 LAN IIH on ge-0/0/0.0
Mar 22 10:18:39.118818     packet length 48
Mar 22 10:18:39.119354 Sending L2 LAN IIH on ge-0/0/0.0
Mar 22 10:18:39.119420     packet length 48
Mar 22 10:18:46.837409 ISIS L1 periodic xmit to 01:80:c2:00:00:14 interface ge-0/0/0.0
Mar 22 10:18:48.065218 ISIS L2 periodic xmit to 01:80:c2:00:00:15 interface ge-0/0/0.0
Mar 22 10:18:54.117277 ISIS L1 periodic xmit to 01:80:c2:00:00:14 interface ge-0/0/0.0
Mar 22 10:18:57.012819 ISIS L2 periodic xmit to 01:80:c2:00:00:15 interface ge-0/0/0.0
Mar 22 10:19:03.043863 ISIS L1 periodic xmit to 01:80:c2:00:00:14 interface ge-0/0/0.0

-
I hope it was informative post.

Mounir Mohamed, CCIE No.19573