Un voisin IS-IS qui refuse de se former, ou une route qui n'apparaît jamais là où on l'attend, se ramène presque toujours à l'une d'une poignée d'incohérences de paramètres — pas à un bug du protocole. Voici l'ordre de diagnostic qui isole laquelle : d'abord l'état de l'interface, puis le System ID / le niveau / la zone, puis le MTU compté à la bonne couche, puis la portée de l'importation de routes — plus trois cas de terrain réels et les commandes display à exécuter à chaque étape.
Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026
Les voisins IS-IS ne tombent pas en panne de façon créative — ils échouent toujours de six ou sept façons identiques, dans un ordre prévisible.
Un voisin IS-IS qui ne se forme pas, ou une route qui refuse discrètement d'aller là où elle devrait, est l'un des tickets les plus courants dans les déploiements IS-IS multi-fournisseurs — précisément parce que le protocole regroupe plusieurs vérifications indépendantes (unicité du System ID, MTU, niveau, adresse de zone, authentification) dans un seul échange Hello, et que l'une d'elles suffit à bloquer silencieusement tout le reste. Le réflexe est de comparer les configurations complètes côte à côte ; il est plus rapide de parcourir les vérifications dans l'ordre où le routeur lui-même les évalue.
Voici le flux de diagnostic sur lequel ce texte s'appuie, les commandes exactes pour chaque étape, trois cas de terrain réels — une incohérence de type de coût à l'importation de routes qui préfère silencieusement le mauvais chemin, une valeur de MTU qui ne signifie pas la même chose selon le fournisseur, et une charge de Hello IS-IS qui a coupé la joignabilité d'un appareil qui n'était jamais censé faire tourner IS-IS — et les réponses aux questions qui reviennent sans cesse une fois les bases passées.
Les pannes IS-IS se répartissent comme la plupart des pannes d'adjacence L2/L3 : le voisin ne se forme jamais, ou il se forme et quelque chose en aval ne va toujours pas.
Placer d'abord le symptôme sur cet arbre indique immédiatement si vous traquez un problème d'interface/Hello ou un problème au niveau des routes — les deux n'ont pas de cause commune.
Les légendes du schéma restent en anglais pour la clarté technique.
Les pannes de System ID, de niveau et de MTU se lisent directement dans les compteurs de display isis interface et display isis error — ce sont les mécanismes propres du protocole IS-IS. Le comportement de l'importation de routes (cost-type, portée du niveau) est un choix de configuration distinct superposé, et mérite d'être vérifié séparément même une fois le voisin en bonne santé.
Quatre vérifications, une commande chacune — et une liste de raccourcis indiquant précisément quoi regarder quand display isis error désigne un compteur particulier.
Le champ d'état de display isis interface indique s'il s'agit d'un problème de liaison avant même d'ouvrir la configuration 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 transforme une supposition en un compteur précis — Repeated System ID et Mismatched Level appellent deux corrections totalement différentes.
<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 adjacencyL'échec IS-IS multi-fournisseurs le plus courant n'est pas une mauvaise valeur de MTU — c'est le même chiffre qui signifie deux choses différentes.
# 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 2Un voisin en bonne santé ne garantit pas que les routes importées arrivent là où on l'attend, ni qu'elles soient préférées comme on l'attend.
[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 deviceUne fois que les vérifications ci-dessus ont indiqué où se situe le problème, ces cinq causes couvrent l'essentiel de ce qui ne va vraiment pas.
SYMPTÔMEDeux appareils de bordure importent tous deux les mêmes routes directement connectées ou statiques dans IS-IS, mais les appareils du cœur n'apprennent jamais la route que via l'un d'eux — l'autre chemin n'est jamais utilisé, sans aucune erreur nulle part.
CAUSEimport-route est par défaut en cost-type external (ajoute +64 au coût d'origine) sauf indication contraire. Si un appareil est réglé sur internal et le pair laissé sur external, le chemin au coût le plus bas gagne toujours même quand les deux chemins devraient être viables pour un partage de charge. Cela ne se manifeste réellement que si le processus IS-IS tourne en cost-style narrow.
SOLUTIONConfigurez import-route direct cost-type internal et import-route static cost-type internal de façon identique sur chaque appareil de bordure important les mêmes préfixes, afin que le coût ne reflète que la métrique d'origine des deux côtés.
[DeviceD-isis-1] import-route static cost-type internal
// DeviceD's default (external, +64) was what made DeviceB/C always prefer itSYMPTÔMEL'interface est Up, l'IP est joignable, les paramètres IS-IS sont tous corrects individuellement, mais le voisin ne se forme jamais sur une agrégation de liens vers un appareil d'un autre fournisseur.
CAUSELa commande mtu de cette plateforme définit la taille utile de couche 3 ; celle de l'autre fournisseur définit par défaut une taille de trame de couche 2. Les deux côtés ont configuré mtu 9126 en croyant correspondre — mais le vrai plafond de couche 3 du pair était 9126 moins l'en-tête Ethernet de 14 octets, soit 9112, si bien que le Hello surdimensionné ne passait jamais.
SOLUTIONConfigurez le MTU de ce côté comme le MTU de couche 2 du pair moins 14, ou contournez complètement la vérification avec isis small-hello de ce côté et hello-padding disable level 2 chez le pair.
SYMPTÔMEdisplay isis error montre Mismatched Level qui augmente, ou la machine à états du voisin ne dépasse jamais Init.
CAUSEUne interface Level-1 ne s'adjacence qu'avec un pair configuré Level-1 ou Level-1-2 ; Level-2 uniquement avec Level-2 ou Level-1-2. Pour les adjacences Level-1 spécifiquement, l'adresse de zone de network-entity doit aussi correspondre aux deux extrémités — les adjacences Level-2 ignorent totalement cette vérification.
SOLUTIONAlignez is-level sous le processus IS-IS (ou isis circuit-level sur l'interface) aux deux extrémités, et pour les liaisons Level-1 confirmez que la partie adresse de zone de network-entity des deux appareils est identique.
SYMPTÔMEUne route a clairement été importée — elle apparaît dans la table de routage locale, import-route est configuré — mais elle n'apparaît jamais du tout sur un appareil Level-1 uniquement dans une autre zone.
CAUSEimport-route sans mot-clé de niveau explicite n'injecte la route que dans le Level 2. Rien ne le signale bruyamment — la route n'est simplement pas annoncée dans le Level 1 sauf indication contraire.
SOLUTIONSpécifiez le niveau explicitement — import-route direct level-1 (ou level-1-2) — partout où la route doit atteindre une zone Level-1 uniquement.
[Huawei-isis-1] import-route direct level-1-2
// without level-1 / level-1-2, the route only ever reaches Level 2SYMPTÔMEUn appareil directement connecté qui n'est pas un routeur — un boîtier encodeur/décodeur, un serveur — commence par être pingable, puis devient intermittent, puis cesse totalement de répondre, alors que rien n'a changé côté réseau.
CAUSEL'interface côté Huawei a IS-IS activé et envoie des paquets Hello périodiques par conception. Certains appareils non-routeurs gèrent si mal un trafic Hello IS-IS inattendu qu'il évince leur propre traitement des requêtes ARP/ICMP, dégradant puis finissant par bloquer la joignabilité de base — sans rien côté IS-IS à quoi se raccrocher.
SOLUTIONConfigurez isis silent sur les interfaces faisant face à des serveurs, des encodeurs, ou tout appareil qui n'était jamais censé s'adjacencer via des protocoles de routage de couche 3 — cela supprime l'envoi et la réception de paquets IS-IS sur cette interface sans désactiver l'interface elle-même.
Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Le MTU physique d'Ethernet est de 1500 octets dans les deux cas. Sur une liaison P2P (encapsulation PPP), IS-IS rapporte le 1500 complet. Sur une liaison de diffusion (802.3), l'en-tête LLC sur lequel IS-IS s'appuie ajoute 3 octets à l'intérieur de cette même trame de 1500 octets, donc la charge utile réellement disponible pour IS-IS est 1497 — ce n'est pas une erreur de configuration, juste une surcharge d'encapsulation différente.
Une interface Level-1 ne forme d'adjacence qu'avec un pair Level-1 ou Level-1-2. Une interface Level-2 ne le fait qu'avec Level-2 ou Level-1-2. Une interface Level-1-2 s'adjacencera avec n'importe lequel des trois. Si cette seule règle n'est pas satisfaite, rien d'autre dans la configuration n'a d'importance.
La raison la plus courante est la portée, pas la syntaxe : import-route sans mot-clé de niveau n'injecte la route que dans le Level 2 par défaut. Si la zone de destination est Level-1 uniquement, la route n'y a jamais été envoyée — ajoutez explicitement level-1 ou level-1-2 à import-route pour corriger cela.
IS-IS s'appuie sur le System ID pour identifier de façon unique chaque appareil du domaine de routage. Deux appareils qui en partagent un ressemblent, du point de vue du protocole, au même routeur apparaissant simultanément sur deux interfaces — le compteur Repeated System ID de display isis error augmente, l'adjacence ne se termine jamais, et la correction consiste simplement à changer network-entity d'un appareil pour que la partie System ID soit unique.
L'interaction entre le cost-type internal/external d'import-route et la préférence de chemin qui en résulte n'est réellement visible qu'en cost-style narrow, où la pénalité +64 pour external et le coût transmis tel quel pour internal changent véritablement quel chemin l'emporte. En cost-style wide, la plage de métriques est assez large pour que cette incohérence en particulier ait bien moins de chances de faire basculer seule le chemin préféré — mais il reste utile de régler le cost-type de façon identique sur chaque appareil important les mêmes préfixes.
D'abord la priorité — l'interface avec le isis dis-priority le plus élevé l'emporte ; en cas d'égalité, le SNPA (adresse MAC) le plus élevé sur l'interface l'emporte. Contrairement au DR d'OSPF, le DIS d'IS-IS n'a pas de BDR de secours et relance cette élection immédiatement si un routeur de priorité supérieure rejoint le segment, ce qui vaut la peine d'être su avant de supposer qu'un changement de DIS signifie qu'un problème existe réellement.
Cette note s'appuie sur le modèle de classification des pannes IS-IS du routeur Huawei série AR et ses commandes display isis interface / isis error / isis statistics packet, ainsi que sur les cas de terrain qui les sous-tendent. Si votre appareil est d'un autre fournisseur, les commandes exactes changent, mais la logique d'adjacence sous-jacente — état de l'interface, unicité du System ID, correspondance de niveau et de zone, comptage du MTU par couche, portée de l'importation de routes — s'applique directement. Elle ne couvre pas en profondeur les cas particuliers d'élection du DIS sur de grands LAN à accès multiple, ni les spécificités de la famille d'adresses IPv6 (M-ISIS).
Dites-nous sur quelle vérification display isis error échoue — Repeated System ID, Mismatched Level, ou autre chose — plus l'état de l'interface, et nous vous aiderons à l'interpréter.