Juniper EX: Troubleshoot an IRB or VLAN Interface (KB22220)

An IRB (integrated routing and bridging) interface — also called a VLAN interface — that refuses to come up is one of the most common Juniper EX support cases, and the cause is usually a chain of simple checks rather than a single exotic failure. This resolution guide, adapted from Juniper KB22220, walks the exact decision tree Juniper support engineers use: admin status first, then link status, then VLAN-to-interface mapping, and finally the physical layer. Each step includes the legacy and ELS command variants so it works across EX and QFX platforms alike.

Background: What an IRB Actually Is

On an EX or QFX switch, an IRB interface is a logical Layer 3 interface that is bound to a Layer 2 VLAN. It is how the switch becomes the default gateway for hosts in that VLAN: the VLAN carries the frames, and the IRB holds the IP address. The binding runs in two directions, and both must exist for the interface to work:

1. The VLAN must point at the IRB: set vlans DATA-1 l3-interface irb.15
2. The IRB must have an address: set interfaces irb unit 15 family inet address 10.0.15.1/24

Miss either half and the IRB exists in configuration but never carries traffic. This is the single most frequent cause of the “IRB is down” ticket, and it is invisible to show interfaces alone.

Juniper's interface nomenclature changed with the Enhanced Layer 2 Software (ELS) rewrite, and that is why every command in this guide has two forms. On ELS platforms (most EX Series from EX4300 onward, all QFX Series, EX3400, EX2300 and newer) the interface is named irb. On legacy platforms (EX4200, EX3200, EX2200, EX8200 with the older Junos build) it is named vlan. The same object, two names.

Prerequisites

• CLI access with sufficient privileges (this guide uses root@switch> operational mode).
• The interface name and VLAN name used in your network. Replace irb.15, vlan.10, DATA-1 and TEST with your own values throughout.
• Awareness of which software family the switch runs, so you use the right command variant:

root@switch> show version | match "JUNOS|Model"

If the output describes ELS behaviour in the documentation for that release, use the irb commands. When in doubt, try show interfaces irb terse first; on a legacy platform it returns an error rather than silently showing nothing.

• A rollback habit: run commit confirmed 5 for any change made on a switch you cannot reach physically. If you lose the session, Junos automatically reverts the configuration after the timer expires.

Step 1 — Check the Admin Status

Display the admin and link state of the IRB or VLAN interface:

root@switch> show interfaces irb.15 terse          # ELS
root@switch> run show interfaces vlan.10 terse     # legacy

Expected output looks like this:

Interface               Admin Link Proto    Local                 Remote
irb.15                  up    up   inet     10.0.15.1/24

If Admin is Down, the interface was administratively disabled. Confirm with show configuration interfaces | display set — you will see set interfaces vlan unit 30 disable. Re-enable it (check with the network owner first, as it alters topology):

delete interfaces vlan unit 30 disable      # legacy
delete interfaces irb unit 15 disable       # ELS

Commit the change and re-check the terse output. If Admin moves to up but Link stays down, continue to Step 2. If both move to up, you are done — but verify reachability before closing the case, because an IRB can be up and still have no working hosts behind it.

Step 2 — Check the Link Status

If Admin is up but Link is Down, the IRB has no active member in the VLAN. Verify that the physical interfaces are mapped to the VLAN:

root@switch> show vlans DATA-1
Name       Tag     Interfaces
DATA-1     10      ae0.0, ge-0/0/0.0*, ge-0/0/3.0, ge-0/0/10.0

The Tag column is the 802.1Q VLAN ID; the Interfaces column lists every logical interface that is a member. Two things to check here:

• The VLAN ID is what you expect. A VLAN named DATA-1 with tag 10 must match the tag on the remote switch and on every access port. A mismatch produces an IRB that is up with no reachable hosts, which is worse than a down IRB because it hides the fault.
• Every expected member appears. A missing interface means the port is not in the VLAN.

Missing members? Add them:

set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members DATA-1

On ELS platforms, the access-port form is usually explicit about the interface mode as well:

set interfaces ge-0/0/0 unit 0 family ethernet-switching interface-mode access
set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members DATA-1
commit

For an uplink that carries several VLANs, use trunk mode with an explicit member list and a native VLAN:

set interfaces ge-0/0/1 unit 0 family ethernet-switching interface-mode trunk
set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members [ DATA-1 DATA-2 ]
set interfaces ge-0/0/1 unit 0 family ethernet-switching native-vlan-id 10
commit

A common trap on ELS: an interface configured with interface-mode trunk but no vlan members statement belongs to no VLAN at all and will never bring the IRB up, even though the port looks configured.

Step 3 — Confirm an Active Member Exists

An IRB can only be up if at least one physical interface in the VLAN is active. The asterisk (*) marks the active connection:

root@switch> show vlans TEST
Name   Tag  Interfaces
TEST   30   ge-0/0/0.0*, ge-0/0/1.0

• Yes, there is a * — your IRB should be up. If it is still down, contact support.
• No * — work through the physical-interface resolution guide (KB19797) for every member without an asterisk, then the IRB should come up.

The reason the rule exists is architectural: the IRB's own link state is derived from the Layer 2 forwarding state of the VLAN's members. If every member is blocking or down, the VLAN has no forwarding path, so the RVI has nothing to attach to. That is why the fault is almost always downstream of the IRB itself.

Step 4 — Check the Physical Member Interface

For each member without an asterisk, inspect both the physical state and the Layer 2 forwarding state. The two can disagree, and show interfaces alone will not reveal it:

root@switch> show interfaces ge-0/0/0 terse
root@switch> show ethernet-switching interface ge-0/0/0

The second command is the important one. It reports the interface mode (access or trunk), the VLAN membership, and the STP state — look for Layer 2 forwarding state: Forwarding. A port that is physically up but in Blocking or Discarding state contributes nothing to the VLAN and therefore nothing to the IRB.

Typical causes for a member that never reaches forwarding, in rough order of frequency:

• No link partner or a dead cable. Verified with show interfaces ge-0/0/0 extensive — check the error counters and the link partner information.
• Interface disabled (disable in configuration) or administratively down at the far end.
• Speed and duplex mismatch with a non-negotiating device.
• Port security restricting the port. If MAC limits are configured, an over-limit condition puts the port into a restrictive state that never forwards. See our write-up on Junos port security with MAC limits if that is in play.
• LACP not established on an aggregated member. An AE bundle that never negotiates keeps its members non-forwarding — the behaviour is covered in Junos Aggregated Ethernet and LACP configuration.
• STP blocking by design. A loop-protected topology intentionally blocks one path; if the only member carrying your VLAN is the blocked one, the VLAN has no active member and the IRB stays down.

Error counters worth reading on the physical interface:

root@switch> show interfaces ge-0/0/0 extensive | match -5 "error|CRC|dropped|discard|Link"
root@switch> clear interfaces statistics ge-0/0/0

Step 5 — Check the VLAN ID and the l3-interface Binding

This is the step people skip because the IRB appears correctly configured. Verify both directions of the binding:

root@switch> show configuration vlans DATA-1 | display set
set vlans DATA-1 vlan-id 10
set vlans DATA-1 l3-interface irb.15

If the l3-interface line is absent, the VLAN exists as pure Layer 2 only — no routing, no gateway, and no IRB link state derived from it. If it points at the wrong unit number (irb.15 on the VLAN but irb.10 in the interfaces stanza), the VLAN points at an interface that has no address, and hosts in that VLAN get no gateway.

A dedicated VLAN ID is mandatory for an IRB. A VLAN with no vlan-id statement, or one using the all keyword, cannot support an IRB with an inet address because there is no tag to associate with the RVI. Confirm with:

root@switch> show vlans detail | match "Name|Tag|Interfaces"

Step 6 — Verify Layer 3 Addressing and Routing

Once the interface is up, confirm it can actually route:

root@switch> show interfaces irb.15
root@switch> show route 10.0.15.0/24
root@switch> show arp | match irb.15
root@switch> ping 10.0.15.254 count 5 rapid

Checks that catch the remaining cases:

• Address present and in the right subnet. A /24 address in a /23-designed VLAN produces asymmetric behaviour that looks intermittent.
• Duplicate address. Another device using the same IP, or a VRRP virtual address that collides with the physical address, produces ARP conflicts in the log. Check show log messages | match irb.
• VRRP/VRRPv3 misconfiguration. If the IRB participates in a virtual router, verify the group state with show vrrp. A backup-only state across all members means the virtual address is never advertised.
• Firewall filters. An input or output filter on the IRB can silently drop the traffic you are testing. Check with show configuration interfaces irb unit 15 family inet filter.
• Virtual Chassis port mapping. On a VC, the IRB is only up if a member with an active port in that VLAN is present. See the Virtual Chassis overview for how member roles affect derived interface state.

ELS vs Non-ELS: Command Mapping

Rollback Safety

If any configuration change goes wrong, roll back immediately and commit:

rollback 1
commit

For changes made on a switch you cannot physically reach, use the confirmed-commit mechanism so a lost session cannot strand the device:

commit confirmed 5
# confirm within five minutes once you have verified the change
commit

Two more Junos safety features are worth knowing during an IRB investigation. show system rollback 1 compare prints the difference between the active configuration and the previous candidate, which is the fastest way to see exactly what the last change did. And on platforms that support it, commit check validates a candidate configuration without activating it.

Symptom to Root Cause: Quick Reference

FAQ

Can one VLAN have more than one IRB unit? No. A VLAN binds to exactly one Layer 3 interface. If you need two subnets in the same VLAN, use secondary addresses on the same unit with family inet address <ip>/<mask> repeated, not a second IRB.

Why does the IRB go down when I remove the last access port? Because IRB link state is derived from the VLAN's forwarding members. With zero forwarding members the VLAN has no path, so the RVI drops. This is expected behaviour, not a bug — but it makes the interfaces stanza a misleading place to look for the fault.

Does the IRB need its own MAC address? Junos allocates one per IRB from the chassis range. It is not user-configurable on most EX and QFX platforms, and it changes if the IRB unit number changes, which is one reason to treat a unit renumber as a real change rather than a cosmetic one.

What if show vlans shows the VLAN but show interfaces irb reports no such interface? The VLAN has no l3-interface statement pointing at it, or the unit number in that statement does not match a configured IRB unit. Add the binding and commit.

How do I check this on QFX with EVPN? The same decision tree applies for the local RVI, but Layer 2 reachability may come from the EVPN overlay rather than a local access port. Validate the MAC-VRF state separately — a worked example is in EVPN MAC-VRF validation.

Related Reading on This Site

Related Junos troubleshooting: inter-VLAN communication on EX Series, SR-TE LSPs through a multi-domain network, and reading show interfaces extensive error fields when you reach Step 4.

原文链接：https://supportportal.juniper.net/s/article/Resolution-Guide-EX-Troubleshoot-VLAN-Interface