Guest

Problema de Incompatibilidade de MTU em IS-IS

Opções de download

  • PDF     (89.2 KB)
    Ver no Adobe Reader em vários dispositivos
  • ePub     (75.6 KB)
    Ver em vários aplicativos no iPhone, iPad, Android, Sony Reader ou Windows Phone
  • Mobi (Kindle)     (69.4 KB)
    Ver no dispositivo Kindle ou no aplicativo Kindle em vários dispositivos
Atualizado:10 de Agosto de 2005
ID do documento:47201
Sobre a tradução

Sobre esta tradução

A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.

Introdução

As saudações do IS-IS (Sistema intermediário para sistema intermediário) são preenchidas até o tamanho máximo da unidade de transmissão (MTU). A vantagem do preenchimento de IS-IS Hellos (IIH) até o tamanho máximo da unidade de transmissão (MTU) é que esse recurso permite a detecção antecipada de erros causados por problemas de transmissão com quadros grandes ou de incompatibilidade de MTUs nas interfaces adjacentes.

O estofamento dos IIH pode ser desligado (no Cisco IOS ® Software libera 12.0(5)T e 12.0(5)S) para todas as relações em um roteador com o comando no hello padding no modo de configuração do roteador para o processo de roteamento IS-IS. É possível desativar o preenchimento dos IIHs para interfaces ponto-a-ponto e multiponto com o comando no hello padding multi-point ou no hello padding point-to-point no modo de configuração do roteador para o processo de roteamento IS-IS. O preenchimento de saudação também pode ser desativado em cada interface, utilizando o comando no isis hello padding interface configuration.

Um usuário desabilitaria o preenchimento de hello em ordem evita desperdiçar a largura de banda de rede caso que o MTU de ambas as relações é o mesmo ou, em caso do Translational Bridging. Quando o preenchimento de hello for desabilitado, os roteadores Cisco ainda enviam o primeiro cinco tamanho do MTU acolchoado IS-IS hellos ao máximo. Esta é manter os benefícios de descobrir más combinações MTU. Os hellos consecutivos são acolchoados já não.

Este documento demonstra o que acontece quando existe uma incompatibilidade de MTU nas interfaces dos dois roteadores conectados executando IS-IS. O MTU no Roteador F teve seu valor padrão de 1500 bytes alterado para 2000 com o comando de configuração de interface mtu 2000. A interface serial “foi batida.” Consequentemente, porque o valor novo MTU para tomar o efeito, você deve desabilitar o Serial 0 com o comando shutdown, e permite-o então com o comando no shutdown.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

Convenções

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Problema

O diagrama da rede e as configurações usados para descrever este problema são mostrados aqui:

isis_mtu_01.gif

Roteador H Roteador 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

Em ambo o Roteadores, você pode ver o estado da adjacência entre o roteador F e o roteador H com o comando show clns neighbors. Na saída do Roteador F, observe que a adjacência do Roteador H está no estado INIT. Na saída do roteador H, você pode ver que a adjacência com roteador que F é tipo É, e o protocolo é extremidade Sistema-ao sistema intermediário (ES-IS). Essa saída indica que existe um problema com a adjacência do Serviço de Rede sem Conexão (CLNS).

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

Se você permite a eliminação de erros do adjacência-pacote IS-IS com o comando debug isis adj-packets, você pode ver que o roteador F envia e recebe IIH de série na subinterface de série do 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 saída mostra que o roteador H não recebe IIH em Serial0.2 do roteador F. Consequentemente, nenhuma adjacência IS-IS é formada. Em vez disso, a adjacência é Sistema Final (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

A causa do problema

O roteador H não recebe os hellos do roteador F porque os IIH são ao máximo MTU acolchoado do link, visto que os hellos ES não são acolchoados ao tamanho do MTU completo. Isto acontece porque o roteador F pensa que o MTU é 2000, e envia um 2000-byte olá!, que seja ignorado pelo roteador H.

Solução

A solução é certificar-se de que os ambos os lados de um link têm o mesmo MTU. Uma maneira de fazer isto é usar como mostrado o comando mtu aqui:

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#

Agora, o Roteador H e o Roteador F podem se tornar vizinhos e direcionar o tráfego um do outro.

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

A adjacência CLNS devido ao problema à má combinação MTU pode igualmente ser resolvida usando o comando clns mtu como mostrado aqui:

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#

Informações Relacionadas

Colaborado por engenheiros da Cisco

Este documento lhe foi útil?

Feedback

Deixe-nos ajudar