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, QFX5120, 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.

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.

LAGs with member links of different interface types, for example, ge and mge are not supported on multirate switches.

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. Following are the LAGs supported on different switches:

    • Up to 448 LAGs are supported on QFX3500, QFX3600, EX4600, and OCX Series switches.
    • Up to 1,000 LAGs (hardware limit) are supported on QFX5100, QFX5120, QFX5200, QFX5110 switches.
    • Up to 1,750 LAGs are supported on 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.

See Also

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.

See Also

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.

See Also

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:

See Also

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.

See Also

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.

See Also

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.

See Also

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.

See Also

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 User Guide.

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

Configuring LACP Link Protection

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

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

See Also

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.

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:

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.

Meaning

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

See Also

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.

See Also

Configuring 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.

Note:

Starting in Junos OS Evolved Release 20.1R1, independent micro Bidirectional Forwarding Detection (BFD) sessions are enabled on a per member link basis of a Link Aggregation Group (LAG) bundle.

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. The configured micro-BFD local-address should match with the micro-BFD neighbour-address configured on the peer router.

  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:

  • The version option is not supported on the QFX Series. Starting in Junos OS Release 17.2R1, a warning will appear if you attempt to use this command.

  • 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.

See Also

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 and QFX5120

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, QFX5120, 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 and QFX5120

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 and QFX5120

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 and QFX5120

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 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:

    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:

    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:

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:

    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:

    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:

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:

    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:

    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:

Configuring Other Hashing Parameters

To configure hashing parameters for either ECMP or LAG traffic:

  1. Configure the preprocess parameter:
  2. Configure the function parameter:
  3. Configure the offset value:

See Also

Release History Table
Release
Description
19.3
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.
19.1R1
on the QFX5000 line of switches, you can change hashing parameters for the existing algorithms implemented.
16.1
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.
16.1
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.
14.2
Starting with Junos OS Release 14.2, aggregated Ethernet supports mixed link speeds on PTX Series Packet Transport Routers.
14.1X53-D25
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.
14.1
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.
14.1
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.
13.3
Starting with Junos OS Release 13.3, IANA has allocated 01-00-5E-90-00-01 as the dedicated MAC address for micro BFD.
13.2
Starting with Junos OS Release 13.2, aggregated Ethernet supports mixed rates and mixed modes on T640, T1600, T4000, and TX Matrix Plus routers.
13.2
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.