Comportamento de preenchimento de saudação IS-IS

Introduction

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

Informações de Apoio

Por padrão, o IS-IS envia os pacotes Hello para a MTU (Unidade máxima de transmissão) de interface completa. Isso serve para detectar incompatibilidades de MTU. A MTU em cada lado do link deve corresponder. O preenchimento também pode ser usado para detectar o valor real de MTU da tecnologia que está abaixo. Por exemplo, para o transporte da Camada 2 (L2) em cenários de Multi Protocol Label Switching (MPLS), 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 preenchimento poderá ser desativado. Como tal, o uso desnecessário de largura de banda e buffers por pacotes Hello IS-IS pode ser evitado. O comando do roteador usado para desativar o preenchimento Hello é no hello padding [multipoint|point-to-point]. O comando de interface usado para desativar o preenchimento Hello é no isis hello padding.

Se o preenchimento estiver desativado no início, o roteador ainda enviará pacotes Hello na MTU completa. Para evitar isso, desabilite o preenchimento com o comando de interface e use a palavra-chave always. Nesse caso, todos os pacotes IS-IS Hello não são preenchidos.

Note: A Cisco recomenda que você não desabilite o preenchimento de saudação IS-IS 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.

TLVs de preenchimento

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

Exemplo de TLV de preenchimento

O exemplo fornecido na imagem a seguir é usado nesta seção para explicar o MTU e a desabilitação do preenchimento de Hello no IS-IS:

 

Neste exemplo, PE1 e PE2 configuraram um Circuito Virtual (VC) 100 entre eles para conectar os roteadores R1 e R2 em L2. Esse 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 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

A 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 apenas pacotes de 1.500 bytes, menos oito bytes (dois rótulos MPLS para o serviço MPLS), que equivalem a 1.492 bytes (o tamanho do pacote que pode passar). Para o transporte de L2 sobre MPLS, o tamanho do cabeçalho de L2 deve ser subtraído dos 1.492 bytes que também resultam.

Sem preenchimento 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 preenchimento 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 com até 1.400 bytes de tamanho podem certamente 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 preenchimento. O tamanho agora é 1.400 bytes menos um.

Quando a MTU é baixada na interface Serial 2/0 no roteador R2, o preenchimento é 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ê a chegada do pacote IS-IS Hello do roteador R2, ele ativa a adjacência IS-IS. Como o roteador R2 também vê os pacotes IS-IS Hello do roteador R1, eventualmente a adjacência IS-IS passa para o estado UP, o que significa que uma adjacência de três vias é criada. Nesse ponto, o roteador R1 (com o preenchimento de Hello desativado na interface Serial 2/0) reduz o tamanho do pacote de 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 será ativada se nenhum dos lados 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ó aparece depois que o MTU é definido com o valor correto em cada lado do link.

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

No Hello Padding Always

Com o MTU definido como 1.500 bytes na interface Serial2/0 no roteador R1, a adjacência não surge porque os pacotes IS-IS Hello transmitidos ainda são o tamanho total 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 preenchimento 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 do IS-IS têm o tamanho mínimo. A adjacência 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 interface MTU

Se o MTU da interface não corresponder, a adjacência 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. No entanto, isso pode não ser uma correçã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 atravessa o 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 passar. Isso ocorre porque o roteador R1 acredita que o MTU é 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 eles não tiverem o bit de não fragmentação (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 da MTU é importante para o tráfego que atravessa o roteador, mas também para o tráfego que se origina do roteador e atravessa esse link. Um exemplo do último é o Border Gateway Protocol (BGP), que usa TCP e pode usar a Path MTU Discovery.

Inundação de IS-IS

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

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

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 em 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 buraco negro do tráfego.

Para resolver esse problema, você pode reduzir o MTU de LSP através do comando lsp-mtu <128-4352> IS-IS do roteador. Se você configurar esse comando apenas no roteador R2, o roteador R2 não alterará os LSPs 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, que são pequenos o suficiente para cruzar o link entre os roteadores R2 e R1.

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

Concluindo, se você tiver um link com uma MTU menor e usar o comando no isis hello padding always, isso poderá causar inundação de tráfego e buraco negro. Para resolver o problema de inundação, você pode reduzir o tamanho máximo dos LSPs, mas também deve configurar o comando lsp-mtu router IS-IS em cada roteador IS-IS.

Alterações na MTU

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

Preenchimento Hello Habilitado

Neste cenário, a rede funciona corretamente desde o início. O MTU é definido como 1.400 bytes na interface Serial2/0 nos roteadores R1 e R2. O preenchimento de Hello do 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 IS-IS através da serial está ativa e a inundação 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 de Hello está habilitado (o comportamento padrão), a adjacência IS-IS é desativada rapidamente na interface Serial2/0. Isso indica que há um problema na nuvem MPLS. Como a adjacência IS-IS é desativada, o roteamento não aponta mais para essa nuvem MPLS e nenhum tráfego fica em buraco negro por ela.

Preenchimento Hello Desabilitado

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

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 IS-IS através da serial está ativa e a inundação 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 permanecerá enquanto o tempo de atualização do LSP for atingido. Quando chegar o momento de atualizar os LSPs, a inundação será 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 após o tempo de espera ter expirado para alguns dos fragmentos 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 dos fragmentos LSP do roteador R3 atingiram o tempo limite 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 poderá ocultar um problema futuro na rede. Quando a MTU subjacente é alterada, pode causar um problema de roteamento que é muito mais difícil de resolver porque 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 de Hello ativado, o fato de a adjacência IS-IS ficar inativa facilita muito a determinação do local 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 de IS-IS funcione corretamente e que o roteador seja capaz de executar a fragmentação corretamente ou se comporte corretamente quando auxilia com a Path MTU Discovery.

O problema com a inundação de IS-IS só pode se tornar óbvio quando os LSPs se tornam maiores (quando a rede cresce). Quando o preenchimento IS-IS Hello é desabilitado, ele corrige o problema onde as adjacências IS-IS não aparecem. No entanto, a questão de inundação, tráfego de buraco negro e talvez Path MTU Discovery quebrado, pode potencialmente surgir muito mais tarde do que o momento em que o preenchimento IS-IS Hello é desabilitado. Isso torna o problema muito mais difícil de ser solucionado, o que leva muito mais tempo.