Understanding Ethernet Link Aggregation on ACX Series Routers
Ethernet link aggregation is mechanism for increasing the bandwidth linearly and improving the resiliency of Ethernet links by bundling or combining multiple full-duplex same-speed point-to-point Ethernet links into a single virtual link. The virtual link interface is referred to as link aggregation group (LAG) or aggregated Ethernet (AE) interface. The LAG balances traffic across the member links within an aggregated Ethernet bundle and effectively increases the uplink bandwidth. Another advantage of link aggregation is increased availability, because the LAG is composed of multiple member links. If one member link fails, the LAG continues to carry traffic over the remaining links.
ACX Series routers support connectivity fault management (CFM) on aggregated Ethernet interfaces with continuity check interval of 100 milliseconds or higher.
ACX5048 and ACX5096 routers support connectivity fault management (CFM) on aggregated Ethernet interfaces with continuity check interval of 1 second or higher.
The Ethernet options configurations for ACX5048 and ACX5096 routers differ compared to other ACX Series routers. For more information, see Layer 2 Next Generation Mode for ACX Series.
On ACX Series routers, up to 128 AE interfaces can be created with each AE interface having up to 8 physical interfaces. AE interfaces can be created across PICs and fixed-ports on the chassis.
On ACX5048 and ACX5096 routers, up to 64 AE interfaces can be created with each AE interface having up to 16 physical interfaces.
ACX Series routers do not support statistics for aggregated Ethernet interface. However, statistics can be retrieved for member interface.
To configure aggregated Ethernet interface:
Specify the number of aggregated Ethernet interfaces to be created:
[edit chassis] user@host#
set aggregated-devices ethernet device-count numberSpecify the minimum number of links for the aggregated Ethernet interface (aex), that is, the defined bundle, to be labeled “up”:
Note:By default only one link must be up for the bundle to be labeled “up”.
[edit interfaces] user@host#
set ae0 aggregated-ether-options minimum-links number (1 — 8)Specify the link speed for the aggregated Ethernet bundle:
[edit interfaces] user@host#
set ae0 aggregated-ether-options link-speed speed (10g | 1g | 100m)Specify the members to be included within the aggregated Ethernet bundle:
[edit interfaces] user@host#
set ge-1/0/0 gigether-options 802.3ad ae0user@host#set ge-1/0/1 gigether-options 802.3ad ae0Specify an interface family for the aggregated Ethernet bundle:
[edit interfaces] user@host#
set ae0 unit 0 family inet address ip-address
The above procedure creates an AE interface and they would be up and ready for running the services defined on AE logical interfaces.
AE interfaces can be VLAN-tagged or untagged. You can configure flexible-vlan-tagging, native-vlan-id, and dual-tagging on AE interfaces.
Whenever there is a configuration change (AE interface to Gigabit Ethernet interfaces or vice versa), you need to remove the existing configuration, perform a commit, then add the new configuration and again commit the configuration.
To delete an aggregated Ethernet interface:
Delete the aggregated Ethernet configuration.
This step changes the interface state to down and removes the configuration statements related to aex.
[edit] user@host#
delete interfaces aexDelete the interface from the device count.
[edit] user@host#
delete chassis aggregated-devices ethernet device-count
For aggregated Ethernet interfaces, you can configure the Link Aggregation Control Protocol (LACP). LACP is one method of bundling several physical interfaces to form one logical interface. You can configure both VLAN-tagged and untagged aggregated Ethernet with or without LACP enabled.
Load Balancing
JUNOS load-balances traffic across member links in an AE bundle based on the Layer 3 information in the packet. You can globally configure what fields are used for load-balancing for inet and MPLS
On ACX Series Routers, the inet family knobs are available at PIC level. You can configure inet family Layer 3 and Layer 4 fields to be used for load-balancing. For bridge family, Layer 2, layer 3 and Layer 4 fields to be used for load-balancing.
ACX Series routers also support load balancing across the member
links using Layer 2 source MAC addresses, destination MAC addresses,
or both. This can be configured at the [edit forwarding-options
hash-key family multiservice] hierarchy level. Layer 2 source
MAC addresses and destination MAC addresses are used as hash-keys
for load balancing.
[edit]
forwarding-options {
hash-key {
family multiservice {
destination-mac;
source-mac;
}
}
}
For IP Layer 2 packets, only IP fields are used for load balancing across member links. Source MAC address and destination MAC address are not be used for load balancing.
For non-IP Layer 2 packets, either Source MAC address or destination MAC address is used as hash-keys for load balancing.
If you want to hash based on layer 2 fields, then you need to configure
multiservice.If you want to hash based on layer 3 and layer 4 fields, then you need to configure
family (inet | inet6)
LACP Monitoring
LACP exchanges are made between actors and partners. An actor is the local interface in an LACP exchange. A partner is the remote interface in an LACP exchange.
LACP is defined in IEEE 802.3ad, Aggregation of Multiple Link Segments.
LACP is designed to achieve the following:
Automatic addition and deletion of individual links to the aggregate bundle without user intervention
Link monitoring to check whether both ends of the bundle are connected to the correct group
The Junos OS implementation of LACP provides link monitoring but not automatic addition and deletion of links.
LACP monitoring can be either distributed or centralized. The default is distributed and it can be overriden by configuring the centralized knob under LACP protocols. LACP exchanges are made between actors and partners. An actor is the local interface in an LACP exchange. A partner is the remote interface in an LACP exchange.
By default, LACP does not initiate a LACP PDU exchange. LACP packets can be configured to exchange LACP PDUs at a rate of 1 packet per second, or a slower rate of 1 packet for 30 seconds.
The LACP mode can be active or passive. If the actor and partner are both in passive mode, they do not exchange LACP packets, which results in the aggregated Ethernet links not coming up. If either the actor or partner is active, they do exchange LACP packets. By default, LACP is turned off on aggregated Ethernet interfaces. If LACP is configured, it is in passive mode by default. To initiate transmission of LACP packets and response to LACP packets, you must configure LACP in active mode.
To enable LACP active mode, include the lacp statement
at the [edit interfaces interface-name aggregated-ether-options] hierarchy level, and specify the active option:
[edit interfaces interface-name aggregated-ether-options] lacp { active; }
The LACP process exists in the system only if you configure the system in either active or passive LACP mode.
To restore the default behavior, include the lacp statement at the [edit interfaces interface-name aggregated-ether-options] hierarchy level, and specify the passive option:
[edit interfaces interface-name aggregated-ether-options] lacp { passive; }
Link Protection
Link protection can be configured on AE interfaces to provide 1:1 link resiliency using LACP. Primary and backup links can be configured within an AE bundle. The primary link is used for all transit traffic and host generated traffic. The backup link is used when the primary link fails.
Link protection is supported only when the AE bundles have no more than 2 member links, one primary and another backup. LACP works in revertive link-protection mode by default and can be configured to work in non-revertive mode.
Link protection without LACP (static link protection on AE interfaces) is not supported on all ACX Series routers. Link protection works as expected with LACP configured on the AE bundle.
- Configuring Link Protection for Aggregated Ethernet Interfaces
- Disabling Link Protection for Aggregated Ethernet Interfaces
Configuring Link Protection for Aggregated Ethernet Interfaces
Aggregated Ethernet interfaces support link protection to ensure QoS on the interface.
To configure link protection:
Configure the options for an aggregated Ethernet interface.
user@host# edit interfaces aex aggregated-ether-options
Configure the link protection mode.
[edit interfaces aex aggregated-ether-options] user@host# set link-protection
Disabling Link Protection for Aggregated Ethernet Interfaces
To disable link protection, issue the delete interface revert aex configuration command.
user@host# delete interfaces aex aggregated-ether-options link-protection
Understanding the Algorithm Used to Hash LAG Bundle
ACX Series routers use a hashing algorithm to determine how to forward traffic over a link aggregation group (LAG) bundle.
The hashing algorithm makes hashing decisions based on values in various packet fields, as well as on some internal values like source port ID and source device ID. You can configure some of the fields that are used by the hashing algorithm.
The hashing algorithm is used to make traffic-forwarding decisions for traffic entering a LAG bundle.
For LAG bundles, the hashing algorithm determines how traffic entering a LAG bundle is placed onto the bundle’s member links. The hashing algorithm tries to manage bandwidth by evenly load-balancing all incoming traffic across the member links in the bundle.
The hashing algorithm makes hashing decisions based on values in various packet fields, as well as on some internal values like source port ID and source device ID. The packet fields used by the hashing algorithm varies by the packet’s EtherType and, in some instances, by the configuration on the router. The hashing algorithm recognizes the following EtherTypes:
IPv4
MPLS
Traffic that is not recognized as belonging to any of these EtherTypes is hashed based on the Layer 2 header. IP and MPLS traffic are also hashed based on the Layer 2 header when a user configures the hash mode as Layer 2 header.
You can configure some fields that are used by the hashing algorithm to make traffic forwarding decisions. You cannot, however, configure how certain values within a header are used by the hashing algorithm.
Note the following points regarding the hashing algorithm:
The fields selected for hashing are based on the packet type only. The fields are not based on any other parameters, including forwarding decision (bridged or routed) or egress LAG bundle configuration (Layer 2 or Layer 3).
The same fields are used for hashing unicast and multicast packets. Unicast and multicast packets are, however, hashed differently.
Table 1 describes the fields used for hashing by Layer 2 services. The table explains the default behavior and the configurable fields based on the type of traffic received on the Layer 2 service
Traffic Type |
Default Hash Fields |
Configurable Fields (Hash keys) |
|---|---|---|
Layer 2 |
None |
Source MAC Address Destination MAC Source MAC and Destination MAC |
IP |
Source IP and Destination IP |
Source MAC Address Destination MAC Source MAC and Destination MAC |
MPLS |
MPLS label 1 and MPLS label 2 |
Source MAC Address Destination MAC Source MAC and Destination MAC |
Table 2 describes the fields used for hashing by Layer 3 services. The table explains the default behavior and the configurable fields based on the type of traffic received on the Layer 3 service
Traffic Type |
Default Hash Fields |
Configurable Fields (Hash keys) |
|---|---|---|
IP |
Source IP and Destination IP |
Layer 3 (Source IP and/or| destination IP) Layer 4 (UDP/TCP source port andr UDP/TCP destination port) |