12.2 Link Aggregation (LAG/LACP) & Redundant Trunk Groups (RTG)

Link Aggregation (LAG/LACP) & Redundant Trunk Groups (RTG)

In modern enterprise campus architectures, network resilience and bandwidth capacity must scale together. High-density access switches require high-speed uplinks to distribution layers, while distribution switches demand multi-gigabit interconnections to the campus core. Relying on single physical uplinks introduces single points of failure, while connecting redundant parallel links risks Layer 2 switching loops that standard Spanning Tree Protocol (STP) blocks—leaving costly bandwidth idle.

To overcome these constraints, Junos OS provides two essential Layer 2 link redundancy mechanisms: Link Aggregation Groups (LAG) operating with the Link Aggregation Control Protocol (LACP), and Redundant Trunk Groups (RTG).

---

1. IEEE 802.3ad / 802.1AX Link Aggregation Fundamentals

Link aggregation, formalized under IEEE 802.3ad and subsequently maintained under IEEE 802.1AX, allows network engineers to combine multiple physical point-to-point Ethernet links into a single logical, high-bandwidth connection known as a Link Aggregation Group (LAG) or bundle.

In Junos OS, a LAG is represented logically as an Aggregated Ethernet (ae) interface (e.g., ae0, ae1).

+-----------------------------------------------------------------------------------+
| Switch A (EX4300)                                              Switch B (EX4600)  |
|                                                                                   |
|  +-------------+     ge-0/0/0 (1 Gbps) - Member Link     +-------------+          |
|  |             |========================================|             |          |
|  | Logical ae0 |     ge-0/0/1 (1 Gbps) - Member Link     | Logical ae0 |          |
|  |   (2 Gbps)  |========================================|   (2 Gbps)  |          |
|  +-------------+                                         +-------------+          |
+-----------------------------------------------------------------------------------+

Primary Advantages of Link Aggregation

• Aggregated Bandwidth: Bundling physical links scales throughput beyond the capacity of individual physical ports. Two 10GbE links form a 20 Gbps logical pipe, while four 10GbE links create a 40 Gbps pipe.
• Transparent Fault Tolerance: If one member fails, the logical ae interface can remain UP provided enough usable members remain to satisfy minimum-links and other bundle requirements. Traffic automatically rehashes across the remaining operational member links in milliseconds. Because the logical interface state remains UP, upper-layer protocols (VLANs, STP, OSPF, and BGP) experience zero topology flapping.
• Load Distribution: Ingress traffic is dynamically balanced across all active member links using deterministic hardware hash algorithms.
• Prevention of STP Blocking: Because the spanning tree protocol treats the aggregated bundle as a single logical interface, STP does not block redundant parallel physical links within the LAG.

---

2. Link Aggregation Control Protocol (LACP) Mechanics

Link aggregation can be deployed in two modes: Static LAG (manual configuration without protocol handshakes) or Dynamic LAG using the Link Aggregation Control Protocol (LACP).

Static LAG vs. Dynamic LACP

In a static LAG, both switches assume all assigned member links are operational and actively forward frames. However, if a cabling error connects one member link to an unintended switch, or if an optical link suffers a unidirectional fault, the static LAG cannot detect the mismatch. Traffic forwarded over the misconnected link is lost, creating silent black holes.

Dynamic LACP solves this by exchanging standardized Link Aggregation Control Protocol Data Units (LACPDUs) across all member links:

• LACP Frame Attributes: LACPDUs are transmitted directly in Ethernet frames using destination multicast MAC address 01:80:C2:00:00:02 and Ethertype 0x8809 (Slow Protocols).
• Validation: LACPDUs continuously exchange system identifiers, port numbers, port keys, and operational states, ensuring that both ends agree on link speed, duplex, and partner identity before bundling a link into the forwarding state.

LACP Operational Modes

Each interface participating in LACP can be configured in one of two operational modes:

Exam Trap & Operational Gotcha: For an LACP aggregate bundle to form successfully, at least one side of the connection must operate in Active mode. If both endpoints are configured in Passive mode, neither side initiates LACPDU transmission, resulting in negotiation failure and an inactive bundle (Down state).

LACP Timers: Fast vs. Slow

LACP allows tuning the periodic transmission rate of LACPDUs:

• Fast Periodic Interval (fast): LACPDUs are transmitted every 1 second. A link partner is declared dead after missing 3 consecutive LACPDUs (3-second timeout). Fast timers are recommended for high-availability enterprise uplinks.
• Slow Periodic Interval (slow): LACPDUs are transmitted every 30 seconds. A link partner is declared dead after missing 3 consecutive LACPDUs (90-second timeout). This is the standard IEEE default to conserve CPU processing.

System Priority & Port Priority

To resolve contention when more member links are configured than the platform hardware supports (e.g., configuring 10 links when only 8 can be active simultaneously), LACP uses priority values:

• LACP System Priority: A 2-byte value (range 0 to 65535; default in Junos is 127). Combined with the switch's base MAC address, it forms the LACP System ID. The switch with the numerically lowest System ID wins mastership and dictates which member ports are selected.
• LACP Port Priority: A 2-byte value assigned to each physical member port (range 0 to 65535; default 127). When ties must be broken, ports with the lowest port priority are selected to forward traffic, while excess ports enter a standby state.

Output note: Command output shown here is a schematic teaching example, not a captured device session. Field names and feature support depend on platform and Junos release.

3. Junos LAG & LACP Configuration Workflow

Configuring an Aggregated Ethernet interface in Junos OS follows a strict, multi-step hierarchy. Overlooking the foundational chassis statement is one of the most common configuration errors on the JNCIS-ENT exam.

Step 1: Configure Chassis Aggregated Device Count

By default, Junos creates zero aggregated Ethernet interfaces. Before defining ae interfaces, you must instruct the chassis daemon (chassisd) to allocate the required number of logical aggregated devices:

[edit chassis]
user@EX4300# set aggregated-devices ethernet device-count 4

This statement reserves system resources for interfaces ae0 through ae3. On a platform requiring explicit allocation, an omitted or insufficient count prevents the requested ae interface from becoming usable. Other platforms preallocate ae interfaces; inspect platform documentation and the actual error rather than assuming one cause.

Step 2: Configure the Logical Aggregated Interface (ae0)

Define operational parameters, LACP mode, timers, and Layer 2 VLAN trunking directly on the logical bundle:

[edit interfaces ae0]
user@EX4300# show
description "Aggregated Trunk Uplink to Core";
aggregated-ether-options {
    minimum-links 2;
    link-speed 1g;
    lacp {
        active;
        periodic fast;
    }
}
unit 0 {
    family ethernet-switching {
        interface-mode trunk;
        vlan {
            members [ DATA_VLAN VOICE_VLAN MGMT_VLAN ];
        }
    }
}

The minimum-links Statement

The minimum-links statement specifies the minimum number of physical member links that must remain operationally active for the ae bundle to stay UP. For example, if a 4-port LAG has minimum-links 2 configured and three member links fail, Junos forces the entire ae0 interface operationally DOWN. This deliberate shutdown prevents the single remaining link from becoming severely oversubscribed and signals upstream routing protocols (OSPF) or STP to reconverge onto an alternate redundant path.

Step 3: Bind Physical Interfaces to the Aggregated Bundle

Assign physical member ports to the bundle using the 802.3ad statement under ether-options:

[edit interfaces]
user@EX4300# set ge-0/0/0 ether-options 802.3ad ae0
user@EX4300# set ge-0/0/1 ether-options 802.3ad ae0

Exam Trap & Operational Gotcha: Physical member interfaces bound to an ae bundle must have no protocol families, units, or VLAN configurations applied directly to them. All Layer 2 and Layer 3 parameters must be configured exclusively under the logical ae interface itself. If an engineer leaves unit 0 family ethernet-switching on ge-0/0/0, Junos generates a commit error.

---

4. LAG Load-Balancing & Hashing Algorithms

Link aggregation increases aggregate bandwidth, but it does not dynamically split individual packets across member links. Doing so would cause packets within a single TCP connection to arrive out of order, triggering duplicate ACKs, false packet loss detection, and catastrophic TCP window collapse.

Instead, Junos switches employ flow-based load distribution. Every packet belonging to a specific conversation (flow) is deterministically hashed to the exact same physical member link, guaranteeing strict in-order packet delivery.

Hardware Hashing Fields (The Hash Tuple)

Packet forwarding engines compute a multi-tuple hash value over specific header fields:

• Layer 2 Hashing: Source MAC, Destination MAC, Ethertype, VLAN ID.
• Layer 3 Hashing: Source IPv4/IPv6 Address, Destination IPv4/IPv6 Address, Protocol field.
• Layer 4 Hashing: Source TCP/UDP Port, Destination TCP/UDP Port.

On EX Series switches, engineers can customize the fields included in the hash key under [edit forwarding-options hash-key]:

[edit forwarding-options hash-key]
user@EX4300# show
family inet {
    layer-3;
    layer-4;
}

Including Layer 4 port numbers ensures that multiple distinct web or database sessions between the same pair of servers hash across different physical member links, maximizing throughput balance across the bundle.

---

5. Redundant Trunk Groups (RTG): The Campus Alternative to STP

While Link Aggregation bundles parallel links between two switches, campus access switches frequently dual-home to two distinct upstream distribution switches for chassis-level redundancy. If those distribution switches do not run Virtual Chassis technology, standard LAG cannot span across them.

Traditionally, Spanning Tree Protocol (STP) is used to block one of the dual uplinks. However, spanning tree networks can suffer from configuration drift, slow convergence on indirect faults, and potential loop storms if BPDUs are dropped. Junos provides Redundant Trunk Groups (RTG) as a robust, deterministic alternative to STP for dual-homed access designs.

RTG Architecture and Forwarding Mechanics

An RTG consists of a designated pair of Ethernet trunk links connecting an access switch to two separate upstream aggregation switches:

• Primary Link: Actively forwards user traffic for all configured VLANs.
• Secondary Link (Backup): Placed in a hardware blocking state. It does not forward user traffic or learn MAC addresses.
• Zero BPDU Transmission: RTG interfaces do not transmit or process Spanning Tree BPDUs. Spanning tree must be explicitly disabled on RTG member interfaces to prevent unexpected port state conflicts.
• Carrier-Triggered Failover: The access switch monitors the physical carrier state of the primary link directly in hardware. If the primary link drops link carrier, the switch instantly transitions the secondary link from blocking to forwarding in a platform-dependent interval, bypassing all spanning tree listening and learning timers.

Preemption and Hold Timers

When a primary link is explicitly designated, RTG preempts by default: a restored primary takes over after the preempt cutover timer (default one second). If no primary is designated, the first active link can continue forwarding. Distinguish these configurations before predicting recovery.

To delay return to an explicitly designated primary, configure preempt-cutover-timer:

[edit switch-options redundant-trunk-group group rtg0]
user@EX4300# set interface ge-0/0/0.0 primary
user@EX4300# set interface ge-0/0/1.0
user@EX4300# set preempt-cutover-timer 60

The preempt-cutover-timer 60 statement instructs the switch to wait 60 seconds after the primary link stabilizes before preempting the secondary link, allowing additional recovery time; verify upstream state rather than assuming a timer guarantees convergence.

---

6. Architectural Comparison: LAG vs. RTG vs. Spanning Tree

The table below contrasts the three primary Layer 2 link redundancy mechanisms deployed on Juniper EX switches:

---

7. Operational Verification & Troubleshooting

To verify LACP negotiation and member link health, use show lacp interfaces:

user@EX4300> show lacp interfaces ae0
Aggregated interface: ae0
    LACP state:       Role   Exp   Def  Dist  Col  Syn  Aggr  Timeout  Activity
      ge-0/0/0.0     Actor    No    No   Yes  Yes  Yes   Yes     Fast    Active
      ge-0/0/0.0   Partner    No    No   Yes  Yes  Yes   Yes     Fast    Active
      ge-0/0/1.0     Actor    No    No   Yes  Yes  Yes   Yes     Fast    Active
      ge-0/0/1.0   Partner    No    No   Yes  Yes  Yes   Yes     Fast    Active

In this output, verify that both Dist (Distributing) and Col (Collecting) are Yes, confirming that member links are actively transmitting and receiving user traffic.

To verify RTG operational status:

user@EX4300> show redundant-trunk-group
Group              Interface      State
rtg0     ge-0/0/0.0     Forwarding (Primary)
rtg0     ge-0/0/1.0     Blocking (Secondary)

Official references checked 2026-10-18: ELS RTG syntax, RTG recovery timer.