Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

ON THIS PAGE

Aggregated Ethernet Interfaces

 

The below topics discuss the overview aggregated ethernet interfaces, configuration details of link aggregation and aggregated Ethernet interfaces, troubleshooting and verification of aggregated Ethernet Interfaces.

Understanding Aggregated Ethernet Interfaces and LACP for Switches

IEEE 802.3ad link aggregation enables you to group Ethernet interfaces to form a single link layer interface, also known as a link aggregation group (LAG) or bundle.

Aggregating multiple links between physical interfaces creates a single logical point-to-point trunk link or a LAG. The LAG balances traffic across the member links within an aggregated Ethernet bundle and effectively increases the uplink bandwidth. Another advantage of link aggregation is increased availability, because the LAG is composed of multiple member links. If one member link fails, the LAG continues to carry traffic over the remaining links.

Note

On QFX5100, EX4600, QFX10002 standalone switches, and on a QFX5100 Virtual Chassis and EX4600 Virtual Chassis, you can configure a mixed rate of link speeds for the aggregated Ethernet bundle. Only link speeds of 40G and 10G are supported. Load balancing will not work if you configure link speeds that are not supported.

Note

The QFX5200 switches do not support mixed rate aggregated Ethernet bundles.

Link Aggregation Control Protocol (LACP) is a subcomponent of the IEEE 802.3ad standard and is used as a discovery protocol.

Note

To ensure load balancing across the aggregated Ethernet (AE) interfaces on a redundant server Node group, the members of the AE must be equally distributed across the redundant server Node group.

Note

During a network Node group switchover, traffic might be dropped for a few seconds.

Link Aggregation Group

You configure a LAG by specifying the link number as a physical device and then associating a set of interfaces (ports) with the link. All the interfaces must have the same speed and be in full-duplex mode. Juniper Networks Junos operating system (Junos OS) for EX Series Ethernet Switches assigns a unique ID and port priority to each interface. The ID and priority are not configurable.

The number of interfaces that can be grouped into a LAG and the total number of LAGs supported on a switch varies according to switch model. Table 1 lists the EX Series switches and the maximum number of interfaces per LAG and the maximum number of LAGs they support.

Note

For Junos OS Evolved, the software does not impose a limit on the maximum number of AE interfaces in a mixed-rate AE bundle. Because all child logical interfaces belong to same AE physical interface and share the same selector, using much less load balance memory, mixed-rate AE interface configurations should go through even if they exceed 64 logical interfaces.

Table 1: Maximum Interfaces per LAG and Maximum LAGs per Switch

Switch

Maximum Interfaces per LAG

Maximum LAGs

EX2200

8

32

EX2300

8

128

EX3200

8

32

EX3300 and EX3300 Virtual Chassis

8

32

EX3400

16

128

EX4200 and EX4200 Virtual Chassis

8

111

EX4300 and EX4300 Virtual Chassis

16

128

EX4500, EX4500 Virtual Chassis, EX4550, and EX4550 Virtual Chassis

8

111

EX4600

32

128

EX6200

8

111

EX8200

12

255

EX8200 Virtual Chassis

12

239

EX9200

64

150

To create a LAG:

  1. Create a logical aggregated Ethernet interface.

  2. Define the parameters associated with the logical aggregated Ethernet interface, such as a logical unit, interface properties, and Link Aggregation Control Protocol (LACP).

  3. Define the member links to be contained within the aggregated Ethernet interface—for example, two 10-Gigabit Ethernet interfaces.

  4. Configure LACP for link detection.

Keep in mind these hardware and software guidelines:

  • For Junos OS Evolved, when a new interface is added as a member to the aggregated Ethernet bundle, a link flap event is generated. When you add an interface to the bundle, the physical interface is deleted as a regular interface and then added back as a member. During this time, the details of the physical interface are lost.

  • Up to 32 Ethernet interfaces can be grouped to form a LAG on a redundant server Node group, a server Node group, and a network Node group on a QFabric system. Up to 48 LAGs are supported on redundant server Node groups and server Node groups on a QFabric system, and up to 128 LAGs are supported on network Node groups on a QFabric system. You can configure LAGs across Node devices in redundant server Node groups, server Node groups, and network Node groups.

    Note

    If you try to commit a configuration containing more than 32 Ethernet interfaces in a LAG, you will receive an error message saying that the group limit of 32 has been exceeded, and the configuration checkout has failed.

  • Up to 64 Ethernet interfaces can be grouped to form a LAG, and up to 448 LAGs are supported on QFX3500, QFX3600, EX4600, and OCX Series switches, and up to 1,000 LAGs are supported on QFX5100, QFX5200, QFX5110, QFX10002, QFX10008, and QFX10016 switches.

    Note

    If you try to commit a configuration containing more than 64 Ethernet interfaces in a LAG, you will receive an error message saying that the group limit of 64 has been exceeded, and the configuration checkout has failed.

  • Up to 64 Ethernet interfaces can be grouped to form a LAG, and In a Junos Fusion, up to 1,000 LAGs are supported on QFX10002 switches acting as aggregation devices.

  • The LAG must be configured on both sides of the link.

  • The interfaces on either side of the link must be set to the same speed and be in full-duplex mode.

    Note

    Junos OS assigns a unique ID and port priority to each port. The ID and priority are not configurable.

  • QFabric systems support a special LAG called an FCoE LAG, which enables you to transport FCoE traffic and regular Ethernet traffic (traffic that is not FCoE traffic) across the same link aggregation bundle. Standard LAGs use a hashing algorithm to determine which physical link in the LAG is used for a transmission, so communication between two devices might use different physical links in the LAG for different transmissions. An FCoE LAG ensures that FCoE traffic uses the same physical link in the LAG for requests and replies in order to preserve the virtual point-to-point link between the FCoE device converged network adapter (CNA) and the FC SAN switch across a QFabric system Node device. An FCoE LAG does not provide load balancing or link redundancy for FCoE traffic. However, regular Ethernet traffic uses the standard hashing algorithm and receives the usual LAG benefits of load balancing and link redundancy in an FCoE LAG. See Understanding FCoE LAGs for more information.

Link Aggregation Control Protocol (LACP)

LACP is one method of bundling several physical interfaces to form one logical aggregated Ethernet interface. By default, Ethernet links do not exchange LACP protocol data units (PDUs), which contain information about the state of the link. You can configure Ethernet links to actively transmit LACP PDUs, or you can configure the links to passively transmit them, sending out LACP PDUs only when the Ethernet link receives them from the remote end. The LACP mode can be active or passive. The transmitting link is known as the actor, and the receiving link is known as the partner. If the actor and partner are both in passive mode, they do not exchange LACP packets, and the aggregated Ethernet links do not come up. If either the actor or partner is active, they do exchange LACP packets. By default, LACP is in passive mode on aggregated Ethernet interfaces. To initiate transmission of LACP packets and response to LACP packets, you must enable LACP active mode. You can configure both VLAN-tagged and untagged aggregated Ethernet interfaces without LACP enabled. LACP is defined in IEEE 802.3ad, Aggregation of Multiple Link Segments.

LACP was designed to achieve the following:

  • Automatic addition and deletion of individual links to the LAG without user intervention.

  • Link monitoring to check whether both ends of the bundle are connected to the correct group.

In a scenario where a dual-homed server is deployed with a switch, the network interface cards form a LAG with the switch. During a server upgrade, the server might not be able to exchange LACP PDUs. In such a situation, you can configure an interface to be in the up state even if no PDUs are exchanged. Use the force-up statement to configure an interface when the peer has limited LACP capability. The interface selects the associated LAG by default, whether the switch and peer are both in active or passive mode. When PDUs are not received, the partner is considered to be working in the passive mode. Therefore, LACP PDU transmissions are controlled by the transmitting link.

If the remote end of the LAG link is a security device, LACP might not be supported because security devices require a deterministic configuration. In this case, do not configure LACP. All links in the LAG are permanently operational unless the switch detects a link failure within the Ethernet physical layer or data link layers.

When LACP is configured, it detects misconfigurations on the local end or the remote end of the link. Thus, LACP can help prevent communication failure:

  • When LACP is not enabled, a local LAG might attempt to transmit packets to a remote single interface, which causes the communication to fail.

  • When LACP is enabled, a local LAG cannot transmit packets unless a LAG with LACP is also configured on the remote end of the link.

Configuring an Aggregated Ethernet Interface

You can associate a physical interface with an aggregated Ethernet interface.

To configure an aggregated Ethernet interface:

  1. Specify that you want to configure the link aggregation group interface.
  2. Configure the aggregated Ethernet interface.

You specify the interface instance number x to complete the link association; x can be from 0 through 480, for a total of 480 aggregated interfaces on MX Series routers or EX9200 switches. You must also include a statement defining aex at the [edit interfaces] hierarchy level. You can optionally specify other physical properties that apply specifically to the aggregated Ethernet interfaces; for details, see Ethernet Interfaces Overview.

Note

In general, aggregated Ethernet bundles support the features available on all supported interfaces that can become a member link within the bundle. As an exception, Gigabit Ethernet IQ features and some newer Gigabit Ethernet features are not supported in aggregated Ethernet bundles.

Gigabit Ethernet IQ and SFP interfaces can be member links, but IQ- and SFP-specific features are not supported on the aggregated Ethernet bundle even if all the member links individually support those features.

You need to configure the correct link speed for the aggregated Ethernet interface to eliminate any warning message.

Note

Before you commit an aggregated Ethernet configuration, ensure that link mode is not configured on any member interface of the aggregated Ethernet bundle; otherwise, the configuration commit check fails.

Configuring Tagged Aggregated Ethernet Interfaces

To specify aggregated Ethernet interfaces, include the vlan-tagging statement at the [edit interfaces aex] hierarchy level:

You must also include the vlan-id statement:

You can include this statement at the following hierarchy levels:

  • [edit interfaces interface-name unit logical-unit-number]

  • [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number]

For more information about the vlan-tagging and vlan-id statements, see 802.1Q VLANs Overview.

Configuring Untagged Aggregated Ethernet Interfaces

When you configure an untagged Aggregated Ethernet interface, the existing rules for untagged interfaces apply. These rules are as follows:

  • You can configure only one logical interface (unit 0) on the port. The logical unit 0 is used to send and receive LACP or marker protocol data units (PDUs) to and from the individual links.

  • You cannot include the vlan-id statement in the configuration of the logical interface.

Configure an untagged aggregated Ethernet interface by omitting thevlan-tagging and vlan-id statements from the configuration:

Configuring the Number of Aggregated Ethernet Interfaces on the Device (Enhanced Layer 2 Software)

By default, no aggregated Ethernet interfaces are created. You must set the number of aggregated Ethernet interfaces on the routing device before you can configure them.

On MX Series routers and EX9200 switches, you can configure a maximum of 480 aggregated interfaces. The aggregated interfaces(LAG bundles) are numbered from ae0 through ae479 on MX Series routers and EX9200 switches.

  1. Specify that you want to access the aggregated Ethernet configuration on the device.
  2. Set the number of aggregated Ethernet interfaces.

You must also specify the constituent physical links by including the 802.3ad statement at the [edit interfaces interface-name ether-options] or [edit interfaces interface-name ether-options] hierarchy level.

See also

Example: Configuring Aggregated Ethernet Interfaces

Aggregated Ethernet interfaces can use interfaces from different FPCs, DPCs, or PICs. The following configuration is sufficient to get an aggregated Gigabit Ethernet interface up and running.

Deleting an Aggregated Ethernet Interface

There are two approaches to deleting an aggregated Ethernet interface:

  • You can delete an aggregated Ethernet interface from the interface configuration. The Junos OS removes the configuration statements related to aex and sets this interface to down state.

  • You can also permanently remove the aggregated Ethernet interface from the device configuration by deleting it from the device-count on the routing device.

To delete an aggregated Ethernet interface:

  1. Delete the aggregated Ethernet configuration.

    This step changes the interface state to down and removing the configuration statements related to aex.

  2. Delete the interface from the device count.

Local link bias conserves bandwidth on Virtual Chassis ports (VCPs) by using local links to forward unicast traffic exiting a Virtual Chassis or Virtual Chassis Fabric (VCF) that has a Link Aggregation group (LAG) bundle composed of member links on different member switches in the same Virtual Chassis or VCF. A local link is a member link in the LAG bundle that is on the member switch that received the traffic. Because traffic is received and forwarded on the same member switch when local link bias is enabled, no VCP bandwidth is consumed by traffic traversing the VCPs to exit the Virtual Chassis or VCF using a different member link in the LAG bundle. The traffic flow of traffic exiting a Virtual Chassis or VCF over a LAG bundle when local link bias is enabled is illustrated in Figure 1.

When local link bias is disabled, egress traffic exiting a Virtual Chassis or VCF on a LAG bundle can be forwarded out of any member link in the LAG bundle. Traffic forwarding decisions are made by an internal algorithm that attempts to load-balance traffic between the member links in the bundle. VCP bandwidth is frequently consumed by egress traffic when local link bias is disabled because the egress traffic traverses the VCPs to reach the destination egress member link in the LAG bundle. The traffic flow of traffic exiting a Virtual Chassis or VCF over a LAG bundle when local link bias is disabled is illustrated in Figure 2.

Starting in Junos OS Release 14.1X53-D25, local link bias can be enabled globally for all LAG bundles in a Virtual Chassis or VCF, or individually per LAG bundle in a Virtual Chassis. In prior Junos OS releases, local link bias could be enabled individually per LAG bundle only.

A Virtual Chassis or VCF that has multiple LAG bundles can contain bundles that have and have not enabled local link bias. Local link bias only impacts the forwarding of unicast traffic exiting a Virtual Chassis or VCF; ingress traffic handling is not impacted by the local link bias setting. Egress multicast, unknown unicast, and broadcast traffic exiting a Virtual Chassis or VCF over a LAG bundle is not impacted by the local link bias setting and is always load-balanced among the member links. Local link bias is disabled, by default.

You should enable local link bias if you want to conserve VCP bandwidth by always forwarding egress unicast traffic on a LAG bundle out of a local link. You should not enable local link bias if you want egress traffic load-balanced across the member links in the LAG bundle as it exits the Virtual Chassis or VCF.

Local link bias is used to conserve bandwidth on Virtual Chassis ports (VCPs) by using local links to forward unicast traffic exiting a Virtual Chassis or Virtual Chassis Fabric (VCF) that has a Link Aggregation group (LAG) bundle composed of member links on different member switches in the same Virtual Chassis or VCF. A local link is a member link in the LAG bundle that is on the member switch that received the traffic. Because traffic is received and forwarded on the same member switch when local link bias is enabled, no VCP bandwidth is consumed by traffic traversing the VCPs to exit the Virtual Chassis or VCF on a different member link in the LAG bundle.

You should enable local link bias if you want to conserve VCP bandwidth by always forwarding egress unicast traffic on a LAG out of a local link. You should not enable local link bias if you want egress traffic load-balanced as it exits the Virtual Chassis or VCF.

Local link bias can be enabled or disabled globally or per LAG bundle on a Virtual Chassis or VCF. In cases where local link bias is enabled at both the global and per LAG bundle levels, the per LAG bundle configuration takes precedence. For instance, if local link bias is enabled globally but disabled on a LAG bundle named ae1, local link bias is disabled on the LAG bundle named ae1.

To enable local link bias on a LAG bundle:

[edit]

user@switch# set interface aex aggregated-ether-options local-bias

where aex is the name of the aggregated Ethernet link bundle.

For instance, to enable local link bias on aggregated Ethernet interface ae0:

[edit]

user@switch# set interface ae0 aggregated-ether-options local-bias

Note

When describing the local minimum links feature, member links are links that are part of an aggregated Ethernet bundle (LAG), member switches are chassis that are members in a Virtual Chassis or Virtual Chassis Fabric (VCF), and local member links (or simply local links) are member links of the same LAG that are local to a particular Virtual Chassis or VCF member switch.

A link aggregation group (LAG) can include member links on different chassis, and multiple local member links on member switches in a Virtual Chassis or VCF. If member links in the LAG fail, the LAG continues to carry traffic over the remaining member links that are still active. When multiple member links are local to one chassis and one or more of those links fail, LAG traffic coming into that chassis will be redistributed over the remaining local links. However, the remaining active local links can suffer traffic loss if the failed links result in sufficiently reduced total bandwidth through the chassis.

Introduced in Junos OS Release 14.1X53-D40, the local minimum links feature helps avoid traffic loss due to asymmetric bandwidth on LAG forwarding paths through a Virtual Chassis or VCF member switch when one or more local member links have failed.

Note

The local minimum links feature is supported on Virtual Chassis or VCFs with QFX5100 member switches only.

Based on a user-configured threshold value, when one or more member links fail, this feature marks any remaining active local links as “down,” forcing LAG traffic to be redistributed only through member links on other chassis. To enable this feature on a particular aggregated Ethernet interface (aex), you set the local-minimum-links-threshold configuration statement with a threshold value that represents the percentage of local member links that must be up on a chassis for any local member links on that chassis to continue to be active in the aggregated Ethernet bundle.

The configured threshold value:

  • Applies to a specified aggregated Ethernet interface.

  • Applies to any chassis that has links in the specified aggregated Ethernet bundle.

  • Represents a percentage of active local member links out of the total number of local member links for the chassis.

When the local minimum links feature is enabled for a LAG, if one or more member links on a chassis fail, the feature compares the percentage of local member links that are still up to the threshold. If the percentage of “up” links is less than the threshold, the feature forces down the remaining active local links, and no traffic for the aggregated Ethernet interface will be forwarded through the member links on that chassis. If the percentage of links that are “up” is greater than or equal to the threshold, the status of the active links remains unchanged, and LAG traffic will continue to be distributed over available member links on that chassis.

For example, consider a member switch in a Virtual Chassis Fabric that has four links that are active member links of a LAG, and the local minimum links feature is enabled with the threshold set to 60:

  • If one member link goes down, 75 percent (three out of four) of the links are still up, which is greater than the threshold (60 percent), so the remaining links stay up.

  • If two member links go down, only 50 percent (two out of four) of the links are “up”, so the local minimum links feature forces the remaining two active links “down.” The same is true if three member links fail, the remaining link is forced down as well.

The local minimum links feature tracks whether links are down because the link failed or the link was forced down, as well as when active, failed, or forced-down member links are added or removed. As a result, the feature can respond dynamically when:

  • Failed local member links come back up.

  • You change the configured threshold value, or you disable the local minimum links feature.

  • Adding or removing local member links changes the total number of local member links, or changes the ratio of “up” links to total local member links as compared to the threshold.

For example, if a failed member link causes all local member links to be forced down, then that link comes back up and brings the percentage of “up” links above the current threshold, the system adjusts the status of the forced-down links to mark them up again as well.

You should enable this feature only if your system closely manages ingress and egress traffic forwarding paths on LAGs for individual chassis in a Virtual Chassis and VCFs, especially where local link bias is also enabled.

Configuring Local Minimum Links

The local minimum links feature is disabled by default. To enable this feature for a LAG bundle (which then applies to any chassis that has local member links in the LAG), simply configure a threshold value for the LAG interface, as follows:

[edit interfaces]

user@switch# set aggregated-ether-options aex local-minimum-links-threshold threshold-value

To update the threshold value, use the same command with the new threshold value.

To disable the local minimum links feature, delete the local-minimum-links-threshold statement from the configuration. Any links that were forced down by this feature are automatically brought up again within a few seconds.

Local Minimum Links Effect on LAG Minimum Links

The per-chassis local minimum links threshold is similar to the minimum-links setting for a LAG bundle, which configures the minimum number of member links in the bundle that should be up for the aggregated Ethernet interface as a whole to be considered “up.” (See Configuring Link Aggregation for details.) Local member links that fail or are forced down by the local minimum links feature contribute to the count of “up” links for the LAG as a whole. As a result, this feature can cause the entire LAG to be brought down if enough local links are forced down. Enabling and configuring the local minimum links feature is independent of LAG minimum links configuration, but you should carefully consider the combined potential effect on the LAG as a whole when configuring both features.

Local Minimum Links and Local Link Bias

The local minimum links and local link bias features operate independently, but can influence each other’s traffic forwarding results. For example, when local link bias is enabled and would otherwise favor forwarding traffic out of local links in the aggregated Ethernet bundle, but those links are down because the local minimum links threshold is not currently met, outgoing traffic will be redirected through the VCPs to other Virtual Chassis or VCF member switches for forwarding. In that case, unanticipated increased VCP traffic can impact Virtual Chassis or VCF performance.

See Understanding Local Link Bias for details on the local link bias feature.

Troubleshooting an Aggregated Ethernet Interface

Troubleshooting issues for aggregated Ethernet interfaces:

Show Interfaces Command Shows the LAG is Down

Problem

Description: The show interfaces terse command shows that the LAG is down.

Solution

Check the following:

  • Verify that there is no configuration mismatch.

  • Verify that all member ports are up.

  • Verify that a LAG is part of family ethernet—switching (Layer 2 LAG) or family inet (Layer 3 LAG).

  • Verify that the LAG member is connected to the correct LAG at the other end.

  • Verify that the LAG members belong to the same switch (or the same Virtual Chassis).

Logical Interface Statistics Do Not Reflect All Traffic

Problem

Description: The traffic statistics for a logical interface do not include all of the traffic.

Solution

Traffic statistics fields for logical interfaces in show interfaces commands show only control traffic; the traffic statistics do not include data traffic. You can view the statistics for all traffic only per physical interface.

IPv6 Interface Traffic Statistics Are Not Supported

Problem

Description: The IPv6 transit statistics in the show interfaces command display all 0 values.

Solution

EX Series switches do not support the collection and reporting of IPv6 transit statistics.

SNMP Counters ifHCInBroadcastPkts and ifInBroadcastPkts Are Always 0

Problem

Description: The values for the SNMP counters ifHCInBroadcastPkts and ifInBroadcastPkts are always 0.

Solution

The SNMP counters ifHCInBroadcastPkts and ifInBroadcastPkts are not supported for aggregated Ethernet interfaces on EX Series switches.

Use the link aggregation feature to aggregate one or more links to form a virtual link or aggregation group. The MAC client can treat this virtual link as if it were a single link. Link aggregation increases bandwidth, provides graceful degradation as failure occurs, and increases link availability.

Note

An interface with an already configured IP address cannot form part of the aggregation group.

Note

On QFX5100, QFX5200, EX4600, QFX10002 , and QFX10008 standalone switches and on QFX5100 Virtual Chassis and EX4600 Virtual Chassis, you can configure a mixed rate of link speeds for the aggregated Ethernet bundle. Load balancing will not work if you configure link speeds that are not supported. (Platform support depends on the Junos OS release in your installation.)

  1. Creating an Aggregated Ethernet Interface

  2. Configuring the VLAN Name and VLAN ID Number

  3. Configuring Aggregated Ethernet LACP (CLI Procedure)

Creating an Aggregated Ethernet Interface

To create an aggregated Ethernet interface:

  1. Specify the number of aggregated Ethernet interfaces to be created:
    [edit chassis]

    user@switch# set aggregated-devices interfaces device-count device-count

    For example, to specify 5:

    [edit chassis]

    user@switch# set aggregated-devices interfaces device-count 5
  2. Specify the minimum number of links for the aggregated Ethernet interface (aex), that is, the defined bundle, to be labeled “up”:Note

    By default only one link must be up for the bundle to be labeled “up”.

    [edit interfaces]

    user@switch# set interface-name aggregated-ether-options minimum-links minimum-links

    For example, to specify 5:

    [edit interfaces]

    user@switch# set interface-name aggregated-ether-options minimum-links 5
  3. Specify the link speed for the aggregated Ethernet bundle:
    [edit interfaces]

    user@switch# set interface-name aggregated-ether-options link-speed link-speed

    For example, to specify 10g:

    [edit interfaces]

    user@switch# set interface-name aggregated-ether-options link-speed 10g
  4. Specify the members to be included within the aggregated Ethernet bundle:
    [edit interfaces]

    user@switch# set interface-name ether-options 802.3ad aex

    user@switch# set interface-name ether-options 802.3ad aex

Configuring the VLAN Name and VLAN ID Number

Note

VLANs are not supported on OCX Series switches.

[edit vlans]

user@switch# set vlan-name vlan-id vlan-id-number

For example, 100.

Note

When you add or remove a vlan from a LAG interface, the interface goes down and comes back (flaps). The flapping happens when a low speed SFP is plugged into a relatively high speed port. To avoid flapping, configure the port speed to match the speed of the SFP.

Configuring Aggregated Ethernet LACP (CLI Procedure)

For aggregated Ethernet interfaces on EX Series switches, you can configure the Link Aggregation Control Protocol (LACP). LACP is one method of bundling several physical interfaces to form one logical interface. You can configure aggregated Ethernet interfaces with or without LACP enabled.

LACP was designed to achieve the following:

  • Automatic addition and deletion of individual links to the bundle without user intervention

  • Link monitoring to check whether both ends of the bundle are connected to the correct group

Note

You can also configure LACP link protection on aggregated Ethernet interfaces. For information, see Configuring LACP Link Protection of Aggregated Ethernet Interfaces for Switches.

The Junos OS implementation of LACP provides link monitoring but not automatic addition and deletion of links.

Before you configure LACP for EX Series, be sure you have:

When LACP is enabled, the local and remote sides of the aggregated Ethernet links exchange protocol data units (PDUs), which contain information about the state of the link. You can configure Ethernet links to actively transmit PDUs, or you can configure the links to passively transmit them (sending out LACP PDUs only when they receive them from another link). One side of the link must be configured as active for the link to be up.

Note

Do not add LACP to a LAG if the remote end of the LAG link is a security device, unless the security device supports LACP. Security devices often do not support LACP because they require a deterministic configuration.

To configure LACP:

  1. Enable the LACP mode:
    [edit interfaces]

    user@switch# set aex aggregated-ether-options lacp mode

    For example, to specify the mode as active, execute the following command:

    [edit interfaces]

    user@switch# set aex aggregated-ether-options lacp active
    Note

    LACP decides active and back up state of links. When configuring LACP, state of the backup link should not be configured manually as down. The following command is not supported if LACP is configured:set interfaces ae0 aggregated-ether-options link-protection backup-state down

  2. Specify the interval and speed at which the interfaces send LACP packets:
    [edit interfaces]

    user@switch# set aex aggregated-ether-options lacp periodic interval

    For example, to specify the interval as fast, execute the following command:

    [edit interfaces]

    user@switch# set aex aggregated-ether-options lacp periodic fast
Note

The LACP process exists in the system only if you configure the system in either active or passive LACP mode.

You can configure link protection for aggregated Ethernet interfaces to provide QoS on the links during operation.

On aggregated Ethernet interfaces, you designate a primary and backup link to support link protection. Egress traffic passes only through the designated primary link. This includes transit traffic and locally generated traffic on the router or switch. When the primary link fails, traffic is routed through the backup link. Because some traffic loss is unavoidable, egress traffic is not automatically routed back to the primary link when the primary link is reestablished. Instead, you manually control when traffic should be diverted back to the primary link from the designated backup link.

Note

Link protection is not supported on MX80.

Aggregated Ethernet interfaces support link protection to ensure QoS on the interface.

To configure link protection:

  1. Specify that you want to configure the options for an aggregated Ethernet interface.
  2. Configure the link protection mode.

To configure link protection, you must specify a primary and a secondary, or backup, link.

To configure a primary link and a backup link:

  1. Configure the primary logical interface.
  2. Configure the backup logical interface.

See also

On aggregated Ethernet interfaces, you designate a primary and backup link to support link protection. Egress traffic passes only through the designated primary link. This includes transit traffic and locally generated traffic on the router or switch. When the primary link fails, traffic is routed through the backup link. Because some traffic loss is unavoidable, egress traffic is not automatically routed back to the primary link when the primary link is reestablished. Instead, you manually control when traffic should be diverted back to the primary link from the designated backup link.

To manually control when traffic should be diverted back to the primary link from the designated backup link, enter the following operational command:

To disable link protection, issue the delete interface revert aex configuration command.

On aggregated Ethernet interfaces, you can set the required link speed for all interfaces included in the bundle. Generally, all interfaces that make up a bundle must have the same speed. If you include in the aggregated Ethernet interface an individual link that has a speed different from the speed that you specify in the link-speed parameter, an error message is logged. However, there are exceptions.

Starting with Junos OS Release 13.2, aggregated Ethernet supports mixed rates and mixed modes on T640, T1600, T4000, and TX Matrix Plus routers. For example, these mixes are supported:

  • Member links of different modes (WAN and LAN) for 10-Gigabit Ethernet links.

  • Member links of different rates: 10-Gigabit Ethernet, 40-Gigabit Ethernet, 50-Gigabit Ethernet, 100-Gigabit Ethernet, and OC192 (10-Gigabit Ethernet WAN mode)

Starting with Junos OS Release 14.1R1 and 14.2, support for mixed rates on aggregated Ethernet bundles is extended to MX240, MX480, MX960, MX2010, and MX2020 routers.

Starting with Junos OS Release 14.2, aggregated Ethernet supports mixed link speeds on PTX Series Packet Transport Routers.

Note
  • Member links of 50-Gigabit Ethernet can only be configured using the 50-Gigabit Ethernet interfaces of 100-Gigabit Ethernet PIC with CFP (PD-1CE-CFP-FPC4).

  • Starting with Junos OS Release 13.2, 100-Gigabit Ethernet member links can be configured using the two 50-Gigabit Ethernet interfaces of 100-Gigabit Ethernet PIC with CFP. This 100-Gigabit Ethernet member link can be included in an aggregated Ethernet link that includes member links of other interfaces as well. In releases before Junos OS Release 13.2, the 100-Gigabit Ethernet member link configured using the two 50-Gigabit Ethernet interfaces of 100-Gigabit Ethernet PIC with CFP cannot be included in an aggregated Ethernet link that includes member links of other interfaces.

To configure member links of mixed rates and mixed modes on T640, T1600, T4000, TX Matrix Plus, and PTX routers, you need to configure the mixed option for the [edit interfaces aex aggregated-ether-options link-speed] statement.

To set the required link speed:

  1. Specify that you want to configure the aggregated Ethernet options.
  2. Configure the link speed.

    speed can be in bits per second either as a complete decimal number or as a decimal number followed by the abbreviation k (1000), m (1,000,000), or g (1,000,000,000).

    Aggregated Ethernet interfaces on the M120 router can have one of the following speeds:

    • 100m—Links are 100 Mbps.

    • 10g—Links are 10 Gbps.

    • 1g—Links are 1 Gbps.

    • oc192—Links are OC192 or STM64c.

    Aggregated Ethernet links on EX Series switches can be configured to operate at one of the following speeds:

    • 10m—Links are 10 Mbps.

    • 100m—Links are 100 Mbps.

    • 1g—Links are 1 Gbps.

    • 10g—Links are 10 Gbps.

    • 50g—Links are 50 Gbps.

    Aggregated Ethernet links on T Series, MX Series, PTX Series routers, and QFX5100, QFX10002, QFX10008, and QFX10016 switches can be configured to operate at one of the following speeds:

    • 100g—Links are 100 Gbps.

    • 100m—Links are 100 Mbps.

    • 10g—Links are 10 Gbps.

    • 1g—Links are 1 Gbps.

    • 40g—Links are 40 Gbps.

    • 50g—Links are 50 Gbps.

    • 80g—Links are 80 Gbps.

    • 8g—Links are 8 Gbps.

    • mixed—Links are of various speeds.

    • oc192—Links are OC192.

Configuring Periodic Rebalancing of Subscribers in an Aggregated Ethernet Interface

If subscribers are frequently logging in and logging out of your network, you can configure the system to periodically rebalance the links based on a specific time and interval.

To configure periodic rebalancing:

  1. Access the aggregated Ethernet interface for which you want to configure periodic rebalancing.
  2. Configure the rebalancing parameters for the interface, including the time and the interval between rebalancing actions.

EX Series switches allow you to combine multiple Ethernet links into one logical interface for higher bandwidth and redundancy. The ports that are combined in this manner are referred to as a link aggregation group (LAG) or bundle. The number of Ethernet links you can combine into a LAG depends on your EX Series switch model.

This example describes how to configure uplink LAGs to connect a Virtual Chassis access switch to a Virtual Chassis distribution switch:

Requirements

This example uses the following software and hardware components:

  • Junos OS Release 9.0 or later for EX Series switches

  • Two EX4200-48P switches

  • Two EX4200-24F switches

  • Four XFP uplink modules

Before you configure the LAGs, be sure you have:

Overview and Topology

For maximum speed and resiliency, you can combine uplinks between an access switch and a distribution switch into LAGs. Using LAGs can be particularly effective when connecting a multimember Virtual Chassis access switch to a multimember Virtual Chassis distribution switch.

The Virtual Chassis access switch in this example is composed of two member switches. Each member switch has an uplink module with two 10-Gigabit Ethernet ports. These ports are configured as trunk ports, connecting the access switch with the distribution switch.

Configuring the uplinks as LAGs has the following advantages:

  • Link Aggregation Control Protocol (LACP) can optionally be configured for link negotiation.

  • It doubles the speed of each uplink from 10 Gbps to 20 Gbps.

  • If one physical port is lost for any reason (a cable is unplugged or a switch port fails, or one member switch is unavailable), the logical port transparently continues to function over the remaining physical port.

The topology used in this example consists of one Virtual Chassis access switch and one Virtual Chassis distribution switch. The access switch is composed of two EX4200-48P switches (SWA-0 and SWA-1), interconnected to each other with their Virtual Chassis ports (VCPs) as member switches of Host-A. The distribution switch is composed of two EX4200-24F switches (SWD-0 and SWD-1), interconnected with their VCPs as member switches of Host-D.

Each member of the access switch has an uplink module installed. Each uplink module has two ports. The uplinks are configured to act as trunk ports, connecting the access switch with the distribution switch. One uplink port from SWA-0 and one uplink port from SWA-1 are combined as LAG ae0 to SWD-0. This link is used for one VLAN. The remaining uplink ports from SWA-0 and from SWA-1 are combined as a second LAG connection (ae1) to SWD-1. LAG ae1 is used for another VLAN.

Note

If the remote end of the LAG link is a security device, LACP might not be supported because security devices require a deterministic configuration. In this case, do not configure LACP. All links in the LAG are permanently operational unless the switch detects a link failure within the Ethernet physical layer or data link layers.

Figure 3: Topology for LAGs Connecting an EX4200 Virtual Chassis Access Switch to an EX4200 Virtual Chassis Distribution Switch
Topology for LAGs Connecting an EX4200 Virtual Chassis
Access Switch to an EX4200 Virtual Chassis Distribution Switch

Table 2 details the topology used in this configuration example.

Table 2: Components of the Topology for Connecting a Virtual Chassis Access Switch to a Virtual Chassis Distribution Switch

SwitchHostname and VCIDBase HardwareUplink ModuleMember IDTrunk Port

SWA-0

Host-A Access switch

VCID 1

EX4200-48P switch

One XFP uplink module

0

xe-0/1/0 to SWD-0

xe-0/1/1 to SWD-1

SWA-1

Host-A Access switch

VCID 1

EX4200-48P switch

One XFP uplink module

1

xe-1/1/0 to SWD-0

xe-1/1/1 to SWD-1

SWD-0

Host-D Distribution switch

VCID 4

EX4200 L-24F switch

One XFP uplink module

0

xe-0/1/0 to SWA-0

xe-0/1/1 to SWA-1

SWD-1

Host-D Distribution switch

VCID 4

EX4200 L-24F switch

One XFP uplink module

1

xe-1/1/0 to SWA-0

xe-1/1/1 to SWA-1

Configuration

To configure two uplink LAGs from the Virtual Chassis access switch to the Virtual Chassis distribution switch:

CLI Quick Configuration

To quickly configure aggregated Ethernet high-speed uplinks between a Virtual Chassis access switch and a Virtual Chassis distribution switch, copy the following commands and paste them into the switch terminal window:

[edit]

set chassis aggregated-devices ethernet device-count 2

set interfaces ae0 aggregated-ether-options minimum-links 1

set interfaces ae0 aggregated-ether-options link-speed 10g

set interfaces ae1 aggregated-ether-options minimum-links 1

set interfaces ae1 aggregated-ether-options link-speed 10g

set interfaces ae0 unit 0 family inet address 192.0.2.0/25

set interfaces ae1 unit 0 family inet address 192.0.2.128/25

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-0/1/1 ether-options 802.3ad ae1

set interfaces xe-1/1/1 ether-options 802.3ad ae1

Step-by-Step Procedure

To configure aggregated Ethernet high-speed uplinks between a Virtual Chassis access switch and a Virtual Chassis distribution switch:

  1. Specify the number of LAGs to be created on the chassis:
    [edit chassis]

    user@Host-A# set aggregated-devices ethernet device-count 2
  2. Specify the number of links that need to be present for the ae0 LAG interface to be up:
    [edit interfaces]

    user@Host-A# set ae0 aggregated-ether-options minimum-links 1
  3. Specify the number of links that need to be present for the ae1 LAG interface to be up:
    [edit interfaces]

    user@Host-A# set ae1 aggregated-ether-options minimum-links 1
  4. Specify the media speed of the ae0 link:
    [edit interfaces]

    user@Host-A# set ae0 aggregated-ether-options link-speed 10g
  5. Specify the media speed of the ae1 link:
    [edit interfaces]

    user@Host-A# set ae1 aggregated-ether-options link-speed 10g
  6. Specify the interface ID of the uplinks to be included in LAG ae0:
    [edit interfaces]

    user@Host-A# set xe-0/1/0 ether-options 802.3ad ae0

    user@Host-A# set xe-1/1/0 ether-options 802.3ad ae0
  7. Specify the interface ID of the uplinks to be included in LAG ae1:
    [edit interfaces]

    user@Host-A# set xe-0/1/1 ether-options 802.3ad ae1

    user@Host-A# set xe-1/1/1 ether-options 802.3ad ae1
  8. Specify that LAG ae0 belongs to the subnet for the employee broadcast domain:
    [edit interfaces]

    user@Host-A# set ae0 unit 0 family inet address 192.0.2.0/25

  9. Specify that LAG ae1 belongs to the subnet for the guest broadcast domain:
    [edit interfaces]

    user@Host-A# set ae1 unit 0 family inet address 192.0.2.128/25

Results

Display the results of the configuration:

Verification

To verify that switching is operational and two LAGs have been created, perform these tasks:

Verifying That LAG ae0 Has Been Created

Purpose

Verify that LAG ae0 has been created on the switch.

Action

show interfaces ae0 terse

Meaning

The output confirms that the ae0 link is up and shows the family and IP address assigned to this link.

Verifying That LAG ae1 Has Been Created

Purpose

Verify that LAG ae1 has been created on the switch

Action

show interfaces ae1 terse

Meaning

The output shows that the ae1 link is down.

Troubleshooting

Troubleshooting a LAG That Is Down

Problem

The show interfaces terse command shows that the LAG is down

Solution

Check the following:

  • Verify that there is no configuration mismatch.

  • Verify that all member ports are up.

  • Verify that a LAG is part of family ethernet switching (Layer 2 LAG) or family inet (Layer 3 LAG).

  • Verify that the LAG member is connected to the correct LAG at the other end.

  • Verify that the LAG members belong to the same switch (or the same Virtual Chassis).

A QFX Series product allows you to combine multiple Ethernet links into one logical interface for higher bandwidth and redundancy. The ports that are combined in this manner are referred to as a link aggregation group (LAG) or bundle. The number of Ethernet links you can combine into a LAG depends on your QFX Series product model. You can configure LAGs to connect a QFX Series product or an EX4600 switch to other switches, like aggregation switches, servers, or routers. This example describes how to configure LAGs to connect a QFX3500, QFX3600, EX4600, QFX5100, and QFX10002 switch to an aggregation switch.

Requirements

This example uses the following software and hardware components:

  • Junos OS Release 11.1 or later for the QFX3500 and QFX3600 switches, Junos OS 13.2 or later for the QFX5100 and EX4600 switch, and Junos OS Release 15.1X53-D10 or later for QFX10002 switches.

  • One QFX3500, QFX3600, EX4600, QFX5100, or QFX10002 switch.

Overview and Topology

In this example, the switch has one LAG comprising two 10-Gigabit Ethernet interfaces. This LAG is configured in port-mode trunk (or interface-mode trunk) so that the switch and the VLAN to which it has been assigned can send and receive traffic.

Configuring the Ethernet interfaces as LAGs has the following advantages:

  • If one physical port is lost for any reason (a cable is unplugged or a switch port fails), the logical port transparently continues to function over the remaining physical port.

  • Link Aggregation Control Protocol (LACP) can optionally be configured for link monitoring and automatic addition and deletion of individual links without user intervention.

Note

If the remote end of the LAG link is a security device, LACP might not be supported because security devices require a deterministic configuration. In this case, do not configure LACP. All links in the LAG are permanently operational unless the switch detects a link failure within the Ethernet physical layer or data link layers.

The topology used in this example consists of one switch with a LAG configured between two of its 10-Gigabit Ethernet interfaces. The switch is connected to an aggregation switch.

Table 3 details the topology used in this configuration example.

Table 3: Components of the Topology for Configuring a LAG Between a Switch and an Aggregation Switch

HostnameBase HardwareTrunk Port

switch

QFX3500, QFX3600, EX4600, QFX5100, or QFX10002 switch

ae0 is configured as a trunk port and combines the following two interfaces:

xe-0/0/2 and

xe-0/0/3

.

Configuration

To configure a LAG between two 10-Gigabit Ethernet interfaces:

CLI Quick Configuration

To quickly configure a LAG between two 10-Gigabit Ethernet interfaces on a switch, copy the following commands and paste them into the switch terminal window:

Note

If you are configuring a LAG using Enhanced Layer 2 Software—for example, on the EX4600, QFX5100, or QFX10002 switch—use the interface-mode statement instead of the port-mode statement. For ELS details, see Using the Enhanced Layer 2 Software CLI.

[edit]

set chassis aggregated-devices ethernet device-count 1

set interfaces ae0 aggregated-ether-options minimum-links 1

set interfaces ae0 aggregated-ether-options link-speed 10g

set interfaces ae0 unit 0 family ethernet-switching vlan members green

set interfaces xe-0/0/2 ether-options 802.3ad ae0

set interfaces xe-0/0/3 ether-options 802.3ad ae0

set interfaces ae0 unit 0 family ethernet-switching port-mode trunk

set interfaces ae0 aggregated-ether-options lacp active

set interfaces ae0 aggregated-ether-options lacp periodic fast

Step-by-Step Procedure

To configure a LAG between a QFX Series switch and an aggregation switch:

  1. Specify the number of LAGs to be created on the switch:
    [edit chassis]

    user@switch# set aggregated-devices ethernet device-count 1
  2. Specify the number of links that need to be present for the ae0 LAG interface to be up:
    [edit interfaces]

    user@switch# set ae0 aggregated-ether-options minimum-links 1
  3. Specify the media speed of the ae0 link:
    [edit interfaces]

    user@switch# set ae0 aggregated-ether-options link-speed 10g
  4. Specify the members to be included within the aggregated Ethernet bundle:
    [edit interfaces]

    user@switch# set interfaces xe-0/0/2 ether-options 802.3ad ae0

    [edit interfaces]

    user@switch# set interfaces xe-0/0/3 ether-options 802.3ad ae0

  5. Assign a port mode of trunk to the ae0 link:Note

    If you are configuring a LAG using Enhanced Layer 2 Software—for example, on the EX4600, QFX5100, or QFX10002 switch—use the interface-mode statement instead of the port-mode statement. For ELS details, see Using the Enhanced Layer 2 Software CLI.

    [edit interfaces]

    user@switch# set ae0 unit 0 family ethernet-switching port-mode trunk

    or

    [edit interfaces]

    user@switch# set ae0 unit 0 family ethernet-switching interface-mode trunk
  6. Assign the LAG to a VLAN:
    [edit interfaces]

    user@switch# set ae0 unit 0 family ethernet-switching vlan members green vlan-id 200
  7. (Optional): Designate one side of the LAG as active for LACP:
    [edit interfaces]

    user@switch# set ae0 aggregated-ether-options lacp active
  8. (Optional): Designate the interval and speed at which the interfaces send LACP packets:
    [edit interfaces]

    user@switch# set ae0 aggregated-ether-options lacp periodic fast

Results

Display the results of the configuration on a QFX3500 or QFX3600 switch:

Verification

To verify that switching is operational and one LAG has been created, perform these tasks:

Verifying That LAG ae0.0 Has Been Created

Purpose

Verify that LAG ae0.0 has been created on the switch.

Action

show interfaces ae0 terse

Meaning

The output confirms that the ae0.0 link is up and shows the family and IP address assigned to this link.

Verifying That LAG ae0 Has Been Created

Purpose

Verify that LAG ae0 has been created on the switch

Action

show interfaces ae0 terse

Meaning

The output shows that the ae0.0 link is down.

Troubleshooting

Troubleshooting a LAG That Is Down

Problem

The show interfaces terse command shows that the LAG is down.

Solution

Check the following:

  • Verify that there is no configuration mismatch.

  • Verify that all member ports are up.

  • Verify that a LAG is part of family ethernet switching (Layer 2 LAG) or family inet (Layer 3 LAG).

  • Verify that the LAG member is connected to the correct LAG at the other end.

Configuring Aggregated Ethernet LACP

For aggregated Ethernet interfaces, you can configure the Link Aggregation Control Protocol (LACP). LACP is one method of bundling several physical interfaces to form one logical interface. You can configure both VLAN-tagged and untagged aggregated Ethernet with or without LACP enabled.

For Multichassis Link Aggregation (MC-LAG), you must specify the system-id and admin key. MC-LAG peers use the same system-id while sending the LACP messages. The system-id can be configured on the MC-LAG network device and synchronized between peers for validation.

LACP exchanges are made between actors and partners. An actor is the local interface in an LACP exchange. A partner is the remote interface in an LACP exchange.

LACP is defined in IEEE 802.3ad, Aggregation of Multiple Link Segments.

LACP was designed to achieve the following:

  • Automatic addition and deletion of individual links to the aggregate bundle without user intervention

  • Link monitoring to check whether both ends of the bundle are connected to the correct group

The Junos OS implementation of LACP provides link monitoring but not automatic addition and deletion of links.

The LACP mode can be active or passive. If the actor and partner are both in passive mode, they do not exchange LACP packets, which results in the aggregated Ethernet links not coming up. If either the actor or partner is active, they do exchange LACP packets. By default, LACP is turned off on aggregated Ethernet interfaces. If LACP is configured, it is in passive mode by default. To initiate transmission of LACP packets and response to LACP packets, you must configure LACP in active mode.

To enable LACP active mode, include the lacp statement at the [edit interfaces interface-name aggregated-ether-options] hierarchy level, and specify the active option:

Note

The LACP process exists in the system only if you configure the system in either active or passive LACP mode.

To restore the default behavior, include the lacp statement at the [edit interfaces interface-name aggregated-ether-options] hierarchy level, and specify the passive option:

Starting with Junos OS release 12.2, you can also configure LACP to override the IEEE 802.3ad standard and to allow the standby link always to receive traffic. Overriding the default behavior facilitates subsecond failover.

To override the IEEE 802.3ad standard and facilitate subsecond failover, include the fast-failover statement at the [edit interfaces interface-name aggregated-ether-options lacp] hierarchy level.

For more information, see the following sections:

Configuring the LACP Interval

By default, the actor and partner send LACP packets every second. You can configure the interval at which the interfaces send LACP packets by including the periodic statement at the [edit interfaces interface-name aggregated-ether-options lacp] hierarchy level:

The interval can be fast (every second) or slow (every 30 seconds). You can configure different periodic rates on active and passive interfaces. When you configure the active and passive interfaces at different rates, the transmitter honors the receiver’s rate.

Note

Source address filtering does not work when LACP is enabled.

Percentage policers are not supported on aggregated Ethernet interfaces with the CCC protocol family configured. For more information about percentage policers, see the Routing Policies, Firewall Filters, and Traffic Policers Feature Guide.

Generally, LACP is supported on all untagged aggregated Ethernet interfaces. For more information, see Configuring Untagged Aggregated Ethernet Interfaces.

Note

When using LACP link protection, you can configure only two member links to an aggregated Ethernet interface: one active and one standby.

To force active and standby links within an aggregated Ethernet, you can configure LACP link protection and system priority at the aggregated Ethernet interface level using the link-protection and system-priority statements. Configuring values at this level results in only the configured interfaces using the defined configuration. LACP interface configuration also enables you to override global (chassis) LACP settings.

LACP link protection also uses port priority. You can configure port priority at the Ethernet interface [ether-options] hierarchy level using the port-priority statement. If you choose not to configure port priority, LACP link protection uses the default value for port priority (127).

Note

LACP link protection supports per-unit scheduling configuration on aggregated Ethernet interfaces.

To enable LACP link protection for an aggregated Ethernet interfaces, use the link-protection statement at the [edit interfaces aeX aggregated-ether-options lacp] hierarchy level:

By default, LACP link protection reverts to a higher-priority (lower-numbered) link when that higher-priority link becomes operational or a link is added to the aggregator that is determined to be higher in priority. However, you can suppress link calculation by adding the non-revertive statement to the LACP link protection configuration. In nonrevertive mode, once a link is active and collecting and distributing packets, the subsequent addition of a higher-priority (better) link does not result in a switch and the current link remains active.

If LACP link protection is configured to be nonrevertive at the global ([edit chassis] hierarchy) level, you can add the revertive statement to the LACP link protection configuration to override the nonrevertive setting for the interface. In revertive mode, the addition of a higher-priority link to the aggregator results in LACP performing a priority recalculation and switching from the current active link to the new active link.

Caution

If both ends of an aggregator have LACP link protection enabled, make sure to configure both ends of the aggregator to use the same mode. Mismatching LACP link protection modes can result in lost traffic.

We strongly recommend you to use LACP on both ends of the aggregator, when you connect an aggregated Ethernet interface with two member interfaces to any other vendor device. Otherwise, the vendor device (say a Layer 2 switch, or a router), will not be able to manage the traffic coming from the two link aggregated Ethernet bundle. As a result, you might observe the vendor device sending back the traffic to the backup member link of the aggregated Ethernet interface.

Currently, MX-MPC2-3D, MX-MPC2-3D-Q, MX-MPC2-3D-EQ, MX-MPC1-3D, MX-MPC1-3D-Q, and MPC-3D-16XGE-SFPP do not drop traffic coming back to the backup link, whereas DPCE-R-Q-20GE-2XGE, DPCE-R-Q-20GE-SFP, DPCE-R-Q-40GE-SFP, DPCE-R-Q-4XGE-XFP, DPCE-X-Q-40GE-SFP, and DPCE-X-Q-4XGE-XFP drop traffic coming to the backup link.

Configuring LACP System Priority

To configure LACP system priority for aggregated Ethernet interfaces on the interface, use the system-priority statement at the [edit interfaces aeX aggregated-ether-options lacp] hierarchy level:

The system priority is a 2-octet binary value that is part of the LACP system ID. The LACP system ID consists of the system priority as the two most-significant octets and the interface MAC address as the six least-significant octets. The system with the numerically lower value for system priority has the higher priority. By default, system priority is 127, with a range of 0 to 65,535.

Configuring LACP System Identifier

To configure the LACP system identifier for aggregated Ethernet interfaces, use the system-id statement at the [edit interfaces aeX aggregated-ether-options lacp] hierarchy level:

The user-defined system identifier in LACP enables two ports from two separate devices to act as though they were part of the same aggregate group.

The system identifier is a 48-bit (6-byte) globally unique field. It is used in combination with a 16-bit system-priority value, which results in a unique LACP system identifier.

Configuring LACP administrative Key

To configure an administrative key for LACP, include the admin-key number statement at the edit interfaces aex aggregated-ether-options lacp] hierarchy level:

Note

You must configure MC-LAG to configure the admin-key statement. For more information about MC-LAG, see Configuring Multichassis Link Aggregation on MX Series Routers.

Configuring LACP Port Priority

To configure LACP port priority for aggregated Ethernet interfaces, use the port-priority statement at the [edit interfaces interface-name ether-options 802.3ad aeX lacp] or [edit interfaces interface-name ether-options 802.3ad aeX lacp] hierarchy levels:

The port priority is a 2-octet field that is part of the LACP port ID. The LACP port ID consists of the port priority as the two most-significant octets and the port number as the two least-significant octets. The system with the numerically lower value for port priority has the higher priority. By default, port priority is 127, with a range of 0 to 65,535.

Port aggregation selection is made by each system based on the highest port priority and are assigned by the system with the highest priority. Ports are selected and assigned starting with the highest priority port of the highest priority system and working down in priority from there.

Note

Port aggregation selection (discussed above) is performed for the active link when LACP link protection is enabled. Without LACP link protection, port priority is not used in port aggregation selection.

Tracing LACP Operations

To trace the operations of the LACP process, include the traceoptions statement at the [edit protocols lacp] hierarchy level:

You can specify the following flags in the protocols lacp traceoptions statement:

  • all—All LACP tracing operations

  • configuration—Configuration code

  • packet—Packets sent and received

  • process—LACP process events

  • protocol—LACP protocol state machine

  • routing-socket—Routing socket events

  • startup—Process startup events

For general information about tracing, see the tracing and logging information in the Junos OS Administration Library.

LACP Limitations

LACP can link together multiple different physical interfaces, but only features that are supported across all of the linked devices will be supported in the resulting link aggregation group (LAG) bundle. For example, different PICs can support a different number of forwarding classes. If you use link aggregation to link together the ports of a PIC that supports up to 16 forwarding classes with a PIC that supports up to 8 forwarding classes, the resulting LAG bundle will only support up to 8 forwarding classes. Similarly, linking together a PIC that supports WRED with a PIC that does not support it will result in a LAG bundle that does not support WRED.

Example: Configuring Aggregated Ethernet LACP

Configure aggregated Ethernet LACP over a VLAN-tagged interface:

LACP with VLAN-Tagged Aggregated Ethernet

Configure aggregated Ethernet LACP over an untagged interface:

LACP with Untagged Aggregated Ethernet

You can configure LACP link protection and system priority at the global level on the switch or for a specific aggregated Ethernet interface. When using LACP link protection to protect a single link in the aggregated ethernet bundle, you configure only two member links for an aggregated Ethernet interface: one active and one standby. LACP link protection ensures that only one link—the link with the higher priority—is used for traffic. The other link is forced to stay in a waiting state.

When using LACP link protection to protect multiple links in an aggregated ethernet bundle, you configure links into primary and backup subgroups. A link protection subgroup is a collection of ethernet links within the aggregated ethernet bundle. When you use link protection subgroups, you configure a primary subgroup and a backup subgroup. The configuration process includes assigning member links to each subgroup. When the configuration process is complete, the primary subgroup is used to forward traffic until a switchover event, such as a link failure, occurs and causes the backup subgroup to assume control of traffic that was travelling on the links in the primary subgroup within the bundle.

By default LACP link protection reverts to a higher-priority (lower-numbered) link when the higher-priority link becomes operational or when a higher-priority link is added to the aggregated Ethernet bundle. For priority purposes, LACP link protection treats subgroups like links. You can suppress link calculation by adding the non-revertive statement to the link protection configuration. In nonrevertive mode, when a link is active in sending and receiving LACP packets, adding a higher-priority link to the bundle does not change the status of the currently active link. It remains active.

If LACP link configuration is specified to be nonrevertive at the global [edit chassis] hierarchy level, you can specify the revertive statement in the LACP link protection configuration at the aggregated Ethernet interface level to override the nonrevertive setting for the interface. In revertive mode, adding a higher-priority link to the aggregated Ethernet bundle results in LACP recalculating the priority and switching the status from the currently active link to the newly added, higher-priority link.

Note

When LACP link protection is enabled on both local and remote sides of the link, both sides must use the same mode (either revertive or nonrevertive).

Configuring LACP link configuration at the aggregated Ethernet level results in only the configured interfaces using the defined configuration. LACP interface configuration also enables you to override global (chassis) LACP settings.

Before you configure LACP link protection, be sure you have:

You can configure LACP link protection for all aggregated Ethernet interfaces on the switch by enabling it at the global level on the switch or configure it for a specific aggregated Ethernet interface by enabling it on that interface.

To configure LACP link protection for aggregated Ethernet interfaces at the global level:

  1. Enable LACP link protection on the switch:
    [edit chassis aggregated-devices ethernet lacp]

    user@switch# set link-protection
  2. (Optional) Configure the LACP link protection for the aggregated Ethernet interfaces to be in nonrevertive mode:Note

    LACP link protection is in revertive mode by default.

    [edit chassis aggregated-devices ethernet lacp link-protection]

    user@switch# set non-revertive
  3. (Optional)To configure LACP system priority for the aggregated Ethernet interfaces:
    [edit chassis aggregated-devices ethernet lacp]

    user@switch# set system-priority

To enable LACP link protection for a specific aggregated Ethernet interface:

  1. Enable LACP link protection for the interface:
    [edit interfaces aeX aggregated-ether-options lacp]

    user@switch# set link-protection
  2. (Optional) Configure the LACP link protection for the aggregated Ethernet interface to be in revertive or nonrevertive mode:
  3. (Optional)To configure LACP system priority for an aggregated Ethernet interface:
    [edit interfaces aeX aggregated-ether-options lacp link-protection]

    user@switch# set system-priority
  4. (Optional) To configure LACP port priority for an aggregated Ethernet interface:
    [edit interfaces ge-fpc/pic/port ether-options 802.3ad lacp]

    user@switch# set port-priority

You can configure link protection subgroup bundles to provide link protection for multiple links in an aggregated ethernet bundle.

Link protection subgroups allow you to provide link protection to a collection of Ethernet links within a LAG bundle, instead of providing protection to a single link in the aggregated ethernet bundle only. You can, for instance, configure a primary subgroup with three member links and a backup subgroup with three different member links and use the backup subgroup to provide link protection for the primary subgroup.

To configure link protection using subgroups:

  1. Configure the primary link protection subgroup in the aggregated ethernet interface:
    [edit interfaces aeX aggregated-ether-options]

    user@switch# set link-protection-sub-group group-name primary

    For instance, to create a primary link protection subgroup named subgroup-primary for interface ae0:

    [edit interfaces ae0 aggregated-ether-options]

    user@switch# set link-protection-sub-group subgroup-primary primary
  2. Configure the backup link protection subgroup in the aggregated ethernet interface:
    [edit interfaces aeX aggregated-ether-options]

    user@switch# set link-protection-sub-group group-name backup

    For instance, to create a backup link protection subgroup named subgroup-backup for interface ae0:

    [edit interfaces ae0 aggregated-ether-options]

    user@switch# set link-protection-sub-group subgroup-backup backup
    Note

    You can create one primary and one backup link protection subgroup per aggregated ethernet interface.

  3. Attach interfaces to the link protection subgroups:
    [edit interfaces interface-name ether-options 802.3ad]

    user@switch# set link-protection-sub-group group-name
    Note

    The primary and backup link protection subgroups must contain the same number of interfaces. For instance, if the primary link protection subgroup contains three interfaces, the backup link protection subgroup must also contain three interfaces.

    For instance, to configure interfaces ge-0/0/0 and ge-0/0/1 into link protection subgroup subgroup-primary and interfaces ge-0/0/2 and ge-0/0/3 into link protection subgroup subgroup-backup:

    [edit interfaces ge-0/0/0 ether-options 802.3ad]

    user@switch# set link-protection-sub-group subgroup-primary


    [edit interfaces ge-0/0/1 ether-options 802.3ad]

    user@switch# set link-protection-sub-group subgroup-primary


    [edit interfaces ge-0/0/2 ether-options 802.3ad]

    user@switch# set link-protection-sub-group subgroup-backup


    [edit interfaces ge-0/0/3 ether-options 802.3ad]

    user@switch# set link-protection-sub-group subgroup-backup
  4. (Optional) Configure the port priority for link protection:
    [edit interfaces interface-name ether-options 802.3ad]

    user@switch# set port-priority priority

    The port priority is used to select the active link.

  5. Enable link protection

    To enable link protection at the LAG level:

    [edit interfaces aeX aggregated-ether-options]

    user@switch# set link-protection
    Note

    ACX Series routers do not support static link protection.

    To enable link protection at the LACP level:

    [edit interfaces aeX aggregated-ether-options lacp]

    user@switch# set link-protection

    For instance, to enable link protection on ae0 at the LAG level:

    [edit interfaces ae0 aggregated-ether-options]

    user@switch# set link-protection

    For instance, to enable link protection on ae0 at the LACP level:

    [edit interfaces ae0 aggregated-ether-options lacp]

    user@switch# set link-protection
Note

The LACP decides active and back up state of links. When configuring LACP, the state of the backup link should not be configured manually as down. The following command is not supported if LACP is configured:set interfaces ae0 aggregated-ether-options link-protection backup-state down

On link aggregation group (LAG) interfaces, when a member (child) link goes down, its state changes from current to expired. This link might flap from the current state to the expired state and back to current state when it receives intermittent LACP protocol data units (PDUs) and keepalive timeouts. Such flapping can adversely affect the traffic on the link.

To prevent excessive flapping of a LAG child link, you can configure a hold-up timer on the LAG interface that is applicable to all member links on that particular interface. To hold up, in networking terms, means to prevent the transitioning of an interface from down to up for a specified time interval.

When configured, the hold-up timer is triggered when an LACP state machine tries to move to the current state from the expired or default state when it receives an LACP PDU. The hold-up timer is triggered only if the LACP state machine had acquired the current state at least once earlier. The timer is not triggered if LACP attempts to transition to the current state for the first time. LACP monitors the PDUs received on the child link but prevents the link from transitioning to current state. If no flapping is observed when the link receives the PDUs, the hold-up timer expiries and triggers the member link to transition back to the current state. This transition is triggered as soon as the hold-up timer expires and not necessarily when the link receives a PDU.

To configure LACP hold-up timer for LAG interface, use the hold-time up statement at the [edit interfaces aex aggregated-ether-options lacp] hierarchy level.

Note
  • The hold-up timer keeps running even when the interface that receives the LACP PDU moves to the port disable state. The timer is then restarted if, before the timer expires, the interface comes up again and receives an LACP PDU from its neighbor. This ensures that the timer is maintained even during a quick physical port flap.

  • When the following events occur, a hold-up timer is not triggered until the member link acquires the current state after the event:

    • LACP daemon restart

    • Deactivation and reactivation of child or aggregated Ethernet interface

    • Deletion and reconfiguration of child or aggregated Ethernet interface

    • System reboot

    • Routing Engine switchover

Verifying That LACP Is Configured Correctly and Bundle Members Are Exchanging LACP Protocol Packets

Verify that LACP has been set up correctly and that the bundle members are transmitting LACP protocol packets.

  1. Verifying the LACP Setup

  2. Verifying That LACP Packets Are Being Exchanged

Verifying the LACP Setup

Purpose

Verify that the LACP has been set up correctly.

Action

To verify that LACP has been enabled as active on one end:

user@switch>show lacp interfaces xe-0/0/0

Meaning

This example shows that LACP has been configured with one side as active and the other as passive. When LACP is enabled, one side must be set as active in order for the bundled link to be up.

Verifying That LACP Packets Are Being Exchanged

Purpose

Verify that LACP packets are being exchanged between interfaces.

Action

Use the show lacp statistics interfaces interface-name command to display LACP BPDU exchange information.

show lacp statistics interfaces ae0

Meaning

The output here shows that the link is up and that PDUs are being exchanged.

EX Series switches allow you to combine multiple Ethernet links into one logical interface for higher bandwidth and redundancy. The ports that are combined in this manner are referred to as a link aggregation group (LAG) or bundle. EX Series switches allow you to further enhance these links by configuring Link Aggregation Control Protocol (LACP).

This example describes how to overlay LACP on the LAG configurations that were created in Example: Configuring Aggregated Ethernet High-Speed Uplinks Between an EX4200 Virtual Chassis Access Switch and an EX4200 Virtual Chassis Distribution Switch:

Requirements

This example uses the following software and hardware components:

  • Junos OS Release 9.0 or later for EX Series switches

  • Two EX4200-48P switches

  • Two EX4200-24F switches

  • Four EX Series XFP uplink modules

Before you configure LACP, be sure you have:

Overview and Topology

This example assumes that you are familiar with Example: Configuring Aggregated Ethernet High-Speed Uplinks Between an EX4200 Virtual Chassis Access Switch and an EX4200 Virtual Chassis Distribution Switch. The topology in this example is exactly the same as the topology in that other example. This example shows how to use LACP to enhance the LAG functionality.

LACP exchanges are made between actors (the transmitting link) and partners (the receiving link). The LACP mode can be either active or passive.

Note

If the actor and partner are both in passive mode, they do not exchange LACP packets, which results in the aggregated Ethernet links not coming up. By default, LACP is in passive mode. To initiate transmission of LACP packets and responses to LACP packets, you must enable LACP in active mode.

By default, the actor and partner send LACP packets every second.

The interval can be fast (every second) or slow (every 30 seconds).

Configuring LACP for the LAGs on the Virtual Chassis Access Switch

To configure LACP for the access switch LAGs, perform these tasks:

CLI Quick Configuration

To quickly configure LACP for the access switch LAGs, copy the following commands and paste them into the switch terminal window:

[edit]

set interfaces ae0 aggregated-ether-options lacp active periodic fast


set interfaces ae1 aggregated-ether-options lacp active periodic fast

Step-by-Step Procedure

To configure LACP for Host-A LAGs ae0 and ae1:

  1. Specify the aggregated Ethernet options for both bundles:
    [edit interfaces]

    user@Host-A#set ae0 aggregated-ether-options lacp active periodic fast

    user@Host-A#set ae1 aggregated-ether-options lacp active periodic fast

Results

Display the results of the configuration:

Configuring LACP for the LAGs on the Virtual Chassis Distribution Switch

To configure LACP for the two uplink LAGs from the Virtual Chassis access switch to the Virtual Chassis distribution switch, perform these tasks:

CLI Quick Configuration

To quickly configure LACP for the distribution switch LAGs, copy the following commands and paste them into the switch terminal window:

[edit interfaces]

set ae0 aggregated-ether-options lacp passive periodic fast

set ae1 aggregated-ether-options lacp passive periodic fast

Step-by-Step Procedure

To configure LACP for Host D LAGs ae0 and ae1:

  1. Specify the aggregated Ethernet options for both bundles:
    [edit interfaces]

    user@Host-D#set ae0 aggregated-ether-options lacp passive periodic fast

    user@Host-D#set ae1 aggregated-ether-options lacp passive periodic fast

Results

Display the results of the configuration:

Verification

To verify that LACP packets are being exchanged, perform these tasks:

Verifying the LACP Settings

Purpose

Verify that LACP has been set up correctly.

Action

Use the show lacp interfaces interface-name command to check that LACP has been enabled as active on one end.

user@Host-A> show lacp interfaces xe-0/1/0

Meaning

The output indicates that LACP has been set up correctly and is active at one end.

Verifying That the LACP Packets Are Being Exchanged

Purpose

Verify that LACP packets are being exchanged.

Action

Use the show interfaces aex statistics command to display LACP information.

user@Host-A> show interfaces ae0 statistics

Meaning

The output here shows that the link is down and that no protocol data units (PDUs) are being exchanged.

Troubleshooting

To troubleshoot a nonworking LACP link, perform these tasks:

Troubleshooting a Nonworking LACP Link

Problem

The LACP link is not working.

Solution

Check the following:

  • Remove the LACP configuration and verify whether the static LAG is up.

  • Verify that LACP is configured at both ends.

  • Verify that LACP is not passive at both ends.

  • Verify whether LACP protocol data units (PDUs) are being exchanged by running the monitor traffic-interface lag-member detail command.

QFX Series products allow you to combine multiple Ethernet links into one logical interface for higher bandwidth and redundancy. The ports that are combined in this manner are referred to as a link aggregation group (LAG) or bundle. The number of Ethernet links you can combine into a LAG depends on your QFX Series product model. On a standalone switch, you can group up to 32 Ethernet interfaces to form a LAG. On a QFabric system, you can group up to 8 Ethernet interfaces to form a LAG. QFX Series products allow you to further enhance these links by configuring Link Aggregation Control Protocol (LACP).

This example describes how to overlay LACP on the LAG configurations that were created in Example: Configuring Link Aggregation Between a QFX Series Product and an Aggregation Switch:

Requirements

This example uses the following software and hardware components:

  • Junos OS Release 11.1 or later for the QFX3500 switch, Junos OS Release 12.1 or later for the QFX3600 switch, Junos OS Release 13.2 or later for the QFX5100 switch, and Junos OS Release 15.1X53-D10 or later for the QFX10002 switch.

  • One QFX3500, QFX3600, QFX5100, QFX10002 switch.

Before you configure LACP, be sure you have:

  • Configured the ports on the switches as trunk ports.

  • Configured the LAG.

Overview and Topology

The topology in this example is exactly the same as the topology used in the Configuring a LAG Between a QFX Switch and an Aggregation Switch example. This example shows how to use LACP to enhance the LAG functionality.

LACP exchanges are made between actors (the transmitting link) and partners (the receiving link). The LACP mode can be either active or passive.

Note

If the actor and partner are both in passive mode, they do not exchange LACP packets, which results in the aggregated Ethernet links not coming up. By default, LACP is in passive mode. To initiate transmission of LACP packets and responses to LACP packets, you must enable LACP in active mode.

By default, the actor and partner send LACP packets every second. You can configure the interval at which the interfaces send LACP packets by including the periodic statement at the [edit interfaces interface-name aggregated-ether-options lacp] hierarchy level.

The interval can be fast (every second) or slow (every 30 seconds).

Configuring LACP for the LAG on the QFX Series

To configure LACP for a QFX Series LAG, perform these tasks:

CLI Quick Configuration

To quickly configure LACP for the access switch LAGs, copy the following commands and paste them into the switch terminal window:

[edit]

set interfaces ae0 aggregated-ether-options lacp active periodic fast

Step-by-Step Procedure

To configure LACP for LAG ae0 :

  1. Specify the aggregated Ethernet options for the LAG:
    [edit interfaces]

    user@switch# set ae0 aggregated-ether-options lacp active periodic fast

Results

Display the results of the configuration:

Verification

To verify that LACP packets are being exchanged, perform the following tasks:

Verifying the LACP Settings

Purpose

Verify that LACP has been set up correctly.

Action

Use the show lacp interfaces interface-name command to check that LACP has been enabled as active on one end.

user@switch> show lacp interfaces xe-0/02

Meaning

The output indicates that LACP has been set up correctly and is active at one end.

Verifying That the LACP Packets Are Being Exchanged

Purpose

Verify that LACP packets are being exchanged.

Action

Use the show interfaces aex statistics command to display LACP information.

user@switch> show interfaces ae0 statistics

Meaning

The output here shows that the link is down and that no PDUs are being exchanged.

Troubleshooting

To troubleshoot a nonworking LACP link, perform these tasks:

Troubleshooting a Nonworking LACP Link

Problem

The LACP link is not working.

Solution

Check the following:

  • Remove the LACP configuration and verify whether the static LAG is up.

  • Verify that LACP is configured at both ends.

  • Verify that LACP is not passive at both ends.

  • Verify whether LACP protocol data units (PDUs) are being exchanged by running the monitor traffic-interface lag-member detail command.

Understanding Independent Micro BFD Sessions for LAG

Starting with Junos OS Release 13.3, this feature is supported on the following PIC/FPC types:

  • PC-1XGE-XENPAK (Type 3 FPC)

  • PD-4XGE-XFP (Type 4 FPC)

  • PD-5-10XGE-SFPP (Type 4 FPC)

  • 24x10GE (LAN/WAN) SFPP, 12x10GE (LAN/WAN) SFPP, 1x100GE Type 5 PICs

  • All MPCs on MX Series with Ethernet MICs

  • FPC-PTX-P1-A on PTX5000 with 10-Gigabit Ethernet interfaces

  • FPC2-PTX-P1A on PTX5000 with 10-Gigabit Ethernet interfaces in Junos OS Release 14.1 and later

  • All FPCs on PTX Series with Ethernet interfaces in Junos OS Release 14.1R3 and later 14.1 releases, and Junos 14.2 and later

Tip

See PTX Series PIC/FPC Compatibility for a list of PICs that are supported on each PTX Series FPC.

Note

Micro-BFD configuration with interface addresses is not supported on PTX routers on FPC3 and QFX10000 line of switches.

The Bidirectional Forwarding Detection (BFD) protocol is a simple detection protocol that quickly detects failures in the forwarding paths. A link aggregation group (LAG) combines multiple links between devices that are in point-to-point connections, thereby increasing bandwidth, providing reliability, and allowing load balancing. To run a BFD session on LAG interfaces, configure an independent, asynchronous mode BFD session on every LAG member link in a LAG bundle. Instead of a single BFD session monitoring the status of the UDP port, independent micro BFD sessions monitor the status of individual member links.

The individual BFD sessions determine the Layer 2 and Layer 3 connectivity of each member link in the LAG. Once a BFD session is established on a particular link, the member links are attached to the LAG and the load balancer either by a static configuration or by the Link Aggregation Control Protocol (LACP). If the member links are attached to the LAG by a static configuration, the device control process acts as the client to the micro BFD session. When member links are attached to the LAG by the LACP, the LACP acts as the client to the micro BFD session.

When the micro BFD session is up, a LAG link is established and data is transmitted over that LAG link. If the micro BFD session on a member link is down, that particular member link is removed from the load balancer, and the LAG managers stop directing traffic to that link. These micro BFD sessions are independent of each other despite having a single client that manages the LAG interface.

Note
  • Starting with Junos OS Release 13.3, IANA has allocated 01-00-5E-90-00-01 as the dedicated MAC address for micro BFD. Dedicated MAC mode is used by default for micro BFD sessions, in accordance with the latest draft for BFD over LAG.

  • In Junos OS, MicroBFD control packets are always untagged by default. For L2 aggregated interfaces, the configuration must include vlan-tagging or flexible-vlan-tagging in the Aggregated Ethernet with BFD. Otherwise, the system will throw error while committing the configuration.

  • When you enable MicroBFD on an aggregated Ethernet Interface, the aggregated Interface can receive MicroBFD packets. Starting with Junos OS Release 19.3 and later, for MPC10E and MPC11E MPCs, you cannot apply firewall filters on the MicroBFD packets received on the aggregated Ethernet Interface. For MPC1E through MPC9E, you can apply firewall filters on the MicroBFD packets received on the aggregated Ethernet Interface only if the aggregated Ethernet Interface is configured as an untagged Interface.

Micro BFD sessions run in the following modes:

  • Distribution Mode—Micro BFD sessions are distributed by default at Layer 3.

  • Non-Distribution Mode—You can configure the BFD session to run in this mode by including the no-delegate-processing statement under periodic packet management (PPM). In this mode, the packets are being sent or received by the Routing Engine at Layer 2.

A pair of routing devices in a LAG exchange BFD packets at a specified, regular interval. The routing device detects a neighbor failure when it stops receiving a reply after a specified interval. This allows the quick verification of member link connectivity with or without LACP. A UDP port distinguishes BFD over LAG packets from BFD over single-hop IP.

Note

IANA has allocated 6784 as the UDP destination port for micro BFD.

To enable failure detection for LAG networks for aggregated Ethernet interfaces:

  • Include the bfd-liveness-detection statement in the configuration.

  • Specify a hold-down interval value to set the minimum time that the BFD session must remain up before a state change notification is sent to the other members in the LAG network.

  • Specify the minimum interval that indicates the time interval for transmitting and receiving data.

  • Starting with Junos OS Release 14.1, specify the neighbor in a BFD session. In releases prior to Junos OS Release 16.1, you must configure the loopback address of the remote destination as the neighbor address. Beginning with Junos OS Release 16.1, you can also configure this feature on MX series routers with aggregated Ethernet interface address of the remote destination as the neighbor address.

    Note

    On T1600 and T4000 routers, you cannot configure the local aggregated Ethernet Interface address of the remote destination as the neighbor address.

    Caution

    Deactivate bfd-liveness-detection at the [edit interfaces aex aggregated-ether-options] hierarchy level or deactivate the aggregated Ethernet interface before changing the neighbor address from loopback IP address to aggregated Ethernet interface IP address. Modifying the local and neighbor address without deactivating bfd-liveness-detection or the aggregated Ethernet interface first might cause micro BFD sessions failure.

    Note

    Beginning with Release 16.1R2, Junos OS checks and validates the configured micro BFD local-address against the interface or loopback IP address before the configuration commit. Junos OS performs this check on both IPv4 and IPv6 micro BFD address configurations, and if they do not match, the commit fails.

Note

This feature works only when both the devices support BFD. If BFD is configured at one end of the LAG, this feature does not work.

For the IPv6 address family, disable duplicate address detection before configuring this feature with AE interface addresses. To disable duplicate address detection, include the dad-disable statement at the [edit interface aex unit y family inet6] hierarchy level.

Configuring Independent Micro BFD Sessions for LAG

The Bidirectional Forwarding Detection (BFD) protocol is a simple detection protocol that quickly detects failures in the forwarding paths. A link aggregation group (LAG) combines multiple links between devices that are in point-to-point connections, thereby increasing bandwidth, providing reliability, and allowing load balancing. To run a BFD session on LAG interfaces, configure an independent, asynchronous mode BFD session on every LAG member link in a LAG bundle. Instead of a single BFD session monitoring the status of the UDP port, independent micro BFD sessions monitor the status of individual member links.

To enable failure detection for aggregated Ethernet interfaces:

  1. Include the following statement in the configuration at the [edit interfaces aex aggregated-ether-options] hierarchy level:
  2. Configure the authentication criteria of the BFD session for LAG.

    To specify the authentication criteria, include the authentication statement:

    • Specify the algorithm to be used to authenticate the BFD session. You can use one of the following algorithms for authentication:

      • keyed-md5

      • keyed-sha-1

      • meticulous-keyed-md5

      • meticulous-keyed-sha-1

      • simple-password

    • To configure the key chain, specify the name that is associated with the security key for the BFD session. The name you specify must match one of the key chains configured in the authentication-key-chains key-chain statement at the [edit security] hierarchy level.

    • Configure loose authentication checking on the BFD session. Use only for transitional periods when authentication might not be configured at both ends of the BFD session.

  3. Configure BFD timers for aggregated Ethernet interfaces.

    To specify the BFD timers, include the detection-time statement:

    Specify the threshold value. This is the maximum time interval for detecting a BFD neighbor. If the transmit interval is greater than this value, the device triggers a trap.

  4. Configure a hold-down interval value to set the minimum time that the BFD session must remain up before a state change notification is sent to the other members in the LAG network.

    To specify the hold-down interval, include the holddown-interval statement:

    You can configure a number in the range from 0 through 255,000 milliseconds, and the default is 0. If the BFD session goes down and then comes back up during the hold-down interval, the timer is restarted.

    This value represents the minimum interval at which the local routing device transmits BFD packets, as well as the minimum interval in which the routing device expects to receive a reply from a neighbor with which it has established a BFD session. You can configure a number in the range from 1 through 255,000 milliseconds. You can also specify the minimum transmit and receive intervals separately.

  5. Configure the source address for the BFD session.

    To specify a local address, include the local-address statement:

    The BFD local address is the loopback address of the source of the BFD session.

    Note

    Beginning with Junos OS Release 16.1, you can also configure this feature with the AE interface address as the local address in a micro BFD session. For the IPv6 address family, disable duplicate address detection before configuring this feature with the AE interface address. To disable duplicate address detection, include the dad-disable statement at the [edit interface aex unit y family inet6] hierarchy level.

    Beginning with Release 16.1R2, Junos OS checks and validates the configured micro BFD local-address against the interface or loopback IP address before the configuration commit. Junos OS performs this check on both IPv4 and IPv6 micro BFD address configurations, and if they do not match, the commit fails.

  6. Specify the minimum interval that indicates the time interval for transmitting and receiving data.

    This value represents the minimum interval at which the local routing device transmits BFD packets, as well as the minimum interval in which the routing device expects to receive a reply from a neighbor with which it has established a BFD session. You can configure a number in the range from 1 through 255,000 milliseconds. You can also specify the minimum transmit and receive intervals separately.

    To specify the minimum transmit and receive intervals for failure detection, include the minimum-interval statement:

    Note

    BFD is an intensive protocol that consumes system resources. Specifying a minimum interval for BFD less than 100 ms for Routing Engine-based sessions and 10 ms for distributed BFD sessions can cause undesired BFD flapping.

    Depending on your network environment, these additional recommendations might apply:

    • For large-scale network deployments with a large number of BFD sessions, specify a minimum interval of 300 ms for Routing Engine-based sessions and 100 ms for distributed BFD sessions.

    • For very large-scale network deployments with a large number of BFD sessions, contact Juniper Networks customer support for more information.

    • For BFD sessions to remain up during a Routing Engine switchover event when nonstop active routing is configured, specify a minimum interval of 2500 ms for Routing Engine-based sessions. For distributed BFD sessions with nonstop active routing configured, the minimum interval recommendations are unchanged and depend only on your network deployment.

  7. Specify only the minimum receive interval for failure detection by including the minimum-receive-interval statement:

    This value represents the minimum interval in which the local routing device expects to receive a reply from a neighbor with which it has established a BFD session. You can configure a number in the range from 1 through 255,000 milliseconds.

  8. Specify the number of BFD packets that were not received by the neighbor that causes the originating interface to be declared down by including the multiplier statement:

    The default value is 3. You can configure a number in the range from 1 through 255.

  9. Configure the neighbor in a BFD session.

    The neighbor address can be either an IPv4 or an IPv6 address.

    To specify the next hop of the BFD session, include the neighbor statement:

    The BFD neighbor address is the loopback address of the remote destination of the BFD session.

    Note

    Beginning with Junos OS Release 16.1, you can also configure the AE interface address of the remote destination as the BFD neighbor address in a micro BFD session.

  10. (Optional) Configure BFD sessions not to adapt to changing network conditions.

    To disable BFD adaptation, include the no-adaptation statement:

    Note

    We recommend that you do not disable BFD adaptation unless it is preferable not to have BFD adaptation in your network.

  11. Specify a threshold for detecting the adaptation of the detection time by including the threshold statement:

    When the BFD session detection time adapts to a value equal to or greater than the threshold, a single trap and a system log message are sent. The detection time is based on the multiplier of the minimum-interval or the minimum-receive-interval value. The threshold must be a higher value than the multiplier for either of these configured values. For example, if the minimum-receive-interval is 300 ms and the multiplier is 3, the total detection time is 900 ms. Therefore, the detection time threshold must have a value greater than 900.

  12. Specify only the minimum transmit interval for failure detection by including the transmit-interval minimum-interval statement:

    This value represents the minimum interval at which the local routing device transmits BFD packets to the neighbor with which it has established a BFD session. You can configure a value in the range from 1 through 255,000 milliseconds.

  13. Specify the transmit threshold for detecting the adaptation of the transmit interval by including the transmit-interval threshold statement:

    The threshold value must be greater than the transmit interval. When the BFD session detection time adapts to a value greater than the threshold, a single trap and a system log message are sent. The detection time is based on the multiplier of the minimum-interval or the minimum-receive-interval value. The threshold must be a higher value than the multiplier for either of these configured values.

  14. Specify the BFD version by including the version statement:

    The default is to have the version detected automatically.

Note

This feature works when both the devices support BFD. If BFD is configured at only one end of the LAG, this feature does not work.

Understanding the Algorithm Used to Hash LAG Bundle and Egress Next-Hop ECMP Traffic

Juniper Networks EX Series and QFX Series use a hashing algorithm to determine how to forward traffic over a link aggregation group (LAG) bundle or to the next-hop device when equal-cost multipath (ECMP) is enabled.

The hashing algorithm makes hashing decisions based on values in various packet fields, as well as on some internal values like source port ID and source device ID. You can configure some of the fields that are used by the hashing algorithm.

Note

Platform support depends on the Junos OS release in your installation.

This topic contains the following sections:

Understanding the Hashing Algorithm

The hashing algorithm is used to make traffic-forwarding decisions for traffic entering a LAG bundle or for traffic exiting a switch when ECMP is enabled.

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.

For ECMP, the hashing algorithm determines how incoming traffic is forwarded to the next-hop device.

The hashing algorithm makes hashing decisions based on values in various packet fields, as well as on some internal values like source port ID and source device ID. The packet fields used by the hashing algorithm varies by the packet’s EtherType and, in some instances, by the configuration on the switch. The hashing algorithm recognizes the following EtherTypes:

  • IP (IPv4 and IPv6)

  • MPLS

  • MAC-in-MAC

Traffic that is not recognized as belonging to any of these EtherTypes is hashed based on the Layer 2 header. IP and MPLS traffic are also hashed based on the Layer 2 header when a user configures the hash mode as Layer 2 header.

You can configure some fields that are used by the hashing algorithm to make traffic forwarding decisions. You cannot, however, configure how certain values within a header are used by the hashing algorithm.

Note the following points regarding the hashing algorithm:

  • The fields selected for hashing are based on the packet type only. The fields are not based on any other parameters, including forwarding decision (bridged or routed) or egress LAG bundle configuration (Layer 2 or Layer 3).

  • The same fields are used for hashing unicast and multicast packets. Unicast and multicast packets are, however, hashed differently.

  • The same fields are used by the hashing algorithm to hash ECMP and LAG traffic, but the hashing algorithm hashes ECMP and LAG traffic differently. LAG traffic uses a trunk hash while ECMP uses ECMP hashing. Both LAG and ECMP use the same RTAG7 seed but use different offsets of that 128B seed to avoid polarization. The initial config of the HASH function to use the trunk and ECMP offset are set at the PFE Init time. The different hashing ensures that traffic is not polarized when a LAG bundle is part of the ECMP next-hop path.

  • The same fields are used for hashing regardless of whether the switch is or is not participating in a mixed or non-mixed Virtual Chassis or Virtual Chassis Fabric (VCF).

The fields used for hashing by each EtherType as well as the fields used by the Layer 2 header are discussed in the following sections.

IP (IPv4 and IPv6)

Payload fields in IPv4 and IPv6 packets are used by the hashing algorithm when IPv4 or IPv6 packets need to be placed onto a member link in a LAG bundle or sent to the next-hop device when ECMP is enabled.

The hash mode is set to Layer 2 payload field, by default. IPv4 and IPv6 payload fields are used for hashing when the hash mode is set to Layer 2 payload.

If the hash mode is configured to Layer 2 header, IPv4, IPv6, and MPLS packets are hashed using the Layer 2 header fields. If you want incoming IPv4, IPv6, and MPLS packets hashed by the source MAC address, destination MAC address, or EtherType fields, you must set the hash mode to Layer 2 header.

Table 4 displays the IPv4 and IPv6 payload fields that are used by the hashing algorithm, by default.

  • ✓—Field is used by the hashing algorithm, by default.

  • Χ—Field is not used by the hashing algorithm, by default.

  • (configurable)—Field can be configured to be used or not used by the hashing algorithm.

On EX2300 switches, following payload fields in IPv4 and IPv6 packets are used by the hashing algorithm when IPv4 or IPv6 packets need to be placed onto a member link in a LAG bundle or sent to the next-hop device when ECMP is enabled:

  • For unicast traffic on LAG - SIP, DIP, L4SP, L4DP

  • For known multicast traffic on LAG - Source IP, Destination IP, Ingress Mod Id, and Ingress Port Id

  • For broadcast, unknown unicast, and unknown multicast traffic on LAG - Source MAC, Destination MAC, Ingress Mod Id, and Ingress Port Id

  • ECMP load balancing: Destination IP, Layer 4 Source Port, and Layer 4 Destination Port

Table 4: IPv4 and IPv6 Hashing Fields

Fields

EX3400

EX4300

QFX5100

QFX5110

QFX5200

 

LAG

ECMP

LAG

ECMP

LAG

ECMP

LAG

ECMP

LAG

ECMP

Source MAC

X

Χ

X

Χ

Χ

Χ

Χ

Χ

Χ

X

Destination MAC

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

EtherType

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

VLAN ID

Χ

(configurable)

Χ

(configurable)

Χ

(configurable)

Χ

(configurable)

Χ

(configurable)

Χ

(configurable)

Χ

(configurable)

Χ

(configurable)

Χ

(configurable)

Χ

(configurable)

Source IP or IPv6

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

Destination IP or IPv6

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

Protocol (IPv4 only)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

Next header (IPv6 only)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

Layer 4 Source Port

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

Layer 4 Destination Port

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

IPv6 Flow label (IPv6 only)

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Ingress Mod Id

(configurable)

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Ingress Port Id

(configurable)

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

MPLS

The hashing algorithm hashes MPLS packets using the source IP, destination IP, MPLS label 0, MPLS label 1, MPLS label 2, and MPLS 3 fields. On the QFX5110 and QFX5200 switches, LSR routers also support ECMP. ECMP uses these fields for hashing on an LSR router:

  • Layer 3 VPN: MPLS Labels (top 3 labels), source IP, destination IP, and ingress port ID

  • Layer 2 Circuit: MPLS Labels (top 3 labels) and ingress port ID

Table 5 displays the MPLS payload fields that are used by the hashing algorithm, by default:

  • ✓—Field is used by the hashing algorithm, by default.

  • Χ—Field is not used by the hashing algorithm, by default.

The fields used by the hashing algorithm for MPLS packet hashing are not user-configurable.

The source IP and destination IP fields are not always used for hashing. For non-terminated MPLS packets, the payload is checked if the bottom of stack (BoS) flag is seen in the packet. If the payload is IPv4 or IPv6, then the IP source address and IP destination address fields are used for hashing along with the MPLS labels. If the BoS flag is not seen in the packet, only the MPLS labels are used for hashing.

Table 5: MPLS Hashing Fields

Field

EX3400

EX4300

QFX5100

QFX5110

QFX5200

Source MAC

Χ

Χ

Χ

Χ

Χ

Destination MAC

Χ

Χ

Χ

Χ

Χ

EtherType

Χ

Χ

Χ

Χ

Χ

VLAN ID

Χ

Χ

Χ

Χ

Χ

Source IP

Destination IP

Protocol (for IPv4 packets)

Χ

Χ

Χ

Χ

Χ

Next header (for IPv6 packets)

Χ

Χ

Χ

Χ

Χ

Layer 4 Source Port

Χ

Χ

Χ

Χ

Χ

Layer 4 Destination Port

Χ

Χ

Χ

Χ

Χ

IPv6 Flow lab

Χ

Χ

Χ

Χ

Χ

MPLS label 0

Χ

MPLS label 1

MPLS label 2

MPLS label 3

X

X

X

X

Ingress Port ID

(LSR and L2Circuit)

X

X

X

(LSR and L2Circuit)

(LSR and L2Circuit)

MAC-in-MAC Packet Hashing

Packets using the MAC-in-MAC EtherType are hashed by the hashing algorithm using the Layer 2 payload source MAC, Layer 2 payload destination MAC, and Layer 2 payload EtherType fields. See Table 6.

Hashing using the fields in the MAC-in-MAC EtherType packet is first supported on EX4300 switches in Release 13.2X51-D20. Hashing using the fields in the MAC-in-MAC EtherType is not supported on earlier releases.

The fields used by the hashing algorithm for MAC-in-MAC hashing are not user-configurable.

  • ✓—Field is used by the hashing algorithm, by default.

  • Χ—Field is not used by the hashing algorithm, by default.

Table 6: MAC-in-MAC Hashing Fields

Field

EX3400

EX4300

QFX5100

QFX5110

QFX5200

Layer 2 Payload Source MAC

Layer 2 Payload Destination MAC

Layer 2 Payload EtherType

Layer 2 Payload Outer VLAN

Χ

Χ

Χ

Χ

Layer 2 Header Hashing

Layer 2 header fields are used by the hashing algorithm when a packet’s EtherType is not recognized as IP (IPv4 or IPv6), MPLS, or MAC-in-MAC. The Layer 2 header fields are also used for hashing IPv4, IPv6, and MPLS traffic instead of the payload fields when the hash mode is set to Layer 2 header.

  • ✓—Field is used by the hashing algorithm, by default.

  • Χ—Field is not used by the hashing algorithm, by default.

  • (configurable)—Field can be configured to be used or not used by the hashing algorithm.

Table 7: Layer 2 Header Hashing Fields

Field

EX3400

EX4300

QFX5100

QFX5110

QFX5200

Source MAC

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

Destination MAC

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

EtherType

(configurable)

(configurable)

(configurable)

(configurable)

(configurable)

VLAN ID

Χ

(configurable)

Χ

(configurable)

Χ

(configurable)

(configurable)

(configurable)

Hashing Parameters

Starting in Junos OS Release 19.1R1, on the QFX5000 line of switches, you can change hashing parameters for the existing algorithms implemented. You can change the threshold of shared buffer pools for both ingress and egress buffer partitions and you can make changes to the hash function selection, hash algorithm, and other additional parameters. See Configuring the Shared-Buffer Threshold and Other Hashing Parameters, later in this document.

Configuring the Fields in the Algorithm Used To Hash LAG Bundle and ECMP Traffic (CLI Procedure)

Juniper Networks EX Series and QFX Series switches use a hashing algorithm to determine how to forward traffic over a Link Aggregation group (LAG) bundle or to the next-hop device when equal-cost multipath (ECMP) is enabled.

The hashing algorithm makes hashing decisions based on values in various packet fields.. You can configure some of the fields that are used by the hashing algorithm.

Configuring the fields used by the hashing algorithm is useful in scenarios where most of the traffic entering the bundle is similar and the traffic needs to be managed in the LAG bundle. For instance, if the only difference in the IP packets for all incoming traffic is the source and destination IP address, you can tune the hashing algorithm to make hashing decisions more efficiently by configuring the algorithm to make hashing decisions using only those fields.

Note

Configuring the hash mode is not supported on QFX10002 and QFX10008 switches.

Configuring the Hashing Algorithm to Use Fields in the Layer 2 Header for Hashing

To configure the hashing algorithm to use fields in the Layer 2 header for hashing:

  1. Configure the hash mode to Layer 2 header:
    [edit forwarding-options enhanced-hash-key]

    user@switch# set hash-mode layer2-header

    The default hash mode is Layer 2 payload. Therefore, this step must be performed if you have not previously configured the hash mode.

  2. Configure the fields in the Layer 2 header that the hashing algorithm uses for hashing:
    [edit forwarding-options enhanced-hash-key]

    user@switch# set layer2 {no-destination-mac-address | no-ether-type | no-source-mac-address | vlan-id}

    By default, the hashing algorithm uses the values in the destination MAC address, Ethertype, and source MAC address fields in the header to hash traffic on the LAG. You can configure the hashing algorithm to not use the values in these fields by configuring no-destination-mac-address, no-ether-type, or no-source-mac-address.

    You can also configure the hashing algorithm to include the VLAN ID field in the header by configuring the vlan-id option.

    If you want the hashing algorithm to not use the Ethertype field for hashing:

    [edit forwarding-options enhanced-hash-key]

    user@switch# set layer2 no-ether-type

Configuring the Hashing Algorithm to Use Fields in the IP Payload for Hashing

To configure the hashing algorithm to use fields in the IP payload for hashing:

  1. Configure the hash mode to Layer 2 payload:
    [edit forwarding-options enhanced-hash-key]

    user@switch# set hash-mode layer2-payload

    The IP payload is not checked by the hashing algorithm unless the hash mode is set to Layer 2 payload. The default hash mode is Layer 2 payload.

  2. Configure the fields in the IP payload that the hashing algorithm uses for hashing:
    [edit forwarding-options enhanced-hash-key]

    user@switch# set inet {no-ipv4-destination-address | no-ipv4-source-address | no-l4-destination-port | no-l4-source-port | no-protocol | vlan-id}

    For instance, if you want the hashing algorithm to ignore the Layer 4 destination port, Layer 4 source port, and protocol fields and instead hash traffic based only on the IPv4 source and destination addresses:

    [edit forwarding-options enhanced-hash-key]

    user@switch# set inet no-l4-destination-port no-l4-source-port no-protocol

Configuring the Hashing Algorithm to Use Fields in the IPv6 Payload for Hashing

To configure the hashing algorithm to use fields in the IPv6 payload for hashing:

  1. Configure the hash mode to Layer 2 payload:
    [edit forwarding-options enhanced-hash-key]

    user@switch# set hash-mode layer2-payload

    The IPv6 payload is not checked by the hashing algorithm unless the hash mode is set to Layer 2 payload. The default hash mode is Layer 2 payload.

  2. Configure the fields in the IPv6 payload that the hashing algorithm uses for hashing:
    [edit forwarding-options enhanced-hash-key]

    user@switch# set inet6 {no-ipv6-destination-address | no-ipv6-source-address | no-l4-destination-port | no-l4-source-port | no-next-header | vlan-id}

    For instance, if you want the hashing algorithm to ignore the Layer 4 destination port, Layer 4 source port, and the Next Header fields and instead hash traffic based only on the IPv6 source and IPv6 destination address fields only:

    [edit forwarding-options enhanced-hash-key]

    user@switch# set inet6 no-l4-destination-port no-l4-source-port no-next-header

Configuring Other Hashing Parameters

To configure hashing parameters for either ECMP or LAG traffic:

  1. Configure the preprocess parameter:
    [edit forwarding-options enhanced-hash-key]

    user@switch# set hash-parameters (ecmp | lag) preprocess
  2. Configure the function parameter:
    [edit forwarding-options enhanced-hash-key]

    user@switch# set hash-parameters (ecmp | lag) function (crc16-bisync | crc16-ccitt | crc32-hi | crc32-lo)
  3. Configure the offset value:
    [edit forwarding-options enhanced-hash-key]

    user@switch# set hash-parameters (ecmp | lag) offset offset-value
Release History Table
Release
Description
Starting with Junos OS Release 19.3 and later, for MPC10E and MPC11E MPCs, you cannot apply firewall filters on the MicroBFD packets received on the aggregated Ethernet Interface. For MPC1E through MPC9E, you can apply firewall filters on the MicroBFD packets received on the aggregated Ethernet Interface only if the aggregated Ethernet Interface is configured as an untagged Interface.
on the QFX5000 line of switches, you can change hashing parameters for the existing algorithms implemented.
Beginning with Junos OS Release 16.1, you can also configure this feature on MX series routers with aggregated Ethernet interface address of the remote destination as the neighbor address.
Beginning with Release 16.1R2, Junos OS checks and validates the configured micro BFD local-address against the interface or loopback IP address before the configuration commit.
Starting with Junos OS Release 14.2, aggregated Ethernet supports mixed link speeds on PTX Series Packet Transport Routers.
Starting in Junos OS Release 14.1X53-D25, local link bias can be enabled globally for all LAG bundles in a Virtual Chassis or VCF, or individually per LAG bundle in a Virtual Chassis.
Starting with Junos OS Release 14.1R1 and 14.2, support for mixed rates on aggregated Ethernet bundles is extended to MX240, MX480, MX960, MX2010, and MX2020 routers.
Starting with Junos OS Release 14.1, specify the neighbor in a BFD session. In releases prior to Junos OS Release 16.1, you must configure the loopback address of the remote destination as the neighbor address.
Starting with Junos OS Release 13.3, IANA has allocated 01-00-5E-90-00-01 as the dedicated MAC address for micro BFD.
Starting with Junos OS Release 13.2, aggregated Ethernet supports mixed rates and mixed modes on T640, T1600, T4000, and TX Matrix Plus routers.
Starting with Junos OS Release 13.2, 100-Gigabit Ethernet member links can be configured using the two 50-Gigabit Ethernet interfaces of 100-Gigabit Ethernet PIC with CFP.