A Junos ISIS adjacency stuck in Initializing means your router receives the neighbor's hellos, but the neighbor does not list you in its own hellos. In other words, your hellos are being lost or rejected on the far side. The usual causes are a missing family iso, a malformed NET, an MTU too small for padded 1,492-byte hellos, or a mismatch in level, area, circuit type, authentication or address family.
Start on the router that shows nothing at all, not the one stuck in Initializing. The side with no adjacency is the one that is not receiving or accepting hellos. That single observation halves the search.
This guide is written against the Junos OS 23.4 train on MX Series and vMX. We have not lab-tested every command on every release. Confirm each statement with ? completion on your version, and test in a lab before production. If you are coming from OSPF, the Routing and Switching hub covers the equivalent OSPF failure states.
Why IS-IS Gets Stuck in Initializing
IS-IS uses a three-way handshake on point-to-point links and a neighbor list on LAN circuits. A router moves an adjacency to Up only after it sees its own identity reflected in the neighbor's hello. If you hear the neighbor but it never reflects you, you sit in Initializing forever.
The less obvious part is hello padding. By default Junos pads hellos up to 1,492 bytes during adjacency formation. This is a deliberate MTU test. IS-IS runs directly over 802.3 with an LLC header, not over IP, so an LSP that cannot fit a link simply cannot be flooded across it. Padding surfaces that problem at bring-up time rather than months later during an LSP storm.
The trade-off is diagnostic confusion. A link that passes every ping and carries IP traffic happily can still refuse IS-IS, because ICMP defaults to small packets. Engineers see a healthy link and assume the protocol is broken. In our experience, padding is the cause people reach for last and should reach for third.
Healthy vs Broken Output
A healthy point-to-point Level 2 adjacency looks like this. The hold time counts down from 27 seconds and resets with each hello.
user@r1> show isis adjacency
Interface System L State Hold (secs) SNPA
ge-0/0/0.0 r2 2 Up 26The broken state shows Initializing on one side. If the other side shows no entry at all, hellos are only arriving in one direction.
user@r1> show isis adjacency
Interface System L State Hold (secs) SNPA
ge-0/0/0.0 r2 2 Initializing 24
user@r2> show isis adjacency
user@r2>The interface detail tells you the padding mode and the hello size Junos is using. The ISO MTU on the interface must be at least that size.
user@r1> show isis interface ge-0/0/0.0 extensive | match "padding|IIH"
LSP interval: 100 ms, CSNP interval: disabled, Loose Hello padding, IIH max size: 1492
user@r1> show interfaces ge-0/0/0 | match "MTU"
Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, ...
Protocol inet, MTU: 1500
Protocol iso, MTU: 1497On MX with the default media MTU of 1,514, the ISO MTU is 1,497. That leaves room for a 1,492-byte hello. The Juniper KB on adjacencies stuck in Initializing with an ISO MTU below 1492 shows what happens when the media MTU drops to 1,400. The ISO MTU becomes 1,383, and the padded hello no longer fits.
What each state combination usually means
| Router A | Router B | Most likely meaning |
|---|---|---|
| No entry | No entry | No hellos in either direction: family iso, NET, IS-IS not enabled on the interface, or no Layer 2 path. |
| Initializing | No entry | A hears B, but B drops or rejects A: MTU and padding, authentication, area or level, or a one-way path. |
| Initializing | Initializing | Both hear each other, but neither accepts the other: circuit type mismatch, point-to-point on one side only, or address family mismatch. |
| Up, then flapping | Up, then flapping | Hellos lost intermittently: congestion, CPU, an unstable member link, or aggressive timers. |
Junos ISIS Adjacency Initializing: Ordered Diagnostic
Work through these in order. The first five are read-only and take seconds each. Tracing comes last because it needs a commit.
- Is family iso on the interface? Run
show interfaces ge-0/0/0.0 terseand confirm iso appears in the Proto column. - Is the NET well formed? Run
show configuration interfaces lo0. The ISO address must end in.00, andlo0.0must be in the IS-IS configuration. - Do levels, area and circuit type agree? Run
show isis interface detailon both routers and compare level, circuit type and point-to-point settings. - Can a full-size packet cross the link? Run
ping 192.0.2.1 size 1464 do-not-fragment. That sends a 1,492-byte IP packet, which is the size Juniper recommends testing with. - Are hellos arriving but being discarded? Run
show isis statisticstwice. Compare IIH Received with IIH Processed and watch the Drops column. - Is authentication configured the same on both ends? Run
show configuration protocols isis | display set | match authon both routers. - Only now, trace hellos. Enable IS-IS traceoptions for hello and error flags, reproduce the failure, then remove the trace.
user@r1> show interfaces ge-0/0/0.0 terse
user@r1> show configuration interfaces lo0
user@r1> show isis interface detail
user@r1> ping 192.0.2.1 size 1464 do-not-fragment count 5
user@r1> show isis statisticsJuniper publishes its own triage steps in the MX IS-IS troubleshooting resolution guide. Its sample statistics output shows a router receiving tens of thousands of IIHs but processing only a handful. That pattern means hellos are arriving and being rejected, so stop looking at the cable.
Root Causes Ranked by Frequency
This ranking reflects what we see in the field and what keeps coming up on r/Juniper, r/networking and the Juniper community forum. It is our experience, not a Juniper statistic.
1. Missing family iso or a malformed NET
IS-IS will not send or accept hellos on an interface without family iso. The loopback needs an ISO address, which becomes the system ID. A NET without the trailing .00 selector is a common typo. It appears in a widely read r/networking thread about Cisco and Juniper routers stuck in INIT, where one Juniper loopback NET was missing the selector.
The Juniper guide adds a subtler rule. If the neighbor has an IPv4 address on the link, the local interface needs one too. The alternative is to set no-ipv4-routing under IS-IS.
2. Level, area or circuit type mismatch
Junos interfaces run Level 1 and Level 2 by default. Level 1 adjacencies need a matching area address; Level 2 adjacencies do not. If one side is Level 2 only and the other is Level 1 only, no adjacency forms. A point-to-point setting on one side with a broadcast circuit on the other is another classic cause of Initializing on both routers.
3. MTU too small for padded hellos
This shows up on tunnels, on links with a reduced media MTU, and on carrier Ethernet with a lower service MTU. GRE and IPsec tunnels are the usual culprits, because encapsulation eats into the payload. If you run IS-IS across an st0 tunnel, as in our SRX route-based IKEv2 VPN guide, check the ISO MTU on the tunnel before anything else.
The right fix is usually to raise the MTU along the path. Lowering max-hello-size and max-lsp-size works, as the Juniper KB shows. But LSPs cannot be fragmented in transit, so a smaller LSP buffer on one router affects flooding for the whole area. Treat it as a deliberate design decision, not a quick fix.
4. Authentication mismatch
A key, or an authentication type, present on one side only drops every hello silently. The tell is hellos counted as received with no adjacency progress. Junos can authenticate hellos per interface and LSPs per level. Check both levels on both routers.
5. Address family and topology mismatch, mostly with other vendors
Junos IS-IS defaults to single topology and advertises IPv6 capability in its hellos. Interop notes and our own experience agree on one point: in single topology, every link has to carry the same address families. A Cisco IOS neighbor with no IPv6 on the link, facing Junos, can fail for this reason. Either run IPv6 on both ends, disable IPv6 routing in IS-IS, or move both sides to multi-topology as defined in RFC 5120.
6. Something in the path eats IS-IS frames
IS-IS frames are not IP, so anything that only forwards IP will drop them. Examples include SRX devices in flow mode, some IRB and virtual lab setups, and certain carrier services. Branch SRX devices only pass ISO traffic in packet-based mode for the iso family. One EVE-NG report on r/Juniper traced the fault to a middle router that bridged IP but never forwarded the IS-IS multicast frames.
Copy-Ready Configuration and Fixes
These changes touch your IGP. Use commit confirmed 5 and have console or out-of-band access, especially if you manage the router in-band across the IS-IS link. A mistake here can remove the route you are logged in over.
Baseline point-to-point Level 2 link (r1)
set interfaces ge-0/0/0 unit 0 family inet address 192.0.2.0/31
set interfaces ge-0/0/0 unit 0 family iso
set interfaces ge-0/0/0 unit 0 family inet6 address 2001:db8:12::/127
set interfaces lo0 unit 0 family inet address 198.51.100.1/32
set interfaces lo0 unit 0 family iso address 49.0001.1980.5110.0001.00
set protocols isis interface ge-0/0/0.0 point-to-point
set protocols isis interface ge-0/0/0.0 level 1 disable
set protocols isis interface lo0.0 passive
set protocols isis level 1 disable
set protocols isis level 2 wide-metrics-only
commit confirmed 5The system ID comes from the loopback address, with each octet padded to three digits. On r2, use 192.0.2.1/31, 2001:db8:12::1/127 and a NET of 49.0001.1980.5110.0002.00. Both routers must agree on point-to-point, or neither will reach Up.
Authentication, identical on both routers
set protocols isis level 2 authentication-key "replace-with-shared-key"
set protocols isis level 2 authentication-type md5
commit confirmed 5MD5 authentication confirms that the peer knows the key. It does not encrypt IS-IS traffic, and MD5 is a weak algorithm by current standards. Check which stronger options your release and your neighbors support.
MTU and address family workarounds
# Only when you cannot raise the path MTU. Values must not exceed the ISO MTU.
set protocols isis max-hello-size 1383
set protocols isis max-lsp-size 1383
# Single-topology interop with a neighbor that does not run IPv6 on the link:
set protocols isis no-ipv6-routing
# Or move to multi-topology (the neighbor must also run multi-topology):
set protocols isis topologies ipv6-unicastDo not disable hello padding to hide an MTU mismatch in production. The adjacency will come up, and the first LSP too large for the path will be dropped. Junos supports adaptive, loose, strict and disable modes under set protocols isis interface ge-0/0/0.0 hello-padding. Use disable only for a brief test that proves MTU is the cause.
Tracing hellos
set protocols isis traceoptions file isis-trace size 5m files 3
set protocols isis traceoptions flag hello detail
set protocols isis traceoptions flag error
commit
run show log isis-trace | match "IIH|reject|mismatch|padding|auth"
delete protocols isis traceoptions
commitA sent hello in the trace shows the circuit type, area address, the protocols it speaks, the padding added and the final packet length. Compare those fields line by line with the neighbor's received hellos. That comparison finds most mismatches within a minute.
Verification After the Fix
Confirm the adjacency, then the database, then the routes. Healthy output looks broadly like this. The figures are illustrative.
user@r1> show isis adjacency detail
r2
Interface: ge-0/0/0.0, Level: 2, State: Up, Expires in 25 secs
Priority: 0, Up/Down transitions: 1, Last transition: 00:04:12 ago
Circuit type: 2, Speaks: IP, IPv6
Topologies: Unicast
Restart capable: Yes, Adjacency advertisement: Advertise
IP addresses: 192.0.2.1
user@r1> show isis database
IS-IS level 2 link-state database:
LSP ID Sequence Checksum Lifetime Attributes
r1.00-00 0x5 0x7a1c 1102 L1 L2
r2.00-00 0x4 0x3e90 1087 L1 L2
2 LSPs
user@r1> show route 198.51.100.2/32 protocol isisUp/Down transitions should stay at 1 and stop rising. Both routers should appear in each other's database, and the neighbor's loopback should be in inet.0 as an IS-IS route. A rising transition count means the root cause is still there, often a flapping member link. If the IS-IS link is an aggregated bundle, see our guide to Junos LACP ae interfaces stuck in Defaulted or Detached.
Platform and Release Notes
On LAN circuits, the elected DIS sends hellos every 3 seconds with a 9 second hold time, rather than the 9 and 27 second defaults. Juniper notes this can drop adjacencies during a Routing Engine switchover. Its guidance is to use point-to-point circuits where possible, or longer LAN timers on both sides.
Junos OS Evolved uses the same IS-IS configuration model, but show output formatting can differ, so match on keywords rather than column positions in scripts. IP reachability in IS-IS is defined in RFC 1195, and the base protocol in ISO/IEC 10589. For more symptom-led guides, see the Troubleshooting hub.
Juniper, Junos, MX, SRX, EX and QFX are trademarks of Juniper Networks, Inc., now part of HPE. Cisco and IOS are trademarks of Cisco Systems, Inc. juniperclient.com is independent and unaffiliated.
Frequently Asked Questions
Why is my ISIS not forming adjacency correctly when the config matches the other routers?
Check the one thing that differs per router: the loopback NET and the family iso on that specific link. Then compare IIH Received with IIH Processed in show isis statistics. Hellos received but not processed mean they are being rejected, usually over authentication, area or MTU.
Why is the IS-IS adjacency not forming between Cisco and Juniper?
The most common interop causes are MTU and padding, which the two vendors calculate differently, and single-topology IPv6. Make the ISO MTU match on both ends and either run IPv6 on both sides or set no-ipv6-routing on the Junos side. Also check the level: Cisco defaults to Level 1 and Level 2, as Junos does.
Why does the ISIS adjacency stay in Initializing when the protocol iso MTU is less than 1492?
Junos pads hellos to 1,492 bytes, so a padded hello cannot fit an ISO MTU below that and is dropped. Raise the media MTU if you can. If not, set max-hello-size and max-lsp-size to a value no larger than the ISO MTU, on every router that shares the constraint.
How do I fix an IS-IS adjacency issue in EVE-NG?
Check whether the middle node actually forwards IS-IS frames, because they are not IP and some virtual bridges and IRB setups drop them. Capture on both sides of that node to confirm hellos leave and arrive. On virtual SRX, remember that ISO traffic needs packet-based mode for the iso family.
Do I need an IPv4 address on the interface for ISIS to come up?
If the neighbor has an IPv4 address on the link, Junos expects one locally as well. The alternative is set protocols isis no-ipv4-routing when you only want IPv6 over IS-IS. The loopback always needs an ISO address for the system ID.
Discussion (0)