Comportamento de preenchimento de saudação IS-IS

Introduction

Este documento descreve o comportamento do preenchimento de pacote de Hello do IS-IS (Integrated Intermediate System-to-Intermediate System) no Cisco IOS^®.

Informações de Apoio

Por padrão, o IS-IS expande os pacotes Hello para a MTU (Maximum Transmission Unit, Unidade Máxima de Transmissão) da interface completa. Isso é feito para detectar incompatibilidades de MTU. A MTU em ambos os lados do link deve corresponder. O enchimento também pode ser usado para detectar o valor real de MTU da tecnologia que está abaixo. Por exemplo, para cenários de transporte de Camada 2 (L2 - Layer 2) sobre MPLS (Multi Protocol Label Switching), o MTU da tecnologia de transporte pode ser muito menor que o MTU na borda. Por exemplo, o MTU pode ter 9.000 bytes na borda, enquanto a tecnologia de transporte MPLS tem um MTU de 1.500 bytes.

Se os valores de MTU corresponderem em ambos os lados, o enchimento poderá ser desativado. Como tal, o uso desnecessário de largura de banda e buffers pelos pacotes Hello IS-IS pode ser evitado. O comando do roteador usado para desabilitar o preenchimento Hello é no hello padding [multi-point|point-to-point]. O comando de interface usado para desabilitar o preenchimento Hello é no isis hello padding.

Se o enchimento estiver desabilitado no início, o roteador ainda enviará pacotes Hello em MTU completo. Para evitar isso, desative o preenchimento com o comando interface e use a palavra-chave always. Nesse caso, todos os pacotes de saudação IS-IS não são preenchidos.

Note: A Cisco recomenda que você não desative o preenchimento IS-IS Hello para garantir que dois roteadores formem uma adjacência IS-IS em um link que tenha valores de MTU incompatíveis em ambos os lados.

Padding TLVs

Os pacotes Hello IS-IS têm um TLV (Type Length Value, valor de comprimento do tipo de preenchimento). Para um IH ponto-a-ponto (P2P), o TLV do enchimento é 8. Para a LAN IIH, o TLV para o enchimento é 8.

Exemplo de preenchimento de TLV

O exemplo fornecido na próxima imagem é usado nesta seção para explicar o MTU e a desativação do preenchimento Hello em IS-IS:

 

Neste exemplo, PE1 e PE2 configuraram um Circuito Virtual (VC - Virtual Circuit) 100 entre eles para conectar os roteadores R1 e R2 em L2. Este VC é um VC Ethernet sobre MPLS (EoMPLS).

PE1#show xconnect all
Legend:   XC ST=Xconnect State S1=Segment1 State S2=Segment2 State
UP=Up       DN=Down           AD=Admin Down     IA=Inactive
SB=Standby HS=Hot Standby     RV=Recovering     NH=No Hardware
 
XC ST Segment 1                         S1 Segment 2                         S2
------+---------------------------------+--+---------------------------------+--
UP pri   ac Se2/0(HDLC)                 UP mpls 10.100.1.5:100              UP

PE1#show mpls l2transport vc 100
 
Local intf     Local circuit             Dest address   VC ID     Status
------------- -------------------------- --------------- ---------- ----------
Se2/0         HDLC                      10.100.1.5     100       UP      

Esta é a saída do roteador R1:

interface Serial2/0
ip address 10.1.1.1 255.255.255.0
ip router isis 1
serial restart-delay 0

Esta é a saída do roteador R2:

interface Serial2/0
ip address 10.1.1.2 255.255.255.0
ip router isis 1
serial restart-delay 0

A saída do comando debug debug isis adj-packets debug fornece informações sobre a adjacência IS-IS:

R1#debug isis adj-packets
IS-IS Adjacency related packets debugging is on for router process 1

R1#
13:00:59.978: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1499
13:01:07.758: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1499
13:01:16.280: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1499

R2#
13:01:50.100: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1499
13:02:00.062: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1499
13:02:07.899: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1499

Neste cenário, a adjacência IS-IS falha.

R1#show isis neighbors
 
Tag 1:
System Id     Type Interface   IP Address     State Holdtime Circuit Id
R1#

R1#show clns interface Serial 2/0
Serial2/0 is up, line protocol is up
Checksums enabled, MTU 1500, Encapsulation HDLC
ERPDUs enabled, min. interval 10 msec.
CLNS fast switching enabled
CLNS SSE switching disabled
DEC compatibility mode OFF for this interface
Next ESH/ISH in 18 seconds
Routing Protocol: IS-IS
   Circuit Type: level-1-2
   Interface number 0x1, local circuit ID 0x101
   Level-1 Metric: 10, Priority: 64, Circuit ID: R1.01
   Level-1 IPv6 Metric: 10
   Number of active level-1 adjacencies: 0
   Next IS-IS Hello in 5 seconds
   if state DOWN

O MTU nas interfaces seriais dos roteadores R1 e R2 são os 1.500 bytes padrão.

A adjacência IS-IS falha porque os pacotes Hello IS-IS têm 1.499 bytes de tamanho. A rede MPLS permite somente pacotes de 1.500 bytes, menos oito bytes (dois rótulos MPLS para o serviço MPLS), o que equivale a 1.492 bytes (o tamanho do pacote que pode passar). Para o transporte de L2 sobre MPLS, o tamanho do cabeçalho L2 deve ser subtraído dos 1.492 bytes que também resultam.

Nenhum preenchimento de Hello

Neste cenário, o comando no isis hello padding é usado na interface Serial2/0 do roteador R1:

interface Serial2/0
ip address 10.1.1.1 255.255.255.0
ip router isis 1
serial restart-delay 0
no isis hello padding

R1#
13:03:46.712: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1499
13:03:54.717: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1499
13:04:03.057: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1499
13:04:11.538: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1499
13:04:21.301: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1499
13:04:30.636: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1499
13:04:39.958: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1499

Como mostrado, mais de cinco pacotes Hello IS-IS são enviados com tamanho MTU completo (1.497 bytes). O roteador continua a enviar os pacotes Hello com enchimento até que a adjacência IS-IS seja ativada. No entanto, a menos que o problema de MTU seja corrigido, a adjacência não aparece.

O MTU é reduzido para 1.400 bytes na interface Serial2/0 no roteador R1. Assim, os pacotes de até 1.400 bytes de tamanho certamente podem passar pela rede MPLS pelo pseudo-fio.

Esta é a saída do roteador R1:

!
interface Serial2/0
mtu 1400
ip address 10.1.1.1 255.255.255.0
ip router isis 1
serial restart-delay 0
no isis hello padding

R1#
13:07:19.428: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1399
13:07:29.024: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1399
13:07:38.185: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1399
13:07:45.715: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1399
13:07:55.351: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1399
13:08:04.814: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1399
13:08:14.216: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1399
13:08:23.447: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1399
13:08:31.676: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1399
13:08:39.966: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:DOWN, length 1399

O roteador R1 continua a transmitir os pacotes Hello com enchimento. O tamanho agora é 1.400 bytes menos um.

Depois que o MTU for baixado na interface Serial 2/0 no roteador R2, o enchimento será desativado.

Esta é a saída do roteador R2:

interface Serial2/0
mtu 1400
ip address 10.1.1.2 255.255.255.0
ip router isis 1
serial restart-delay 0

Quando o roteador R1 vê o pacote Hello IS-IS chegar do roteador R2, ele ativa a adjacência IS-IS. Como o roteador R2 também vê os pacotes Hello IS-IS do roteador R1, eventualmente a adjacência IS-IS se move para o estado UP, o que significa que uma adjacência de três vias é criada. Neste ponto, o roteador R1 (com preenchimento de Hello desativado na interface Serial 2/0) reduz o tamanho do pacote Hello ao mínimo.

R1#
13:08:47.010: ISIS-Adj: Rec serial IIH from *HDLC* (Serial2/0), cir type L1, cir id 01,
 length 1399
13:08:47.010: ISIS-Adj: newstate:1, state_changed:1, going_up:0, going_down:0
13:08:47.010: ISIS-Adj: Action = GOING UP, new type = L1
13:08:47.010: ISIS-Adj: New serial adjacency
13:08:47.010: ISIS-Adj: rcvd state INIT, old state DOWN, new state INIT, nbr usable TRUE
13:08:47.011: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:INIT, length 1399
13:08:47.055: ISIS-Adj: Rec serial IIH from *HDLC* (Serial2/0), cir type L1, cir id 01,
 length 1399
13:08:47.055: ISIS-Adj: rcvd state UP, old state INIT, new state UP, nbr usable TRUE
13:08:47.056: ISIS-Adj: newstate:0, state_changed:1, going_up:1, going_down:0
13:08:47.056: ISIS-Adj: Action = GOING UP, new type = L1
13:08:47.056: ISIS-Adj: L1 adj count 1
13:08:47.056: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:UP, length 43

Como mostrado, o roteador R1 envia um pacote Hello IS-IS com comprimento 43 e recebe os pacotes Hello do roteador R2 com comprimento 1399. Isso ocorre porque o preenchimento Hello ainda está ativo no roteador R2.

Neste exemplo, a adjacência IS-IS não aparece se qualquer lado do link ainda tiver o MTU definido como 1.500 bytes na interface Serial 2/0. Esse é o caso mesmo quando o comando no isis hello padding está ativado. A interface só é ativada depois que o MTU é definido para o valor correto em qualquer lado do link.

Assim, se você desativar apenas o preenchimento IS-IS Hello, não é suficiente ativar a adjacência IS-IS. O MTU deve ser baixo o suficiente para que os pacotes de saudação IS-IS do tamanho de MTU sejam enviados e recebidos corretamente pelos roteadores em ambos os lados do link.

Nenhum preenchimento de saudação sempre

Com o MTU definido como 1.500 bytes na interface Serial2/0 no roteador R1, a adjacência não é ativada porque os pacotes IS-IS Hello transmitidos ainda são o tamanho completo do MTU. Para contornar esse problema, você pode configurar o comando de interface no isis hello padding always na interface Serial2/0 para desabilitar o enchimento sempre.

!
interface Serial2/0
ip address 10.1.1.1 255.255.255.0
ip router isis 1
serial restart-delay 0
no isis hello padding always

Assim que esse comando é configurado, os pacotes Hello IS-IS têm o tamanho mínimo. A adjacência de IS-IS entre os roteadores R1 e R2 é imediatamente ativada.

R1#
13:25:47.284: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:INIT,
 length 43, never pad
13:25:47.328: ISIS-Adj: Rec serial IIH from *HDLC* (Serial2/0), cir type L1,
 cir id 01, length 1399
13:25:47.328: ISIS-Adj: rcvd state INIT, old state INIT, new state UP,
 nbr usable TRUE
13:25:47.328: ISIS-Adj: newstate:0, state_changed:1, going_up:1, going_down:0
13:25:47.328: ISIS-Adj: Action = GOING UP, new type = L1
13:25:47.329: ISIS-Adj: L1 adj count 1
13:25:47.330: ISIS-Adj: Sending serial IIH on Serial2/0, 3way state:UP,
 length 43, never pad
13:25:47.374: ISIS-Adj: Rec serial IIH from *HDLC* (Serial2/0), cir type L1,
 cir id 01, length 1399
13:25:47.374: ISIS-Adj: rcvd state UP, old state UP, new state UP,
 nbr usable TRUE
13:25:47.375: ISIS-Adj: newstate:0, state_changed:0, going_up:0, going_down:0
13:25:47.375: ISIS-Adj: Action = ACCEPT
13:25:47.375: ISIS-Adj: ACTION_ACCEPT:

O problema com IS-IS e MTU da interface

Se o MTU da interface não tiver correspondência, a adjacência de IS-IS não será ativada. Para uma correção rápida, você pode desativar o preenchimento IS-IS Hello com a palavra-chave always. Entretanto, isso pode não ser uma solução real.

Esta é a saída do roteador R1:

interface Serial2/0
ip address 10.1.1.1 255.255.255.0
ip router isis 1
serial restart-delay 0
no isis hello padding always

A adjacência IS-IS está ativa.

R1#show isis neighbors
 
Tag 1:
System Id     Type Interface   IP Address     State Holdtime Circuit Id
R2             L1   Se2/0       10.1.1.2       UP   22       01

Aqui está um ping enviado do roteador R1 para o roteador R3 para verificar o tráfego que passa pelo link:

R1#ping 10.100.1.3 source 10.100.1.1 size 1400 repeat 1
Type escape sequence to abort.
Sending 1, 1400-byte ICMP Echos to 10.100.1.3, timeout is 2 seconds:
Packet sent with a source address of 10.100.1.1
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 44/44/44 ms

R1#ping 10.100.1.3 source 10.100.1.1 size 1500 repeat 1
Type escape sequence to abort.
Sending 1, 1500-byte ICMP Echos to 10.100.1.3, timeout is 2 seconds:
Packet sent with a source address of 10.100.1.1
.
Success rate is 0 percent (0/1)

Como mostrado, os pacotes com um tamanho de 1.500 bytes não fazem isso. Isso ocorre porque o roteador R1 acredita que o MTU é de 1.500 bytes na interface Serial2/0:

R1#show interfaces Serial2/0
Serial2/0 is up, line protocol is up
Hardware is M4T
Internet address is 10.1.1.1/24
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, crc 16, loopback not set
Keepalive set (10 sec)
Restart-Delay is 0 secs
Last input 00:00:01, output 00:00:01, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations 0/1/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 1158 kilobits/sec
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
     590 packets input, 283131 bytes, 0 no buffer
     Received 567 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     693 packets output, 313789 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out
     3 carrier transitions     DCD=up DSR=up DTR=up RTS=up CTS=up

Se o MTU for reduzido para 1.400 bytes na interface Serial2/0, o roteador R1 poderá fragmentar os pacotes se os pacotes não tiverem o bit Do Not fragment (DF) definido. Se os pacotes tiverem o bit DF definido, o roteador poderá enviar de volta uma mensagem ICMP 3/4, que é usada pela Path MTU Discovery. Isso permite que o remetente dos pacotes reduza o tamanho dos pacotes que ele envia. A configuração correta do MTU é importante para o tráfego que atravessa o roteador, mas também para o tráfego que se origina do roteador e cruza esse link. Um exemplo deste último é o Border Gateway Protocol (BGP), que usa TCP e pode usar a Path MTU Discovery.

Inundação IS-IS

Para corrigir o problema de adjacência IS-IS, o operador da rede pode desativar o preenchimento Hello com a palavra-chave always. O MTU do link serial é deixado em 1.500 bytes.

Ainda há a questão da inundação IS-IS. Quando o banco de dados IS-IS é pequeno, não há problema.

R1#debug isis update-packets
IS-IS Update related packet debugging is on for router process 1

Quando o roteador R3 adiciona um prefixo e inunda isso, o roteador R1 recebe o roteador R3 Link State PDU (LSP) do roteador R2.

R1#
*Nov 19 13:53:58.227: ISIS-Upd: Rec L1 LSP 0000.0000.0003.00-00, seq B, ht 1197,
*Nov 19 13:53:58.227: ISIS-Upd: from SNPA *HDLC* (Serial2/0)
*Nov 19 13:53:58.227: ISIS-Upd: LSP newer than database copy
*Nov 19 13:53:58.227: ISIS-Upd: TLV contents different, code 130
*Nov 19 13:53:58.228: ISIS-Upd: TID 0 leaf routes changed

Quando o número de prefixos anunciados pelo roteador R3 aumenta, o LSP do roteador R3 é tão grande que é dividido em vários fragmentos:

R3#show isis database
 
Tag 1:
IS-IS Level-1 Link State Database:
LSPID               LSP Seq Num LSP Checksum LSP Holdtime     ATT/P/OL
R1.00-00             0x0000000C   0x5931       1137             0/0/0
R2.00-00             0x0000000B   0xCB7D       1162             0/0/0
R3.00-00           * 0x0000000D   0xF637       1104             0/0/0
R3.00-01           * 0x00000001   0x6AD8       1104             0/0/0
R3.00-02           * 0x00000001   0xB58A       1104             0/0/0
R3.01-00           * 0x00000002   0x9BB1       387              0/0/0
 
Tag null:

O R3.00-00 é o primeiro fragmento, o R3.00-01 é o segundo fragmento, e assim por diante.

R2#
14:22:15.584: ISIS-Upd: Retransmitting L1 LSP 0000.0000.0003.00-00 on Serial2/0
14:22:15.624: ISIS-Upd: Sending L1 LSP 0000.0000.0003.00-00, seq E, ht 467 on
 Serial2/0
14:22:18.352: ISIS-Snp: Rec L1 CSNP from 0000.0000.0003 (Ethernet1/0)
14:22:20.625: ISIS-Upd: Retransmitting L1 LSP 0000.0000.0003.00-00 on Serial2/0
14:22:20.657: ISIS-Upd: Sending L1 LSP 0000.0000.0003.00-00, seq E, ht 462 on
 Serial2/0

Esse é o LSP que é retransmitido pelo roteador R2 pela interface Serial2/0. O comprimento da PDU é de 1.490 bytes, portanto o tamanho desse pacote não permite que ele acesse o roteador R1.

Enquanto a adjacência IS-IS entre os roteadores R1 e R2 está ativa, o roteador R1 tem menos prefixos IP na sua tabela de roteamento:

R1#show isis neighbors
 
Tag 1:
System Id     Type Interface   IP Address     State Holdtime Circuit Id
R2             L1   Se2/0       10.1.1.2       UP   25       01

R2#show isis neighbors
 
Tag 1:
System Id     Type Interface   IP Address     State Holdtime Circuit Id
R1             L1   Se2/0       10.1.1.1       UP   26       01
R3             L1   Et1/0       10.1.2.3       UP   8        R3.01            

R2#show ip route summary
IP routing table name is default (0x0)
IP routing table maximum-paths is 32
Route Source   Networks   Subnets     Replicates Overhead   Memory (bytes)
connected       0           5           0           360         900
static          0           0           0           0           0
application     0           0           0           0           0
isis 1          0           252         0           18144       45360
Level 1: 252 Level 2: 0 Inter-area: 0
internal        1                                               10620
Total           1           257         0           18504       56880

R1#show ip route summary
IP routing table name is default (0x0)
IP routing table maximum-paths is 32
Route Source   Networks   Subnets     Replicates Overhead   Memory (bytes)
connected        0           3           0           216         540
static           0           0           0           0           0
application      0           0           0           0           0
isis 1           0           2           0           144         360
Level 1: 2 Level 2: 0 Inter-area: 0
internal          1                                              560
Total           1           5           0           360         1460

Isso ocorre porque o LSP R3.00-00 do roteador R3 não alcança o roteador R1.

R3#show isis database
 
Tag 1:
IS-IS Level-1 Link State Database:
LSPID                 LSP Seq Num LSP Checksum LSP Holdtime     ATT/P/OL
R1.00-00             0x0000000E   0x5533       1009              0/0/0
R2.00-00             0x0000000C   0xC97E       453               0/0/0
R3.00-00           * 0x0000000F   0xF239       1045              0/0/0
R3.00-01           * 0x00000003   0x66DA       1098              0/0/0
R3.00-02           * 0x00000003   0xB18C       1060              0/0/0
R3.01-00           * 0x00000004   0x97B3       554               0/0/0
 
Tag null:

R1#show isis database
 
Tag 1:
IS-IS Level-1 Link State Database
LSPID                 LSP Seq Num LSP Checksum LSP Holdtime     ATT/P/OL
R1.00-00           * 0x0000000E   0x5533       1008              0/0/0
R2.00-00             0x0000000C   0xC97E       449               0/0/0
R3.00-01             0x00000002   0x68D9       223               0/0/0
R3.00-02             0x00000002   0xB38B       246               0/0/0
R3.01-00             0x00000004   0x97B3       545               0/0/0

O roteador R1 não tem o primeiro fragmento do LSP L1 (R3.00-00) do roteador R3. Esse primeiro fragmento é o maior e contém a maioria dos prefixos nesse caso. Por esse motivo, o roteador R1 não tem alguns dos prefixos, o que causa o holocaute do tráfego.

Para resolver esse problema, você pode reduzir o LSP MTU por meio do comando lsp-mtu <128-4352> IS-IS do roteador. Se você configurar esse comando somente no roteador R2, o roteador R2 não altera os LSPs que são recebidos do roteador R3 de nenhuma forma. Isso significa que se o roteador R2 receber um LSP com um tamanho de 1.490 bytes, o roteador R2 não o fragmentará. Se você configurar o comando lsp-mtu 1400 no roteador R3, o roteador R3 criará LSPs menores, pequenos o suficiente para cruzar o link entre os roteadores R2 e R1.

O comprimento da PDU agora é de 1.394 bytes se você configurar o comando lsp-mtu 1400 no roteador R3:

Para concluir, se você tiver um link com uma MTU menor e usar o comando no isis hello padding always, ele pode levar a uma inundação de tráfego e à retenção de negros. Para resolver o problema de inundação, você pode reduzir o tamanho máximo dos LSPs, mas também deve configurar o comando IS-IS do roteador lsp-mtu em cada roteador IS-IS.

Alterações na MTU

Esta seção descreve os efeitos das alterações feitas no MTU subjacente.

Preenchimento de Hello ativado

Neste cenário, a rede funciona corretamente desde o início. O MTU está definido como 1.400 bytes na interface Serial2/0 nos roteadores R1 e R2. O preenchimento Hello IS-IS está ativado, que é o comportamento padrão.

Esta é a saída do roteador R1:

interface Serial2/0
mtu 1400
ip address 10.1.1.1 255.255.255.0
ip router isis 1
serial restart-delay 0

Esta é a saída do roteador R2:

interface Serial2/0
mtu 1400
ip address 10.1.1.2 255.255.255.0
ip router isis 1
serial restart-delay 0

R1#show isis neighbors
 
Tag 1:
System Id     Type Interface   IP Address     State Holdtime Circuit Id
R2             L1   Se2/0       10.1.1.2       UP   23       01

R2#show isis neighbors
 
Tag 1:
System Id     Type Interface   IP Address     State Holdtime Circuit Id
R1             L1   Se2/0       10.1.1.1       UP   27       01
0000.0000.0003 L1   Et1/0       10.1.2.3       UP   7       0000.0000.0003.01

A adjacência de IS-IS na série está ativa e a inundação de IS-IS está boa.

Em um determinado momento, ocorre um problema na rede do provedor de serviços MPLS que faz com que o MTU de ponta a ponta entre o PE1 e o PE2 caia abaixo de 1.400 bytes.

Como o preenchimento Hello está ativado (o comportamento padrão), a adjacência IS-IS rapidamente fica inativa na interface Serial2/0. Isso indica que há um problema na nuvem MPLS. Como a adjacência de IS-IS é desativada, o roteamento não aponta mais para essa nuvem MPLS, e nenhum tráfego é totalmente isolado.

Preenchimento de Hello desativado

Neste cenário, a rede funciona corretamente desde o início. O MTU está definido como 1.400 bytes na interface Serial2/0 nos roteadores R1 e R2. O preenchimento Hello IS-IS está desativado.

Esta é a saída do roteador R1:

!
interface Serial2/0
mtu 1400
ip address 10.1.1.1 255.255.255.0
ip router isis 1
serial restart-delay 0
no isis hello padding

Esta é a saída do roteador R2:

!
interface Serial2/0
mtu 1400
ip address 10.1.1.2 255.255.255.0
ip router isis 1
serial restart-delay 0
no isis hello padding

A adjacência de IS-IS na série está ativa e a inundação de IS-IS está boa.

Este é o banco de dados do roteador R1:

R1#show isis database
 
Tag 1:
IS-IS Level-1 Link State Database:
LSPID                 LSP Seq Num LSP Checksum LSP Holdtime     ATT/P/OL
R1.00-00           * 0x0000001D   0x3742       1148              0/0/0
R2.00-00             0x0000001D   0xA78F       1161              0/0/0
R3.00-00             0x00000016   0xAFE4       454               0/0/0
R3.00-01             0x0000000B   0x0A0B       393               0/0/0
R3.00-02             0x0000000B   0xC2A5       451               0/0/0
R3.01-00             0x00000009   0x8DB8       435               0/0/0

Em um determinado momento, ocorre um problema na rede do provedor de serviços MPLS que faz com que o MTU de ponta a ponta entre o PE1 e o PE2 caia abaixo de 1.400 bytes.

O IS-IS não é afetado imediatamente, mas o tráfego IP pode ser. Se houver tráfego com pacotes de 1.400 bytes de tamanho, eles serão descartados na rede MPLS.

Se a rede estiver estável, não haverá inundação por muito tempo. Isso permanece enquanto o tempo de atualização do LSP for atingido. Depois que for hora de atualizar o(s) LSP(s), a inundação é interrompida na rede MPLS.

R2#
15:27:07.848: ISIS-Upd: Retransmitting L1 LSP 0000.0000.0003.00-01 on Serial2/0
15:27:07.880: ISIS-Upd: Sending L1 LSP 0000.0000.0003.00-01, seq C, ht 1147 on
 Serial2/0
15:27:12.883: ISIS-Upd: Retransmitting L1 LSP 0000.0000.0003.00-01 on Serial2/0
15:27:12.924: ISIS-Upd: Sending L1 LSP 0000.0000.0003.00-01, seq C, ht 1142 on
 Serial2/0

Este é o banco de dados IS-IS do roteador R1 depois que o problema ocorre na rede MPLS:

R1#show isis database
 
Tag 1:
IS-IS Level-1 Link State Database:
LSPID                 LSP Seq Num LSP Checksum LSP Holdtime     ATT/P/OL
R1.00-00           * 0x0000001D   0x3742       725               0/0/0
R2.00-00             0x0000001D   0xA78F       737               0/0/0
R3.00-00             0x00000016   0xAFE4       30                0/0/0
R3.00-01             0x0000000B   0xCE1F       0 (30)            0/0/0
R3.00-02             0x0000000C   0xC0A6       895               0/0/0
R3.01-00             0x0000000A   0x8BB9       906               0/0/0

Este é o banco de dados depois que o tempo de espera expirou para alguns dos fragmentos de LSP do roteador R3:

R1#show isis database
 
Tag 1:
IS-IS Level-1 Link State Database:
LSPID                LSP Seq Num LSP Checksum LSP Holdtime     ATT/P/OL
R1.00-00           * 0x0000001D   0x3742       605               0/0/0
R2.00-00             0x0000001D   0xA78F       618               0/0/0
R3.00-02             0x0000000C   0xC0A6       775               0/0/0
R3.01-00             0x0000000A   0x8BB9       787               0/0/0

Os fragmentos R3.00-00 e R3.00-01 não aparecem mais no roteador R1 e as rotas do roteador R3 não estão mais no roteador R1:

R1#show ip route summary
IP routing table name is default (0x0)
IP routing table maximum-paths is 32
Route Source   Networks   Subnets     Replicates Overhead   Memory (bytes)
connected       0           3           0           216         540
static          0           0           0           0           0
application     0           0           0           0           0
isis 1          0           2           0           144         360
Level 1: 2 Level 2: 0 Inter-area: 0
internal        1                                               560
Total           1           5           0           360         1460

Como mostrado, alguns fragmentos de LSP do R3 do roteador têm tempo limite esgotado e não aparecem. Isso faz com que algumas das rotas não apareçam na tabela de roteamento.

Se você desabilitar o preenchimento Hello, ele pode ocultar um problema futuro na rede. Quando o MTU subjacente é alterado, ele pode causar um problema de roteamento muito mais difícil de ser solucionado, pois você deve examinar a tabela de roteamento e o banco de dados IS-IS em vários roteadores para identificar o problema. Com o preenchimento Hello ativado, o fato de a adjacência IS-IS ser desativada torna muito mais fácil determinar a localização do problema.

Notas importantes

A melhor solução é definir o MTU para o valor correto nos links e garantir que ele seja igual em ambos os lados dos links. Isso garante que a inundação IS-IS funcione corretamente e que o roteador seja capaz de executar a fragmentação corretamente ou se comportar corretamente quando auxilia na descoberta da MTU do caminho.

O problema com a inundação IS-IS só pode se tornar óbvio quando os LSPs se tornam maiores (quando a rede cresce). Quando o preenchimento Hello IS-IS está desativado, ele corrige o problema em que as adjacências IS-IS não aparecem. No entanto, a questão da inundação, do tráfego de retenção de negros e, talvez, da descoberta de MTU de caminho quebrado, pode surgir muito mais tarde do que o horário em que o preenchimento de saudação IS-IS está desabilitado. Isso torna o problema muito mais difícil de ser solucionado, o que leva muito mais tempo.