Para parceiros
Este documento descreve o comportamento do preenchimento de pacote de Hello do IS-IS (Integrated Intermediate System-to-Intermediate System) no Cisco IOS®.
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.
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.
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.
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.
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:
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.
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.
Esta seção descreve os efeitos das alterações feitas no MTU subjacente.
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.
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.
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.