An IS-IS neighbor that refuses to come up, or a route that never shows up where you expect it, almost always traces back to one of a handful of parameter mismatches — not a protocol bug. This is the diagnostic order that isolates which one: interface state first, then System ID / Level / area, then MTU counted at the right layer, then route import scope — plus three real field cases and the display commands to run at each step.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
IS-IS neighbors don't fail in creative ways — they fail in the same six or seven ways, in a predictable order.
An IS-IS neighbor that won't form, or a route that quietly refuses to travel where it should, is one of the most common tickets in multi-vendor IS-IS deployments — precisely because the protocol packs several independent checks (System ID uniqueness, MTU, Level, area address, authentication) into a single Hello exchange, and any one of them silently blocks the rest. The instinct is to start comparing full running-configs side by side; it's faster to walk the checks in the order the router itself evaluates them.
What follows is the diagnostic flow this is built on, the exact commands for each stage, three field cases — a route-import cost mismatch that silently prefers the wrong path, an MTU value that means something different on each vendor's box, and an IS-IS Hello load that broke reachability to a device that was never supposed to run IS-IS — and answers to the questions that come up constantly once you're past the basics.
IS-IS trouble splits the same way most L2/L3 adjacency trouble does: the neighbor never forms, or it forms and something downstream is still wrong.
Placing the symptom on this tree first tells you whether you're chasing an interface/Hello problem or a route-level problem — the two don't share a root cause.
Diagram labels are kept in English for engineering clarity.
System ID, Level and MTU failures are read directly off display isis interface and display isis error counters — they're IS-IS's own protocol machinery. Route import behavior (cost-type, level scope) is a separate configuration choice layered on top, and it's worth checking on its own even after the neighbor itself is healthy.
Four checks, one command each, and a shortcut list of exactly what to look at when display isis error blames a specific counter.
display isis interface's state field tells you whether this is a link problem before you even open the IS-IS configuration.
<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 turns a guess into a specific counter — Repeated System ID and Mismatched Level are two completely different fixes.
<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 adjacencyThe single most common cross-vendor IS-IS failure isn't a bad MTU value — it's the same number meaning two different things.
# 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 2A healthy neighbor doesn't mean imported routes land where you expect, or get preferred the way you expect.
[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 deviceOnce the checks above have told you where the problem sits, these five account for most of what's actually wrong.
SYMPTOMTwo edge devices both import the same directly-connected or static routes into IS-IS, but the core devices only ever learn the route through one of them — the other path is never used, with no error anywhere.
CAUSEimport-route defaults to cost-type external (adds +64 to the original cost) unless told otherwise. If one device is set to internal and the peer left at external, the lower-cost path always wins even when both paths should be viable for load sharing. This only actually surfaces when the IS-IS process is running cost-style narrow.
FIXSet import-route direct cost-type internal and import-route static cost-type internal identically on every edge device importing the same prefixes, so cost reflects only the original metric on both sides.
[DeviceD-isis-1] import-route static cost-type internal
// DeviceD's default (external, +64) was what made DeviceB/C always prefer itSYMPTOMInterface is Up, IP is reachable, IS-IS parameters all check out individually, but the neighbor never forms across a link aggregation to another vendor's device.
CAUSEThis platform's mtu command sets the Layer 3 payload size; the other vendor's default sets a Layer 2 frame size instead. Both sides configured mtu 9126 believing they matched — but the peer's real Layer 3 ceiling was 9126 minus the 14-byte Ethernet header, i.e. 9112, so the oversized Hello never got through.
FIXConfigure this side's MTU as the peer's Layer 2 MTU minus 14, or bypass the check entirely with isis small-hello on this side and hello-padding disable level 2 on the peer.
SYMPTOMdisplay isis error shows Mismatched Level climbing, or the neighbor state machine never advances past Init.
CAUSEA Level-1 interface only adjacencies with a peer configured Level-1 or Level-1-2; Level-2 only with Level-2 or Level-1-2. For Level-1 adjacencies specifically, the network-entity's area address also has to match on both ends — Level-2 adjacencies skip that check entirely.
FIXAlign is-level under the IS-IS process (or isis circuit-level on the interface) on both ends, and for Level-1 links confirm both devices' network-entity area portion is identical.
SYMPTOMA route was clearly imported — it shows in the local routing table, import-route is configured — but it never appears at all on a Level-1-only device in a different area.
CAUSEimport-route without an explicit level keyword only injects the route into Level 2. Nothing about this fails loudly — the route simply isn't advertised into Level 1 unless told to be.
FIXSpecify the level explicitly — import-route direct level-1 (or level-1-2) — wherever the route needs to reach a Level-1-only area.
[Huawei-isis-1] import-route direct level-1-2
// without level-1 / level-1-2, the route only ever reaches Level 2SYMPTOMA directly connected device that isn't a router — an encoder/decoder box, a server — starts out pingable, then goes intermittent, then stops responding entirely, despite nothing changing on the network side.
CAUSEThe Huawei-side interface has IS-IS enabled and sends periodic Hello packets by design. Some non-router devices handle unexpected IS-IS Hello traffic poorly enough that it crowds out their own ARP/ICMP request processing, degrading and eventually blocking basic reachability — with nothing on the IS-IS side to point at.
FIXConfigure isis silent on interfaces facing servers, encoders, or any device that was never meant to peer at Layer 3 routing protocols — it suppresses both sending and receiving IS-IS packets on that interface without disabling the interface itself.
Pulled straight from the field — the ones worth having an answer ready for.
Ethernet's physical MTU is 1500 bytes either way. On a P2P (PPP-encapsulated) link, IS-IS reports the full 1500. On a broadcast (802.3) link, the LLC header IS-IS rides on top of adds 3 bytes inside that same 1500-byte frame, so the usable payload IS-IS actually gets is 1497 — it's not a misconfiguration, just different encapsulation overhead.
A Level-1 interface only forms an adjacency with a peer that's Level-1 or Level-1-2. A Level-2 interface only forms with Level-2 or Level-1-2. A Level-1-2 interface will adjacency with any of the three. If this one rule isn't satisfied, nothing else about the configuration matters.
The most common reason is scope, not syntax: import-route with no level keyword only injects the route into Level 2 by default. If the destination area is Level-1-only, the route was never sent there in the first place — add level-1 or level-1-2 explicitly to import-route to fix it.
IS-IS relies on System ID to uniquely identify every device in the routing domain. Two devices sharing one look, from the protocol's perspective, like the same router appearing on two interfaces at once — display isis error's Repeated System ID counter climbs, the adjacency never completes, and the fix is simply to change one device's network-entity so the System ID portion is unique.
The interaction between import-route's internal/external cost-type and the resulting path preference is really only visible under cost-style narrow, where the +64 penalty for external and the pass-through cost for internal genuinely change which path wins. Under wide cost-style the metric range is large enough that this specific mismatch is far less likely to flip the preferred path on its own — but it's still worth setting cost-type identically on every device importing the same prefixes regardless.
Priority first — the interface with the highest isis dis-priority wins; on a tie, the highest SNPA (MAC address) on the interface wins. Unlike OSPF's DR, IS-IS's DIS has no BDR backup and re-runs this election immediately if a higher-priority router joins the segment, which is worth knowing before assuming a DIS change means something is actually broken.
This note is built around the Huawei AR-series router's IS-IS fault-classification model and its display isis interface / isis error / isis statistics packet commands, plus the field cases behind them. If your device is a different vendor, the exact commands change, but the underlying adjacency logic — interface state, System ID uniqueness, Level and area matching, MTU layer counting, route import scope — carries over directly. It doesn't cover DIS election edge cases on large multi-access LANs in depth, or IPv6 (M-ISIS) address-family specifics.
Tell us which check display isis error is failing on — Repeated System ID, Mismatched Level, or something else — plus the interface state, and we'll help you read it.