Un vecino IS-IS que se niega a formarse, o una ruta que nunca aparece donde se espera, casi siempre se reduce a una de un puñado de discrepancias de parámetros — no a un error del protocolo. Este es el orden de diagnóstico que aísla cuál: primero el estado de la interfaz, luego el System ID / nivel / área, luego el MTU contado en la capa correcta, luego el alcance de la importación de rutas — más tres casos reales de campo y los comandos display a ejecutar en cada paso.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
Los vecinos IS-IS no fallan de formas creativas — fallan siempre de las mismas seis o siete maneras, en un orden predecible.
Un vecino IS-IS que no se forma, o una ruta que discretamente se niega a ir adonde debería, es uno de los tickets más comunes en despliegues IS-IS multifabricante — precisamente porque el protocolo agrupa varias comprobaciones independientes (unicidad del System ID, MTU, nivel, dirección de área, autenticación) en un solo intercambio Hello, y basta con que una falle para bloquear silenciosamente todo lo demás. El instinto es comparar las configuraciones completas lado a lado; es más rápido recorrer las comprobaciones en el orden en que el propio router las evalúa.
A continuación, el flujo de diagnóstico en el que se basa este texto, los comandos exactos para cada etapa, tres casos reales de campo — una discrepancia de tipo de costo en la importación de rutas que prefiere silenciosamente la ruta equivocada, un valor de MTU que significa algo distinto en cada equipo de cada fabricante, y una carga de Hello de IS-IS que rompió la accesibilidad de un dispositivo que nunca debía ejecutar IS-IS — y respuestas a las preguntas que surgen constantemente una vez superadas las bases.
Los problemas de IS-IS se dividen igual que la mayoría de problemas de adyacencia L2/L3: el vecino nunca se forma, o se forma y algo aguas abajo sigue sin funcionar.
Ubicar primero el síntoma en este árbol indica de inmediato si se está persiguiendo un problema de interfaz/Hello o un problema a nivel de ruta — los dos no comparten causa raíz.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Las fallas de System ID, nivel y MTU se leen directamente en los contadores de display isis interface y display isis error — son la maquinaria propia del protocolo IS-IS. El comportamiento de la importación de rutas (cost-type, alcance de nivel) es una elección de configuración distinta superpuesta, y vale la pena revisarla por separado incluso cuando el vecino ya está sano.
Cuatro comprobaciones, un comando cada una — y una lista rápida de qué revisar exactamente cuando display isis error señala un contador específico.
El campo de estado de display isis interface indica si se trata de un problema de enlace antes incluso de abrir la configuración 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 convierte una suposición en un contador específico — Repeated System ID y Mismatched Level son dos soluciones completamente distintas.
<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 adjacencyLa falla IS-IS multifabricante más común no es un valor de MTU incorrecto — es el mismo número significando dos cosas distintas.
# 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 2Que el vecino esté sano no significa que las rutas importadas lleguen adonde se espera, ni que se prefieran como se 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 deviceUna vez que las comprobaciones anteriores han indicado dónde está el problema, estas cinco causas cubren la mayoría de lo que realmente falla.
SÍNTOMADos dispositivos de borde importan las mismas rutas directamente conectadas o estáticas a IS-IS, pero los dispositivos del núcleo solo aprenden la ruta a través de uno de ellos — la otra ruta nunca se usa, sin ningún error en ninguna parte.
CAUSAimport-route por defecto usa cost-type external (añade +64 al costo original) a menos que se indique lo contrario. Si un dispositivo está en internal y el par se deja en external, la ruta de menor costo siempre gana aunque ambas rutas deberían ser viables para reparto de carga. Esto solo se manifiesta realmente cuando el proceso IS-IS corre en cost-style narrow.
SOLUCIÓNConfigure import-route direct cost-type internal e import-route static cost-type internal de forma idéntica en cada dispositivo de borde que importe los mismos prefijos, para que el costo refleje solo la métrica original en ambos lados.
[DeviceD-isis-1] import-route static cost-type internal
// DeviceD's default (external, +64) was what made DeviceB/C always prefer itSÍNTOMALa interfaz está Up, el IP es alcanzable, los parámetros de IS-IS son correctos individualmente, pero el vecino nunca se forma a través de una agregación de enlaces hacia un equipo de otro fabricante.
CAUSAEl comando mtu de esta plataforma define el tamaño de carga útil de capa 3; el predeterminado del otro fabricante define en cambio un tamaño de trama de capa 2. Ambos lados configuraron mtu 9126 creyendo que coincidían — pero el verdadero techo de capa 3 del par era 9126 menos el encabezado Ethernet de 14 bytes, es decir 9112, así que el Hello sobredimensionado nunca pasaba.
SOLUCIÓNConfigure el MTU de este lado como el MTU de capa 2 del par menos 14, o evite la comprobación por completo con isis small-hello en este lado y hello-padding disable level 2 en el par.
SÍNTOMAdisplay isis error muestra Mismatched Level subiendo, o la máquina de estados del vecino nunca avanza más allá de Init.
CAUSAUna interfaz Level-1 solo forma adyacencia con un par configurado Level-1 o Level-1-2; Level-2 solo con Level-2 o Level-1-2. Para las adyacencias Level-1 en particular, la dirección de área de network-entity también debe coincidir en ambos extremos — las adyacencias Level-2 omiten esa comprobación por completo.
SOLUCIÓNAlinee is-level bajo el proceso IS-IS (o isis circuit-level en la interfaz) en ambos extremos, y para enlaces Level-1 confirme que la parte de dirección de área de network-entity de ambos dispositivos es idéntica.
SÍNTOMAUna ruta claramente fue importada — aparece en la tabla de enrutamiento local, import-route está configurado — pero nunca aparece en absoluto en un dispositivo Level-1 exclusivo en otra área.
CAUSAimport-route sin una palabra clave de nivel explícita solo inyecta la ruta en Level 2. Nada de esto falla ruidosamente — la ruta simplemente no se anuncia en Level 1 a menos que se indique.
SOLUCIÓNEspecifique el nivel explícitamente — import-route direct level-1 (o level-1-2) — donde la ruta necesite llegar a un área exclusiva de Level-1.
[Huawei-isis-1] import-route direct level-1-2
// without level-1 / level-1-2, the route only ever reaches Level 2SÍNTOMAUn dispositivo directamente conectado que no es un router — un codificador/decodificador, un servidor — empieza siendo alcanzable por ping, luego se vuelve intermitente, y finalmente deja de responder por completo, sin que nada haya cambiado del lado de la red.
CAUSALa interfaz del lado Huawei tiene IS-IS activado y envía paquetes Hello periódicos por diseño. Algunos dispositivos que no son routers manejan tan mal el tráfico Hello inesperado de IS-IS que desplaza su propio procesamiento de solicitudes ARP/ICMP, degradando y finalmente bloqueando la accesibilidad básica — sin nada del lado de IS-IS a qué señalar.
SOLUCIÓNConfigure isis silent en las interfaces que dan a servidores, codificadores, o cualquier dispositivo que nunca debía establecer adyacencia con protocolos de enrutamiento de capa 3 — esto suprime tanto el envío como la recepción de paquetes IS-IS en esa interfaz sin deshabilitar la interfaz en sí.
Sacadas directamente del campo — las que vale la pena tener respuesta lista.
El MTU físico de Ethernet es de 1500 bytes en ambos casos. En un enlace P2P (encapsulado en PPP), IS-IS reporta el 1500 completo. En un enlace de difusión (802.3), el encabezado LLC sobre el que va IS-IS añade 3 bytes dentro de esa misma trama de 1500 bytes, así que la carga útil realmente disponible para IS-IS es 1497 — no es un error de configuración, solo una sobrecarga de encapsulación distinta.
Una interfaz Level-1 solo forma adyacencia con un par Level-1 o Level-1-2. Una interfaz Level-2 solo lo hace con Level-2 o Level-1-2. Una interfaz Level-1-2 formará adyacencia con cualquiera de los tres. Si esta única regla no se cumple, nada más en la configuración importa.
La razón más común es el alcance, no la sintaxis: import-route sin palabra clave de nivel solo inyecta la ruta en Level 2 por defecto. Si el área de destino es exclusiva de Level-1, la ruta nunca se envió allí en primer lugar — añada level-1 o level-1-2 explícitamente a import-route para solucionarlo.
IS-IS depende del System ID para identificar de forma única a cada dispositivo del dominio de enrutamiento. Dos dispositivos que comparten uno se ven, desde la perspectiva del protocolo, como el mismo router apareciendo en dos interfaces a la vez — el contador Repeated System ID de display isis error sube, la adyacencia nunca se completa, y la solución es simplemente cambiar el network-entity de un dispositivo para que la parte del System ID sea única.
La interacción entre el cost-type internal/external de import-route y la preferencia de ruta resultante solo se ve realmente bajo cost-style narrow, donde la penalización de +64 para external y el costo transmitido tal cual para internal realmente cambian qué ruta gana. Bajo cost-style wide, el rango de métrica es lo bastante grande como para que esta discrepancia en particular tenga muchas menos probabilidades de voltear por sí sola la ruta preferida — pero sigue valiendo la pena fijar el cost-type de forma idéntica en cada dispositivo que importe los mismos prefijos.
Primero la prioridad — la interfaz con el isis dis-priority más alto gana; en caso de empate, gana el SNPA (dirección MAC) más alto de la interfaz. A diferencia del DR de OSPF, el DIS de IS-IS no tiene respaldo BDR y vuelve a ejecutar esta elección de inmediato si un router de mayor prioridad se une al segmento, algo que vale la pena saber antes de asumir que un cambio de DIS significa que algo realmente está roto.
Esta nota se basa en el modelo de clasificación de fallas de IS-IS del router Huawei serie AR y sus comandos display isis interface / isis error / isis statistics packet, además de los casos de campo que los respaldan. Si su equipo es de otro fabricante, los comandos exactos cambian, pero la lógica de adyacencia subyacente — estado de la interfaz, unicidad del System ID, coincidencia de nivel y área, conteo de capa del MTU, alcance de la importación de rutas — se traslada directamente. No cubre en profundidad casos particulares de elección de DIS en LAN de acceso múltiple grandes, ni detalles específicos de la familia de direcciones IPv6 (M-ISIS).
Cuéntenos en qué comprobación está fallando display isis error — Repeated System ID, Mismatched Level, u otra cosa — junto con el estado de la interfaz, y le ayudamos a interpretarlo.