If your junos irb interface down state shows Admin up and Link down, look at Layer 2 first. The problem is almost never the IP address. An IRB unit stays down until the VLAN (EX/QFX) or bridge domain (MX) it is bound to has at least one member logical interface that is up and forwarding. A common thread on r/Juniper puts it this way: the physical port is up, the config matches a working twin switch, and irb.100 still says no link. In that case, spanning tree was blocking the only member port.

This guide was written against Junos OS 23.4 with Enhanced Layer 2 Software (ELS) syntax on EX and QFX, and with the bridge-domain model on MX. We have not tested it on every platform, so check each command on your own release in a lab before you rely on it. Junos OS Evolved and older non-ELS EX software (which used vlan.X instead of irb.X) can show different output.

What Junos IRB Interface Down Actually Means

Junos works out an IRB link state from the Layer 2 domain behind it. If every member interface in that VLAN is down, or none of them is forwarding, the kernel marks the IRB logical unit Hardware-Down. Its local subnet is then flagged Dest-route-down. The address is still configured, but the connected route is not active. You cannot ping it, and routing protocols will not advertise it.

This is on purpose. A subnet with no working Layer 2 path behind it is a dead end. If a router kept advertising it, traffic would be drawn toward a black hole. Cisco uses the name SVI autostate for the same idea. The difference is that Junos gives you no general knob to turn it off. The community answer has been the same for years: if you need an address that is always up, put it on lo0, not on an IRB.

The trade-off matters most for in-band management. A management IP on an IRB goes away whenever the last uplink carrying that VLAN goes down. That is also the moment you most need to reach the box. The default is correct for routing, but it costs you reachability. That is why out-of-band access on fxp0/me0, or a loopback reached through the IGP, is worth setting up before you need it.

Step-by-Step Diagnosis: Checks in Order

Run these from cheapest to most expensive. Most cases are solved by step 3.

  1. Confirm the symptom and flags on the IRB unit.
  2. List the VLAN members and see if any are up.
  3. Check that the VLAN is actually allowed on the trunk or access port you expect.
  4. Check spanning tree state for that VLAN on each member port.
  5. Confirm the IRB is bound with l3-interface (EX/QFX) or routing-interface (MX) in the right instance.
  6. Only then suspect software. Look for known issues for your release, upgrade to a JTAC-recommended release, or open a case.

Check 1: Confirm the broken state

user@ex> show interfaces terse irb
user@ex> show interfaces irb.100 extensive | match "Flags|Destination"

Broken output looks like this (trimmed). Note Hardware-Down on the logical unit and Dest-route-down on the address:

Interface               Admin Link Proto    Local                 Remote
irb                     up    up
irb.100                 up    down inet     192.0.2.1/24

  Logical interface irb.100 (Index 550) (SNMP ifIndex 557)
    Flags: Hardware-Down Up SNMP-Traps 0x4004000 Encapsulation: ENET2
      Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
        Destination: 192.0.2/24, Local: 192.0.2.1, Broadcast: 192.0.2.255

Check 2 and 3: VLAN membership and trunk allow-list

user@ex> show vlans v100 extensive
user@ex> show ethernet-switching interface ge-0/0/20
user@ex> show configuration interfaces ge-0/0/20

(MX)
user@mx> show bridge domain bd100
user@mx> show configuration interfaces ge-0/0/4

In show vlans, an asterisk after a member means that member is up. An empty member list is your answer. A member marked up with the IRB still down sends you to spanning tree.

Check 4: Spanning tree on the member port

user@ex> show spanning-tree interface ge-0/0/20 detail
user@ex> show spanning-tree mstp configuration

Check 5: The binding

user@ex> show configuration vlans v100
user@mx> show configuration bridge-domains bd100

Root Causes Ranked by Frequency

This ranking comes from forum threads and from our experience. Your environment may differ, but work through them in this order.

1. No member port in the VLAN is up

This is the most common cause by far. Maybe nothing is plugged in yet. The downstream switch may be off, or the only access port may be disabled. A member port can also be shut down by a BPDU error or port-security action, or be an ae bundle whose LACP never came up. The IRB is doing its job: there is no live Layer 2 path. Fix the member first, and the IRB follows within seconds.

2. The VLAN is not carried on the trunk

The uplink is up, but the VLAN is not in its vlan members list. So the VLAN has no members, even though the port looks healthy. This often happens when one trunk is copied to another and a range is left out. It also happens when the far end sends a VLAN untagged but the Junos trunk has no native-vlan-id. On ELS, native-vlan-id goes at the physical interface level. On legacy EX it goes under the unit, and the two syntaxes are easy to mix up.

3. The only member port is blocked by STP or MSTP

The port is up and in the VLAN, but spanning tree has it in a blocking or alternate role for that VLAN. With MSTP, the VLAN may map to an MSTI in which that port is not forwarding. show vlans still shows the port as up, which is what makes this one confusing. Fix the topology or the VLAN-to-MSTI mapping. Do not disable STP to get around it.

4. The IRB is not bound to the VLAN or bridge domain

An IRB unit with an address but no binding has no Layer 2 domain to follow, and in our experience it does not come up. On EX/QFX you need l3-interface irb.100 under the VLAN. On MX you need routing-interface irb.100 under the bridge domain. Also check that the VLAN and its member ports are in the same instance, such as default-switch or a virtual-switch instance.

5. Software or platform state

Some posters fixed an IRB that stayed down on an SRX by upgrading. Others fixed an MX lab by rebooting after all config checks passed. Treat this as a last resort, not a first guess. Rule out causes 1 to 4, check the known-issues list for your release, and move to a JTAC-recommended release before you blame the code.

Quick Reference: Symptom, Cause, Fix

What you seeLikely causeFix
No members listed under the VLANVLAN not assigned to any portAdd it to an access port or trunk members list
Members listed, none marked upMember ports down, disabled, err-disabled, or ae downFix the physical, BPDU, or LACP issue on the member
Trunk up, one VLAN IRB down, others upVLAN missing from that trunk members listAdd the VLAN to the trunk
Member up, STP role ALT or state BLKSpanning tree blocking the only pathCorrect topology or MSTI mapping
IRB has an address but is not listed on any VLANMissing l3-interface or routing-interfaceBind the IRB to the VLAN or bridge domain
Management IP disappears when uplink failsExpected IRB behaviourUse lo0 or out-of-band management

The Fix: Copy-Ready Configuration

Change the addressing and interface names, then commit with commit confirmed 5. This touches Layer 2 and routing, so have console or out-of-band access ready in case a trunk change cuts you off.

EX and QFX (ELS)

set vlans v100 vlan-id 100
set vlans v100 l3-interface irb.100
set interfaces irb unit 100 family inet address 192.0.2.1/24
set interfaces irb unit 100 family inet6 address 2001:db8:100::1/64
set interfaces ge-0/0/10 unit 0 family ethernet-switching interface-mode access
set interfaces ge-0/0/10 unit 0 family ethernet-switching vlan members v100
set interfaces ge-0/0/20 unit 0 family ethernet-switching interface-mode trunk
set interfaces ge-0/0/20 unit 0 family ethernet-switching vlan members v100
commit confirmed 5

MX (bridge domain in the default instance)

set bridge-domains bd100 vlan-id 100
set bridge-domains bd100 routing-interface irb.100
set interfaces irb unit 100 family inet address 198.51.100.1/24
set interfaces ge-0/0/4 unit 0 family bridge interface-mode trunk
set interfaces ge-0/0/4 unit 0 family bridge vlan-id-list 100
commit confirmed 5

When you want an address that never goes down

Do not try to force an IRB up. Put the always-on address on a loopback, add it to your IGP, and protect it with a filter:

set interfaces lo0 unit 0 family inet address 203.0.113.10/32
set protocols ospf area 0.0.0.0 interface lo0.0 passive
commit confirmed 5

Community posts mention looping a spare port to keep a VLAN alive. Reports say it can interfere with MAC learning, so we do not recommend it for production.

Verification: What Healthy Output Looks Like

user@ex> show interfaces terse irb.100
Interface               Admin Link Proto    Local                 Remote
irb.100                 up    up   inet     192.0.2.1/24
                                   inet6    2001:db8:100::1/64

user@ex> show vlans v100
Routing instance        VLAN name             Tag          Interfaces
default-switch          v100                  100
                                                           ge-0/0/10.0*
                                                           ge-0/0/20.0*

user@ex> show route 192.0.2.0/24
192.0.2.0/24       *[Direct/0] 00:02:11
                    >  via irb.100

Healthy means the Link column says up, Hardware-Down and Dest-route-down are gone, and the connected route is active. If the IRB is up but traffic still fails on an SRX, the problem is now zone or policy, not Layer 2.

If a member port is err-disabled, work through recovering a Juniper EX BPDU error. If the member is a bundle, see fixing a Junos LACP ae interface that stays down. If the IRB is up on an SRX but packets still drop, go to SRX security flow traceoptions. More guides are in the troubleshooting hub and the routing and switching section.

Primary sources: Juniper Integrated Routing and Bridging documentation, the KB IRBs not coming up after being configured, and the MX IRB troubleshooting checklist. The STP case above comes from this r/Juniper thread.

Frequently Asked Questions

Does an irb have to be associated with a physical interface in order to be up?

Yes. At least one member of the IRB VLAN or bridge domain must be up and forwarding. Check with show vlans <name> extensive. If you need an address that is always reachable, use lo0.

Keep IRB/VLAN up even when no physical port is connected?

Junos has no supported autostate-off knob for this. The usual answer is a /32 on lo0 advertised into your IGP, or out-of-band management on fxp0/me0.

IRB interface up/down despite access port being up?

First confirm the port is in the right VLAN and the VLAN has l3-interface irb.X. Then run show spanning-tree interface <port> detail to rule out blocking. If all of that is clean, check the known issues for your release.

EX series, no link on irb interface, but the physical port is fine?

A member that is up but blocked by STP still leaves the IRB down. In the thread this question comes from, spanning tree was blocking the only trunk. show spanning-tree interface ge-0/0/20 detail showed it.

IRB interfaces down despite active trunk?

If some IRBs on the same trunk are up and others are down, the down VLANs are almost always missing from that trunk vlan members list. Compare show configuration interfaces <trunk> against show vlans.

How do we clear Hardware-Down status on an irb interface?

There is no clear command for it. Hardware-Down goes away by itself once a member interface in the VLAN comes up and forwards. If the IRB is not in use, delete the unit or deactivate it.

Juniper, Junos, MX, SRX, EX and QFX are trademarks of Juniper Networks, Inc., now part of HPE. juniperclient.com is independent and unaffiliated.