Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Layer 2 Protocol Tunneling over VXLAN Tunnels in EVPN-VXLAN Bridged Overlay Networks

Enables Layer 2 (L2) protocol tunneling (L2PT) for protocol control frames from an access interface to VXLAN tunnel destinations in an EVPN-VXLAN bridged overlay (BO) network.

L2PT over VXLAN Tunnels

L2PT transmits bridge protocol data units (BPDUs) transparently across a bridged network between devices as if those devices are directly connected for those protocol control frames. The nodes in the transmission path don't trap and process the control frames for the tunneled protocols.

VXLAN tunnels in an EVPN-VXLAN bridged overlay (BO) network help isolate one customer's traffic from the traffic of other customers across the network.

L2PT over VXLAN tunnels enables a device in an EVPN-VXLAN bridged overlay network to transmit tagged or untagged protocol control frames transparently to destinations across the VXLAN tunnel endpoints (VTEPs) in the network. The VXLAN tunnels keep each customer's traffic separated, and L2PT prevents the devices in the network along the transmission path from processing the protocol frames. See Figure 1:

Figure 1: L2PT over VXLAN Tunnels L2PT over VXLAN Tunnels

You enable L2PT on an access interface for the protocols you want to tunnel through the EVPN-VXLAN network. When control frames come into the device on that access interface, the device doesn't trap those frames to the control plane for protocol processing. Instead, the device encapsulates the frame with a VXLAN media access control (MAC) UDP header and VXLAN network identifier (VNI), and transparently floods the frames over the associated VXLAN tunnels toward the destination host. In other words, the devices in the EVPN-VXLAN network send those frames across the network the same way they send data packets.

The protocol control packets can be VLAN-tagged or untagged. The devices uses the following VNI values for the VXLAN encapsulation:

  • VLAN-tagged—The device uses the VNI corresponding to the control packet's VLAN.

  • Untagged—The device uses the VNI corresponding to the native VLAN.

The device at the destination VTEP terminates the VXLAN tunnel, decapsulates the frame, and floods the frame toward the destination access interfaces.

You can use L2PT over VXLAN in cases such as when your network has hosts attached to leaf devices over remote connections in the EVPN-VXLAN network, and the devices use LLDP to discover EVPN-VXLAN neighbor relationships.

To configure this feature for L2 protocol control frames coming in on a specified access interface name, you must configure both of the following statements at the [edit protocols layer2-control l2pt interface interface-name] hierarchy level:

  • destination vxlan-tunnel—Enable L2PT in general toward network destinations that are across the VXLAN tunnels in the network.

  • protocol (all | protocol-name)—Specify an L2 protocol to tunnel. Use the all option to tunnel all supported protocols, or include individual protocol statements for each protocol you want to tunnel.

See Configure and Verify L2PT over VXLAN for more on how to configure this feature.

Benefits of L2PT over VXLAN Tunnels

  • Provides a secure option for network administrators to extend tagged or untagged L2 BPDUs across the EVPN-VXLAN BO fabric.

L2PT over VXLAN Support Details

Use Feature Explorer to confirm platform and release support for this feature.

See Platform-Specific L2PT over VXLAN Behavior for a summary of platform-specific support differences. This section describes common supported behavior with this feature on all platforms.

We support L2PT over VXLAN tunnels in an EVPN-VXLAN BO network as follows:

  • Supported Protocols to Tunnel lists the L2 protocols you can configure the device to transparently forward over VXLAN tunnels.

  • If you enable an L2 protocol for L2PT over VXLAN on an interface, you can't configure that interface with the same protocol for data traffic on the device. The device throws a commit error in that case.

  • When you enable L2PT over VXLAN for a supported protocol, the device transparently forwards the protocol control frames with that protocol destination MAC address. If you enable L2PT for a protocol that has the same destination MAC address as one or more other supported protocols, the device transparently forwards the control frames for all of those protocols.

    For example, LACP and 802.3AH protocol use the same destination MAC address, 01:80:C2:00:00:02. If you configure L2PT over VXLAN for LACP, the device tunnels 802.3ah protocol frames as well as LACP frames. (See Supported Protocols to Tunnel for the standard destination MAC addresses for each supported protocol.)

  • The device can tunnel L2 protocol frames that are VLAN-tagged or are untagged. We support Q-in-Q for the tunneled traffic according to the use cases described in Examples: Tunneling Q-in-Q Traffic in an EVPN-VXLAN Overlay Network.

    To send tagged control BPDUs over the VXLAN tunnels, the device uses the VNI corresponding to the VLAN in the tagged frame. To send untagged control BPDUs over the VXLAN tunnels, the device uses the native VLAN and its corresponding VNI.

    Note:

    For L2PT over VXLAN to work, you must configure a VLAN as the native VLAN and a VNI mapping for the native VLAN on the interface.

  • The specified access interface can be an interface that is:

  • You can't configure L2PT over VXLAN and standard L2PT (for the same or different protocols) on the same interface. See Layer 2 Protocol Tunneling for details on the standard L2PT feature (not over VXLAN encapsulation tunnels), which uses a MAC rewrite operation to perform the L2 tunneling. The MAC rewrite statements and commands described there apply only to the standard L2PT feature and not to L2PT over VXLAN.

    However, you can configure L2PT over VXLAN on one interface and standard L2PT on a different interface (for the same or different protocols). You can also use the show l2pt interface command to see if L2PT over VXLAN or standard L2PT is enabled for an interface. In the Destination output field, the command displays VXLAN-TUNNEL for interfaces you enable with L2PT over VXLAN, or the MAC rewrite address for interfaces you enable with standard L2PT.

Supported Protocols to Tunnel

See Platform-Specific L2PT over VXLAN Behavior for platform-specific differences for supported protocol options.

You can configure the device to transparently tunnel BPDUs for the protocols listed in Table 1. The table lists the options you configure at the [edit protocols layer2-control l2pt interface interface-name protocol] hierarchy level to enable L2PT for each protocol, as well as the protocol's standard destination MAC address.

The device tunnels the protocol control frames based on the destination MAC address. As a result, the device will tunnel all protocols that share the same destination MAC address if you enable L2PT for any one of the protocols with that destination MAC address.

Table 1: Protocol Options with L2PT over VXLAN Tunnels

Protocol

Protocol Name Configuration Option

Protocol MAC Address

802.1X—IEEE 802.1X authentication

ieee8021x

01:80:C2:00:00:03

802.3ah—IEEE 802.3ah Operation, Administration, and Maintenance (OAM) link fault management (LFM)

ieee8023ah

01:80:C2:00:00:02

Cisco Discovery Protocol (CDP)

cdp

01:00:0C:CC:CC:CC

Ethernet local management interface (E-LMI)

elmi

01:80:C2:00:00:07

Generic Attribute Registration Protocol (GARP) VLAN Registration Protocol (GVRP)

gvrp

01:80:C2:00:00:21

Link Aggregation Control Protocol (LACP)

lacp

01:80:C2:00:00:02

Link Layer Discovery Protocol (LLDP)

lldp

01:80:C2:00:00:0E

Multiple MAC Registration Protocol (MMRP)

mmrp

01:80:C2:00:00:20

MVRP VLAN Registration Protocol (MVRP)

mvrp

01:80:c2:00:00:21

Per-VLAN Spanning Tree (PVST) protocol and PVST plus (PVST+) protocol

pvstp

01:00:0C:CC:CC:CD

STP, Rapid STP (RSTP), and Multiple STP (MSTP)

stp

01:80:C2:00:00:00

Unidirectional Link Detection (UDLD)

udld

01:00:0C:CC:CC:CC

VLAN Spanning Tree Protocol (VSTP)

vstp

01:00:0C:CC:CC:CD

VLAN Trunking Protocol (VTP)

vtp

01:00:0C:CC:CC:CC

Platform-Specific L2PT over VXLAN Behavior

Use Feature Explorer to confirm platform and release support for this feature.

Use the following table to review platform-specific behaviors for your platforms that support this feature.

Table 2: Platform Specific L2PT Over VXLAN Differences

Platform

Difference

EX Series and QFX Series (Junos OS)

  • On these devices, you don't need to explicitly enable tunneling BPDUs in the STP family of protocols (called xSTP here for brevity, which includes STP, MSTP, RSTP, VSTP, and PVST/PVST+). These devices flood xSTP control BPDUs into the VXLAN tunnels by default, so we don't support the protocol options in Table 1 to tunnel xSTP protocols over VXLAN. If you don't want the device to tunnel xSTP control BPDUs over VXLAN, you can configure the BPDU protection feature on the ingress access interface. See bpdu-block and bpdu-block-on-edge for details on the BPDU protection feature.

QFX Series (Junos OS Evolved)

  • These devices do not tunnel xSTP protocol BPDUs over VXLAN by default. We provide the pvstp, stp, and vstp protocol options on these devices to enable tunneling xSTP BPDUs over VXLAN (see Table 1).

  • On these devices, you must set the enable-all-ifl option at the [edit protocols layer2-control l2pt interface interface-name] hierarchy level on any L2PT-enabled physical interface that you configure with multiple logical interface units. See Step 3 in Configure and Verify L2PT over VXLAN for details.

  • These devices implement L2PT over VXLAN using protocol profiles. A protocol profile is a set of protocols to tunnel on an interface. Each distinct set of protocols is a different profile, and the same profile can be shared on multiple interfaces. However, these devices support only up to 8 profiles, which limits the number of protocol combinations you can configure to tunnel on the device.

Configure and Verify L2PT over VXLAN

To enable this feature, you configure statements in the l2pt stanza at the [edit protocols layer2-control] hierarchy level.

Configure and verify L2PT over VXLAN on the device as follows:

  1. Enable this feature on the access interface from which you want to use L2PT to forward any received control BPDUs transparently across the device's VXLAN tunnels. You must include the interface name and the destination vxlan-tunnel options:

    For example, you might configure a service provider style access interface (et-0/1/1:3) and enable L2PT over VXLAN for that interface as follows:

  2. Set protocol you want to tunnel when control BPDUs arrive on that interface. See the supported protocol options in Supported Protocols to Tunnel.

    Configure additional protocol protocol-name statements at this hierarchy for each protocol you want to tunnel from this interface.

    For example, configure the following if you want to transparently tunnel LLDP and VTP control frames coming in on interface et-0/1/1:3:

    To tunnel control BPDUs from all of the supported protocols from this interface, you can use a single statement and specify the all option, as follows:

  3. (Required on supported Junos OS Evolved QFX Series switches) Configure the enable-all-ifl option on the L2PT-enabled interface.

    When you commit a configuration update, the commit operation doesn't necessarily apply the statements in a predictable order. In a configuration update in which you enable L2PT on an interface, if the configuration update includes any logical interfaces on that physical interface, the commit operation might not also tag all of the logical interfaces as having L2PT enabled. The enable-all-ifl option ensures that all of the logical interfaces on the specified physical interface have the same L2PT settings.

  4. Repeat steps 1 through 3 for each access interface from which you want to tunnel control BPDUs for one or more protocols.
  5. Use the show l2pt interface CLI command to verify L2PT over VXLAN operation. This command displays the interfaces and protocols for which the device transparently tunnels control BPDUs across its VXLAN tunnels.

    For example:

    Or to display details only for a specified interface, such as et-0/1/1:3: