ON THIS PAGE
Stateful Load Balancing for Aggregated Ethernet Interfaces Using 5-Tuple Data
Configuring Stateful Load Balancing on Aggregated Ethernet Interfaces
Configuring Symmetrical Load Balancing on an 802.3ad Link Aggregation Group on MX Series Routers
Configuring PIC-Level Symmetrical Hashing for Load Balancing on 802.3ad LAGs for MX Series Routers
Platform-Specific Aggregated Ethernet Load Balancing Behavior
Load Balancing on Aggregated Ethernet Interfaces
Load balancing on aggregated ethernet interfaces reduces network congestion by dividing traffic among multiple interfaces.
When you bundle several physical aggregated Ethernet Interfaces to form a single logical interface, it is called link aggregation. Link aggregation increases bandwidth, provides graceful degradation as failure occurs, increases availability and provides load-balancing capabilities. Load balancing enables the device to divide incoming and outgoing traffic along multiple interfaces to reduce congestion in the network. This topic describes load balancing and how to configure load balancing on your device.
Use Feature Explorer to confirm platform and release support for specific features.
Review the Platform-Specific Aggregated Ethernet Load Balancing Behavior section for notes related to your platform.
Load Balancing and Ethernet Link Aggregation Overview
You can create a link aggregation group (LAG) for a group of Ethernet ports. Layer 2 bridging traffic is load balanced across the member links of this group, making the configuration attractive for congestion concerns as well as for redundancy. Each LAG bundle contains up to 16 links. (Platform support depends on the Junos OS release in your installation.)
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
hash-mode of the hashing algorithm is set to Layer 2 payload by default. When the
hash-mode is set to Layer 2 payload, the hashing algorithm uses the IPv4 and IPv6
payload fields for hashing. You can also configure the
load balancing hash key for Layer 2 traffic to use fields in the Layer 3 and Layer 4
headers using the payload statement.
However, note that the load-balancing behavior
is platform-specific and based on appropriate hash-key configurations.
For more information, see Configuring Load Balancing on a LAG Link.In a Layer 2 switch, one link is overutilized and other links are underutilized.
Understanding Aggregated Ethernet Load Balancing
The link aggregation feature is used to bundle several physical aggregated Ethernet interfaces to form one logical interface. One or more links are aggregated to form a virtual link or link aggregation group (LAG). The MAC client treats this virtual link as if it were a single link. Link aggregation increases bandwidth, provides graceful degradation as failure occurs, and increases availability.
In addition to these benefits, an aggregated Ethernet bundle is enhanced to provide load-balancing capabilities that ensure that the link utilization among the member links of the aggregated Ethernet bundle are fully and efficiently utilized.
The load-balancing feature allows a device to divide incoming and outgoing traffic along multiple paths or interfaces in order to reduce congestion in the network. Load balancing improves the utilization of various network paths and provides more effective network bandwidth.
Typically, the applications that use load balancing include:
Aggregated Interfaces (Layer 2)
Aggregated Interfaces (also called AE for aggregated Ethernet, and AS for aggregated SONET) are a Layer 2 mechanism for load-balancing across multiple interfaces between two devices. Because this is a Layer 2 load-balancing mechanism, all of the individual component links must be between the same two devices on each end. Junos OS supports a non-signaled (static) configuration for Ethernet and SONET, as well as the 802.3ad standardized LACP protocol for negotiation over Ethernet links.
Equal-Cost Multipath (ECMP) (Layer 3)
By default, when there are multiple equal-cost paths to the same destination for the active route, Junos OS uses a hash algorithm to choose one of the next-hop addresses to install in the forwarding table. Whenever the set of next hops for a destination changes in any way, the next-hop address is rechosen using the hash algorithm. There is also an option that allows multiple next-hop addresses to be installed in the forwarding table, known as per-packet load balancing.
ECMP load balancing can be:
Across BGP paths (BGP multipath)
Within a BGP path, across multiple LSPs
In complex Ethernet topologies, traffic imbalances occur due to increased traffic flow, and load balancing becomes challenging for some of the following reasons:
Incorrect load balancing by aggregate next hops
Incorrect packet hash computation
Insufficient variance in the packet flow
Incorrect pattern selection
As a result of traffic imbalance, the load is not well distributed causing congestion in certain links, whereas some other links are not efficiently utilized.
To overcome these challenges, Junos OS provides the following solutions for resolving the genuine traffic imbalance on aggregated Ethernet bundles (IEEE 802.3ad).
Adaptive Load Balancing
Adaptive load balancing uses a feedback mechanism to correct a genuine traffic imbalance. To correct the imbalance weights, the bandwidth and packet stream of links are adapted to achieve efficient traffic distribution across the links in an AE bundle.
To configure adaptive load balancing, include the
adaptivestatement at the[edit interfaces aex aggregated-ether-options load-balance]hierarchy level.To configure the tolerance value as a percentage, include the
toleranceoptional keyword at the[edit interfaces aex aggregated-ether-options load-balance adaptive]hierarchy level.To configure adaptive load balancing based on packets per second (instead of the default bits per second setting), include the
ppsoptional keyword at the[edit interfaces aex aggregated-ether-options load-balance adaptive]hierarchy level.To configure the scan interval for the hash value based on the sample rate for the last two seconds, include the
scan-intervaloptional keyword at the[edit interfaces aex aggregated-ether-options load-balance adaptive]hierarchy level.Per-Packet Random Spray Load Balancing
When the adaptive load-balancing option fails, per-packet random spray load balancing serves as a last resort. It ensures that the members of an AE bundle are equally loaded without taking bandwidth into consideration. Per packet causes packet reordering and hence is recommended only if the applications absorb reordering. Per-packet random spray eliminates traffic imbalance that occurs as a result of software errors, except for packet hash.
To configure per-packet random spray load balancing, include the
per-packetstatement at the[edit interfaces aex aggregated-ether-options load-balance]hierarchy level.
The aggregated Ethernet load-balancing solutions are mutually
exclusive. When more than one of the load-balancing solutions is configured,
the solution that is configured last overrides the previously configured
one. You can verify the load-balancing solution being used by issuing
the show interfaces aex aggregated-ether-options
load-balance command.
See Also
Stateful Load Balancing for Aggregated Ethernet Interfaces Using 5-Tuple Data
When multiple flows are transmitted out of an aggregated Ethernet (ae)
interface, the flows must be distributed across the different member links evenly to enable an
effective and optimal load-balancing behavior. To obtain a streamlined and robust method of
load-balancing, the member link of the aggregated Ethernet interface bundle that is selected each
time for load balancing plays a significant part. The balanced mode of link selection uses 'n'
bits in a precomputed hash value if it needs to select one of 2^n (2 raised to the power of n)
next-hop in the unilist. The unbalanced mode of member-link or next-hop selection uses 8 bits in
a precomputed hash to select an entry in a selector table, which is randomly done with the member
link IDs of the link aggregation group (LAG) or aebundle.
The term balanced versus unbalanced indicates whether a selector table is used for load balancing mechanism or not. The LAG bundle uses the unbalanced mode (selector table balancing) to balance the traffic across member links. When the traffic flows are minimal, the following problems might occur with the unbalanced mode: The link selection logic utilizes only subset bits of the precomputed hash. Regardless of the efficiency of the hashing algorithm, it is only the compressed representation of a flow. Because the inter-flow variance is very low, the resultant hashes and the subset that are computed do not provide the necessary variability to effectively utilize all the LAG member links. An excessive amount of random nature exists in the hash computation and also in the selector table. As a result, the deviation from being an optimal load-balancing technique for each child link that is selected is higher when the number of flows is lower.
The deviation per child link is defined as
Vi = ((Ci - (M/N)))/N
where
Vi denotes the deviation for that child link ’i’.
i denotes the child link member/index.
Ci represents the packets transmitted for that child link 'i'.
M signifies the total packets transmitted on that LAG bundle.
N denotes the number of child links in that LAG.
Because of these drawbacks, for smaller number of flows, or flows with less inter-flow variance, the link utilization is skewed, and a high probability of a few child links not being utilized entirely exists.
The mechanism to record and retain states for the flows and distribute the traffic load accordingly is added. As a result, for m number of flows, they are distributed among n member links of a LAG bundle or among the unilist of next-hops in an ECMP link. This method of splitting the load among member links is called stateful load balancing and it uses 5-tuple information (source and destination addresses, protocol, source and destination ports). Such a method can be mapped directly to the flows, or to a precompute hash based on certain fields in the flow. As a result, the deviation observed on each child link is reduced.
This mechanism works efficiently only for minimal number of flows (less than thousands of flows, approximately). For a larger number of flows (between 1000 and 10,000 flows), we recommend that distributed Trio-based load-balancing mechanism is used.
Consider a sample scenario in which 'n' links in the LAG are identified with link IDs of 0 through n-1. A hash table or a flow table is used to record the flows as and when they show up. The hashing key is constructed using the fields that uniquely identify a flow. The result of the lookup identifies the link_id that the flow is currently using. For each packet, the flow table based on the flow identifier is examined. If a match is found, it denotes a packet that belongs to a flow that is previously processed or detected. The link ID is associated with the flow. If a match is not found, it is the first packet that belongs to the flow. The link ID is used to select the link and the flow is inserted into the flow table.
To enable per-flow load balancing based on hash values, include
the per-flow statement at the at the [edit interfaces
aeX unit logical-unit-number forwarding-options load-balance-stateful] hierarchy level.
By default, Junos OS uses a hashing method based only on the destination
address to elect a forwarding next hop when multiple equal-cost paths
are available. All Packet Forwarding Engine slots are assigned the
same hash value by default. To configure the load-balancing algorithm
to dynamically rebalance the LAG using existing parameters, include
the rebalance interval statement
at the [edit interfaces aeX unit logical-unit-number forwarding-options load-balance-stateful] hierarchy level. This parameter periodically load balances traffic
by providing a synchronized rebalance switchover across all the ingress
Packet Forwarding Engines (PFEs) over a rebalance interval. You can
specify the interval as a value in the range of 1 through 1000 flows
per minute. To configure the load type, include the load-type
(low | medium | high) statement at the [edit interfaces
aeX unit logical-unit-number forwarding-options load-balance-stateful] hierarchy level.
The stateful per-flow option enables the load-balancing
capability on AE bundles. The rebalance option clears the
load balance state at specified intervals. The load option
informs the Packet Forwarding Engine regarding the appropriate memory
pattern to be used. If the number of flows that flow on this aggregated
Ethernet interface is less (between 1 and 100 flows), then the low keyword can be used. Similarly for relatively higher flows
(between 100 and 1000 flows), the medium keyword can be
used and the large keyword can be used for the maximum
flows (between 1000 and 10,000 flows). The approximate number of flows
for effective load-balancing for each keyword is a derivative.
The clear interfaces aeX unit logical-unit-number forwarding-options load-balance state command clears the load balance state at the hardware level and
enables rebalancing from the cleaned up, empty state. This clear state
is triggered only when you use this command. The clear interfaces
aggregate forwarding-options load-balance state command clears
all the aggregate Ethernet interface load balancing states and re-creates
them newly.
Guidelines for Configuring Stateful Load Balancing for Aggegated Ethernet Interfaces or LAG Bundles
Keep the following points in mind while configuring stateful load-balancing for aggregated Ethernet interfaces:
When a child link is removed or added, a new aggregate selector is selected and traffic flows onto the new selector. Because the selector is empty, flows are filled in the selector. This behavior causes redistribution of flows because the old state is lost. This is the existing behavior without enabling stateful per-flow load-balancing.
Stateful per-flow load-balancing functions on AE interfaces if the incoming traffic reaches the MPC1E, MPC2E, MPC3E-3D, MPC5E, and MPC6E line cards. Any other type of line card does not rigger this functionality. Appropriate CLI errors are displayed if the MPCs do not support this capability.
With the ingress line card as MPC and the egress line card as MPC or DPC, this feature works properly. Stateful load-balancing is not supported if the ingress line card is a DPC and the egress line card is a DPC or an MPC.
This capability is not supported for multicast traffic (native/flood).
Enabling the rebalance option or clearing the load balance state can cause packet reordering for active flows because different sets of links can be selected for traffic flows.
Although the feature performance is high, it consumes significant amount of line card memory. Approximately, 4000 logical interfaces or 16 aggregated Ethernet logical interfaces can have this feature enabled on supported MPCs. However, when the Packet Forwarding Engine hardware memory is low, depending upon the available memory, it falls back to the default load balancing mechanism. A system logging message is generated in such a situation and sent to the Routing Engine. A restriction on the number of AE interfaces that support stateful load-balancing does not exist; the limit is determined by the line cards.
If the traffic flows become aged frequently, then the device needs to remove or refresh the load balancing states. As a result, you must configure rebalancing or run the clear command at periodic intervals for proper load-balancing. Otherwise, traffic skewing can occur. When a child link goes down or comes up, the load balancing behavior does not undergo changes on existing flows. This condition is to avoid packet reordering. New flows pick up the child link that come up. If you observe load distribution to be not very effective, you can clear the load-balancing states or use rebalancing functionality to cause an automatic clearance of the hardware states. When you configure the rebalancing facility, traffic flows can get redirected to different links, which can cause packet reordering.
Configuring Stateful Load Balancing on Aggregated Ethernet Interfaces
The mechanism to record and retain states for the flows and distribute the traffic load accordingly is added. As a result, for m number of flows, they are distributed among n member links of a LAG bundle or among the unilist of next-hops in an ECMP link. This method of splitting the load among member links is called stateful load balancing and it uses 5-tuple information (source and destination addresses, protocol, source and destination ports). Such a method can be mapped directly to the flows, or to a precompute hash based on certain fields in the flow. As a result, the deviation observed on each child link is reduced.
To configure stateful load balancing on ae interface bundles:
Configuring Adaptive Load Balancing
This topic describes how to configure adaptive load balancing. Adaptive load balancing maintains efficient utilization of member link bandwidth for an aggregated Ethernet (AE) bundle. Adaptive load balancing uses a feedback mechanism to correct traffic load imbalance by adjusting the bandwidth and packet streams on links within an AE bundle.
Before you begin:
Configure a set of interfaces with a protocol family and IP address. These interfaces can make up the membership for the AE bundle.
Create an AE bundle by configuring a set of router interfaces as aggregated Ethernet and with a specific AE group identifier.
To configure adaptive load balancing for an AE bundles:
See Also
Configuring Symmetrical Load Balancing on an 802.3ad Link Aggregation Group on MX Series Routers
- Symmetrical Load Balancing on an 802.3ad LAG on MX Series Routers Overview
- Configuring Symmetric Load Balancing on an 802.3ad LAG on MX Series Routers
- Configuring Symmetrical Load Balancing on Trio-Based MPCs
- Example Configurations
Symmetrical Load Balancing on an 802.3ad LAG on MX Series Routers Overview
MX Series routers with Aggregated Ethernet PICs support symmetrical load balancing on an 802.3ad LAG. This feature is significant when two MX Series routers are connected transparently through deep packet inspection (DPI) devices over an LAG bundle. DPI devices keep track of flows and require information of a given flow in both forward and reverse directions. Without symmetrical load balancing on an 802.3ad LAG, the DPIs could misunderstand the flow, leading to traffic disruptions. By using this feature, a given flow of traffic (duplex) is ensured for the same devices in both directions.
Symmetrical load balancing on an 802.3ad LAG utilizes a mechanism
of interchanging the source and destination addresses for a hash computation
of fields, such as source address and destination address. The result
of a hash computed on these fields is used to choose the link of the
LAG. The hash-computation for the forward and reverse flow must be
identical. This is achieved by swapping source fields with destination
fields for the reverse flow. The swapped operation is referred to
as complement hash computation or symmetric-hash
complement and the regular (or unswapped) operation as symmetric-hash computation or symmetric-hash. The swappable fields are MAC address, IP address, and port.
Configuring Symmetric Load Balancing on an 802.3ad LAG on MX Series Routers
You can specify whether symmetric hash or complement hash is
done for load-balancing traffic. To configure symmetric hash, use
the symmetric-hash statement at the [edit forwarding-options
hash-key family inet] hierarchy level. To configure symmetric
hash complement, use the symmetric-hash complement statement
and option at the [edit forwarding-options hash-key family inet] hierarchy level.
These operations can also be performed at the PIC level by specifying
a hash key. To configure a hash key at the PIC
level, use the symmetric-hash or symmetric-hash complement statement at the [edit chassis hash-key family inet] and [edit chassis hash-key family multiservice] hierarchy levels.
Consider the example in Figure 1.
Router A is configured with symmetric hash and Router B is configured with symmetric hash complement. Thus, for a given flow fx, post hash computation is from Router A to Router B through i2. The reverse traffic for the same flow fx is from Router B to Router A through the same i2 device as its hashing (done after swapping source and destination fields) and returns the same link index; since it is performed on the interchanged source and destination addresses.
However, the link chosen may or may not correspond to what was attached to the DPI. In other words, the hashing result should point to the same links that are connected, so that the traffic flows through the same DPI devices in both directions. To make sure this happens, you need to also configure the counterpart ports (ports that are connected to same DPI-iN) with the identical link index. This is done when configuring a child-link into the LAG bundle. This ensures that the link chosen for a given hash result is always the same on either router.
Note that any two links connected to each other should have the same link index and these link indices must be unique in a given bundle.
The following restrictions apply when configuring symmetric load balancing on an 802.3ad LAG on MX Series routers:
The Packet Forwarding Engine (PFE) can be configured to hash the traffic in either symmetric or complement mode. A single PFE complex cannot work simultaneously in both operational modes and such a configuration can yield undesirable results.
The per-PFE setting overrides the chassis-wide setting only for the family configured. For the other families, the PFE complex still inherits the chassis-wide setting (when configured) or the default setting.
This feature supports VPLS, INET, and bridged traffic only.
This feature cannot work in tandem with the
per-flow-hash-seed load-balancingoption. It requires that all the PFE complexes configured in complementary fashion share the same seed. A change in the seed between two counterpart PFE complexes may yield undesired results.
For additional information, see the Junos OS VPNs Library for Routing Devices and the Junos OS Administration Library for Routing Devices.
Example Configuration Statements
To configure 802.3ad LAG parameters at the bundle level:
[edit interfaces]
g(x)e-fpc/pic/port {
gigether-options {
802.3ad {
bundle;
link-index number;
}
}
}
where the link-index number ranges
from 0 through 15.
You can check the link index configured above using the show interfaces command:
[edit forwarding-options hash-key]
family inet {
layer-3;
layer-4;
symmetric-hash {
[complement;]
}
}
family multiservice {
source-mac;
destination-mac;
payload {
ip {
layer-3 {
source-ip-only | destination-ip-only;
}
layer-4;
}
}
symmetric-hash {
[complement;]
}
}
For load-balancing Layer 2 traffic based on Layer 3 fields, you can configure 802.3ad LAG parameters at a per PIC level. These configuration options are available under the chassis hierarchy as follows:
[edit chassis]
fpc X {
pic Y {
.
.
.
hash-key {
family inet {
layer-3;
layer-4;
symmetric-hash {
[complement;]
}
}
family multiservice {
source-mac;
destination-mac;
payload {
ip {
layer-3 {
source-ip-only | destination-ip-only;
}
layer-4;
}
}
symmetric-hash {
[complement;]
}
}
}
.
.
.
}
}
Configuring Symmetrical Load Balancing on Trio-Based MPCs
With some configuration differences, symmetrical load-balancing over an 802.3ad link aggregation group is supported on MX Series routers with Trio-based MPCs.
To achieve symmetrical load-balancing on Trio-Based MPCs, the following needs to be done:
Compute a Symmetrical Hash
Both routers must compute the same hash value from the flow in the forward and reverse directions. On Trio-based platforms, the calculated hash value is independent of the direction of the flow, and hence is always symmetric in nature. For this reason, no specific configuration is needed to compute a symmetric hash value on Trio-based platforms.
However, it should be noted that the fields used to configure the hash should have identical include and exclude settings on both ends of the LAG.
Configure Link Indexes
To allow both routers to choose the same link using the same hash value, the links within the LAG must be configured with the same link index on both routers. This can be achieved with the
link-indexstatement.Enable Symmetric Load Balancing
To configure symmetric load balancing on Trio-based MPCs, include the
symmetricstatement at the[edit forwarding-options enhanced-hash-key]hierarchy level. This statement is applicable to Trio-based platforms only.The
symmetricstatement can be used with any protocol family and enables symmetric load-balancing for all aggregated Ethernet bundles on the router. The statement needs to be enabled at both ends of the LAG. This statement is disabled by default.Achieve Symmetry for Bridged and Routed Traffic
In some deployments, the LAG bundle on which symmetry is desired is traversed by Layer 2 bridged traffic in the upstream direction and by IPv4 routed traffic in the downstream direction. In such cases, the computed hash is different in each direction because the Ethernet MAC addresses are taken into account for bridged packets. To overcome this, you can exclude source and destination MAC addresses from the enhanced-hash-key computation.
To exclude source and destination MAC addresses from the enhanced-hash-key computation, include the
no-mac-addressesstatement at the[edit forwarding-options enhanced-hash-key family multiservice]hierarchy level. This statement is disabled by default.
When symmetrical load balancing is enabled on Trio-based MPCs, keep in mind the following caveats:
Traffic polarization is a phenomenon that occurs when using topologies that distribute traffic by using hashing of the same type. When routers are cascaded, traffic polarization can occur, and this can lead to unequal traffic distribution.
Traffic polarization occurs when LAGs are configured on cascaded routers. For example, in Figure 2, if a certain flow uses Link 1 of the aggregated Ethernet bundle between Device R1 and Device R2, the flow also uses Link 1 of the aggregated Ethernet bundle between Device R2 and Device R3.
Figure 2: Traffic Polarization on Cascaded Routers When Symmetrical Load Balancing in Enabled on Trio-based MPCs
This is unlike having a random link selection algorithm, where a flow might use Link 1 of the aggregated Ethernet bundle between Device R1 and Device R2, and Link 2 of the aggregated Ethernet bundle between Device R2 and Device R3.
Symmetric load balancing is not applicable to per-prefix load-balancing where the hash is computed based on the route prefix.
Symmetric load balancing is not applicable to MPLS or VPLS traffic, because in these scenarios the labels are not the same in both directions.
Example Configurations
- Example Configurations of Chassis Wide Settings
- Example Configurations of Per–Packet-Forwarding-Engine Settings
Example Configurations of Chassis Wide Settings
Router A
user@host> show configuration forwarding-options hash-key
family multiservice {
payload {
ip {
layer-3;
}
}
symmetric hash;
}
Router B
user@host> show configuration forwarding-options hash-key
family multiservice {
payload {
ip {
layer-3;
}
}
symmetric-hash {
complement;
}
}
Example Configurations of Per–Packet-Forwarding-Engine Settings
Router A
user@host> show configuration chassis fpc 2 pic 2 hash-key
family multiservice {
payload {
ip {
layer-3;
}
}
symmetric hash;
}
Router B
user@host> show configuration chassis fpc 2 pic 3 hash-key
family multiservice {
payload {
ip {
layer-3;
}
}
symmetric-hash {
complement;
}
}
Configuring PIC-Level Symmetrical Hashing for Load Balancing on 802.3ad LAGs for MX Series Routers
Symmetrical hashing for load balancing on an 802.3ad Link Aggregation Group (LAG) is useful when two MX Series routers (for example, Router A and Router B) are connected transparently through Deep Packet Inspection (DPI) devices over a LAG bundle. The DPI devices keep track of traffic flows in both the forward and reverse directions.
If symmetrical hashing is configured, the reverse flow of traffic is also directed through the same child link on the LAG and is bound to flow through the same DPI device. This enables proper accounting on the DPI of the traffic in both the forward and reverse flows.
If symmetrical hashing is not configured, a different child link on the LAG might be chosen for the reverse flow of traffic through a different DPI device. This results in incomplete information about the forward and reverse flows of traffic on the DPI device leading to incomplete accounting of the traffic by the DPI device.
Symmetrical hashing is computed based on fields like source address and destination address. You can configure symmetrical hashing both at the chassis level and the PIC level for load balancing based on Layer 2, Layer 3, and Layer 4 data unit fields for family inet (IPv4 protocol family) and multiservice (switch or bridge) traffic. Symmetrical hashing configured at the chassis level is applicable to the entire router, and is inherited by all its PICs and Packet Forwarding Engines. Configuring PIC-level symmetrical hashing provides you more granularity at the Packet Forwarding Engine level.
For the two routers connected through the DPI devices over a LAG bundle, you can configure symmetric-hash on one router and symmetric-hash complement on the remote-end router or vice-versa.
To configure symmetrical hashing at the chassis level, include
the symmetric-hash or the symmetric-hash complement statements at the [edit forwarding-options hash-key family] hierarchy level. For information about configuring symmetrical hashing
at the chassis level and configuring the link index, see the Junos OS Network Interfaces Library for Routing Devices and
the Junos OS VPNs Library for Routing Devices.
On MX Series DPCs, configuring symmetrical hashing at the PIC level refers to configuring symmetrical hashing at the Packet Forwarding Engine level.
To configure symmetrical hashing at the PIC level on the inbound
traffic interface (where traffic enters the router), include the symmetric-hash or symmetric-hash complement statement
at the [edit chassis fpc slot-number pic pic-number hash-key] hierarchy level:
[edit chassis fpc slot-number pic pic-number hash-key]
family multiservice {
source-mac;
destination-mac;
payload {
ip {
layer-3 (source-ip-only | destination-ip-only);
layer-4;
}
}
symmetric-hash {
complement;
}
}
family inet { layer-3; layer-4; symmetric-hash { complement; } }
PIC-level symmetrical hashing overrides the chassis-level symmetrical hashing configured at the [edit chassis forwarding-options hash-key] hierarchy level.
Symmetrical hashing for load balancing on 802.3ad Link Aggregation Groups is currently supported for the VPLS, INET and bridged traffic only.
Hash key configuration on a PIC or Packet Forwarding Engine can be either in the “symmetric hash” or the “symmetric hash complement” mode, but not both at the same time.
See Also
Examples: Configuring PIC-Level Symmetrical Hashing for Load Balancing on 802.3ad LAGs on MX Series Routers
These examples are applicable only to the DPCs Supported on MX240, MX480, and MX960 Routers. For the list of DPCs supported, see DPCs Supported on MX240, MX480, and MX960 Routers in the Related Documentation section.
The following examples show how to configure symmetrical hashing at the PIC level for load balancing on MX Series routers:
- Configuring Symmetrical Hashing for family multiservice on Both Routers
- Configuring Symmetrical Hashing for family inet on Both Routers
- Configuring Symmetrical Hashing for family inet and family multiservice on the Two Routers
Configuring Symmetrical Hashing for family multiservice on Both Routers
On the inbound traffic interface where traffic enters Router
A, include the symmetric-hash statement at the [edit
chassis fpc slot-number pic pic-number hash-key family multiservice] hierarchy level:
[edit chassis fpc 2 pic 2 hash-key]
family multiservice {
source-mac;
destination-mac;
payload {
ip {
layer-3;
layer-4;
}
}
symmetric-hash;
}
On the inbound traffic interface where traffic enters Router
B, include the symmetric-hash complement statement at the [edit chassis fpc slot-number pic pic-number hash-key family multiservice] hierarchy
level:
[edit chassis fpc 0 pic 3 hash-key]
family multiservice {
source-mac;
destination-mac;
payload {
ip {
layer-3;
layer-4;
}
}
symmetric-hash {
complement;
}
}
Configuring Symmetrical Hashing for family inet on Both Routers
On the inbound traffic interface where traffic enters Router
A, include the symmetric-hash statement at the [edit
chassis fpc slot-number pic pic-number hash-key family inet] hierarchy level:
[edit chassis fpc 0 pic 1 hash-key]
family inet {
layer-3;
layer-4;
symmetric-hash;
}
On the inbound traffic interface where traffic enters Router
B, include the symmetric-hash complement statement at the [edit chassis fpc slot-number pic pic-number hash-key family inet] hierarchy level:
[edit chassis fpc 1 pic 2 hash-key]
family inet {
layer-3;
layer-4;
symmetric-hash {
complement;
}
}
Configuring Symmetrical Hashing for family inet and family multiservice on the Two Routers
On the inbound traffic interface where traffic enters Router
A, include the symmetric-hash statement at the [edit
chassis fpc slot-number pic pic-number hash-key family multiservice] hierarchy level:
[edit chassis fpc 1 pic 0 hash-key]
family multiservice {
payload {
ip {
layer-3;
layer-4;
}
}
symmetric-hash;
}
On the inbound traffic interface where traffic enters Router
B, include the symmetric-hash complement statement at the [edit chassis fpc slot-number pic pic-number hash-key family inet] hierarchy level:
[edit chassis fpc 0 pic 3 hash-key]
family inet {
layer-3;
layer-4;
symmetric-hash {
complement;
}
}
See Also
Example: Configuring Aggregated Ethernet Load Balancing
Example: Configuring Aggregated Ethernet Load Balancing
This example shows how to configure aggregated Ethernet load balancing.
Requirements
This example uses the following hardware and software components:
Three MX Series routers with MIC and MPC interfaces or three PTX Series Packet Transport Routers with PIC and FPC interfaces
Junos OS Release 13.3 or later running on all devices
Overview
Load balancing is required on the forwarding plane when there are multiple paths or interfaces available to the next hop router, and it is best if the incoming traffic is load balanced across all available paths for better link utilization.
Aggregated Ethernet bundle is a typical application that uses load balancing to balance traffic flows across the member links of the bundle (IEEE 802.3ad).
Starting with Junos OS Release 13.3, aggregated Ethernet load balancing is enhanced to provide two solutions for resolving genuine traffic imbalance on aggregated Ethernet bundles on MICs or MPCs of MX Series routers. Starting with Junos OS Release 14.1, aggregated Ethernet load balancing is enhanced to provide two solutions for resolving genuine traffic imbalance on aggregated Ethernet bundles on PICs or FPCs of PTX Series Packet Transport Routers.
The aggregated Ethernet load-balancing solutions are:
Adaptive—Adaptive load balancing is used in scenarios where flow-based hashing is not sufficient to achieve a uniform load distribution. This load-balancing solution implements a real-time feedback and control mechanism to monitor and manage imbalances in network load.
The adaptive load-balancing solution corrects the traffic flow imbalance by modifying the selector entries, and periodically scanning the link utilization on each member link of the AE bundle to detect any deviations. When a deviation is detected, an adjustment event is triggered and fewer flows are mapped to the affected member link. As a result, the offered bandwidth of that member link goes down. This causes a continuous feedback loop, which over a period of time ensures that the same amount of byte rate is offered to all the member links, thus providing efficient traffic distribution across each member link in the AE bundle.
To configure adaptive load balancing, include the
adaptivestatement at the[edit interfaces aex aggregated-ether-options load-balance]hierarchy level.Note:Adaptive load balancing is not supported if the VLAN ID is configured on the aggregated Ethernet interface. This limitation affects the PTX Series Packet Transport Routers only.
The
ppsoption enables load balancing based on the packets-per-second rate. The default setting is bits-per-second load balancing.The
scan-intervalvalue configures the length of time for scanning as a multiple of 30 seconds.The
tolerancevalue is the limit to the variance in the packet traffic flow to the aggregated Ethernet links in the bundle. You can specify a maximum of 100-percent variance. When the tolerance attribute is not configured, a default value of 20 percent is enabled for adaptive load balancing. A smaller tolerance value balances better bandwidth, but takes a longer convergence time.Note:The
ppsandscan-intervaloptional keywords are supported on PTX Series Packet Transport Routers only.Per-packet random spray—When the adaptive load-balancing solution fails, per-packet random spray acts as a last resort. The per-packet random spray load-balancing solution helps to address traffic imbalance by randomly spraying the packets to the aggregate next hops. This ensures that all the member links of the AE bundle are equally loaded, resulting in packet reordering.
In addition, per-packet random spray identifies the ingress Packet Forwarding Engine that caused the traffic imbalance and eliminates traffic imbalance that occurs as a result of software errors, except for packet hash.
To configure per-packet random spray load balancing, include the
per-packetstatement at the[edit interfaces aex aggregated-ether-options load-balance]hierarchy level.Note:The Per-Packet option for load balancing is not supported on the PTX Series Packet Transport Routers.
The aggregated Ethernet load-balancing solutions are mutually
exclusive. When more than one of the load-balancing solutions is configured,
the solution that is configured last overrides the previously configured
one. You can verify the load-balancing solution being implemented
by issuing the show interfaces aex aggregated-ether-options
load-balance command.
Topology
In this topology, two aggregated Ethernet bundles - ae0 and ae1 - are configured on the links between the R2 and R3 routers.
Configuration
CLI Quick Configuration
To quickly configure this example, copy the
following commands, paste them into a text file, remove any line breaks,
change any details necessary to match your network configuration,
and then copy and paste the commands into the CLI at the [edit] hierarchy level.
R1
set chassis aggregated-devices ethernet device-count 12 set interfaces xe-0/0/0 unit 0 family inet address 120.168.1.1/30 set interfaces xe-0/0/0 unit 0 family iso set interfaces xe-0/0/0 unit 0 family mpls set interfaces xe-0/0/1 unit 0 family inet address 120.168.2.1/30 set interfaces xe-0/0/1 unit 0 family iso set interfaces xe-0/0/1 unit 0 family mpls set interfaces ge-1/0/0 unit 0 family inet address 120.168.100.2/30 set interfaces ge-1/0/0 unit 0 family iso set interfaces ge-1/0/0 unit 0 family mpls set interfaces ge-1/0/1 unit 0 family inet address 120.168.101.2/30 set interfaces ge-1/0/1 unit 0 family iso set interfaces ge-1/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 120.168.0.2/32 set interfaces lo0 unit 0 family iso address 49.0001.1201.6800.0002.00 set routing-options router-id 120.168.0.2 set routing-options autonomous-system 55 set protocols rsvp interface ge-1/0/0.0 set protocols rsvp interface ge-1/0/1.0 set protocols mpls label-switched-path videl-to-sweets to 120.168.0.9 set protocols mpls label-switched-path v-2-s-601 to 60.0.1.0 set protocols mpls label-switched-path v-2-s-601 primary v-2-s-601-primary hop-limit 5 set protocols mpls label-switched-path v-2-s-602 to 60.0.2.0 set protocols mpls label-switched-path v-2-s-602 primary v-2-s-602-primary hop-limit 5 set protocols mpls label-switched-path v-2-s-603 to 60.0.3.0 set protocols mpls label-switched-path v-2-s-604 to 60.0.4.0 set protocols mpls path v-2-s-601-primary 120.168.100.1 strict set protocols mpls path v-2-s-601-primary 120.168.104.2 strict set protocols mpls path v-2-s-602-primary 120.168.101.1 strict set protocols mpls path v-2-s-602-primary 120.168.105.2 strict set protocols mpls interface ge-1/0/0.0 set protocols mpls interface ge-1/0/1.0 set protocols bgp group pe-routers type internal set protocols bgp group pe-routers local-address 120.168.0.2 set protocols bgp group pe-routers family inet unicast set protocols bgp group pe-routers family inet-vpn unicast set protocols bgp group pe-routers neighbor 120.168.0.9 set protocols isis traffic-engineering family inet shortcuts set protocols isis level 1 disable set protocols isis interface ge-1/0/0.0 set protocols isis interface ge-1/0/1.0 set protocols isis interface lo0.0 set policy-options policy-statement nhs then next-hop self set policy-options policy-statement vpn-m5-export term 1 from protocol bgp set policy-options policy-statement vpn-m5-export term 1 from protocol direct set policy-options policy-statement vpn-m5-export term 1 then community add vpn-m5-target set policy-options policy-statement vpn-m5-export term 1 then accept set policy-options policy-statement vpn-m5-export term 2 then reject set policy-options policy-statement vpn-m5-import term 1 from protocol bgp set policy-options policy-statement vpn-m5-import term 1 from community vpn-m5-target set policy-options policy-statement vpn-m5-import term 1 then accept set policy-options policy-statement vpn-m5-import term 2 then reject set policy-options community vpn-m5-target members target:55:100 set routing-instances vpn-m5 instance-type vrf set routing-instances vpn-m5 interface xe-0/0/0.0 set routing-instances vpn-m5 interface xe-0/0/1.0 set routing-instances vpn-m5 route-distinguisher 120.168.0.2:1 set routing-instances vpn-m5 vrf-import vpn-m5-import set routing-instances vpn-m5 vrf-export vpn-m5-export set routing-instances vpn-m5 protocols bgp group ce type external set routing-instances vpn-m5 protocols bgp group ce peer-as 100 set routing-instances vpn-m5 protocols bgp group ce as-override set routing-instances vpn-m5 protocols bgp group ce neighbor 120.168.1.2 set routing-instances vpn-m5 protocols bgp group ce neighbor 120.168.2.2 set routing-instances vpn-m5 protocols ospf domain-id 1.0.0.0 set routing-instances vpn-m5 protocols ospf export vpn-m5-import set routing-instances vpn-m5 protocols ospf area 0.0.0.0 interface xe-0/0/1.0 set routing-instances vpn-m5 protocols ospf area 0.0.0.0 interface xe-0/0/0.0
R2
set chassis aggregated-devices ethernet device-count 5 set interfaces ge-1/2/0 unit 0 family inet address 120.168.100.1/30 set interfaces ge-1/2/0 unit 0 family iso set interfaces ge-1/2/0 unit 0 family mpls set interfaces ge-1/2/1 unit 0 family inet address 120.168.101.1/30 set interfaces ge-1/2/1 unit 0 family iso set interfaces ge-1/2/1 unit 0 family mpls set interfaces ge-1/3/0 gigether-options 802.3ad ae0 set interfaces ge-1/3/1 gigether-options 802.3ad ae0 set interfaces ge-1/3/2 gigether-options 802.3ad ae0 set interfaces ge-1/3/3 gigether-options 802.3ad ae0 set interfaces ge-1/3/4 gigether-options 802.3ad ae0 set interfaces ge-2/2/1 gigether-options 802.3ad ae1 set interfaces ge-2/2/2 gigether-options 802.3ad ae1 set interfaces ge-2/2/3 gigether-options 802.3ad ae1 set interfaces ge-2/2/4 gigether-options 802.3ad ae1 set interfaces ge-2/2/5 gigether-options 802.3ad ae1 set interfaces ge-2/2/6 gigether-options 802.3ad ae1 set interfaces ge-2/2/7 gigether-options 802.3ad ae1 set interfaces ge-2/2/8 gigether-options 802.3ad ae1 set interfaces ae0 aggregated-ether-options load-balance adaptive tolerance 10 set interfaces ae0 aggregated-ether-options link-speed 1g set interfaces ae0 aggregated-ether-options lacp active set interfaces ae0 unit 0 family inet address 120.168.104.1/30 set interfaces ae0 unit 0 family iso set interfaces ae0 unit 0 family mpls set interfaces ae1 aggregated-ether-options load-balance adaptive tolerance 10 set interfaces ae1 aggregated-ether-options link-speed 1g set interfaces ae1 aggregated-ether-options lacp active set interfaces ae1 unit 0 family inet address 120.168.105.1/30 set interfaces ae1 unit 0 family iso set interfaces ae1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 120.168.0.4/32 set interfaces lo0 unit 0 family iso address 49.0001.1201.6800.0004.00 set accounting-options selective-aggregate-interface-stats disable set protocols rsvp interface ge-1/2/0.0 set protocols rsvp interface ge-1/2/1.0 set protocols rsvp interface ae0.0 set protocols rsvp interface ae1.0 set protocols mpls interface ge-1/2/0.0 set protocols mpls interface ge-1/2/1.0 set protocols mpls interface ae0.0 set protocols mpls interface ae1.0 set protocols isis traffic-engineering family inet shortcuts set protocols isis level 1 disable set protocols isis interface ge-1/2/0.0 set protocols isis interface ge-1/2/1.0 set protocols isis interface ae0.0 set protocols isis interface ae1.0 set protocols isis interface lo0.0
R3
set chassis aggregated-devices ethernet device-count 5 set interfaces xe-4/0/0 unit 0 family inet address 120.168.9.1/30 set interfaces xe-4/0/0 unit 0 family mpls set interfaces xe-4/0/1 unit 0 family inet address 120.168.10.1/30 set interfaces xe-4/0/1 unit 0 family mpls set interfaces ge-5/0/1 gigether-options 802.3ad ae1 set interfaces ge-5/0/2 gigether-options 802.3ad ae1 set interfaces ge-5/0/3 gigether-options 802.3ad ae1 set interfaces ge-5/0/4 gigether-options 802.3ad ae1 set interfaces ge-5/0/5 gigether-options 802.3ad ae1 set interfaces ge-5/0/6 gigether-options 802.3ad ae1 set interfaces ge-5/0/7 gigether-options 802.3ad ae1 set interfaces ge-5/0/8 gigether-options 802.3ad ae1 set interfaces ge-5/3/0 gigether-options 802.3ad ae0 set interfaces ge-5/3/1 gigether-options 802.3ad ae0 set interfaces ge-5/3/2 gigether-options 802.3ad ae0 set interfaces ge-5/3/3 gigether-options 802.3ad ae0 set interfaces ge-5/3/4 gigether-options 802.3ad ae0 set interfaces ae0 aggregated-ether-options link-speed 1g set interfaces ae0 aggregated-ether-options lacp active set interfaces ae0 unit 0 family inet address 120.168.104.2/30 set interfaces ae0 unit 0 family iso set interfaces ae0 unit 0 family mpls set interfaces ae1 aggregated-ether-options link-speed 1g set interfaces ae1 aggregated-ether-options lacp active set interfaces ae1 unit 0 family inet address 120.168.105.2/30 set interfaces ae1 unit 0 family iso set interfaces ae1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 120.168.0.9/32 set interfaces lo0 unit 0 family iso address 49.0001.1201.6800.0009.00 set routing-options router-id 120.168.0.9 set routing-options autonomous-system 55 set protocols rsvp interface xe-4/0/0.0 set protocols rsvp interface xe-4/0/1.0 set protocols rsvp interface ae0.0 set protocols rsvp interface ae1.0 set protocols mpls label-switched-path to-videl to 120.168.0.2 set protocols mpls interface xe-4/0/0.0 set protocols mpls interface xe-4/0/1.0 set protocols mpls interface ae0.0 set protocols mpls interface ae1.0 set protocols bgp group pe-routers type internal set protocols bgp group pe-routers local-address 120.168.0.9 set protocols bgp group pe-routers family inet unicast set protocols bgp group pe-routers family inet-vpn unicast set protocols bgp group pe-routers neighbor 120.168.0.2 set protocols isis traffic-engineering family inet shortcuts set protocols isis level 1 disable set protocols isis interface ae0.0 set protocols isis interface ae1.0 set protocols isis interface lo0.0 set policy-options policy-statement nhs then next-hop self set policy-options policy-statement vpn-m5-export term 1 from protocol bgp set policy-options policy-statement vpn-m5-export term 1 from protocol direct set policy-options policy-statement vpn-m5-export term 1 then community add vpn-m5-target set policy-options policy-statement vpn-m5-export term 1 then accept set policy-options policy-statement vpn-m5-export term 2 then reject set policy-options policy-statement vpn-m5-import term 1 from protocol bgp set policy-options policy-statement vpn-m5-import term 1 from protocol direct set policy-options policy-statement vpn-m5-import term 1 from community vpn-m5-target set policy-options policy-statement vpn-m5-import term 1 then accept set policy-options policy-statement vpn-m5-import term 2 then reject set policy-options community vpn-m5-target members target:55:100 set routing-instances vpn-m5 instance-type vrf set routing-instances vpn-m5 interface xe-4/0/0.0 set routing-instances vpn-m5 interface xe-4/0/1.0 set routing-instances vpn-m5 route-distinguisher 120.168.0.9:1 set routing-instances vpn-m5 vrf-import vpn-m5-import set routing-instances vpn-m5 vrf-export vpn-m5-export set routing-instances vpn-m5 protocols bgp group ce type external set routing-instances vpn-m5 protocols bgp group ce peer-as 100 set routing-instances vpn-m5 protocols bgp group ce as-override set routing-instances vpn-m5 protocols bgp group ce neighbor 120.168.9.2 set routing-instances vpn-m5 protocols bgp group ce neighbor 120.168.10.2 set routing-instances vpn-m5 protocols ospf domain-id 1.0.0.0 set routing-instances vpn-m5 protocols ospf export vpn-m5-import set routing-instances vpn-m5 protocols ospf area 0.0.0.0 interface xe-4/0/0.0 set routing-instances vpn-m5 protocols ospf area 0.0.0.0 interface xe-4/0/1.0
Configuring Adaptive Load Balancing
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode.
To configure the R2 router:
Repeat this procedure for the other routers, after modifying the appropriate interface names, addresses, and any other parameters for each router.
Specify the number of aggregated Ethernet interfaces to be created.
[edit chassis]user@R2# set aggregated-devices ethernet device-count 5Configure the Gigabit Ethernet interface link connecting R2 to R1.
[edit interfaces]user@R2# set ge-1/2/0 unit 0 family inet address 120.168.100.1/30 user@R2# set ge-1/2/0 unit 0 family iso user@R2# set ge-1/2/0 unit 0 family mpls user@R2# set ge-1/2/1 unit 0 family inet address 120.168.101.1/30 user@R2# set ge-1/2/1 unit 0 family iso user@R2# set ge-1/2/1 unit 0 family mpls user@R2# set lo0 unit 0 family inet address 120.168.0.4/32 user@R2# set lo0 unit 0 family iso address 49.0001.1201.6800.0004.00Configure the five member links of the ae0 aggregated Ethernet bundle.
[edit interfaces]user@R2# set ge-1/3/0 gigether-options 802.3ad ae0 user@R2# set ge-1/3/1 gigether-options 802.3ad ae0 user@R2# set ge-1/3/2 gigether-options 802.3ad ae0 user@R2# set ge-1/3/3 gigether-options 802.3ad ae0 user@R2# set ge-1/3/4 gigether-options 802.3ad ae0Configure the eight member links of the ae1 aggregated Ethernet bundle.
[edit interfaces]user@R2# set ge-2/2/1 gigether-options 802.3ad ae1 user@R2# set ge-2/2/2 gigether-options 802.3ad ae1 user@R2# set ge-2/2/3 gigether-options 802.3ad ae1 user@R2# set ge-2/2/4 gigether-options 802.3ad ae1 user@R2# set ge-2/2/5 gigether-options 802.3ad ae1 user@R2# set ge-2/2/6 gigether-options 802.3ad ae1 user@R2# set ge-2/2/7 gigether-options 802.3ad ae1 user@R2# set ge-2/2/8 gigether-options 802.3ad ae1Enable aggregate Ethernet load balancing on ae0 of R2.
[edit interfaces]user@R2# set ae0 aggregated-ether-options load-balance adaptive tolerance 10Configure the link speed for the ae0 aggregated Ethernet bundle.
[edit interfaces]user@R2# set ae0 aggregated-ether-options link-speed 1gConfigure LACP on the ae0 aggregated Ethernet bundle.
[edit interfaces]user@R2# set ae0 aggregated-ether-options lacp activeConfigure the interface parameters for the ae0 aggregated Ethernet bundle.
[edit interfaces]user@R2# set ae0 unit 0 family inet address 120.168.104.1/30 user@R2# set ae0 unit 0 family iso user@R2# set ae0 unit 0 family mplsEnable aggregate Ethernet load balancing on ae1 of R2.
[edit interfaces]user@R2# set ae1 aggregated-ether-options load-balance adaptive tolerance 10Configure the link speed for the ae1 aggregated Ethernet bundle.
[edit interfaces]user@R2# set ae1 aggregated-ether-options link-speed 1gConfigure LACP on the ae1 aggregated Ethernet bundle.
[edit interfaces]user@R2# set ae1 aggregated-ether-options lacp activeConfigure the interface parameters for the ae1 aggregated Ethernet bundle.
[edit interfaces]user@R2# set ae1 unit 0 family inet address 120.168.105.1/30 user@R2# set ae1 unit 0 family iso user@R2# set ae1 unit 0 family mplsDisable selective aggregate Ethernet statistics.
[edit accounting-options]user@R2# set selective-aggregate-interface-stats disableConfigure RSVP on all the interfaces of R2 and on the AE bundles.
[edit protocols]user@R2# set rsvp interface ge-1/2/0.0 user@R2# set rsvp interface ge-1/2/1.0 user@R2# set rsvp interface ae0.0 user@R2# set rsvp interface ae1.0Configure MPLS on all the interfaces of R2 and on the AE bundles.
[edit protocols]user@R2# set mpls interface ge-1/2/0.0 user@R2# set mpls interface ge-1/2/1.0 user@R2# set mpls interface ae0.0 user@R2# set mpls interface ae1.0Configure IS-IS on all the interfaces of R2 and on the AE bundles.
[edit protocols]user@R2# set isis traffic-engineering family inet shortcuts user@R2# set isis level 1 disable user@R2# set isis interface ge-1/2/0.0 user@R2# set isis interface ge-1/2/1.0 user@R2# set isis interface ae0.0 user@R2# set isis interface ae1.0 user@R2# set isis interface lo0.0
Results
From configuration mode, confirm your configuration
by entering the show chassis, show interfaces, show accounting-options, and show protocols commands. If the output does not display the intended configuration,
repeat the instructions in this example to correct the configuration.
user@R2# show chassis
aggregated-devices {
ethernet {
device-count 5;
}
}
user@R2# show interfaces
ge-1/2/0 {
unit 0 {
family inet {
address 120.168.100.1/30;
}
family iso;
family mpls;
}
}
ge-1/2/1 {
unit 0 {
family inet {
address 120.168.101.1/30;
}
family iso;
family mpls;
}
}
ge-1/3/0 {
gigether-options {
802.3ad ae0;
}
}
ge-1/3/1 {
gigether-options {
802.3ad ae0;
}
}
ge-1/3/2 {
gigether-options {
802.3ad ae0;
}
}
ge-1/3/3 {
gigether-options {
802.3ad ae0;
}
}
ge-1/3/4 {
gigether-options {
802.3ad ae0;
}
}
ge-2/2/1 {
gigether-options {
802.3ad ae1;
}
}
ge-2/2/2 {
gigether-options {
802.3ad ae1;
}
}
ge-2/2/3 {
gigether-options {
802.3ad ae1;
}
}
ge-2/2/4 {
gigether-options {
802.3ad ae1;
}
}
ge-2/2/5 {
gigether-options {
802.3ad ae1;
}
}
ge-2/2/6 {
gigether-options {
802.3ad ae1;
}
}
ge-2/2/7 {
gigether-options {
802.3ad ae1;
}
}
ge-2/2/8 {
gigether-options {
802.3ad ae1;
}
}
ae0 {
aggregated-ether-options {
load-balance {
adaptive tolerance 10;
}
link-speed 1g;
lacp {
active;
}
}
unit 0 {
family inet {
address 120.168.104.1/30;
}
family iso;
family mpls;
}
}
ae1 {
aggregated-ether-options {
load-balance {
adaptive tolerance 10;
}
link-speed 1g;
lacp {
active;
}
}
unit 0 {
family inet {
address 120.168.105.1/30;
}
family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 120.168.0.4/32;
}
family iso {
address 49.0001.1201.6800.0004.00;
}
}
}
user@R2# show accounting-options
selective-aggregate-interface-stats disable;
user@R2# show protocols
rsvp {
interface ge-1/2/0.0;
interface ge-1/2/1.0;
interface ae0.0;
interface ae1.0;
}
mpls {
interface ge-1/2/0.0;
interface ge-1/2/1.0;
interface ae0.0;
interface ae1.0;
}
isis {
traffic-engineering {
family inet {
shortcuts;
}
}
level 1 disable;
interface ge-1/2/0.0;
interface ge-1/2/1.0;
interface ae0.0;
interface ae1.0;
interface lo0.0;
}
Verification
Confirm that the configuration is working properly.
Verifying Adaptive Load Balancing on ae0
Purpose
Verify that packets received on the ae0 aggregated Ethernet bundle are load-balanced among the five member links.
Action
From operational mode, run the show interfaces
ae0 extensive command.
user@R2> show interfaces ae0 extensive
Logical interface ae0.0 (Index 325) (SNMP ifIndex 917) (Generation 134)
Flags: SNMP-Traps 0x4004000 Encapsulation: ENET2
Statistics Packets pps Bytes bps
Bundle:
Input : 848761 9 81247024 7616
Output: 166067308909 3503173 126900990064983 21423804256
Adaptive Statistics:
Adaptive Adjusts: 264
Adaptive Scans : 27682
Adaptive Updates: 10
Link:
ge-1/3/0.0
Input : 290888 5 29454436 3072
Output: 33183442699 704569 25358563587277 4306031760
ge-1/3/1.0
Input : 162703 1 14806325 992
Output: 33248375409 705446 25406995966732 4315342152
ge-1/3/2.0
Input : 127448 1 12130566 992
Output: 33184552729 697572 25354827700261 4267192376
ge-1/3/3.0
Input : 121044 1 11481262 1280
Output: 33245875402 697716 25405953405192 4265750584
ge-1/3/4.0
Input : 146678 1 13374435 1280
Output: 33205071207 697870 25374651121458 4269487384Meaning
The member links of the ae0 aggregated Ethernet bundle are fully utilized with adaptive load balancing.
Platform-Specific Aggregated Ethernet Load Balancing Behavior
Use Feature Explorer to confirm platform and release support for specific features.
Use the following table to review platform-specific behaviors for your platform.
Platform-Specific Aggregated Ethernet Load Balancing Behavior
| Platform | Difference |
|---|---|
|
ACX Series |
|
|
EX Series |
|
|
MX Series |
|
| PTX Series |
|
| QFX Series |
|
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.
payload statement.