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 find and 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
To configure this lightweight PE-CE loop detection feature, specify a logical interface name. We don't support this feature with physical interfaces, only with logical interfaces as follows:
-
Enterprise style interface configurations without flexible Ethernet services—Only with logical unit 0.
-
Enterprise style interface configurations with flexible Ethernet services—On any logical interfaces you can configure on the device, including logical interfaces for a trunk interface with the native VLAN ID and other configured 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 any other devices.
-
Aggregated Ethernet interfaces—On a logical unit X of an aggregated Ethernet interface (aeN.X). With enterprise style aggregated Ethernet interface configurations without flexible Ethernet services configured, we only support logical unit 0. Otherwise you can use any configured logical unit X.
On aggregated Ethernet 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.
See Flexible Ethernet Services Encapsulation for more on flexible Ethernet services, enterprise style interface configurations, and service provider style interface configurations.
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.
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).
When the loop occurs with the same ESI, the CE switch is not using the same bridged interface when connecting to Leaf1 and Leaf3.
When one of the looped ports doesn't have an ESI, the loop goes through the CE switch from Leaf1 to Leaf3.
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
- EVPN-VXLAN Lightweight Leaf to Server Loop Detection Use Case 2
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.
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.
Enable Loop Detection on a Logical Interface
To enable loop detection for a logical interface or for all logical 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:
set protocols loop-detect enhanced interface (logical-interface-name | all) loop-detect-action (interface-down | laser-off) vlan-id vlan-id;
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.
set interfaces ge-0/0/1.0 unit 0 family ethernet-switching interface-mode trunk set interfaces ge-0/0/1.0 unit 0 family ethernet-switching vlan members [ v100 v101 v102 v103 v104 ] set protocols loop-detect enhanced interface ge-0/0/1.0 vlan-id 100 set protocols loop-detect enhanced interface ge-0/0/1.0 loop-detect-action interface-down set protocols loop-detect enhanced interface ge-0/0/1.0 transmit-interval 1s set protocols loop-detect enhanced interface ge-0/0/1.0 revert-interval 50s
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:
set interfaces xe-0/0/0 flexible-vlan-tagging set interfaces xe-0/0/0 encapsulation flexible-ethernet-services set interfaces xe-0/0/0 unit 10 encapsulation vlan-bridge set interfaces xe-0/0/0 unit 10 vlan-id 100 set protocols loop-detect enhanced interface xe-0/0/0.10 vlan-id 100 set vlans vlan100 vlan-id 100 set vlans vlan100 interface xe-0/0/0.10
CE device configuration:
set interfaces xe-0/0/3 flexible-vlan-tagging set interfaces xe-0/0/3 encapsulation flexible-ethernet-services set interfaces xe-0/0/3 unit 10 encapsulation vlan-bridge set interfaces xe-0/0/3 unit 10 vlan-id 100 set protocols loop-detect enhanced interface xe-0/0/3.10 vlan-id 100 set vlans vlan100 vlan-id 100 set vlans vlan100 interface xe-0/0/3.10
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
user@leaf-device# run show loop-detect enhanced interface Interface :ge-0/0/1.0 Vlan-id :100 ESI :00:00:00:00:00:00:00:00:00:00 Current status :Normal[Link Up] Last loop-detect time :- Receive statistics :0 Action configured :Interface-down Action count :0 Transmit Interval :1s Revert Interval :60s
Show command with loop detect status
user@leaf-device# run show loop-detect enhanced interface Interface :ge-0/0/1.0 Vlan-id :100 ESI :00:00:00:00:00:00:00:00:00:00 Current status :Loop-detected Remote Host :leaf04 Remote Chassis :94:f7:ad:94:dd:40 Remote Interface :xe-0/0/2.0 Remote ESI :00:00:00:00:00:00:00:00:00:00 Last loop-detect time :Tue May 26 04:36:37 2020 Receive statistics :4 Action configured :Interface-down Action count :1 Transmit Interval :1s Revert Interval :60s
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.