Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Bridged Overlay Interface Configuration for EVPN-VXLAN

Overview of configuring Service Provider Style Bridged Overlay Interfaces for EVPN-VXLAN networks, that discusses VLAN-ID configuration, encapsulation strategies, and provides example configurations for practical implementations.

Overview

The EVPN-VXLAN bridged overlay is an Ethernet bridging method that extends VLANs between leaf devices across VXLAN tunnels without routing between VLANs. It creates a Layer 2 (L2) overlay network where VLAN traffic is encapsulated in VXLAN packets and sent between VXLAN Tunnel Endpoints (VTEPs). You can use this bridged overlay to create a scalable, flexible L2 extension over a Layer 3 (L3) underlay network, enabling seamless bridging of VLANs across a data center. When configuring the interfaces for bridged overlay, it is important to understand the key components and how they work together. These configurations dictate how tagged traffic is handled, whether the VLAN header is preserved or removed, and how traffic is encapsulated within the VXLAN header for transmission across the network.

In large-scale data centers, multitenant environments, and service provider networks, the service provider (SP) style of configuration in a bridged overlay network addresses the need for high scalability, operational simplicity, and a clear separation between underlay and overlay functions.

Components

Here's a brief overview of each component and how they are related:

  • IFL (Integrated Logical Interface): A logical interface (IFL) that is created on top of a physical interface (IFD) or an aggregated Ethernet interface. An IFD can have multiple logical interfaces with different configurations.

  • VLAN (Virtual Local Area Network): A VLAN is a L2 segment that groups devices on a network to communicate as if they were on the same physical LAN, irrespective of their actual physical location. In the context of VXLAN, VLANs are identified and mapped to bridge domains and VNIs.

  • BD (Bridge Domain): A bridge domain is similar to a VLAN in that it creates a L2 broadcast domain but can span multiple devices. It groups logical interfaces with shared L2 characteristics. In EVPN-VXLAN networks, it is configured with a unique VNI that enables extending the VLAN across the network using VXLANs.

  • VXLAN (Virtual Extensible LAN): The VXLAN protocol encapsulates L2 Ethernet frames within UDP packets to enable L2 connectivity over a L3 IP network. This encapsulation allows VLANs to be extended across the EVPN network.

  • VNI (VXLAN Network Identifier): A VNI is a unique identifier that maps to a bridge domain and its associated VLAN(s), enabling the encapsulation of VLAN traffic in VXLAN packets. All members of a VXLAN must use the same VNI. Devices use the VNI mapping to manage L2 segments over the VXLANs.

  • VTEP (VXLAN Tunnel Endpoint): A VTEP encapsulates and de-encapsulates Ethernet frames into or from VXLAN packets as they enter and exit the VXLAN overlay network.

  • Bridged Overlay (BO): A bridged overlay configuration extends VLANs across the network without routing between them. It uses VXLANs to bridge Ethernet traffic between VTEPs, enabling seamless communication within the same VLAN.

For more information about implementing a Bridged Overlay see: Bridged Overlay Design and Implementation.

Key Considerations

Service Provider Style vs. Enterprise Style IFLs

Junos OS supports two different configuration styles for switch interfaces—the service provider style and the enterprise style. The service provider style requires more configuration but provides greater flexibility. The enterprise style is easier to configure but offers less functionality.

Service provider (SP) style:

  • SP (Service Provider) style IFLs use vlan-bridge encapsulation. They are not automatically part of a BD but require explicit configuration under the vlans hierarchy to join the BD.

  • SP style supports more explicit VLAN tagging and encapsulation configurations than the EP style.

Enterprise (EP) style:

  • EP (Enterprise) style IFLs function in access or trunk mode within the ethernet-switching family and can automatically become part of multiple BDs with matching VLAN IDs or names. EP style interfaces are not configured under the vlans hierarchy for the BD.

The SP style and EP style interface configurations use different encapsulation types. You can use flexible Ethernet services to enable a physical interface to support multiple IFLs using different configuration styles and encapsulation types.

See Flexible Ethernet Services Encapsulation for more information.

VLAN-ID Configuration

You associate logical interfaces with VLANs using the vlan-id or vlan-id-list statements for SP style configurations and the vlan members statement with the EP configuration style. Configuring a vlan-id for a bridge domain is optional. However, it must be unique for each bridge domain if configured. Consider the following points when configuring VLAN IDs:

  • A BD without a VLAN ID configuration is only associated with SP IFLs that you explicitly configure under the vlans hierarchy and it does not support IRB L3 routing.

  • When you configure a BD with a VLAN ID, the BD can be associated with either SP IFLs, EP IFLs, or both.

  • If the BD has a vlan-id configured, you can configure the SP interfaces with the vlan-id statement but not the vlan-id-list statement.

  • If the BD does not have a vlan-id configured, you can use either the vlan-id or the vlan-id-list statements when you configure the associated SP style IFLs.

  • You must configure the BD with a vlan-id statement and either a VLAN ID or none to support an L3 IRB interface and L3 routing.

  • You only explicitly configure SP IFLs under the vlans hierarchy. EP style IFLs are associated with the BD when they are configured with the same VLAN ID as the BD.

Use and Handling of VLAN IDs

Interfaces configured with VLAN IDs will only accept ingress traffic with those specific tags in the VLAN header. The vlan-id and vlan-id-list configurations on the SP style interfaces specify which traffic those interfaces will accept. The vlan members configuration on EP style interfaces specifies which traffic those interfaces accept.

By default, tagged ingress traffic entering a BD has its VLAN header removed before being sent to a remote VTEP. The egress VTEP then sends out the traffic as tagged traffic based on its own VLAN ID configuration. You can change this behavior by adding the encapsulate-inner-vlan configuration to the VXLAN. This configuration encapsulates the incoming VLAN header and sends it across the bridge, ensuring the original VLAN ID is preserved at the egress VTEP.

Note: When you use the encapsulate-inner-vlan configuration, you must configure the source and remote VTEP with set protocols l2-learning decapsulate-accept-inner-vlan to enable the encapsulation and de-encapsulation of the VLAN IDs.

Example Configurations

The following configuration examples show variations of basic configurations for bridged overlay interfaces in an EVPN-VXLAN network. They do not include the underlying EVPN and VXLAN configurations required.

BD with SP Style Interfaces Using vlan-id-list

You can use SP style interface configurations with the vlan-id-list statement to associate 1 or more VLAN IDs with each interface when the BD does not have a vlan-id configured. Because the BD does not have a vlan-id configured, it will not support L3 routing. This example uses the encapsulate-inner-vlan statement to preserve the VLAN ID and send it out the egress VTEP interface.

With this sample configuration:

  • The EVPN overlay model is BO forwarding.

  • We configure the BD with only SP IFLs and no VLAN ID.

  • The SP IFLs are configured with the vlan-id-list statement that contains 1 or more VLAN IDs.

  • The ingress VTEP transports the ingress traffic VLAN tag to the remote VTEP’s egress interface.

BD with SP Style Interfaces Using vlan-id

You can use SP style interface configurations with the vlan-id statement to associate a single VLAN ID with each interface. The BDs in this example have a VLAN ID configured. So, the vlan-id-list statement cannot be used on the IFLs. This example shows 2 BDs with different VNIs. Both BDs use the encapsulate-inner-vlan statement to preserve the VLAN ID on incoming traffic and send it out the egress VTEP interfaces.

With this sample configuration:

  • The EVPN overlay model is BO forwarding.

  • We have 2 different BDs with different VNIs.

  • We configure only SP IFLs, one BD with a VLAN ID and one without a VLAN ID.

  • The SP IFLs are configured with the vlan-id statement and a single VLAN ID.

  • The ingress VTEP transports the ingress traffic VLAN tag to the remote VTEP’s egress interface.

BD with SP Style Interfaces with Different IFLs from the same Physical Interface (IFD)

Sometimes you may need to have different IFLs with different VLAN ID configurations that are on the same IFD configured in the same BD. This configuration requires that both the no-arp-suppression and the encapsulate-inner-vlan statements be configured on each VLAN in order to work.

With this sample configuration:

  • The EVPN overlay model is BO forwarding.

  • We configure the BD with only SP IFLs and no VLAN ID.

  • We have different IFLs from the same IFD with different VLAN ID configurations.

  • The ingress VTEP transports the ingress traffic VLAN tags to the remote VTEP’s egress interface.

Note: When the configuration has different IFLs from the same IFD configured in the same BD, it also requires the no-arp-suppression and encapsulate-inner-vlan configurations to work. Without these 2 configuration statements the configuration will not work.
Note: In Junos OS Releases you can configure the no-arp-suppression statement to turn off suppressing ARP packets and NDP packets. However, starting in Junos OS Release 19.1R1, that statement is hidden in the Junos CLI.

BD with a Mixture of SP and EP Style Interfaces

You can configure a BD with a mixture of SP and EP style IFLs. This requires that the BD have a VLAN ID configured to support the EP style IFLs. Also, the SP style IFLs will need to use the vlan-id statement and not the vlan-id-list statement. This configuration will not work with the no-arp-suppression and the encapsulate-inner-vlan statements configured. Therefore, the incoming tagged traffic is normalized by removing the VLAN header before adding the VXLAN encapsulation and sending it to the remote VTEP. In this example we have a BD associated with an EP style interface with the VLAN ID 100 and an SP style interface configured explicitly in the BD.

You can verify that both IFLs are associated with the BD by using the show vlans command.

With this sample configuration:

  • The incoming tagged traffic is normalized before adding the VXLAN encapsulation.

  • We configure the BD with a VLAN ID and a mix of EP and SP IFLs.

  • The SP IFL is configured with the vlan-id statement and a single VLAN ID.

  • The EP IFL is configured with a VLAN ID that matches the BD VLAN ID.

You can verify that both interfaces in the above configuration are associated with the BD by using the show vlans command. In the example outputs below, you can see that both the EP IFL xe-0/0/0.0 and the SP IFL xe-0/0/1.1 are associated with VLAN BD-100.

BD with EP Style Interfaces with VLAN ID Specified in BD

The SP configuration style supports more explicit VLAN tagging and encapsulation configurations while the EP style offers a simpler configuration model with automatic placement of interfaces into bridge domains as shown in this example.

We included this example here to add some background information for understanding EP style interfaces in the "Real World Case Analysis" that follows it.

For more information about implementing CRB and ERB see: Centrally-Routed Bridging Overlay Design and Implementation and Edge-Routed Bridging Overlay Design and Implementation.

With this sample configuration:

  • The EVPN overlay model is BO forwarding, CRB, and ERB.

  • We configured the BD with a VLAN ID that matches multiple EP IFLs.

  • We have not explicitly configured any SP IFLs

  • This model can support L3 routing using IRBs.

Real World Case Analysis: BDs with Different Interface Style Configurations on the Same Device

The following is a use case analysis comparing an SP style configuration and an EP style configuration on the same device. This case illustrates why it is important to understand the differences between the SP and EP configuration styles. In this example, there is a potential for confusion because we have interfaces in two different BDs, accepting traffic with the VLAN tag of 4013 and they treat that traffic differently when forwarding it to their respective VTEPs.

It is important to note in this case that the SP style and EP style interface configurations are not combined in the same BD. This example illustrates different BDs on the same device with the BDs using different interface configuration styles.

In this case, the SP style and the EP style configurations both have interfaces that accept traffic tagged for VLAN 4013, but they have different VNI configurations. So, even though they both accept VLAN 4013, they are not in the same BD.

Additionally, bridge domain BD-4011 uses the encapsulate-inner-vlan configuration while bridge domain BD-4013 does not. So they are treating the incoming VLAN tags differently. BD-4011 preserves the ingress VLAN tag within the VXLAN encapsulated traffic then sends it to the remote VTEP which forwards it out the egress interface. However, BD-4013 removes the ingress VLAN tags before adding the VXLAN encapsulation and forwarding it to the remote VTEP. The remote VTEP then adds its own VLAN tag before sending it out the egress interface.

Note: When you use the encapsulate-inner-vlan configuration, you must configure the source and remote VTEP with set protocols l2-learning decapsulate-accept-inner-vlan to enable the encapsulation and de-encapsulation of the VLAN IDs.

SP Style Analysis: (BD-4011)

In this configuration:

  • The EVPN overlay model is BO forwarding.

  • We configured BD-4011 (VNI 16004) with only SP IFLs, no VLAN ID is configured.

  • We configured the SP IFLs with the vlan-id-list statement and one VLAN ID.

  • The configurations on IFLs ae52.2/ae6.3 will accept ingress traffic tagged with 4013.

  • We used the encapsulate-inner-vlan statement to preserve the ingress traffic VLAN tag.

  • VXLAN encapsulates the tagged traffic and forwards to the remote VTEP interface.

  • The remote VTEP sends out the traffic with the original VLAN header regardless of its local VLAN ID configuration.

EP Style Analysis: (BD-4013)

In this configuration:

  • The EVPN overlay model is BO forwarding/CRB/ERB.

  • We configured BD-4013 (VNI 4013) with VLAN ID 4013 to match EP IFLs with the same VLAN ID

  • This configuration can support L3 routing using IRBs.

  • We did not configure any explicit SP IFLs in the BD.

  • IFL ae8.0 in BD-4013 accepts ingress traffic tagged with 4009, 4013, and 4014 because those VLAN IDs are listed in vlan members statement.

  • Ingress traffic from ae8.0 will be normalized (VLAN tag removed).

  • VXLAN encapsulates the untagged traffic and forwards it to the remote VTEP interface.

  • The remote VTEP adds a VLAN header based on the egress interface's VLAN ID configuration.

Comparison Analysis of SP style configuration and SP style configuration:

Some key points for the comparison of these configurations:

  • SP style and EP style are configured on same device in different BDs (different VNI).

  • Neither BD has a mixture of EP and SP IFLs.

  • EP style BD (BD-4013) only contains EP IFLs.

  • SP style BD (BD-4011) only contains SP IFLs.

  • EP style IFL ae8.0 accepts ingress traffic tagged with 4009, 4013, and 4014.

  • SP style IFLs ae52.2/ae6.3 accept ingress traffic tagged with 4013 and preserves this tag.

  • BD-4011 preserves the ingress VLAN tags within the VXLAN encapsulated traffic sent to the remote VTEP.

  • BD-4013 removes the ingress VLAN tags, sending untagged VXLAN encapsulated traffic to the remote VTEP.

Case Analysis Configurations

SP Style Configuration:

EP Style Configuration:

Related Documentation