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


No related posts.


You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

AddThis Social Bookmark Button

8 Responses to “IS-IS MTU Mismatch”

  1. Good article. Basically all Routing protocols that require Hello packets they all need MTU to be same on both sides of the link. Your information about Juniper and their intelligent approach is appreciated.

  2. Mounir Mohamed Says:

    Hi Saud,

    Thanks for your comment,

    Yes most of the routing protocols using hellos requiring the MTU value to be matched, RIP is out of the scope because it doesn’t use hello at all, OSPF and IS-IS desired it, but EIGRP doesn’t care about the MTU, EIGRP uses the MTU as part of its composed metric however this field is not used in the calculation, so ultimately you can have EIGRP adjacency established across mismatched MTU interfaces.
    Example:

    CR4.pe4#
    !
    interface GigabitEthernet0/1
    mtu 1700
    ip address 150.0.0.4 255.255.255.0

    CR5.pe5#show run int f0/0

    interface FastEthernet0/0
    ip address 150.0.0.5 255.255.255.0

    CR4.pe4#show ip eigrp neighbors
    EIGRP-IPv4 neighbors for process 1
    H Address Interface Hold Uptime SRTT RTO Q Seq
    (sec) (ms) Cnt Num
    0 150.0.0.5 Gi0/1 13 00:09:52 1 300 0 10

    CR5.pe5#show ip eigrp neighbors
    EIGRP-IPv4 neighbors for process 1
    H Address Interface Hold Uptime SRTT RTO Q Seq
    (sec) (ms) Cnt Num
    0 150.0.0.4 Fa0/0 11 00:01:09 7 200 0 13

    CR4.pe4#show ip route eigrp

    5.0.0.0/32 is subnetted, 1 subnets
    D 5.5.5.5 [90/156160] via 150.0.0.5, 00:09:24, GigabitEthernet0/1

  3. [...] The IIH PDUs also used to verify MTU of the link by adding another TLV called Padding TLV, more details about the padding TLV and it’s function can be found in the IS-IS MTU Mismatch Post. [...]

  4. It should be noted that even with hello padding disabled in IOS, the router still sends the first couple hellos as padded to detect an MTU mismatch. It then stops sending padded hellos after the adjacency is established. So Juniper and Cisco implementation is basically the same.

  5. You are correct with that, I’ll pass it to Mounir

  6. Mounir Mohamed Says:

    Hi Rob,

    Thank you for your comment, In this post I was talking about the default implementation on both vendors, thus I haven’t mentioned any workarounds, However I just added a note for Cisco workaround above.

    Thanks, Please do not hesitate to add more comments.
    Mounir Mohamed

  7. 1. Do you know why the minimum MTU of ISIS is 1492?

    I think 1497 is reasonable because of 1497 + 3B LLC + 18B frame header = 1518 B.

    What do you think?

    2. I found if we use ISO mtu less than 1492, then ISIS adjacency will not be formed up.

  8. Mounir Mohamed Says:

    Hi Mike,

    Thanks for your comment, actually Cisco Ethernet frame for IS-IS is 21-byte with FCS or 17-byte without FCS so the maximum MTU size for IS-IS packets on Cisco IOS is 1497.

    JunOS Ethernet frame for IS-IS is 26-byte with FCS or 22-byte without FCS, so the maximum MTU size for IS-IS packets on JunOS is 1492.

Leave a Reply