LAG
A Link Aggregation Group (LAG), based on the IEEE 802.1ax standard (formerly 802.3ad), increases the bandwidth available between two network devices, depending on the number of links installed. A LAG also provides redundancy if one or more links participating in the LAG fail. All physical links in a LAG combine to form one logical interface.
Packet sequencing is maintained for individual sessions. The hashing algorithm deployed by SR Linux is based on the type of traffic transported to ensure that all traffic in a flow remains in sequence, while providing effective load sharing across the links in the LAG.
LAGs can be either statically configured, or formed dynamically with Link Aggregation Control Protocol (LACP). Load sharing is executed in hardware, which provides line rate forwarding for all port types. A LAG can consist of ports of the same speed, as well as ports of mixed speed; however, the active links would be only those whose port speed matches the configured member-speed parameter for the LAG instance.
Min-link threshold
SR Linux supports configuring a min-link threshold for a LAG, which sets the minimum number of member links that must be active in order for the LAG to be operationally up. If the number of active links falls below this threshold, the entire LAG is brought operationally down.
If the min-link threshold is crossed, the active member links are maintained, including continuing to run LACP on links where it is configured, but the LAG is held out of forwarding state. When the number of active links reaches or exceeds the min-link threshold, the LAG is brought back up operationally.
LACP
LACP, defined by the IEEE 802.3ad standard, specifies a method for two devices to establish and maintain LAGs. When LACP is enabled, SR Linux can automatically associate LACP-compatible ports into a LAG. All non-failing links in a LAG are active, and traffic is load-balanced across the active links.
When LACP is enabled, LACP changes are visible through traps and log messages logged against the LAG.
LACP fallback
LACP fallback allows one or more designated links of an LACP controlled LAG to go into forwarding mode if LACP is not yet operational after a configured timeout period.
SR Linux supports LACP fallback in static mode. In static mode, a single designated LAG member goes into forwarding mode if LACP is not operational after the timeout period.
LACP fallback is configured by selecting the mode and fallback timeout (seconds). If the LAG receives no PDUs and the timeout period expires, the configured fallback mode is enabled. If any member link in the LAG receives a PDU, the fallback mode is immediately disabled.
LAG configuration
To configure a LAG, you specify LAG parameters within the context of a LAG interface, then associate Ethernet interfaces with the LAG interface.
The MAC address of the LAG should be a unique value taken from the chassis MAC address pool.
Member links in the LAG can be associated statically or dynamically.
Static links are explicitly associated with the LAG within the configuration of the LAG instance.
Dynamic links are associated with the LAG using LACP.
A LAG instance can consist of static links only or dynamic links only.
If an Ethernet interface is associated with a LAG interface, the following parameters must be the same for all associated Ethernet ports:
flow-control
port-speed
aggregate-id
The following example shows the configuration for a LAG consisting of three member links.
--{ * candidate shared default }--[ ]--
# info with-context interface *
interface ethernet-1/1 {
admin-state enable
ethernet {
aggregate-id lag1
}
}
interface ethernet-1/2 {
admin-state enable
ethernet {
aggregate-id lag1
}
}
interface ethernet-1/3 {
admin-state enable
ethernet {
aggregate-id lag1
}
}
interface lag1 {
subinterface 1 {
admin-state enable
}
lag {
lag-type static
min-links 2
}
}
Configuring the min-link threshold
You can configure the min-link threshold for a LAG, which specifies the minimum number of member links that must be active in order for the LAG to be operationally up. If the number of active links falls below this threshold, the entire LAG is brought operationally down.
The following example configures the min-link threshold for a LAG to be 4. If the number of active links in the LAG drops below 4, the LAG is taken operationally down.
--{ * candidate shared default }--[ ]--
# info with-context interface lag1
interface lag1 {
lag {
min-links 4
}
}
After the LAG has been taken operationally down because of crossing the min-link threshold, if the number active links in the LAG subsequently reaches 4 or higher, the LAG is brought operationally up. The default for the min-link threshold is 0 (disabled).
Configuring LACP and LACP fallback
When you enable LACP, SR Linux can
automatically associate LACP-compatible ports into a LAG. LACP should be configured
in ACTIVE mode only if LACP fallback is also configured.
Configure LACP to run on an interface
The following example configures LACP to run on an interface, which can dynamically become a member of a LAG:
--{ * candidate shared default }--[ ]--
# info with-context interface lag1
interface lag1 {
lag {
lag-type lacp
min-links 1
member-speed 100G
lacp-fallback-mode static
lacp-fallback-timeout 4
lacp {
interval FAST
lacp-mode ACTIVE
}
}
}In this example, the LACP interval is set to FAST, which causes LACP messages to be sent every second. The SLOW option for LACP interval causes LACP messages to be sent every 30 seconds.
Enable LACP fallback mode for a LAG
The following example enables LACP fallback mode for a LAG, which allows a single designated LAG member to go into forwarding mode if LACP is not operational after the timeout period.
--{ * candidate shared default }--[ ]--
# info with-context interface lag1
interface lag1 {
lag {
lacp-fallback-mode static
lacp-fallback-timeout 4
}
}The LACP fallback timeout range is 4 to 3600 seconds when the LACP interval is FAST, and 90 to 3600 seconds when LACP interval is SLOW.
Enable LACP port priority
The following example enables LACP port priority. When LACP fallback is triggered in static mode, one of the member-links goes into a forwarding state that can be influenced using LACP port priority.
--{ * candidate shared default }--[ ]--
# info with-context interface ethernet-1/1 ethernet
interface ethernet-1/1 {
ethernet {
aggregate-id lag1
lacp-port-priority 1
port-speed 25G
hw-mac-address 00:01:02:FF:00:01
}
}Disabling LAG member interfaces
Administratively disabling the LAG automatically brings the operational state of all its member links down. Disabling all LAG member-link interfaces when the LAG admin is operationally down allows for the continuous monitoring of the operational status of LAG member interfaces. This ensures that traffic is not forwarded through the member interfaces while the LAG is disabled.
--{ * candidate shared default }--[ ]--
# info with-context interface lag1
interface lag1 {
admin-state disable
lag {
lag-type lacp
member-speed 100G
lacp {
lacp-mode ACTIVE
admin-key 1
}
}
}--{ candidate shared default }--[ interface ethernet-1/1 ]--
# show
================================================================================
ethernet-1/1 is down, reason lag-admin-disabled
--------------------------------------------------------------------------------
================================================================================
--{ candidate shared default }--[ interface ethernet-1/1 ]--
# info from state
admin-state enable
loopback-mode none
ifindex 32768
oper-state down
oper-down-reason lag-admin-disabled
last-change "2026-05-19T15:12:00.991Z (an hour ago)"
Forwarding viability configuration for LAG members
By default, all interfaces configured in a LAG are capable of forwarding traffic to the other end of the LAG, assuming all other LAG and port attributes allow it (port and LACP state). You can optionally configure individual LAG members to be non-viable for forwarding traffic to the other end of the LAG link.
When a LAG member is configured as non-viable for forwarding traffic, the interface is not used for the transmission of traffic over the LAG, but is still able to process traffic it receives on the associated member link. In addition, Layer 2 protocols such as LLDP, LACP, and micro-BFD continue to be sent and processed over the non-forwarding-viable LAG member.
LAG forwarding viability interaction with other protocols
If at least one member of a LAG is operational and not configured as non-viable for
forwarding LAG traffic, then the IP subinterfaces associated with the LAG remain up
and continue to operate normally. If all members of a LAG are either operationally
down and, or marked as configured as non-viable for forwarding LAG traffic, the
fib-tx-forwarding state for the LAG is set to
false at the LAG level, interface level and subinterface level.
The fib-tx-forwarding state is set back to true
when at least one member link is operationally up and is configured as viable for
forwarding LAG traffic.
-
For gRIBI, if the
fib-tx-forwardingstate for the LAG isfalse, the IP subinterface is removed from any gRIBI next-hop entry in use. If this results in no active next hop entries being viable, SR Linux switches to an available backup next hop group (NHG).If the
fib-tx-forwardingstate for the LAG is set back totrue, SR Linux re-evaluates any next hop entries that were removed from use and re-installs them, which may result in switching from a backup NHG to the primary NHG if the updated state makes the primary NHG viable again. -
For IP control traffic, if the
fib-tx-forwardingstate for the LAG isfalse, the IP control plane stops sending IP control traffic out of the associated LAG, the same as transit traffic. Any IP control traffic with keepalives or BFD associations time in based on configured timer values.
The fib-tx-forwarding state is used internally by the system and is
not visible in output from info from state commands.
LAG forwarding viability interaction with load balancing
When the forwarding viability configuration for a LAG member is changed from true to false, the LAG dynamic bandwidth value is adjusted based on the remaining number of usable LAG links. This LAG bandwidth value then causes an adjustment to the amount of traffic directed to the LAG by wECMP hashing.
Configuring forwarding viability for a LAG member
To configure the forwarding viability for a LAG member, you set ethernet forwarding-viable to either true or false for the interface.
The following example configures a LAG member to be non-viable for forwarding traffic across a LAG link. The interface can still receive traffic on the LAG link and participate in Layer 2 functions, but does not transmit packets to the other end of the LAG.
--{ candidate shared default }--[ ]--
# info with-context interface ethernet-1/1 ethernet
interface ethernet-1/1 {
ethernet {
aggregate-id lag1
forwarding-viable false
}
}LAG resource allocation
On SR Linux devices, LAG interfaces rely on datapath resource pools allocated for the LAG ID and the member links. By default, the datapath resource pools allow up to 512 LAGs, each with 64 member links.
For the per-subinterface queuing and scheduling feature (see the 7220 IXR and 7250 IXR SR Linux Quality of Service Guide), subinterfaces on a LAG interface require internal resources that come from the same datapath resource pools. Every subinterface on a LAG requires additional resources. This requirement is in addition to the resources already required by the physical LAG interface and member ports. On 7250 IXR-X4 devices, the datapath resource pools are by default entirely reserved for the physical LAG scale (512 LAGs x 64 member links), leaving no resources for subinterfaces with per-subinterface queueing requirements.
To accommodate the resource requirement for the per-subinterface queuing and scheduling feature, you can decrease the amount of resources reserved for physical LAGs, making LAG pool resources available for subinterfaces. To do this, you can change the maximum number of member links per LAG from the default of 64 to a lower value. The maximum number of LAGs remains at generally at 512 for most 7250 IXR devices (256 for 7250 IXR-X4), but each LAG can have no more than the configured maximum number of member links. This lowered value applies to all LAGs system-wide.
After you change the maximum value for LAG member links, a system reboot is required.
When the configuration is loaded following the reboot, previously configured LAGs that
have a larger number of member links than the maximum value are brought up with a number
of links that matches the maximum value; for example, if the maximum value is 8, and a
LAG is configured to have 10 member links, only 8 ports in the LAG are placed in the
oper-up state. The other 2 ports in the LAG are placed in the
oper-down state with port-oper-down-reason =
lag-resource-exceeded, and the LAG members have
member-link-oper-down-reason = port-oper-disabled. The ports made
oper-up and oper-down depend on the system's order
of execution of the startup configuration; that is, links made oper-up
are the ones whose configuration the system executed first, while the links made
oper-down are the ones whose configuration the system executed
after the maximum value for LAG link members was exceeded.
If an additional port is made part of a LAG, and this addition results in the number of
links exceeding the maximum value, the last-added member link is placed in
oper-down state.
oper-down state because of exceeding the
maximum value, and you remove some of the oper-up links from the LAG,
the system does not automatically reallocate resources to bring the
oper-down links up. To bring the oper-down links
up, do any of the following:- Execute the tools interface <lag> resource retry command
- Disable and re-enable the
admin-stateof the LAG - Disable and re-enable the
admin-stateof theoper-downports you want to bring up
Configuring LAG resource allocation
To configure LAG resource allocation, set a value for the maximum number of member links for LAGs on the device, then reboot the system.
Configure the system-wide maximum LAG member count
The following example configures the maximum number of member links for all LAGs on the SR Linux device.
--{ + candidate shared default }--[ ]--
# info with-context platform resource-management
platform {
resource-management {
lag-pool {
max-member-count 32
}
}
}After committing the change, a reboot is required for the
max-member-count to take effect. Following the reboot, LAG
members are brought up, in order of system configuration, up to the
max-member-count. The remaining member links are placed in the
oper-down state with port-oper-down-reason =
lag-resource-exceeded, and each LAG member has
member-link-oper-down-reason = port-oper-disabled.
Retry LAG resource allocation
If some of the member ports are in oper-down state because the
max-member-count was exceeded, and you subsequently remove some
of the oper-up member ports from the LAG, the
oper-down ports do not automatically transition to
oper-up. For these ports to transition to
oper-up, you can disable/re-enable the
admin-state of the LAG or port, or you can use the following
tools command:
--{ + candidate shared default }--[ ]--
# tools interface lag1 resource retry
/interface[name=lag1]:
interface lag1 resource retriedDisplaying LAG interface statistics
To display statistics for a LAG interface, use the info from state command in candidate or running mode, or the info command in state mode.
--{ candidate shared default }--[ ]--
# info with-context from state interface lag1 statistics
interface lag1 {
statistics {
in-octets 0
in-unicast-packets 0
in-broadcast-packets 0
in-multicast-packets 0
in-error-packets 0
in-fcs-error-packets 0
out-octets 7168
out-unicast-packets 0
out-broadcast-packets 0
out-multicast-packets 56
out-error-packets 0
last-clear 2020-06-09T21:58:40.919Z
}
}
Clearing LAG interface statistics
You can clear the statistics counters for a specified LAG interface.
Clear statistics counters for a LAG interface
--{ candidate shared default }--[ ]--
# tools interface lag1 statistics clear
/interface[name=lag1]:
interface lag1 statistics cleared
Clear statistics for a LAG interface and all member links
--{ candidate shared default }--[ ]--
# tools interface lag1 statistics clear include-members
/interface[name=lag1]:
interface lag1 and all member interfaces statistics cleared