MTU Mismatch Problem in IS-IS
Available Languages
Contents
Introduction
Intermediate System-to-Intermediate System (IS-IS) hellos are padded to the full maximum transmission unit (MTU) size. The benefit of padding IS-IS Hellos (IIHs) to the full MTU is that it allows for early detection of errors due to transmission problems with large frames or due to mismatched MTUs on adjacent interfaces.
The padding of IIHs can be turned off (in Cisco IOS® Software Releases 12.0(5)T and 12.0(5)S) for all interfaces on a router with the no hello padding command in router configuration mode for the IS-IS routing process. The padding of IIHs can be selectively turned off for point-to-point or multipoint interfaces with the no hello padding multi-point or no hello padding point-to-point command in router configuration mode for the IS-IS routing process. Hello padding can also be turned off on an individual interface basis using the no isis hello padding interface configuration command.
A user would disable hello padding in order avoid wasting network bandwidth in case the MTU of both interfaces are the same or, in case of translational bridging. While hello padding is disabled, Cisco routers still send the first five IS-IS hellos padded to the full MTU size. This is to maintain the benefits of discovering MTU mismatches. Consecutive hellos are no longer padded.
This document demonstrates what happens when there is an MTU mismatch on the interfaces of two connected routers running IS-IS. The MTU on Router F has been changed from its default value of 1500 bytes to 2000 bytes with the mtu 2000 interface configuration command. The serial interface has been "flapped." Therefore, for the new MTU value to take effect, you must disable Serial 0 with the shutdown command, and then enable it with the no shutdown command.
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
This document is not restricted to specific software and hardware versions.
Conventions
For more information on document conventions, see the Cisco Technical Tips Conventions.
Problem
The network diagram and configurations used to describe this problem are shown here:
| Router H | Router F |
|---|---|
clns routing ! interface Serial0 no ip address no ip directed-broadcast no ip mroute-cache encapsulation frame-relay frame-relay lmi-type ansi ! interface Serial0.1 ip address 10.10.10.4 255.255.255.0 no ip directed-broadcast ip router isis clns router isis frame-relay map clns 132 broadcast frame-relay map clns 131 broadcast frame-relay map ip 10.10.10.1 132 broadcast frame-relay map ip 10.10.10.3 131 broadcast ! interface Serial0.2 point-to-point ip address 10.20.20.4 255.255.255.0 no ip directed-broadcast ip router isis clns router isis frame-relay interface-dlci 130 ! router isis passive-interface Ethernet0 net 49.0001.4444.4444.4444.00 is-type level-1 |
clns routing ! interface Serial2 mtu 2000 no ip address no ip directed-broadcast encapsulation frame-relay frame-relay lmi-type ansi ! interface Serial2.1 point-to-point ip address 10.20.20.2 255.255.255.0 no ip directed-broadcast ip router isis clns router isis frame-relay interface-dlci 103 ! router isis net 49.0001.2222.2222.2222.00 is-type level-1 |
On both routers, you can see the state of the adjacency between Router F and Router H with the show clns neighbors command. In the output from Router F, note that the adjacency with Router H is in the INIT state. In the output from Router H, you can see that the adjacency with Router F is type IS, and the protocol is End System-to Intermediate System (ES-IS). This output indicates there is a problem with the Connectionless Network Service (CLNS) adjacency.
Router_H# show clns neighbors System Id SNPA Interface State Holdtime Type Protocol Router_F DLCI 130 Se0.2 Up 294 IS ES-IS Router_G DLCI 131 Se0.1 Up 7 L1 IS-IS Router_E DLCI 132 Se0.1 Up 27 L1 IS-IS Router_F# show clns neighbors System Id Interface SNPA State Holdtime Type Protocol Router_H Se2.1 DLCI 103 Init 26 L1 IS-IS
If you enable IS-IS adjacency-packet debugging with the debug isis adj-packets command, you can see that Router F both sends and receives serial IIHs on the Serial 2.1 subinterface.
Router_F# debug isis adj-packets IS-IS Adjacency related packets debugging is on ISIS-Adj: Sending serial IIH on Serial2.1 ISIS-Adj: Rec serial IIH from DLCI 103 (Serial2.1), cir type L1, cir id 00 ISIS-Adj: rcvd state DOWN, old state INIT, new state INIT ISIS-Adj: Action = GOING UP, new type = L1 ISIS-Adj: Sending serial IIH on Serial2.1 ISIS-Adj: Rec serial IIH from DLCI 103 (Serial2.1), cir type L1, cir id 00 ISIS-Adj: rcvd state DOWN, old state INIT, new state INIT ISIS-Adj: Action = GOING UP, new type = L1 ISIS-Adj: Sending serial IIH on Serial2.1 ISIS-Adj: Rec serial IIH from DLCI 103 (Serial2.1), cir type L1, cir id 00 ISIS-Adj: rcvd state DOWN, old state INIT, new state INIT ISIS-Adj: Action = GOING UP, new type = L1 ISIS-Adj: Rec serial IIH from DLCI 103 (Serial2.1), cir type L1,cir id 00 ISIS-Adj: rcvd state DOWN, old state INIT, new state INIT ISIS-Adj: Action = GOING UP, new type = L1 ISIS-Adj: Sending serial IIH on Serial2.1
This output shows that Router H does not receive IIHs on Serial 0.2 from Router F. Therefore, no IS-IS adjacency is formed. Instead, the adjacency is End System (ES).
Router_H# debug isis adj-packets IS-IS Adjacency related packets debugging is on ISIS-Adj: Rec L1 IIH from DLCI 131 (Serial0.1), cir type 1, cir id Router_H.01 ISIS-Adj: Sending L1 IIH on Serial0.1 ISIS-Adj: Rec L1 IIH from DLCI 131 (Serial0.1), cir type 1, cir id Router_H.01 ISIS-Adj: Sending serial IIH on Serial0.2 ISIS-Adj: Rec L2 IIH from DLCI 132 (Serial0.1), cir type 3, cir id Router_H.01 ISIS-Adj: Rec L1 IIH from DLCI 131 (Serial0.1), cir type 1, cir id Router_H.01 ISIS-Adj: Rec L1 IIH from DLCI 132 (Serial0.1), cir type 3, cir id Router_H.01 ISIS-Adj: Rec L1 IIH from DLCI 131 (Serial0.1), cir type 1, cir id Router_H.01 ISIS-Adj: Sending L1 IIH on Serial0.1 ISIS-Adj: Rec L1 IIH from DLCI 131 (Serial0.1), cir type 1, cir id Router_H.01 ISIS-Adj: Rec L2 IIH from DLCI 132 (Serial0.1), cir type 3, cir id Router_H.01 ISIS-Adj: Sending serial IIH on Serial0.2 ISIS-Adj: Rec L1 IIH from DLCI 132 (Serial0.1), cir type 3, cir id Router_H.01 ISIS-Adj: Rec L1 IIH from DLCI 131 (Serial0.1), cir type 1, cir id Router_H.01 ISIS-Adj: Rec L1 IIH from DLCI 131 (Serial0.1), cir type 1, cir id Router_H.01
The Cause of the Problem
Router H does not receive the hellos from Router F because IIHs are padded to the full MTU of the link, whereas ES hellos are not padded to full MTU size. This happens because Router F thinks the MTU is 2000, and it sends a 2000-byte hello, which is ignored by Router H.
Solution
The solution is to make sure that both sides of a link have the same MTU. One way to do this is to use the mtu command as shown here:
Router_F# configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router_F(config)# interface serial 2 Router_F(config-if)# mtu 1500 Router_F(config-if)# shutdown Router_F(config-if)# no shutdown Router_F(config-if)# ^Z Router_F#
Now Router H and Router F can become neighbors and route each other's traffic.
Router_H# show clns neighbors System Id SNPA Interface State Holdtime Type Protocol Router_F DLCI 130 Se0.2 Up 28 L1 IS-IS Router_G DLCI 131 Se0.1 Up 8 L1 IS-IS Router_E DLCI 132 Se0.1 Up 29 L1 IS-IS Router_F# show clns neighbors System Id Interface SNPA State Holdtime Type Protocol Router_H Se2.1 DLCI 103 Up 24 L1 IS-IS
The CLNS adjacency problem due to MTU mismatch can also be solved using the clns mtu command as shown here:
Router_F#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router_F(config)#interface serial2 Router_F(config-if)#clns mtu 1500 Router_F(config-if)#^Z Router_F#
Related Information
Revision History
| Revision | Publish Date | Comments |
|---|---|---|
1.0 |
10-Aug-2005 |
Initial Release |
Feedback