Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

EVPN

  • Copy and preserve 802.1p CoS priority bits between VLAN S-tags and C-tags with EVPN-VXLAN (QFX5130-32CD, QFX5130-48C, QFX5130-48CM, QFX5130E-32CD, QFX5700, and QFX5700E)—Use this feature to copy and preserve the 802.1p priority between customer VLAN headers (C-tags) and service provider VLAN headers (S-tags) in EVPN-VXLAN traffic. We support this feature with service provider-style interface configurations.

    • When a leaf device adds an S-tag to a packet, this feature copies the class-of-service (CoS) priority bits from the C-tag to the S-tag.

    • When a leaf device removes an S-tag from a packet, this feature retains the priority bits from the C-tag.

    • The traffic priority remains unchanged in the VXLAN tunnel.

    Use the vxlan-enable-dot1p-copy option at the [edit forwarding-options] hierarchy level to enable this behavior. This setting overrides VLAN rewrite settings.

    [See forwarding-options.]

  • EVPN multihoming and multitenancy support over colored IP fabric with BGP DPF (QFX5130-32CD, QFX5240-64OD, and QFX5240-64QD)—You can leverage EVPN-VXLAN over colored IP fabric using BGP deterministic path forwarding (DPF) to support multihoming and multitenancy configurations for AI/ML applications. This functionality facilitates EVPN for Layer 3 networks with EVPN Type 5, enhancing network segmentation and resource allocation. By using a colored logical fabric, you can achieve flexible routing as uncolored routes integrate seamlessly with all color-coded sessions, optimizing network efficiency and adaptability.

    [See BGP Deterministic Path Forwarding in a CLOS Network.]

  • IGMP snooping and MLD snooping in EVPN-VXLAN bridged overlay networks with IPv4 or IPv6 underlays (QFX5130-32CD, QFX5130-48, QFX5130-48CM, and QFX5700)—With IGMP snooping and MLD snooping, the devices in an EVPN-VXLAN network forward multicast traffic flows only to the hosts that subscribe to those flows, rather than flooding the traffic to all hosts. Now you can enable Layer 2 (L2) multicast with IGMP snooping for intra-VLAN IPv4 multicast traffic and MLD snooping for IPv6 multicast traffic in an EVPN-VXLAN bridged overlay network with:

    • IPv4 or IPv6 underlay peering in the EVPN-VXLAN network with both IPv4 and IPv6 data traffic.

    • MAC-VRF EVPN instances with vlan-based or vlan-aware service types.

    • Enterprise-style interfaces.

    You must configure the bridge domains (VLANs) symmetrically on EVPN multihoming peer devices.

    [See Multicast Support in EVPN-VXLAN Overlay Networks and Overview of Multicast Forwarding with IGMP Snooping or MLD Snooping in an EVPN-VXLAN Environment .]

  • Hardware-assisted inline BFD for EVPN-VXLAN types 2 and 5 with 3x 100-ms timers (QFX5130-32CD, QFX5130-48C, QFX5130E-32CD, QFX5700, and QFX5700E)—You can use hardware-assisted inline BFD over VXLAN tunnels for rapid, deterministic failure detection with 100 x 3 millisecond timers on supported platforms. Use IPv4 and IPv6 multihop BFD for Type 2 (L2/L3) with ECMP or multihomed VTEPs. Use Type 5 with ECMP, including pure Type 5 routing instances. To enable hardware-assisted inline BFD, configure bfd on overlay bgp sessions, peer overlays between loopbacks, and apply the specified timers.

    [See Understanding How BFD Detects Network Failures.]

  • Egress rate limiting per VNI for VXLAN unicast and BUM traffic (QFX5130-32CD, QFX5130-48C, QFX5130-48CM, QFX5130E-32CD, QFX5700, and QFX5700E)—You can enforce per-VNI egress rate limits on VXLAN tunnel-initiated traffic to prevent congestion, mitigate denial-of-service (DoS) risk, and prioritize critical services. This configuration targets VXLAN traffic and preserves locally switched or routed flows. We added a new egress VLAN ACL filter profile to support the egress rate limit per VNI feature. You enable this profile with set system packet-forwarding-options firewall profiles ethernet-switching egress profile1. Changing the filter profile triggers a Packet Forwarding Engine restart. Create the filter using set firewall family ethernet-switching filter filter-name term term-name from vxlan tunnel-initiated and traffic-type known-unicast for unicast traffic or traffic-type-except known-unicast for BUM traffic. Set two-color or three-color policers with the discard action and attach the filters per VLAN with set routing-instances instance-name vlans vlan-name forwarding-options filter output filter-name. You use show firewall to view policer statistics.

    [See ethernet-switching and tunnel-initiated.]

  • sFlow support for EVPN-VXLAN multicast (QFX5130-32CD, QFX5130E-32CD, QFX5130-48C, QFX5130-48CM, and QFX5700)—You can use sFlow technology to sample EVPN-VXLAN multicast traffic configured at the interface level on customer-facing ports. The software replication of samples is also enabled. The software replicates each sample to all egress-sampling-enabled interfaces that are part of the multicast group.

    The sFlow collector can be reached through a standard Layer 3 gateway (underlay), a management IP address (reachable through the default or a nondefault routing instance), or a VXLAN tunnel (overlay).

    To enable known multicast sampling (disabled by default), use the set protocols sflow egress-multicast command.

    To set the maximum packet replication rate in software (the default is 2000), use set protocols sflow max-replication-rate 1000.

    Limitations:

    • The out-priority field for a VLAN is always set to 0 in sFlow samples.

    • IPv6 underlay transport for the EVPN-VXLAN sFlow use case is not supported.

    • EVPN-VXLAN unknown multicast traffic is not sampled; only known multicast traffic is supported for sampling.

    [See sFlow Technology Overview.]

  • Symmetric IRB for IPv6 underlay with EVPN Type-2 MAC-IP routes for intersubnet routing (QFX5130-32CD and QFX5130-48C)—You can now use symmetrical integrated routing and bridging (IRB) to forward traffic consistently across all provider edge (PE) devices. The device carries EVPN Type 2 MAC-IP routes across an IPv6 underlay that provides an ECMP transport for scalable, multitenant L2 and L3 connectivity. For each routing instance, use the irb-symmetric-routing vni statement under the [edit protocols evpn] hierarchy to maintain symmetrical bridging and routing.

    [See EVPN-VXLAN with an IPv6 Underlay and Symmetric Integrated Routing and Bridging with EVPN Type 2 Routes in EVPN-VXLAN Fabrics.]

  • Automatically synchronize multicast router interface status among EVPN multihoming peers in EVPN-VXLAN bridged overlays (QFX5130-32CD, QFX5130-48C, QFX5130-48CM, and QFX5700)—

    Multihoming peer EVPN-VXLAN border leaf (BL) devices that connect to external multicast receivers will now automatically synchronize the multicast router (mrouter) interface status for the EVPN segment identifiers (ESIs) the peer devices share. This feature ensures that multicast traffic reaches external receivers when a non-designated forwarder (NDF) BL peer device receives IGMP or MLD queries from the external PIM domain.

    The peer BL devices:

    • Use EVPN Type 7 Join Sync routes to communicate the mrouter interface status among their ESI peers.

    • Advertise EVPN Type 3 Inclusive Multicast Ethernet Tag (IMET) routes that enable the other EVPN devices to learn how to reach the mrouter interfaces.

    This behavior happens by default, so you no longer need to manually configure the multicast-router-interface setting on the multihoming peer BL devices. If needed, you can disable this behavior using the skip-multicast-router-port-sync-nlri statement at the [edit protocols evpn] hierarchy level.

    We support this feature in EVPN-VXLAN bridged overlay (BO) networks with IPv4 or IPv6 underlay peering.

  • Enable scaling for stretched VXLAN campus networks (QFX5130-32CD and QFX5700)—To support large-scaled stretched VXLAN campus networks, we provide new routing policy options, sample routing policies, and new statements to optimize how host routes are managed across the access, distribution, and core layers. With this feature, you can configure the network to install host routes in the core layer but not advertise the host routes to the distribution and access layers. The core devices advertise only subnet routes (using EVPN Type 5 routes) to the distribution devices. The distribution devices then advertise the subnet routes to the access layer. The configuration includes policies to ensure the EVPN Type 5 subnet routes are the preferred routes on the distribution and access layer devices. This design reduces the route table burden on access and distribution devices, enabling greater scalability.