VXLAN Constraints on EX Series, QFX Series, PTX Series, and ACX Series Devices

VXLAN support on a Virtual Chassis or Virtual Chassis Fabric (VCF) has the following constraints and recommendations:

• We support EVPN-VXLAN on an EX4300-48MP Virtual Chassis only in campus networks.

• Standalone EX4400 switches and EX4400 Virtual Chassis support EVPN-VXLAN. For multihoming use cases, hosts can be multihomed to standalone EX4400 switches, but we don’t support multihoming a host with ESI-LAG interfaces to EX4400 Virtual Chassis.

• Standalone EX4100 (EX4100 and EX4100-F) switches and EX4100 Virtual Chassis (EX4100 and EX4100-F) support EVPN-VXLAN. For multihoming use cases, hosts can be multihomed to standalone EX4100 switches, but we don't support multihoming a host with ESI-LAG interfaces to EX4100 Virtual Chassis.

• In data center networks, we support EVPN-VXLAN only on a Virtual Chassis or VCF consisting of all QFX5100 switches, and not on any other mixed or non-mixed Virtual Chassis or VCF. We support VCF in EVPN-VXLAN data center environments running Junos OS releases starting in 14.1X53-D40 and prior to 17.1R1. However, we don't recommend using EVPN-VXLAN on a QFX5100 Virtual Chassis or VCF because the feature support is at parity only with support on standalone QFX5100 switches running Junos OS Release 14.1X53-D40.

  We have deprecated VCF support in general from Junos OS Release 21.4R1 onward.

• When a QFX5100 Virtual Chassis learns a MAC address on a VXLAN interface, the MAC table entry can possibly take up to 10 to 15 minutes to age out (two to three times the 5-minute default aging interval). This happens when the Virtual Chassis learns a MAC address from an incoming packet on one Virtual Chassis member switch, and then must forward that packet over the Virtual Chassis port (VCP) links to another member switch in the Virtual Chassis on the way to its destination. The Virtual Chassis marks the MAC address as seen again at the second member switch, so the MAC address might not age out for one or two additional aging intervals beyond the first one. MAC learning can’t be turned off on VXLAN interfaces only at the second Virtual Chassis member switch, so you can’t avoid the extra delay in this case.

(QFX5120 switches only) Traffic that is tunneled via a core-facing Layer 3 tagged interface or IRB interface is dropped. To avoid this limitation, you can configure flexible VLAN tagging. For more information, see Understanding VXLANs.

(QFX5110 and QFX5120) If you configure an interface in the enterprise style with flexible Ethernet services encapsulation, the device drops transit Layer 2 VXLAN-encapsulated packets on that interface. To work around this issue, configure the interface in the service provider style instead of using the enterprise style. For more information on enterprise style and service provider style configurations, see Flexible Ethernet Services Encapsulation. For an overview of configuring flexible Ethernet services in an EVPN-VXLAN fabric, see Understanding Flexible Ethernet Services Support With EVPN-VXLAN.

(QFX5110 and QFX5120 switches) In EVPN-VXLAN fabrics, we don't support enterprise style, service provider style, and native VLAN configurations on the same physical interface if the native VLAN is the same as one of the VLANs in the service provider style configuration. The native VLAN can be one of the VLANs in the enterprise style configuration. For more information on enterprise style and service provider style configurations, see Flexible Ethernet Services Encapsulation.

(QFX5xxx switches) In an EVPN-VXLAN fabric, you can’t configure the native-vlan-id statement on the same interface where you enable VLAN translation with the vlan-rewrite statement.

(QFX5100, QFX5110, QFX5200, and QFX5210 switches) We support VXLAN configuration in the default-switch routing instance and in MAC VRF routing instances (instance-type mac-vrf).

(EX4300-48MP and EX4600 switches) We support VXLAN configuration only in the default-switch routing instance.

(QFX5100, QFX5200, QFX5210, EX4300-48MP, and EX4600 switches) Routing traffic between different VXLANs is not supported.

(QFX5100, QFX5110, QFX5120, EX4600, and EX4650 switches) These switches support only one VTEP next hop on VXLAN underlay IRB interfaces. If you don’t want to use multiple egress ports but need more than one VTEP next hop, as a workaround you can do one of the following:

• Place a router between the switch and the remote VTEPs so only one next hop is between them.

• Use physical Layer 3 interfaces instead of IRB interfaces for remote VTEP reachability.

(QFX5110 switches) By default, routing traffic between a VXLAN and a Layer 3 logical interface—for example, an interface configured with the set interfaces interface-name unit logical-unit-number family inet address ip-address/prefix-length command—is not enabled. If this routing functionality is required in your EVPN-VXLAN network, you can perform some additional configuration to make it work. For more information, see Understanding How to Configure VXLANs and Layer 3 Logical Interfaces to Interoperate.

Integrated routing and bridging (IRB) interfaces used in EVPN-VXLAN overlay networks do not support the IS-IS routing protocol.

(QFX5100, QFX5110, QFX5120, QFX5200, QFX5210, EX4300-48MP, and EX4600 switches) A physical interface cannot be a member of a VLAN and a VXLAN. That is, an interface that performs VXLAN encapsulation and de-encapsulation cannot also be a member of a VLAN. For example, if a VLAN that is mapped to a VXLAN is a member of trunk port xe-0/0/0, any other VLAN that is a member of xe-0/0/0 must also be assigned to a VXLAN.

(QFX5110, QFX5120, EX4100, and EX4400 switches) We don’t support VXLAN and non-VXLAN logical interfaces on the same physical interface using enterprise style interface configurations.

(QFX5120, EX4100, EX4300-48MP, EX4400, and EX4650 switches) With 802.1X authentication for VXLAN traffic on an access port, upon authentication, the RADIUS server dynamically switches the traffic from the original VLAN to a dynamic VLAN you configure as a VXLAN-enabled VLAN. A VXLAN-enabled VLAN is a VLAN for which you configure a VXLAN network identifier (VNI) mapping using the vxlan vni vni statement at the [edit vlans vlan-name] hierarchy.

When you configure the 802.1X dynamic VLAN and its corresponding VNI mapping, you must also configure the original VLAN as a VXLAN-enabled VLAN with a VNI mapping. If you don't explicitly configure the port as a member of a VLAN, the port uses the default VLAN. In that case, you must configure the default VLAN as a VXLAN-enabled VLAN with a VNI mapping.

Also, in releases before Junos OS Release 22.2R3-S3, when any dynamic VLAN is assigned to a port, that VLAN must already have been statically configured on another port on the device. Starting in Junos OS Release 22.2R3-S3, we no longer have this constraint.

See 802.1X Authentication and RADIUS Server Configuration for Authentication for more on dynamic VLAN assignment with a RADIUS server.

Multichassis link aggregation groups (MC-LAGs) are not supported with VXLAN.

IP fragmentation and defragmentation are not supported on the Layer 3 side.

The following features are not supported on the Layer 2 side:

• (QFX5100, QFX5200, QFX5210, EX4300-48MP, and EX4600 switches) IGMP snooping with EVPN-VXLAN.

• Redundant trunk groups (RTGs).

• The ability to shut down a Layer 2 interface or temporarily bring down the interface when a storm control level is exceeded is not supported.

• We don't support full STP, MSTP, RSTP, or VSTP (xSTP) features with VXLAN. However, you can configure xSTP on edge (access port) for BPDU block-on-edge support. See BPDU Protection for Spanning-Tree Protocols for details.

Access port security features such as the following are not supported with VXLAN:

• DHCP snooping.

• Dynamic ARP inspection.

• MAC limiting and MAC move limiting.

Some exceptions include:

• MAC limiting is supported on OVSDB-managed interfaces in an OVSDB-VXLAN environment with Contrail controllers. For more information, see Features Supported on OVSDB-Managed Interfaces.

• On these devices serving as L2 VXLAN gateways in EVPN-VXLAN centrally-routed bridging overlay networks:

  • EX4300 multigigabit switches starting in Junos OS Release 19.4R1

  • EX4400 switches starting in Junos OS Release 21.1R1

  • EX4400 multigigabit switches starting in Junos OS Release 21.2R1

  • EX4100 and EX4100-F switches starting in Junos OS Release 22.3R1

  • EX4100 multigigabit switches starting in Junos OS Release 22.3R1

  we support these access security features on Layer 2 access-side interfaces that are associated with VXLAN-mapped VLANs:

  • DHCPv4 and DHCPv6 snooping

  • Dynamic ARP inspection (DAI)

  • Neighbor discovery inspection (NDI)

  • IPv4 and IPv6 source guard

  • Router advertisement (RA) guard

  We support these features only on single-homed access interface connections.

Ingress node replication is not supported in the following cases:

• When PIM is used for the control plane (manual VXLAN).

• When an SDN controller is used for the control plane (OVSDB-VXLAN).

Ingress node replication is supported with EVPN-VXLAN.

PIM-BIDIR and PIM-SSM are not supported with VXLANs.

If you configure a port-mirroring instance to mirror traffic exiting from an interface that performs VXLAN encapsulation, the source and destination MAC addresses of the mirrored packets are invalid. The original VXLAN traffic is not affected.

(QFX5110 switches only) VLAN firewall filters are not supported on IRB interfaces on which EVPN-VXLAN is enabled.

(EX4650 and QFX5000 Series switches) Firewall filter and policer support:

• (QFX5100 switches) Firewall filters and policers are not supported on transit traffic on which EVPN-VXLAN is enabled. They are supported only in the ingress direction on CE-facing interfaces.

• (QFX5100 switches) For IRB interfaces in an EVPN-VXLAN one-layer IP fabric, firewall filtering and policing is supported only at the ingress point of non-encapsulated frames routed through the IRB interface.

• (EX4650, QFX5110, and QFX5120 switches) We support ingress filtering and policing for routed VXLAN interfaces (IRB interfaces) as ingress route Access Control Lists [IRACLs].

• (QFX5110, QFX5120, and QFX5210 switches) We support Ingress filtering and policing on non-routed VXLAN interfaces as ingress port ACLs [IPACLs]).

• (QFX5110 and QFX5120 switches) Filtering and policing support on non-routed VXLAN interfaces extends to the egress direction as egress Port ACLs ([EPACLs]).

(EX4300-48MP switches only) The following styles of interface configuration are not supported:

• Service provider style, where a physical interface is divided into multiple logical interfaces, each of which is dedicated to a particular customer VLAN. The extended-vlan-bridge encapsulation type is configured on the physical interface.

• Flexible Ethernet services, which is an encapsulation type that enables a physical interface to support both service provider and enterprise styles of interface configuration.

For more information about these styles of interface configuration, see Flexible Ethernet Services Encapsulation.

(QFX5100 switches only) Using the no-arp-suppression configuration statement, you can turn off the suppression of ARP requests on one or more specified VLANs. However, starting in Junos OS Release 18.4R3, you must turn off this feature on all VLANs. To do so, you can use one of these configuration options:

• Use a batch command to turn off the feature on all VLANs—set groups group-name vlans * no-arp-suppression. With this command, we use the asterisk (*) as a wildcard that specifies all VLANs.

• Use a command to turn off the feature on each individual VLAN—set vlans vlan-name no-arp-suppression.

QFX5120-48Y, QFX5120-32C, and QFX5200 switches support hierarchical equal-cost multipath (ECMP), which allows these switches to perform a two-level route resolution. However, all other QFX5xxx switches do not support hierarchical ECMP. As a result, when an EVPN Type-5 packet is encapsulated with a VXLAN header, then de-encapsulated by a QFX5xxx switch that does not support hierarchical ECMP, the switch is unable to resolve the two-levels of routes that were in the inner packet. The switch then drops the packet.

(QFX5100, QFX5110, QFX5120, QFX5200, and QFX5210 switches) When you configure the IRB interfaces on a device that is concurrently supporting configured VLANs on both a centrally-routed bridging overlay and an edge-routed bridging overlay, the IRB MAC address and virtual gateway MAC address on the IRB interface for the centrally-routed bridging overlay must be different from the IRB MAC address and virtual gateway MAC address on the IRB interface for the edge-routed bridging overlay.

(QFX5110 and QFX5120 switches only) In an EVPN-VXLAN overlay, we do not support running a routing protocol on an IRB interface that is in a default routing instance (default.inet.0). Instead, we recommend including the IRB interface in a routing instance of type vrf.

The following constraints apply to both VXLANs and VLANs.

• (QFX5xxx switches only) When configuring route leaking between virtual routing and forwarding (VRF) instances, you must specify each prefix with a subnet mask that is equal to or longer than /16 for IPv4 prefixes or equal to or longer than /64 for IPv6 prefixes. If a subnet mask that you specify does not meet these parameters, the specified routes will not be leaked.

• (QFX5120 switches only) By default, QFX5120 switches allocate 5 MB of a shared buffer to absorb bursts of multicast traffic. If a burst of multicast traffic exceeds 5 MB, the switch will drop the packets that the switch receives after the buffer space is exceeded. To prevent the switch from dropping multicast packets when this situation occurs, you can do one of the following:

  • Use the shared-buffer configuration statement in the [edit class-of-service] hierarchy level to reallocate a higher percentage of the shared buffer for multicast traffic. For more information about fine-tuning a shared buffer, see Understanding CoS Buffer Configuration.

  • On the Juniper Networks switch from which the bursts of multicast traffic are coming, apply a shaper on the egress link.

• (QFX5xxx switches only) If you have enabled storm control on an interface, you might notice a significant difference between the configured and actual traffic rates for the interface. This difference is the result of an internal storm control meter that quantifies the actual traffic rate for the interface in increments of 64 kbps, for example, 64 kbps, 128 kbps, 192 kbps, and so on.

(QFX5xxx and EX46xx switches) You can't use hardware-assisted inline Bidirectional Forwarding Detection (BFD) with VXLAN encapsulation of BFD packets. Also, if you configure EVPN overlay BGP peerings, use distributed BFD instead of hardware-assisted inline BFD. See Understanding How BFD Detects Network Failures for details on the different types of BFD sessions that you can configure.

(QFX5xxx and EX46xx switches) We don't support configuring and using MPLS and EVPN-VXLAN at the same time on the same device. We have this constraint because Broadcom-based platforms use the same hardware tables to store tunnel and virtual port information used by both the MPLS and VXLAN feature sets.

Also, you can't use an MPLS underlay with EVPN and a VXLAN overlay; this is a Broadcom hardware limitation.

(QFX5xxx and EX46xx switches) We don’t support tagged L3 interfaces and L2 bridge domains as subunits of the same interface with an IRB in service provider style configurations.

MC-LAGs are not supported with VXLAN.

IP fragmentation is not supported on the Layer 3 side.

The following features are not supported on the Layer 2 side:

• IGMP snooping with EVPN-VXLAN in Junos OS Releases before Junos OS Release 17.2R1.

• STP (any variant).

Access port security features are not supported with VXLAN. For example, the following features are not supported:

• DHCP snooping.

• Dynamic ARP inspection.

• MAC limiting and MAC move limiting.

Ingress node replication is not supported when an SDN controller is used for the control plane (OVSDB-VXLAN). Ingress node replication is supported for EVPN-VXLAN.

QFX10000 switches that are deployed in an EVPN-VXLAN environment do not support an IPv6 physical underlay network.

When the next-hop database on a QFX10000 switch includes next hops for both the underlay network and the EVPN-VXLAN overlay network, the next hop to a VXLAN peer cannot be an Ethernet segment identifier (ESI) or a virtual tunnel endpoint (VTEP) interface.

IRB interfaces used in EVPN-VXLAN overlay networks do not support the IS-IS routing protocol.

VLAN firewall filters applied to IRB interfaces on which EVPN-VXLAN is enabled.

Filter-based forwarding (FBF) is not supported on IRB interfaces used in an EVPN-VXLAN environment.

QFX10002, QFX10008, and QFX10016 switches do not support port mirroring and analyzing when EVPN-VXLAN is also configured.

When you configure the IRB interfaces on a device that is concurrently supporting configured VLANs on both a centrally-routed bridging overlay and an edge-routed bridging overlay, the IRB MAC address and virtual gateway MAC address on the IRB interface for the centrally-routed bridging overlay must be different from the IRB MAC address and virtual gateway MAC address on the IRB interface for the edge-routed bridging overlay.

In an EVPN-VXLAN overlay, we do not support running a routing protocol on an IRB interface that is in a default routing instance (default.inet.0). Instead, we recommend including the IRB interface in a routing instance of type vrf.

In an EVPN-VXLAN environment, we don't support configuring anycast gateways with the default-gateway statement and the advertise statement on links participating in the same Ethernet segment (ES).

You must configure class of service (CoS) rewrite rules to have the differentiated services code point (DSCP) bits copied from the inner VXLAN header to the outer VXLAN header.

You must enable tunnel termination globally on PTX10K series devices in EVPN-VXLAN deployments, as follows:

set forwarding-options tunnel-termination

You can't use a firewall filter on these devices to block VXLAN tunnel termination on specific ports, but you can use the following command to block VXLAN tunnel termination for a port:

set interfaces logical-interface-name unit n family inet/inet6 no-tunnel-termination

Multihoming peers within a DC should be from a similar product family. We do not recommend mixing ACX series with QFX series, PTX series, or MX series for multihoming.

(ACX 7xxx routers) Networks with both MAC and IP scale should configure set system packet-forwarding-options hw-db-profile cloud-metro. The default is lean-edge, which is intended for IP scale.

(ACX 7xxx routers) Load balancing is not enabled by default. Shown here is one sample configuration. Configure only those options necessary for your deployment.

(ACX 7xxx routers) Configure set system packet-forwarding-options system-profile vxlan-extended to support an EVPN-VXLAN IPv6 underlay.

(ACX 7xxx routers) Configure set system packet-forwarding-options system-profile vxlan-stitching to support EVPN-VLXAN to EVPN-VXLAN stitching, and EVPN-VXLAN to EVPN-MPLS stitching with no-control-word support.

(ACX 7xxx routers) Configure set system packet-forwarding-options system-profile vxlan-stitching control-word to support control word functions in a stitched EVPN-VXLAN to EVPN-MPLS network. Refer to vxlan-stitching for additional information regarding control word support.

(ACX 7xxx routers) One user defined Virtual Gateway Address (VGA) IPv4 MAC (virtual-gateway-v4-mac), and one user defined VGA IPv6 MAC (virtual-gateway-v6-mac) will be supported system wide.

(ACX 7xxx routers) Configure set system packet-forwarding-options no-ip-tos-rewrite to propagate DSCP information from payload to VXLAN router header during VXLAN encapsulation.

(ACX 7xxx routers) ESI configuration in EVPN multihoming mode is supported per physical interface device, or per LAG interface only.

(ACX 7xxx routers) IRB interfaces are not supported as EVPN-VXLAN underlay networks.

(ACX 7xxx routers) For EVPN-VXLAN to EVPN-MPLS stitching, devices which do not support forwarding based on bridge-domain labels will not be compatible with ACX series devices as DC peer GW's.

If you configure multiple sub-units on a port with an ESI, we don't support the disable operation (set interfaces logical-interface-name unit n disable) on those logical interfaces.