Guest

Problema de discrepancia de MTU en IS-IS

Opciones de descarga

  • PDF     (91.0 KB)
    Visualice con Adobe Reader en una variedad de dispositivos
  • ePub     (71.2 KB)
    Visualice en diferentes aplicaciones en iPhone, iPad, Android, Sony Reader o Windows Phone
  • Mobi (Kindle)     (86.0 KB)
    Visualice en dispositivo Kindle o aplicación Kindle en múltiples dispositivos
Actualizado:10 de agosto de 2005
ID del documento:47201
Acerca de la traducción

Acerca de esta traducción

Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).

Introducción

Los saludos de Sistema intermedio a sistema a intermedio (IS-IS) se rellenan hacia el tamaño completo de la Unidad de transmisión máxima (MTU). La ventaja de rellenar los hellos IS-IS (IIH) a la MTU completa es que permite la detección temprana de errores debidos a problemas de transmisión con tramas grandes o debidos a la discrepancia de MTU en interfaces adyacentes.

El relleno de los IIH se puede apagar (en el Cisco IOS ® Software libera 12.0(5)T y 12.0(5)S) para todas las interfaces en un router con el comando no hello padding en el modo de configuración del router para el proceso de ruteo IS-IS. La amortiguación de IIHs puede ser desactivada de manera selectiva para interfaces punto a punto o multipunto con el comando no hello padding multi-point o con no hello padding point-to-point en el modo de configuración del router para el proceso de ruteo de IS-IS. La amortiguación de saludo también puede ser desactivada en base a una interfaz individual con el comando de configuración de interfaz no isis hello padding.

Un usuario inhabilitaría el relleno de saludo en la orden evita perder el ancho de banda de la red en caso de que el MTU de ambas interfaces sea el mismo o, en caso del Translational Bridging. Mientras que se inhabilita el relleno de saludo, los routeres Cisco todavía envían los primer cinco hellos IS-IS completados a la talla del MTU completa. Éste es mantener las ventajas de descubrir las discordancías MTU. El hellos consecutivo se completa no más.

Este documento demuestra qué sucede cuando se produce una discordancia de MTU en las interfaces de dos routers conectados que ejecutan IS-IS. La MTU del Router F ha sido cambiada de su valor predeterminado de 1500 bytes a 2000 bytes con el comando de configuración de la interfaz mtu 2000. Se ha agitado la interfaz serial “.” Por lo tanto, para que el nuevo valor MTU tome el efecto, usted debe inhabilitar el serial0 con el comando shutdown, y después lo habilita con el comando no shutdown.

prerrequisitos

Requisitos

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte Convenciones de Consejos Técnicos de Cisco.

Problema

El diagrama de la red y las configuraciones usados para describir este problema se muestran aquí:

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

En ambo Routers, usted puede ver el estado de la adyacencia entre el router F y el router H con el comando show clns neighbors. En la salida del Router F, fíjese que la adyacencia con el router H esté en estado INIT. En la salida del router H, usted puede ver que ES la adyacencia con el router que F es tipo, y el protocolo es extremo Sistema-al sistema intermedio (ES-IS). Esta salida indica que existe un problema con la adyacencia del CLNS (Servicio de red no orientado a la conexión).

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

Si usted habilita el debugging del adyacencia-paquete IS-IS con el comando debug isis adj-packets, usted puede ver que el router F envía y recibe los IIH seriales en la subinterfaz serial del 2.1.

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

Esta salida muestra que el router H no recibe los IIH en el Serial0.2 del router F. Por lo tanto, no se forma ninguna adyacencia IS-IS. En cambio, la adyacencia es Sistema extremo (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

La causa del problema

El router H no recibe el hellos del router F porque los IIH se completan al MTU lleno del link, mientras que el hellos ES no se completa a la talla del MTU completa. Esto sucede porque el router F piensa que el MTU es 2000, y envía un 2000-byte hola, que es ignorado por el router H.

Solución

La solución es aseegurarse que los ambos lados de un link tienen el mismo MTU. Una manera de hacer esto es utilizar el comando mtu como se muestra aquí:

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#

Ahora el router H y el router F pueden convertirse en vecinos y rutear el tráfico del otro.

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

El problema a causa de la adyacencia CLNS a la discordancía MTU se puede también solucionar usando el comando clns mtu como se muestra aquí:

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#

Información Relacionada

Con la colaboración de ingenieros de Cisco

¿Resultó útil este documento?

FeedbackComentarios

Déjenos ayudarlo

Debates relacionados con la comunidad de soporte