Link-Up Does Not Tell You Which Ethernet Ports LACP Is Using

Identify the population before adding the rates

IEEE's 802.1AX-2020 project page describes aggregation of parallel full-duplex point-to-point links into a logical link. Its aggregate-bandwidth concept does not make an installed cable count a forwarding-member count.

A carrier-up indication answers a physical-link question. A port listed as a candidate for a bond or port-channel raises a different question: which aggregation does it actually belong to? That group must also be the one selected for the traffic being considered. Finally, its members need the applicable data participation state. These distinctions matter when an offer combines a cable quantity, a logical-interface name and a capacity number in one line.

For Link Aggregation Control Protocol (LACP), Juniper's Junos OS field definitions make the last distinction concrete. Synchronization concerns allocation to the appropriate aggregation and consistency with system and operational-key information. Collecting enables incoming frames for the aggregation; distributing enables outgoing frames. Enabled participation does not itself say that a particular workload is using every member.

References: [AX1][J1]

How Linux v6.17 groups compatible candidates

Actor denotes the local participant; partner denotes the remote participant. In Linux v6.17, a received message's Actor identity and key fields populate the local partner record. Joining an existing partnered, nonindividual aggregator requires matching the local operational key and the partner system address, system priority and operational key against that aggregator. This does not require the local key to equal the remote key.

The bonding documentation also describes speed and duplex as grouping conditions. Matching port rates therefore leaves the partner and key relationships to establish. A shared label in a purchase schedule cannot substitute for those relationships.

References: [K1][K2][J1]

A selected group still needs forwarding members

The Linux v6.17 documentation describes a choice of active aggregator, with selection policies that consider aggregate bandwidth or member count and differ in when reselection occurs. It lists changes in physical link state and changes in aggregation association state separately. This explains why a carrier inventory alone cannot describe the logical group in use.

Group selection and member participation then answer different buyer questions. The first identifies the relevant aggregate; the second identifies which of its ports can receive or transmit aggregate data. Juniper's field definitions distinguish an attached port from collecting and distributing states, and distinguish the local actor from its remote partner.

For a capacity statement, ask what the reported state enables in the stated direction. A group identifier is incomplete evidence for that question. So is an idle traffic counter: a member can be eligible without a particular observed flow selecting it.

References: [K2][J1]

Why data participation can stop while carrier remains up

Linux v6.17 provides a specific mechanism: LACP receive-timer expiry can move CURRENT to EXPIRED without physical LINK_DOWN, clearing recorded partner synchronization. In the coupled-control multiplexer (MUX) path, lost partner synchronization returns a forwarding port to ATTACHED. Entry to ATTACHED clears collecting/distributing flags and disables that data participation.

Carrier and protocol state can therefore disagree without contradiction. This example explains a possible state transition; it diagnoses no particular installation. The inspected Linux path does not establish another platform's behavior or a traffic-recovery duration. The related BFD timing article examines the separate question of detection versus recovery.

References: [K1]

Work four carrier-up 100 Gb/s links through the distinction

Consider an invented purchase review with four links, P1 through P4, each stipulated to have carrier and a nominal rate of 100 Gb/s. Observe the local endpoint sending toward its LACP partner. Stipulate a supported implementation in which G is this endpoint's active group and the following membership and forwarding states are already established at one observation time. These premises are educational, not a trace from real equipment.

P1 and P2 belong to G, with both local actor and recorded partner synchronization established; both ports are collecting and distributing. P3 records a different partner operational key from P1 and P2 and belongs to another group, H. P4 belongs to G, but its recorded partner synchronization is false and P4 is neither collecting nor distributing. All four physical carriers remain up. P3 illustrates the grouping distinction; P4 illustrates the participation distinction. Neither earns capacity credit in G merely because its physical link is up.

For one sending direction, the eligible nominal member-rate sum is P1 plus P2: 100 + 100 = 200 Gb/s. Adding all installed links gives 400 Gb/s, but that sum includes P3 outside the relevant group and P4 outside its forwarding population. The opposite direction is not added to either figure.

The 200 Gb/s figure establishes only the sum of the stipulated eligible member rates. It establishes neither achieved application throughput nor one 200 Gb/s flow. Once the active population is known, the related Ethernet breakout and link aggregation article explains the next question: how a stated flow-distribution mechanism uses that population.

The useful purchasing response is consequently precise: four physical connections are present, while only two qualify for the stated aggregate at this observation time. If the requirement calls for all four to participate, that requirement remains unresolved. These premises identify no real fault cause or corrective setting.

References: [K1][K2][J1]

Read the evidence behind the capacity statement

A supplier response should connect its capacity number to the named group, the applicable equipment and software, and member-state evidence from the relevant endpoints. The observation time matters: combining yesterday's physical-link inventory with today's aggregation state may describe no single actual population.

In the worked case, confirmation that G is selected would answer only part of the question. The response still needs to account for P3's different association and P4's absent participation before presenting a four-member capacity claim. The network owner can explain those states and the design's intended behavior without asking a buyer to infer a diagnosis from four green link indicators.

References: [K2][J1]

Carry the endpoint identities into the physical handoff

The physical installation record should let the receiving network team map P1 through P4 to the actual rack, panel, cable and port identities. That makes a logical membership question traceable to the installed connections without treating cable completion as LACP acceptance.

Leviathan's Structured Cabling service covers agreed physical installation, routing, dressing, labels and connection records using customer-furnished or separately sourced materials. Aggregation configuration and interpretation of its forwarding behavior remain with the appointed network owner.

Use the service and project inquiry links to share a nonconfidential endpoint and patching plan, materials responsibilities, site constraints and required handoff records. The team can then discuss the physical work, requirements and availability.

References: [L1]