Ethernet Link Aggregation
Learn about Ethernet link aggregation, also known as link aggregation group (LAG), port trunking, or port bonding, is a technology that combines multiple Ethernet links into a single logical link.
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.
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”:
[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 the 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.
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; }
Understanding the Algorithm Used to Hash LAG Bundle
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) |