Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


EVPN-VXLAN Lightweight Leaf to Server Loop Detection

Configure EVPN-VXLAN lightweight leaf to server loop detection to quickly detect and break local area network (LAN) Ethernet loops downstream on the leaf-to-server port side. This feature detects and breaks loops for:

  • Inaccurate wiring of the fabric components.

  • Inaccurate wiring or misconfiguration of third party switches to EVPN fabric devices (such as when connecting customer edge (CE) switches).

This feature helps you repair loops that the EVPN control plane cannot detect without having to rely on the state of BGP EVPN signaling.

How Lightweight Leaf to Server Loop Detection Works

With this feature configured, the device transmits periodic multicast PDUs (based on Connectivity Fault Management [CFM] PDUs) on provider edge (PE) to CE interfaces for loop detection. The device can then block the interface upon receiving these self-generated PDUs. When the device receives a loop detection PDU, it breaks the loop by blocking (operationally shutting down) the ingress port.

The device logs an error message upon loop detection (CFMD_LOOP_DETECTED) and also when the loop is cleared (CFMD_LOOP_CLEARED).

We recommend that you enable loop detection initially before you configure EVPN-VXLAN, so you can detect any loops and take corrective actions before EVPN traffic is flowing through the network. When this feature detects loops, the device raises loop detection error messages immediately. However, if you bring up a large-scale EVPN network that already contains loops, even with this feature enabled, the interface doesn't come down immediately and traffic continues to flow through the loop for some time while the network stabilizes.

If a loop is introduced into the network later in a stable running EVPN-VXLAN fabric, this feature will detect the loop and stop traffic flow through the loop immediately.

Options for Repairing Loops

If required, break and clear the loop. To bring the interface back online, you can configure a revert interval using the revert-interval seconds statement at the [edit protocols loop-detect interface name] hierarchy level. When the revert interval expires, the device automatically brings the interface back online. The default revert interval is 0 seconds, which means the interval never expires and the interface doesn't automatically revert to its prior state.

If you don’t explicitly configure a revert interval other than 0, the port never reverts to its state before the loop detection event and action. To manually bring the interface back online, you must clear the status using the clear loop-detect enhanced interface name command.

Supported Interface Configurations

We support this loop detection feature with:

  • Aggregated Ethernet (AE) interfaces.


    On AE interfaces with Link Aggregation Control Protocol (LACP) enabled, the LACP state remains up (Collecting or Distributing) even if the loop detection action brings the logical interface down.

  • Trunk and enterprise style interface configurations, including logical interfaces for a trunk interface with the native VLAN ID and other VLANs.

  • Service provider style interface configurations—Only on QFX10002-60C, QFX10002, QFX10008, and QFX10016 switches, starting in Junos OS Release 22.4R1. We don't support this lightweight loop detection feature on service provider style interfaces with other switch models.

Loop Detect Scenarios

The following three loop detection scenarios demonstrate that loops can form with different Ethernet segment identifiers (ESIs), with the same ESI, or with no ESI.

Figure 1: Different ESI Looped

When the loop occurs with different ESIs, you can enable a range of fabric router IDs on which the device triggers loop detection (mandatory). Or, you can build the list automatically using router IDs based on EVPN Type 1 auto-discovery route signaling (optional).

Different ESI Looped
Figure 2: Same ESI Looped

When the loop occurs with the same ESI, the CE switch is not using the same bridged interface when connecting to Leaf1 and Leaf3.

Same ESI Looped
Figure 3: No ESI on Looped Ports

When one of the looped ports doesn't have an ESI, the loop goes through the CE switch from Leaf1 to Leaf3.

No ESI on Looped Ports

Loop Detect PE-CE Use Cases using Layer 2 Heartbeats

The following two use cases show that the loop is occurring through the switch due to misconfiguration of the switch (use case 1), or that the loop is caused by misalignment of cable connections on the switch (use case 2). In both of the following two use cases, functionality is not dependent on the BGP speed of control-plane advertisement, and this lightweight PC-CE loop detection is independent of configured ESI values.

EVPN-VXLAN Lightweight Leaf Server Loop Detection Use Case 1

In this first case, the loop occurs at Leaf3. CE-switch1 and CE-switch2 are not CFM-enabled. Leaf1 and Leaf3 are CFM-enabled. The Layer 2 (L2) packet CFM uses a proprietary type, length, value (TLV) format.

Figure 4: Scenario 1 Scenario 1

EVPN-VXLAN Lightweight Leaf to Server Loop Detection Use Case 2

The L2 packet CFM uses is a proprietary type, length, and value (TLV) and the loop occurs on Leaf1. Instead of relying on the speed of BGP, the MAC route reflections speed, and the duplicate MAC or MAC move detections in larger DC fabrics, the lightweight loop detection is independent of the state of the BGP EVPN signaling.

Figure 5: Scenario 2 Scenario 2

Enable Loop Detection on a Logical Interface

To enable loop detection for an interface or for all interfaces, use the loop-detect statement at the [edit protocols] hierarchy level. Include a supported loop-detect-action for the interface(s) and optionally specify a vlan-id, as follows:


We require the vlan-id option for trunk interfaces, and enterprise style or service provider style interface configurations.

You can also optionally set the following values at the [edit protocols loop-detect enhanced interface (logical-interface-name | all)] hierarchy level:

  • The revert-interval option—After you repair the loop, the device brings the interface(s) up again after this interval expires (default is 0 seconds).

  • The transmit-interval option—Customize how often to transmit loop detection PDUs (default is 1 second, see loop-detect for more on the values you can set for this interval).

Sample Configuration with Trunk Mode Enterprise Style Interface

The following sample configuration enables loop detection on interface ge-0/0/1.0, which is a trunk interface with vlan-id 100.

Sample Configuration with Service Provider Style Interface

The following sample configuration enables loop detection for vlan-id 100 on provider edge (PE) and CE devices with service provider style interface configurations. This configuration doesn't specify a revert interval. As a result, after the device detects a loop and you correct the loop, enter the clear loop detect enhanced interface name command to bring the interface back online.

PE device configuration:

CE device configuration:

CLI Commands to Display or Clear Loop Detection Status

Use the show loop-detect enhanced interface command to display loop status on an interface or all interfaces.

Use the clear loop-detect enhanced interface command to restore an interface or all interfaces to their prior state after the device detects a loop and applies a configured action to break the loop.

Show command without any loop

Show command with loop detect status

Release History Table
Starting in Junos OS Release 22.4R1, QFX10002-60C, QFX10002, QFX10008, and QFX10016 support EVPN-VXLAN lightweight loop protection on leaf device to server device links with either enterprise style or service provider style interface configurations.