From: James R. Yeo (james@net-brigade.com)
Date: Tue Jul 20 2004 - 05:08:22 GMT-3
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.
One 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 still have 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," so 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 to describe this problem are shown
below:
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 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 will 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 will see that Router F is both sending and receiving
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
The output below shows that Router H is not receiving 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 is not receiving 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 is happening because Router F thinks the MTU is 2000, and it is
sending a 2000-byte hello, which is being ignored by Router H.
Solutions
The solutions are either to make sure that both sides of a link have the
same MTU, or to make sure the routers are configured not to pad IIHs to
the full MTU size.
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
On Mon, 19 Jul 2004 22:46:37 -0400, "ccie2be" <ccie2be@nyc.rr.com> wrote :
> The only situation I'm aware of where this is a potential issue assuming
the
> default mtu size hasn't been changed is if you're running 802.1q
tunneling
> because that requires the mtu to be larger by 4 bytes. This is a 3550
> feature, so if you're not doing this tunneling, it shouldn't be a
problem.
>
> I also vaguely recall the possibility of a mtu mismatch with isis. I
don't
> recall the details but I believe the problem can be solved with the
command,
> no hello padding. A while back I recall reading a tech note on this but
I
> don't have the link. I wold check the isis support page for more info.
>
> HTH at least a little.
>
> ----- Original Message -----
> From: "CCIE" <ccie@gmx.net>
> To: <ccielab@groupstudy.com>
> Sent: Monday, July 19, 2004 2:17 PM
> Subject: Troubleshoot MTU mismatch?
>
>
> > Hi Group,
> >
> > I search for a solution to successfully troubleshoot MTU mismatch
between
> > devices (Serial link, Atm etc). Assume for example a BGP Peering is
> flapping
> > and you want to know if the Layer 2 connectivity is correct how you can
> > debug or troubleshoot types of MTU mismatch and correct them?
> >
> > Regards
> >
> > Carlos
> >
> > _______________________________________________________________________
> > Please help support GroupStudy by purchasing your study materials from:
> > http://shop.groupstudy.com
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Aug 01 2004 - 10:11:59 GMT-3