ON THIS PAGE
Load Balancing Overview
Learn about load balancing on aggregated ethernet interfaces, and how to configure lod balancing based on MAC addresses. reduces network congestion by dividing traffic among multiple interfaces. to
Load balancing is done on Layer 2 across the member links making the configuration better without congestion and maintaining redundancy. The below topics discuss the overview of load balancing, configuring load balancing based on MAC addresses and on LAG link, understanding the consistency through resilient hashing.
Load Balancing and Ethernet Link Aggregation Overview
You can create a LAG for a group of Ethernet ports. L2 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 L2 payload by default. When the
hash-mode is set to L2 payload, the hashing algorithm uses the
IPv4 and IPv6 payload fields for hashing.
You can also configure the load
balancing hash key for L2 traffic to use fields in the L3 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 an L2 switch, one link is overutilized and other links are underutilized.
Configure Load Balancing Based on MAC Addresses
The hash key mechanism for load-balancing uses L2 MAC information such as frame source
and destination address. To load-balance traffic based on L2 MAC information, include
the multiservice statement at the [edit forwarding-options
hash-key] or [edit chassis fpc slot number pic
PIC number hash-key] hierarchy level:
multiservice {
source-mac;
destination-mac;
payload {
ip {
layer3-only;
layer-3 (source-ip-only | destination-ip-only);
layer-4;
inner-vlan-id;
outer-vlan-id;
}
}
}
Use Feature Explorer to confirm platform and release support for specific features.
Review the Platform-Specific MAC Address Based Load-Balancing Behavior section for notes related to your platform.
To include the destination-address MAC information in the hash key, include the
destination-mac option. To include the source-address MAC
information in the hash key, include the source-mac option.
-
Any packets that have the same source and destination address will be sent over the same path.
-
You can configure per-packet load balancing to optimize EVPN traffic flows across multiple paths.
-
Aggregated Ethernet member links will now use the physical MAC address as the source MAC address in 802.3ah OAM packets.
Platform-Specific MAC Address Based Load-Balancing Behavior
|
Platform |
Difference |
|---|---|
|
ACX Series |
|
See Also
Configure Load Balancing on a LAG Link
You can configure the load balancing hash key for L2 traffic to use fields in the L3 and Layer 4
headers inside the frame payload for load-balancing purposes using the
payload statement. You can configure the statement to look at
layer-3 and source-ip-only or
destination-ip-only packet header fields. You can also
look at layer-4 fields. You configure this statement at the
[edit forwarding-options hash-key family multiservice]
hierarchy level.
You can configure L3 or Layer 4 options, or both. The source-ip-only or
destination-ip-only options are mutually exclusive. The
layer-3-only statement is not available on MX Series
routers.
By default, Junos implementation of 802.3ad balances traffic across the member links within an aggregated Ethernet bundle based on the L3 information carried in the packet.
For more information about LAG configuration, see the Junos OS Network Interfaces Library for Routing Devices.
Example:
This example configures the load-balancing hash key to use the source L3 IP address option and Layer 4 header fields. The example also includes the source and destination MAC addresses for load balancing on a LAG link.
[edit]
forwarding-options {
hash-key {
family multiservice {
source-mac;
destination-mac;
payload {
ip {
layer-3 {
source-ip-only;
}
layer-4;
}
}
}
}
}
Any change in the hash key configuration requires a reboot of the FPC for the changes to take effect.
Example: Configuring Load Balancing on a LAG Link
This example configures the load-balancing hash key to use the source Layer 3 IP address option and Layer 4 header fields as well as the source and destination MAC addresses for load balancing on a link aggregation group (LAG) link:
[edit]
forwarding-options {
hash-key {
family multiservice {
source-mac;
destination-mac;
payload {
ip {
layer-3 {
source-ip-only;
}
layer-4;
}
}
}
}
}
Any change in the hash key configuration requires a reboot of the FPC for the changes to take effect.
Understand Multicast Load Balancing on Aggregated 10-Gigabit Links for Routed Multicast Traffic on EX8200 Switches
Streaming video technology was introduced in 1997. Multicast protocols were subsequently developed to reduce data replication and network overloads. With multicasting, servers can send a single stream to a group of recipients instead of sending multiple unicast streams. Streaming video technology was once limited to occasional company presentations. Multicasting now boosts the technology, enabling a constant stream of movies, real-time data, news clips, and amateur videos to flow nonstop to computers, TVs, tablets, and phones. However, all of these streams quickly overwhelmed the capacity of network hardware and increased bandwidth demands leading to unacceptable blips and stutters in transmission.
To satisfy the growing bandwidth demands, multiple links were virtually aggregated to form bigger logical point-to-point link channels for the flow of data. These virtual link combinations are called multicast interfaces, also known as LAGs.
Multicast load balancing involves managing the individual links in each LAG to ensure that each link is used efficiently. Hashing algorithms continually evaluate the data stream, adjusting stream distribution over the links in the LAG, so that no link is underutilized or overutilized. Multicast load balancing is enabled by default on Juniper Networks EX8200 Ethernet Switches.
This topic includes:
- Create LAGs for Multicasting in Increments of 10 Gigabits
- When Should I Use Multicast Load Balancing?
- How Does Multicast Load Balancing Work?
- How Do I Implement Multicast Load Balancing on an EX8200 Switch?
Create LAGs for Multicasting in Increments of 10 Gigabits
The maximum link size on an EX8200 switch is 10 gigabits. If you need a larger link on an EX8200 switch, you can combine up to twelve 10-gigabit links. In the sample topology shown in Figure 1, four 10-gigabit links have been aggregated to form each 40-gigabit link.
When Should I Use Multicast Load Balancing?
Use a LAG with multicast load balancing when you need a downstream link greater than 10 gigabits. This need frequently arises when you act as a service provider or when you multicast video to a large audience.
To use multicast load balancing, you need the following:
An EX8200 switch—Standalone switches support multicast load balancing, while Virtual Chassis does not.
A Layer 3 routed multicast setup—For information about configuring multicasting, see Junos OS Routing Protocols Configuration Guide.
Aggregated 10-gigabit links in a LAG—For information about configuring LAGs with multicast load balancing , see Configuring Multicast Load Balancing for Use with Aggregated 10-Gigabit Ethernet Links on EX8200 Switches (CLI Procedure).
How Does Multicast Load Balancing Work?
When traffic can use multiple member links, traffic that is part of the same stream must always be on the same link.
Multicast load balancing uses one of seven available hashing algorithms and a technique called queue shuffling (alternating between two queues) to distribute and balance the data, directing streams over all available aggregated links. You can select one of the seven algorithms when you configure multicast load balancing, or you can use the default algorithm, crc-sgip, which uses a cyclic redundancy check (CRC) algorithm on the multicast packets’ group IP address. We recommend that you start with the crc-sgip default and try other options if this algorithm does not evenly distribute the Layer 3 routed multicast traffic. Six of the algorithms are based on the hashed value of IP addresses (IPv4 or IPv6) and will produce the same result each time they are used. Only the balanced mode option produces results that vary depending on the order in which streams are added. See Table 1 for more information.
|
Hashing Algorithms |
Based On |
Best Use |
|---|---|---|
|
crc-sgip |
Cyclic redundancy check of multicast packets’ source and group IP address |
Default—high-performance management of IP traffic on 10-Gigabit Ethernet network. Predictable assignment to the same link each time. This mode is complex but yields a good distributed hash. |
|
crc-gip |
Cyclic redundancy check of multicast packets’ group IP address |
Predictable assignment to the same link each time. Try this mode when crc-sgip does not evenly distribute the Layer 3 routed multicast traffic and the group IP addresses vary. |
|
crc-sip |
Cyclic redundancy check of multicast packets’ source IP address |
Predictable assignment to the same link each time. Try this mode when crc-sgip does not evenly distribute the Layer 3 routed multicast traffic and the stream sources vary. |
|
simple-sgip |
XOR calculation of multicast packets’ source and group IP address |
Predictable assignment to the same link each time. This is a simple hashing method that might not yield as even a distribution as crc-sgip yields. Try this mode when crc-sgip does not evenly distribute the Layer 3 routed multicast traffic. |
|
simple-gip |
XOR calculation of multicast packets’ group IP address |
Predictable assignment to the same link each time. This is a simple hashing method that might not yield as even a distribution as crc-gip yields. Try this when crc-gip does not evenly distribute the Layer 3 routed multicast traffic and the group IP addresses vary. |
|
simple-sip |
XOR calculation of multicast packets’ source IP address |
Predictable assignment to the same link each time. This is a simple hashing method that might not yield as even a distribution as crc-sip yields. Try this mode when crc-sip does not evenly distribute the Layer 3 routed multicast traffic and stream sources vary. |
|
balanced |
Round-robin calculation method used to identify multicast links with the least amount of traffic |
Best balance is achieved, but you cannot predict which link will be consistently used because that depends on the order in which streams come online. Use when consistent assignment is not needed after every reboot. |
How Do I Implement Multicast Load Balancing on an EX8200 Switch?
To implement multicast load balancing with an optimized level of throughput on an EX8200 switch, follow these recommendations:
Allow 25 percent unused bandwidth in the aggregated link to accommodate any dynamic imbalances due to link changes caused by sharing multicast interfaces.
For downstream links, use multicast interfaces of the same size whenever possible. Also, for downstream aggregated links, throughput is optimized when members of the aggregated link belong to the same devices.
For upstream aggregated links, use a Layer 3 link whenever possible. Also, for upstream aggregated links, throughput is optimized when the members of the aggregated link belong to different devices.
See Also
Example: Configure Multicast Load Balancing for Use with Aggregated 10-Gigabit Ethernet Interfaces on EX8200 Switches
EX8200 switches support multicast load balancing on LAGs. Multicast load balancing evenly distributes L3 routed multicast traffic over the LAGs, You can aggregate up to twelve 10-gigabit Ethernet links to form a 120-gigabit virtual link or LAG. The MAC client can treat this virtual link as if it were a single link to increase bandwidth, provides graceful degradation as link failures occur, and increase availability. On EX8200 switches, multicast load balancing is enabled by default. However, if it is explicitly disabled, you can reenable it.
An interface with an already configured IP address cannot form part of the LAG.
Only EX8200 standalone switches with 10-gigabit links support multicast load balancing. Virtual Chassis does not support multicast load balancing.
This example shows how to configure a LAG and reenable multicast load balancing:
Requirements
This example uses the following hardware and software components:
Two EX8200 switches, one used as the access switch and one used as the distribution switch
Junos OS Release 12.2 or later for EX Series switches
Before you begin:
Configure four 10-gigabit interfaces on the EX8200 distribution switch: xe-0/1/0, xe-1/1/0, xe-2/1/0, and xe-3/1/0. See Configuring Gigabit Ethernet Interfaces (CLI Procedure).
Overview and Topology
Multicast load balancing uses one of seven hashing algorithms to balance traffic between the individual 10-gigabit links in the LAG. For a description of the hashing algorithms, see multicast-loadbalance. The default hashing algorithm is crc-sgip. You can experiment with the different hashing algorithms until you determine the one that best balances your L3 routed multicast traffic.
When a link larger than 10 gigabits is needed on an EX8200 switch, you can combine up to twelve 10-gigabit links to create more bandwidth. This example uses the link aggregation feature to combine four 10-gigabit links into a 40-gigabit link on the distribution switch. In addition, multicast load balancing is enabled to ensure even distribution of Layer 3 routed multicast traffic on the 40-gigabit link. In the sample topology illustrated in Figure 2, an EX8200 switch in the distribution layer is connected to an EX8200 switch in the access layer.
Link speed is automatically determined based on the size of the LAG configured. For example, if a LAG is composed of four 10-gigabit links, the link speed is 40 Gbps.
The default hashing algorithm, crc-sgip, involves a cyclic redundancy check (CRC) of both the multicast packet source and group IP addresses.
You will configure a LAG on each switch and reenable multicast load balancing. When reenabled, multicast load balancing will automatically take effect on the LAG, and the speed is set to 10 Gbps for each link in the LAG. Link speed for the 40-gigabit LAG is automatically set to 40 Gbps.
Configuration
Procedure
CLI Quick Configuration
set chassis aggregated-devices ethernet device-count 1 set interfaces ae0 aggregated-ether-options minimum-links 1 set interfaces xe-0/1/0 ether-options 802.3ad ae0 set interfaces xe-1/1/0 ether-options 802.3ad ae0 set interfaces xe-2/1/0 ether-options 802.3ad ae0 set interfaces xe-3/1/0 ether-options 802.3ad ae0 set chassis multicast-loadbalance hash-mode crc-gip
Step-by-Step Procedure
To configure a LAG and reenable multicast load balancing:
Specify the number of aggregated Ethernet interfaces (aex) to be created:
[edit chassis] user@switch#
set aggregated-devices ethernet device-count 1Specify the minimum number of links for the aex, that is, the LAG, to be labeled
up:By default, only one link needs to be up for the LAG to be labeled
up.[edit interfaces] user@switch#
set ae0 aggregated-ether-options minimum-links 1Specify the four members to be included within the LAG:
[edit interfaces] user@switch#
set xe-0/1/0 ether-options 802.3ad ae0user@switch#set xe-1/1/0 ether-options 802.3ad ae0user@switch#set xe-2/1/0 ether-options 802.3ad ae0user@switch#set xe-3/1/0 ether-options 802.3ad ae0Reenable multicast load balancing:
[edit chassis] user@switch# set multicast-loadbalanceYou do not need to set link speed the way you do for LAGs that do not use multicast load balancing. Link speed is automatically set to 40 Gbps on a 40-gigabit LAG.
You can optionally change the value of the
hash-modeoption in the multicast-loadbalance statement to try different algorithms until you find the one that best distributes your L3 routed multicast traffic.If you change the hashing algorithm when multicast load balancing is disabled, the new algorithm takes effect after you reenable multicast load balancing.
Results
Check the results of the configuration:
user@switch> show configuration
chassis
aggregated-devices {
ethernet {
device-count 1;
}
}
multicast-loadbalance {
hash-mode crc-gip;
}
interfaces
xe-0/1/0 {
ether-options {
802.3ad ae0;
}
}
xe-1/1/0 {
ether-options {
802.3ad ae0;
}
}
xe-2/1/0 {
ether-options {
802.3ad ae0;
}
}
xe-3/1/0 {
ether-options {
802.3ad ae0;
}
}
ae0 {
aggregated-ether-options {
minimum-links 1;
}
}
}
Verification
To confirm that the configuration is working properly, perform these tasks:
Verifying the Status of a LAG Interface
Purpose
Verify that a LAG (ae0) has been created on the switch.
Action
Verify that the ae0 LAG has been created:
user@switch> show interfaces ae0 terse
Interface Admin Link Proto Local Remote ae0 up up ae0.0 up up inet 10.10.10.2/24
Meaning
The interface name aex indicates a LAG. A stands for aggregated, and E stands for Ethernet. The number differentiates the various LAGs.
Verifying Multicast Load Balancing
Purpose
Check that traffic is load-balanced equally across paths.
Action
Verify load balancing across the four interfaces:
user@switch> monitor interface traffic
Bytes=b, Clear=c, Delta=d, Packets=p, Quit=q or ESC, Rate=r, Up=^U, Down=^D ibmoem02-re1 Seconds: 3 Time: 16:06:14 Interface Link Input packets (pps) Output packets (pps) xe-0/1/0 Up 2058834 (10) 7345862 (19) xe-1/1/0 Up 2509289 (9) 6740592 (21) xe-2/1/0 Up 8625688 (90) 10558315 (20) xe-3/1/0 Up 2374154 (23) 71494375 (9)
Meaning
The interfaces should be carrying approximately the same amount of traffic.
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.