Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

VXLAN Constraints on QFX Series and EX Series Switches

When configuring Virtual Extensible LANs (VXLANs) on QFX Series and EX Series switches, be aware of the constraints described in the following sections. In these sections, “Layer 3 side” refers to a network-facing interface that performs VXLAN encapsulation and de-encapsulation, and “Layer 2 side” refers to a server-facing interface that is a member of a VLAN that is mapped to a VXLAN.

VXLAN Constraints on QFX5xxx, EX4300-48MP, and EX4600 Switches

  • 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 and an EX4400 Virtual Chassis only in campus networks.

    • 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. However, we do not 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.

    • 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 disabled 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.

  • (QFX5100, QFX5110, QFX5200, QFX5210, EX4300-48MP, and EX4600 switches) VXLAN configuration is supported only in the default-switch routing instance.

  • (QFX5100, QFX5200, QFX5210, and EX4600 switches) Routing traffic between different VXLANs is not supported.

  • (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 disabled. 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.

    Note:

    Starting in Junos OS Releases 18.1R3 and 18.4R1 for QFX5100, QFX5110, QFX5200, and QFX5210 switches and Junos OS Release 19.4R1 for QFX5120 switches, this limitation no longer applies because you can configure flexible Ethernet services on the physical interface. For more information, see Understanding Flexible Ethernet Services Support With EVPN-VXLAN.

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

    Note:

    In an EVPN-VXLAN environment, EVPN multihoming active-active mode is used instead of MC-LAG for redundant connectivity between hosts and leaf devices.

  • 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, and EX4600 switches) IGMP snooping with EVPN-VXLAN.

    • Redundant trunk groups (RTGs).

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

    • STP (any variant).

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

    • DHCP snooping.

      Note:

      Exceptions: EX4300-48MP and EX4400 switches support DHCP snooping with VXLAN.

    • Dynamic ARP inspection.

      Note:

      Exceptions: EX4300-48MP and EX4400 switches support Dynamic ARP inspection with VXLAN.

    • MAC limiting and MAC move limiting.

      Note:

      Exceptions:

      • EX4300-48MP switches support MAC limiting and MAC move limiting with VXLAN.
      • 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.

  • 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.

  • (QFX5100 and QFX5110 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 and QFX5110 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.

  • (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 disable the suppression of ARP requests on one or more specified VLANs. However, starting in Junos OS Release 18.4R3, you must disable this feature on all VLANs. To do so, you can use one of these configuration options:

    • Use a batch command to disable 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 disable 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.

VXLAN Constraints on QFX10000 Switches

  • MC-LAGs are not supported with VXLAN.

    Note:

    In an EVPN-VXLAN environment, EVPN multihoming active-active mode is used instead of MC-LAG for redundant connectivity between hosts and leaf devices.

  • 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.