- play_arrow Configuring Interfaces
- Understanding Interfaces
- Physical Interface Properties
- Logical Interface Properties
- Damping Interfaces
- Interface Ranges
- Gigabit Ethernet Interface
- Optical Transport Network (OTN) Interfaces
- Energy Efficient Ethernet Interfaces
- Uplink Failure Detection
- Targeted Broadcast
- ARP
- Use of Resillient Hashing to Minimize Flow Remapping
- Generic Routing Encapsulation (GRE)
- Understanding Per-Packet Load Balancing
- Understanding ECMP Groups
- play_arrow Port Speed for Switches
- play_arrow Flexible Ethernet Services Encapsulation
- play_arrow Monitoring and Troubleshooting Information
- play_arrow Configuration Statements and Operational Commands
ON THIS PAGE
Load Balancing for Aggregated Ethernet Interfaces
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 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.
Configuring Load Balancing Based on MAC Addresses
The hash key mechanism for load-balancing uses Layer 2 media access control (MAC)
information such as frame source and destination address. To load-balance traffic based
on Layer 2 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 Expolorer 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
Configuring Load Balancing on a LAG Link
You can configure the load balancing hash key for Layer 2
traffic to use fields in the Layer 3 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) or layer-4 fields. You configure
this statement at the [edit forwarding-options hash-key family
multiservice] hierarchy level.
You can configure Layer 3 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 Layer 3 information carried in the packet.
For more information about link aggregation group (LAG) configuration, see the Junos OS Network Interfaces Library for Routing Devices.
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.
Understanding 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. While the use of streaming video technology was previously limited to occasional company presentations, multicasting has provided a boost to the technology resulting in a constant stream of movies, real-time data, news clips, and amateur videos flowing 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 link aggregation groups (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: Configuring Multicast Load Balancing for Use with Aggregated 10-Gigabit Ethernet Interfaces on EX8200 Switches
EX8200 switches support multicast load balancing on link aggregation groups (LAGs). Multicast load balancing evenly distributes Layer 3 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, provide 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 Layer 3 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 gigabits per second).
The default hashing algorithm, crc-sgip, involves a cyclic redundancy check 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 gigabits per second for each link in the LAG. Link speed for the 40-gigabit LAG is automatically set to 40 gigabits per second.
Configuration
Procedure
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.
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 to be created:
content_copy zoom_out_map[edit chassis] user@switch#
set aggregated-devices ethernet device-count 1Specify the minimum number of links for the aggregated Ethernet interface (aex), that is, the LAG, to be labeled
up:Note:By default, only one link needs to be up for the LAG to be labeled
up.content_copy zoom_out_map[edit interfaces] user@switch#
set ae0 aggregated-ether-options minimum-links 1Specify the four members to be included within the LAG:
content_copy zoom_out_map[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:
content_copy zoom_out_map[edit chassis] user@switch# set multicast-loadbalanceNote:You 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 gigabits per second 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 Layer 3 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 link aggregation group (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 that this is 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.