Junos LACP ae Interface Down: Fix Detached Members

Short answer: when a junos lacp ae interface down state persists, the cause is usually one of two things. Either the far end is not sending LACP PDUs, which shows as Defaulted, or the member links physically never came up, which shows as Port disabled. Run show lacp interfaces ae0 first. The Receive State column tells you which half of the problem you have in under ten seconds.

This guide is written against the Junos OS 23.4 train on EX4300, QFX5120 and MX series syntax. We have not lab-tested every command on every platform and release. Check each block on your own platform with ? completion and in a lab before you run it in production. Where behaviour differs across trains or between Junos OS and Junos OS Evolved, we say so.

If you need the basics of reading interface counters first, the Troubleshooting hub has our guide to show interfaces extensive. Commit mechanics and rollback are covered in Junos Basics.

Why the ae Bundle Fails Silently

LACP is a negotiation. Neither side forwards frames on a member until both actor and partner agree on the same aggregation group. Junos is strict about this. With LACP enabled, a member will not carry traffic just because the light is on. It needs a valid PDU from a partner whose system ID and key match the other members of the bundle.

That strictness is a deliberate design trade-off. A static LAG will happily forward into a far end that is cabled to the wrong ports, and you get a loop or a black hole. LACP converts that silent data-plane failure into a visible control-plane failure. The cost is that every misconfiguration on the far end now looks like a Juniper problem. In our experience most "Juniper LACP will not come up" tickets are resolved on the other box.

The second reason this failure is confusing is that Junos gives you very little by default. An ae interface does not even exist until you tell the chassis how many aggregated devices to create. The physical members can show up/up while the bundle shows down, and there is no commit error telling you why. The fix is to read the LACP state machine columns, which most engineers skip.

Reading show lacp interfaces: Healthy vs Broken

Every diagnosis starts here. A healthy two-member bundle looks like this. System identifiers in this article use the RFC 7042 documentation MAC range.

user@ex-access> show lacp interfaces ae0
Aggregated interface: ae0
    LACP state:       Role   Exp   Def  Dist  Col  Syn  Aggr  Timeout  Activity
      xe-0/0/10      Actor    No    No   Yes  Yes  Yes   Yes     Fast    Active
      xe-0/0/10    Partner    No    No   Yes  Yes  Yes   Yes     Fast    Active
      xe-0/0/11      Actor    No    No   Yes  Yes  Yes   Yes     Fast    Active
      xe-0/0/11    Partner    No    No   Yes  Yes  Yes   Yes     Fast    Active
    LACP protocol:        Receive State  Transmit State          Mux State
      xe-0/0/10                 Current   Fast periodic Collecting distributing
      xe-0/0/11                 Current   Fast periodic Collecting distributing

The broken state you will most often see is below. Note Def Yes on both rows and Defaulted in Receive State. The local box is transmitting, but it has never received a usable PDU from the partner.

user@ex-access> show lacp interfaces ae0
Aggregated interface: ae0
    LACP state:       Role   Exp   Def  Dist  Col  Syn  Aggr  Timeout  Activity
      xe-0/0/10      Actor    No   Yes    No   No   No   Yes     Fast    Active
      xe-0/0/10    Partner    No   Yes    No   No   No   Yes     Fast   Passive
    LACP protocol:        Receive State  Transmit State          Mux State
      xe-0/0/10               Defaulted   Fast periodic           Detached

The partner row showing Passive here is not real partner data. It is the default partner information Junos fills in when nothing has been received. Do not conclude that the far end is configured passive. This exact pattern appears in a widely read r/Juniper thread about an EX4550 to Avaya bundle, where the far end had LACP disabled.

What each state combination usually means

Receive State	Mux State	Most likely cause
Port disabled	Detached	Member is physically down: optics, cable, speed or autonegotiation.
Defaulted	Detached	No PDUs arriving: far end not running LACP, both sides passive, or something in the path drops PDUs.
Current	Detached or Waiting	PDUs arrive but the partner system ID or key does not match the rest of the bundle.
Expired, flipping to Current	Varies	Intermittent PDU loss: CPU starvation, congestion or a flapping member.
Current	Collecting distributing	LACP is healthy. If traffic still fails, look at VLANs, units or routing.

If the command returns Warning: lacp subsystem not running not needed by configuration, LACP is not configured in active or passive mode anywhere. You are running a static LAG, or the configuration never committed.

The Ordered Diagnostic: Cheapest Check First

Work through these in order. Each step either finds the fault or rules out a whole class of causes.

Does ae0 exist and are the members physically up? Run show interfaces terse | match "ae0|xe-0/0/1[01]". If ae0 is missing, go to cause two below. If members are down, fix Layer 1 before touching LACP.
Is the device-count high enough? Run show configuration chassis aggregated-devices. The ae number must be lower than the count. A count of 2 creates ae0 and ae1 only.
What does the state machine say? Run show lacp interfaces ae0 and use the table above.
Are PDUs actually arriving? Run show lacp statistics interfaces ae0 twice, about ten seconds apart. LACP Rx must increment on every member.
Is every member talking to the same partner? Run show lacp interfaces ae0 extensive and compare partner system identifier and port key across members.
What did lacpd log? Run show log messages | match lacp and look for timeouts and state changes around the failure time.
Is the path eating PDUs? Only now capture on the member with monitor traffic interface xe-0/0/10 detail. On some platforms LACP is handled in the PFE and may not appear in this capture, so an empty capture is not proof.

user@ex-access> show interfaces terse | match "ae0|xe-0/0/1[01]"
user@ex-access> show configuration chassis aggregated-devices
user@ex-access> show lacp interfaces ae0
user@ex-access> show lacp statistics interfaces ae0
user@ex-access> show lacp interfaces ae0 extensive
user@ex-access> show log messages | match lacp

Root Causes Ranked by Frequency

This ranking reflects what we see in the field and what repeats across r/Juniper, the Juniper community forum and Stack Exchange. It is our experience, not a Juniper statistic.

1. The far end is not running LACP, or both ends are passive

This is the classic Defaulted case. The far end may be a static port-channel, such as Cisco channel-group 1 mode on. It may be a server bond in balance-rr rather than 802.3ad mode. Or both ends may be set passive, which the Juniper documentation confirms will never form a bundle. Set at least one side active. We recommend active on both, because it removes one variable.

2. Missing or too-low aggregated device count

Without set chassis aggregated-devices ethernet device-count, no ae interfaces are created. The symptom is that ae0 simply does not appear in show interfaces terse. The subtler version is a count of 2 with a new ae2 configured. This was the first reply in a recent r/Juniper thread for good reason: it is quick to check and often wrong.

3. Member links physically down: speed, autonegotiation or optics

Port disabled means LACP never got a chance. Common triggers are a 10G copper or SFP+ port facing a 1G peer, and mixed optic types. Some engineers find that bundling a port changes how speed is handled, so they must pin speed on the members. On EX, speed is set under ether-options. The link-speed statement under aggregated-ether-options sets the expected member speed for the bundle.

4. Members land on two different partner systems

This is the "one member always Detached" symptom. Receive State is Current, PDUs are arriving, but one member reports a different partner system identifier. The far end is two independent switches without MC-LAG, vPC or MLAG. Or the far end is a Virtual Chassis that has split. The extensive output makes it obvious:

user@ex-access> show lacp interfaces ae0 extensive
(abridged)
    LACP info:        Role     System             System       Port     Port    Port
                             priority          identifier   priority   number     key
      xe-0/0/10      Actor        127  00:00:5e:00:53:01        127        1       1
      xe-0/0/10    Partner      32768  00:00:5e:00:53:a1      32768        1       1
      xe-0/0/11      Actor        127  00:00:5e:00:53:01        127        2       1
      xe-0/0/11    Partner      32768  00:00:5e:00:53:b7      32768        1       1

Two partner system identifiers means two partners. LACP is doing its job by refusing to aggregate them. A specific case is an SRX chassis cluster reth interface facing a switch. The switch needs one ae per SRX node, not one ae across both nodes. Juniper covers this in the KB article on supported and unsupported SRX and EX LACP configurations. Our Security and Firewalls hub covers SRX clustering in more depth.

5. Leftover unit configuration on a member

Factory-default EX configs often put unit 0 family ethernet-switching on every port. A member link must not carry its own logical units. In our experience the commit is rejected, or the port never joins. Delete the unit on the member and put all Layer 2 or Layer 3 config on the ae instead.

6. Something in the path drops or rewrites PDUs

Virtual labs are the usual culprit. vMX and vQFX across a Linux bridge or hypervisor vSwitch often lose LACP frames, which are sent to a reserved multicast MAC. Some media converters and DWDM transponders do the same. The community workaround in labs is force-up. Treat that as a diagnostic, not a fix, in production.

Copy-Ready Configuration

Any change to an uplink bundle can cut your own management path. Use commit confirmed 5 and have out-of-band console or fxp0/me0 access before you commit. If the bundle does not come up, Junos rolls back automatically when the timer expires.

EX and QFX (ELS syntax)

set chassis aggregated-devices ethernet device-count 4
delete interfaces xe-0/0/10 unit 0
delete interfaces xe-0/0/11 unit 0
set interfaces xe-0/0/10 ether-options 802.3ad ae0
set interfaces xe-0/0/11 ether-options 802.3ad ae0
set interfaces ae0 description uplink-to-dist-01
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 aggregated-ether-options lacp periodic fast
set interfaces ae0 aggregated-ether-options minimum-links 1
set interfaces ae0 unit 0 family ethernet-switching interface-mode trunk
set interfaces ae0 unit 0 family ethernet-switching vlan members v100
set vlans v100 vlan-id 100
commit confirmed 5

Older non-ELS EX software used port-mode trunk rather than interface-mode trunk. Many forum snippets still show the old keyword. If you paste one onto an ELS switch, the commit fails on that line.

MX series (routed bundle)

set chassis aggregated-devices ethernet device-count 4
set interfaces xe-0/0/0 gigether-options 802.3ad ae0
set interfaces xe-0/0/1 gigether-options 802.3ad ae0
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 aggregated-ether-options lacp periodic fast
set interfaces ae0 aggregated-ether-options minimum-links 1
set interfaces ae0 unit 0 family inet address 192.0.2.0/31
set interfaces ae0 unit 0 family inet6 address 2001:db8:0:1::/127
commit confirmed 5

On MX and SRX, the member hierarchy has traditionally been gigether-options. Recent releases also accept ether-options on many line cards. Check with set interfaces xe-0/0/0 ? on your release rather than trusting either form blindly.

Diagnostic force-up and flap damping

set interfaces ae0 aggregated-ether-options lacp force-up
set interfaces ae0 aggregated-ether-options lacp hold-time up 10

On switches, force-up brings one member up without PDUs, typically for servers booting without LACP. By default only one member can be in force-up. The hold-time up timer stops a member that keeps flipping between Expired and Current from re-joining until it has been stable. Verify the supported hierarchy for both statements on your platform, because it differs between switching and routing platforms.

Verification After the Fix

Confirm three things: the state machine, the counters and the bundle itself. Healthy statistics show Rx climbing on every member and zero illegal PDUs:

user@ex-access> show lacp statistics interfaces ae0
Aggregated interface: ae0
    LACP Statistics:       LACP Rx     LACP Tx   Unknown Rx   Illegal Rx
      xe-0/0/10                 842         845            0            0
      xe-0/0/11                 840         844            0            0

user@ex-access> show interfaces terse ae0
Interface               Admin Link Proto    Local                 Remote
ae0                     up    up
ae0.0                   up    up   eth-switch

If Tx climbs but Rx stays at zero on one member, the fault is on the far end or in the path for that member only. A Tx far higher than Rx on a single member, as in one r/Juniper case, points to a member that is receiving PDUs from somewhere other than the bundle partner.

Version and Platform Drift to Watch

Junos OS Evolved behaves differently for untagged ae interfaces with no logical unit. The Juniper show interfaces (Aggregated Ethernet) reference notes that such an ae is not shown as down on Evolved. So a bundle can look healthy there while carrying nothing. The field definitions we used above come from the show lacp interfaces command reference, and the extensive option first appeared in 16.1R1.

The fast and slow timers do not need to match. Each side asks its partner to transmit at its own preferred rate. Fast gives a three second failure detection and slow gives ninety seconds. A mismatch rarely stops a bundle forming, so do not spend time there early in the diagnostic.

Once the bundle is up, remaining traffic problems usually sit in VLAN membership or routing. The Routing and Switching hub covers those next steps.

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

Frequently Asked Questions

Why does my LACP show Defaulted and Detached?

Defaulted means the member has never received a valid LACP PDU from the partner, so Junos uses default partner values. Check that the far end is configured for LACP rather than a static channel, and that at least one side is active. Then confirm LACP Rx increments with show lacp statistics interfaces ae0.

What purpose does chassis aggregated-devices serve?

It tells Junos how many ae interfaces to create, and without it no ae interface exists. Set it with set chassis aggregated-devices ethernet device-count 4, choosing a number higher than your highest ae index. Remember that ae numbering starts at zero.

Why is one interface in my LACP bundle always detached?

Usually that member is connected to a different partner system than the others. Compare partner system identifiers in show lacp interfaces ae0 extensive. If they differ, the far end needs MC-LAG or equivalent, or each partner needs its own bundle.

Do I need to set minimum-links 1 for the ae to come up?

The default minimum is already one link, so it should not be required. Engineers who report that adding it fixed the bundle usually changed something else at the same time, such as re-enabling LACP on the far end. It does no harm to set it explicitly with set interfaces ae0 aggregated-ether-options minimum-links 1.

Why is my LACP ae0 interface always down on vMX?

The virtual bridge between instances often drops LACP frames, which use a reserved multicast MAC. Configure the hypervisor bridge to forward those frames, or use force-up in the lab only. Do not carry that workaround into production configs.

Junos LACP ae Interface Down: Why Members Sit in Defaulted or Detached and How to Fix It