Fehler bei MTU-Nichtübereinstimmung in IS-IS

Download-Optionen

  • PDF     (126.9 KB)
    Mit Adobe Reader auf verschiedenen Geräten anzeigen
  • ePub     (87.4 KB)
    In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
  • Mobi (Kindle)     (87.0 KB)
    Auf einem Kindle-Gerät oder einer Kindle-App auf mehreren Geräten anzeigen
Aktualisiert:10. August 2005
Dokument-ID:47201

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

Einführung

IS-IS-Hellos (Intermediate System-to-Intermediate System) werden der Gesamtgröße der Maximum Transmission Unit (MTU) hinzugefügt. Die vollständige MTU-Größe von IS-IS Hellos (IIHs) wird durch die frühzeitige Erkennung von Fehlern aufgrund von Übertragungsproblemen bei großen Frames oder aufgrund falsch zugeordneter MTUs an benachbarten Schnittstellen ermöglicht.

Das Padding der IIHs kann deaktiviert werden (in den Cisco IOS® Software Releases 12.0(5)T und 12.0(5)S) für alle Schnittstellen auf einem Router mit dem Befehl no hello padding im Router-Konfigurationsmodus für den IS-IS-Routing-Prozess. Das Padding der IIHs kann für Point-to-Point- oder Multipoint-Schnittstellen selektiv deaktiviert werden, wobei kein Hello-Padding-Multipoint oder kein Point-to-Point-Befehl für das Hello-Padding im Router-Konfigurationsmodus für den IS-IS-Routing-Prozess verwendet wird. Hello-Padding kann auch mithilfe des Schnittstellenkonfigurationsbefehls no isis hello padding auf Schnittstellenbasis für eine einzelne Schnittstelle deaktiviert werden.

Ein Benutzer würde Hello-Padding deaktivieren, um zu vermeiden, dass die Netzwerkbandbreite verschwendet wird, wenn die MTU beider Schnittstellen gleich ist oder wenn es sich um ein ÜbersetzungsBridging handelt. Während Hello-Padding deaktiviert ist, senden Cisco-Router immer noch die ersten fünf IS-IS-Hellos, die zur vollständigen MTU-Größe hinzugefügt wurden. Damit sollen die Vorteile der Erkennung von MTU-Diskrepanzen aufrecht erhalten werden. Konsekutive Hellos werden nicht mehr gepolstert.

Dieses Dokument zeigt, was geschieht, wenn auf den Schnittstellen zweier verbundener Router, auf denen IS-IS ausgeführt wird, eine MTU-Diskrepanz auftritt. Die MTU auf Router F wurde mit dem Schnittstellenkonfigurationsbefehl mtu 2000 von seinem Standardwert von 1500 Byte auf 2000 Byte geändert. Die serielle Schnittstelle wurde "geflapst". Damit der neue MTU-Wert wirksam wird, müssen Sie Serial 0 mit dem Befehl shutdown deaktivieren und ihn dann mit dem Befehl no shutdown aktivieren.

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.

Problem

Das Netzwerkdiagramm und die zur Beschreibung dieses Problems verwendeten Konfigurationen werden hier angezeigt:

isis_mtu_01.gif

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

Auf beiden Routern können Sie den Status der Adjacency zwischen Router F und Router H mit dem Befehl show clns neighbors sehen. Beachten Sie in der Ausgabe von Router F, dass sich die Adjacency zu Router H im INIT-Status befindet. In der Ausgabe von Router H sehen Sie, dass die Adjacency zu Router F der Typ IS ist und dass es sich bei dem Protokoll um ein End System-to-Intermediate System (ES-IS) handelt. Diese Ausgabe weist auf ein Problem mit der CLNS-Adjacency (Connectionless Network Service) hin.

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

Wenn Sie das Debuggen von IS-IS-Adjacency-Paketen mit dem Befehl debug isis adj-packages aktivieren, wird auf der Subschnittstelle Serial 2.1 sowohl serielle IDs gesendet als auch empfangen.

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

Diese Ausgabe zeigt, dass Router H keine IIHs auf Serial 0.2 von Router F empfängt. Daher wird keine IS-IS-Adjacency gebildet. Stattdessen ist die Adjacency das Endsystem (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

Die Ursache des Problems

Router H empfängt die Hellos nicht von Router F, da IIHs zur vollständigen MTU der Verbindung hinzugefügt werden, während die ES-Hellos nicht zur vollständigen MTU-Größe gepaart werden. Dies geschieht, weil Router F denkt, dass die MTU 2000 beträgt, und einen 2000-Byte-Hello sendet, der von Router H ignoriert wird.

Lösung

Die Lösung besteht darin, sicherzustellen, dass beide Seiten einer Verbindung die gleiche MTU aufweisen. Eine Möglichkeit hierfür besteht darin, den Befehl mtu zu verwenden, wie hier gezeigt:

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#

Router H und Router F können jetzt Nachbarn werden und den Datenverkehr der anderen Seite weiterleiten.

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

Das CLNS-Adjacency-Problem aufgrund einer MTU-Diskrepanz kann auch mithilfe des Befehls clns mtu gelöst werden, wie hier gezeigt:

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#

Zugehörige Informationen

Revisionsverlauf

Überarbeitung Veröffentlichungsdatum Kommentare
1.0
10-Aug-2005
Erstveröffentlichung

War dieses Dokument hilfreich?

FeedbackFeedback

Cisco kontaktieren