Um vizinho IS-IS que se recusa a se formar, ou uma rota que nunca aparece onde deveria, quase sempre se resume a uma de um punhado de incompatibilidades de parâmetros — não a um bug do protocolo. Esta é a ordem de diagnóstico que isola qual: primeiro o estado da interface, depois o System ID / nível / área, depois o MTU contado na camada certa, depois o escopo da importação de rotas — mais três casos reais de campo e os comandos display a executar em cada etapa.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
Os vizinhos IS-IS não falham de formas criativas — falham sempre das mesmas seis ou sete maneiras, numa ordem previsível.
Um vizinho IS-IS que não se forma, ou uma rota que discretamente se recusa a ir para onde deveria, é um dos chamados mais comuns em implantações IS-IS multifabricante — precisamente porque o protocolo empacota várias verificações independentes (unicidade do System ID, MTU, nível, endereço de área, autenticação) em uma única troca de Hello, e basta uma delas falhar para bloquear silenciosamente todo o resto. O instinto é comparar as configurações completas lado a lado; é mais rápido percorrer as verificações na ordem em que o próprio roteador as avalia.
A seguir está o fluxo de diagnóstico no qual isto se baseia, os comandos exatos para cada etapa, três casos reais de campo — uma incompatibilidade de tipo de custo na importação de rotas que prefere silenciosamente o caminho errado, um valor de MTU que significa algo diferente em cada equipamento de fabricante, e uma carga de Hello do IS-IS que quebrou a acessibilidade de um dispositivo que nunca deveria rodar IS-IS — e respostas às perguntas que aparecem constantemente depois das verificações básicas.
Os problemas de IS-IS se dividem como a maioria dos problemas de adjacência L2/L3: o vizinho nunca se forma, ou se forma e algo a jusante ainda está errado.
Colocar primeiro o sintoma nesta árvore indica de imediato se você está perseguindo um problema de interface/Hello ou um problema a nível de rota — os dois não compartilham a mesma causa raiz.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
As falhas de System ID, nível e MTU são lidas diretamente nos contadores de display isis interface e display isis error — são a própria maquinaria do protocolo IS-IS. O comportamento da importação de rotas (cost-type, escopo de nível) é uma escolha de configuração separada sobreposta, e vale a pena verificá-la isoladamente mesmo depois de o vizinho já estar saudável.
Quatro verificações, um comando cada — e uma lista rápida do que verificar exatamente quando display isis error aponta para um contador específico.
O campo de estado de display isis interface indica se é um problema de link antes mesmo de abrir a configuração do IS-IS.
<Huawei> display isis interface
IS-IS(1) Interface Information
Interface Id IPV4.State IPV6.State MTU Type DIS
GE0/0/1 001 Up Down 1497 L1/L2 No/No
// Lnk:Dn or IP:Dn instead of Up -> chase the interface/route layer, not IS-IS
<Huawei> display current-configuration configuration isis
isis 1
network-entity 49.0001.0000.0000.0001.00
// no network-entity line at all -> IS-IS never actually started on this box
<Huawei> display isis statistics packet interface GigabitEthernet0/0/1
L1 IIH: 0 L2 IIH: 42
// counter not increasing over a 10s+ window -> Hello isn't reaching this interfacedisplay isis error transforma um palpite em um contador específico — Repeated System ID e Mismatched Level são duas correções completamente diferentes.
<Huawei> display isis error interface GigabitEthernet0/0/1
Repeated System ID: 0 Mismatched Level: 17 Bad Area Addr TLV: 0
// Mismatched Level climbing -> compare is-level / isis circuit-level on both ends
<Huawei> display current-configuration configuration isis | include is-level
is-level level-1
// peer's interface is configured level-2-only -> the two will never adjacencyA falha IS-IS multifabricante mais comum não é um valor de MTU errado — é o mesmo número significando duas coisas diferentes.
# Huawei-side IS-IS configuration
isis 1
is-level level-2
cost-style wide
network-entity 49.X.X.X.X.00
#
interface Vlanif1001
mtu 9126 // this device: mtu is the Layer 3 payload size
ip address X.X.X.150 255.255.255.252
isis enable 1
# Other-vendor IS-IS configuration
router isis XXXX
net 49.X.X.X.X.00
metric-style wide
#
interface XXXX
mtu 9126 // peer: same command, but this is the Layer 2 frame size
circuit-type level-2-only
// peer's real L3 ceiling is 9126 - 14 (Ethernet header) = 9112, below Huawei's Hello size
[Huawei-Vlanif1001] mtu 9112
// or, to stop Hello depending on MTU matching at all:
[Huawei-Vlanif1001] isis small-hello
[Peer-interface] hello-padding disable level 2Um vizinho saudável não significa que as rotas importadas cheguem onde você espera, nem que sejam preferidas como você espera.
[DeviceA-isis-1] import-route direct cost-type internal
[DeviceA-isis-1] import-route static cost-type internal
// align cost-type on every device importing the same prefixes
<DeviceB> display isis route
// after aligning cost-type, DeviceB and DeviceC learn two equal-cost paths
// via DeviceA and DeviceD instead of only ever preferring one
[Huawei] interface vlanif 3005
[Huawei-Vlanif3005] isis silent
// suppresses IS-IS Hello toward a directly connected non-router deviceDepois que as verificações acima indicarem onde está o problema, estas cinco causas cobrem a maior parte do que realmente está errado.
SINTOMADois dispositivos de borda importam as mesmas rotas diretamente conectadas ou estáticas para o IS-IS, mas os dispositivos do núcleo só aprendem a rota através de um deles — o outro caminho nunca é usado, sem nenhum erro em lugar algum.
CAUSAimport-route usa por padrão cost-type external (adiciona +64 ao custo original) a menos que especificado de outra forma. Se um dispositivo estiver definido como internal e o par ficar em external, o caminho de menor custo sempre vence mesmo quando ambos os caminhos deveriam ser viáveis para balanceamento de carga. Isso só realmente se manifesta quando o processo IS-IS roda em cost-style narrow.
SOLUÇÃOConfigure import-route direct cost-type internal e import-route static cost-type internal de forma idêntica em cada dispositivo de borda que importe os mesmos prefixos, para que o custo reflita apenas a métrica original nos dois lados.
[DeviceD-isis-1] import-route static cost-type internal
// DeviceD's default (external, +64) was what made DeviceB/C always prefer itSINTOMAA interface está Up, o IP é alcançável, os parâmetros de IS-IS estão todos corretos individualmente, mas o vizinho nunca se forma através de uma agregação de links para um equipamento de outro fabricante.
CAUSAO comando mtu desta plataforma define o tamanho da carga útil de camada 3; o padrão do outro fabricante define em vez disso um tamanho de quadro de camada 2. Ambos os lados configuraram mtu 9126 acreditando que coincidiam — mas o real teto de camada 3 do par era 9126 menos o cabeçalho Ethernet de 14 bytes, ou seja, 9112, então o Hello grande demais nunca passava.
SOLUÇÃOConfigure o MTU deste lado como o MTU de camada 2 do par menos 14, ou contorne a verificação por completo com isis small-hello neste lado e hello-padding disable level 2 no par.
SINTOMAdisplay isis error mostra Mismatched Level subindo, ou a máquina de estados do vizinho nunca avança além de Init.
CAUSAUma interface Level-1 só forma adjacência com um par configurado Level-1 ou Level-1-2; Level-2 apenas com Level-2 ou Level-1-2. Para adjacências Level-1 especificamente, o endereço de área do network-entity também precisa coincidir nas duas pontas — adjacências Level-2 ignoram completamente essa verificação.
SOLUÇÃOAlinhe is-level sob o processo IS-IS (ou isis circuit-level na interface) nas duas pontas, e para links Level-1 confirme que a parte de endereço de área do network-entity de ambos os dispositivos é idêntica.
SINTOMAUma rota claramente foi importada — ela aparece na tabela de roteamento local, import-route está configurado — mas nunca aparece em um dispositivo somente Level-1 em outra área.
CAUSAimport-route sem uma palavra-chave de nível explícita só injeta a rota no Level 2. Nada disso falha ruidosamente — a rota simplesmente não é anunciada no Level 1 a menos que seja instruída a isso.
SOLUÇÃOEspecifique o nível explicitamente — import-route direct level-1 (ou level-1-2) — onde quer que a rota precise chegar a uma área somente Level-1.
[Huawei-isis-1] import-route direct level-1-2
// without level-1 / level-1-2, the route only ever reaches Level 2SINTOMAUm dispositivo diretamente conectado que não é um roteador — um codificador/decodificador, um servidor — começa respondendo a ping, depois fica intermitente, depois para de responder completamente, mesmo sem nada mudar do lado da rede.
CAUSAA interface do lado Huawei tem o IS-IS habilitado e envia pacotes Hello periódicos por design. Alguns dispositivos que não são roteadores lidam tão mal com o tráfego Hello inesperado do IS-IS que ele atropela o próprio processamento de solicitações ARP/ICMP, degradando e eventualmente bloqueando a acessibilidade básica — sem nada do lado do IS-IS para apontar.
SOLUÇÃOConfigure isis silent nas interfaces voltadas para servidores, codificadores, ou qualquer dispositivo que nunca deveria estabelecer adjacência com protocolos de roteamento de camada 3 — isso suprime tanto o envio quanto o recebimento de pacotes IS-IS nessa interface sem desabilitar a interface em si.
Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.
O MTU físico do Ethernet é de 1500 bytes de qualquer forma. Em um link P2P (encapsulado em PPP), o IS-IS reporta o 1500 completo. Em um link de broadcast (802.3), o cabeçalho LLC sobre o qual o IS-IS roda adiciona 3 bytes dentro desse mesmo quadro de 1500 bytes, então a carga útil realmente disponível para o IS-IS é 1497 — não é um erro de configuração, apenas uma sobrecarga de encapsulamento diferente.
Uma interface Level-1 só forma adjacência com um par Level-1 ou Level-1-2. Uma interface Level-2 só forma com Level-2 ou Level-1-2. Uma interface Level-1-2 forma adjacência com qualquer um dos três. Se essa única regra não for satisfeita, mais nada na configuração importa.
O motivo mais comum é o escopo, não a sintaxe: import-route sem palavra-chave de nível só injeta a rota no Level 2 por padrão. Se a área de destino for somente Level-1, a rota nunca foi enviada para lá — adicione level-1 ou level-1-2 explicitamente ao import-route para corrigir.
O IS-IS depende do System ID para identificar de forma única cada dispositivo no domínio de roteamento. Dois dispositivos compartilhando um se parecem, do ponto de vista do protocolo, com o mesmo roteador aparecendo em duas interfaces ao mesmo tempo — o contador Repeated System ID de display isis error sobe, a adjacência nunca se completa, e a correção é simplesmente mudar o network-entity de um dispositivo para que a parte do System ID seja única.
A interação entre o cost-type internal/external do import-route e a preferência de caminho resultante só é realmente visível sob cost-style narrow, onde a penalidade de +64 para external e o custo repassado sem alteração para internal realmente mudam qual caminho vence. Sob cost-style wide, a faixa de métrica é grande o suficiente para que essa incompatibilidade específica tenha muito menos chance de virar sozinha o caminho preferido — mas ainda vale a pena definir o cost-type de forma idêntica em cada dispositivo que importe os mesmos prefixos.
Primeiro a prioridade — a interface com o isis dis-priority mais alto vence; em caso de empate, vence o SNPA (endereço MAC) mais alto na interface. Diferente do DR do OSPF, o DIS do IS-IS não tem backup BDR e reexecuta essa eleição imediatamente se um roteador de prioridade mais alta entrar no segmento, o que vale a pena saber antes de supor que uma mudança de DIS significa que algo realmente está quebrado.
Esta nota se baseia no modelo de classificação de falhas de IS-IS do roteador Huawei série AR e seus comandos display isis interface / isis error / isis statistics packet, além dos casos de campo por trás deles. Se o seu equipamento for de outro fabricante, os comandos exatos mudam, mas a lógica de adjacência subjacente — estado da interface, unicidade do System ID, correspondência de nível e área, contagem de camada do MTU, escopo da importação de rotas — se aplica diretamente. Não cobre em profundidade casos específicos de eleição de DIS em grandes LANs de acesso múltiplo, nem detalhes específicos da família de endereços IPv6 (M-ISIS).
Conte-nos em qual verificação o display isis error está falhando — Repeated System ID, Mismatched Level, ou outra coisa — junto com o estado da interface, e ajudamos você a interpretar.