Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

EVPN

  • EVPN-MPLS E-LAN flow-aware transport (FAT) label load balancing (MX Series, EX9200, vMX) —Starting in Junos OS Release 22.4R1, you can configure provider edge (PE) devices to use FAT labels in an Ethernet VPN-MPLS (EVPN-MPLS) routing instance, according to Request for Comments (RFC) 6391. PE devices use these labels to load-balance EVPN-MPLS unicast packets across equal-cost multipaths (ECMPs) without performing deep packet inspection of the MPLS payload. This feature supports emulated LAN (ELAN) with single-homing and multi-homing active/standby and active/active topologies and supports the VLAN-based, VLAN-bundle, and VLAN-aware bundle EVPN-MPLS variants.

    Note:

    This feature does not support MX Series devices with Advanced Forwarding Toolkit (AFT) cards.
    Note:
    On MX Series devices, a configuration where the local PE has a static-flow-label and the remote PE does not have a static-flow-label, the remote PE can process packets without dropping any traffic.

    Enabling Load Balancing Using Fat Labels for EVPN Routing Instances:

    Warning:

    Configuring a flow label or deleting a flow label with the following CLI commands causes a catastrophic event for the routing instance. As a best practice, perform these CLI commands during a maintenance period to avoid network disruptions.

    • Configure the flow-label-static statement at the [edit routing-instances routing-instance-name protocols evpn] hierarchy level on PE devices to insert FAT flow labels into pseudowire packets sent to remote PE devices.

    • Configure the flow-label statement at the [edit routing-instances routing-instance-name protocols evpn] hierarchy level on PE devices to signal flow-label capability in the EVPN Layer 2 Attributes Extended Community by setting the flow-label (F) bit in the EVPN Type 3 route.

    [See flow-label and flow-label-static.]

  • EVPN-VPWS over SRv6 underlay (MX240, MX304, MX480, MX960, MX10003, MX10008, MX2010, and MX2020)—Starting in Junos OS Release 22.4R1, you can configure a single-active or an all-active multihomed Ethernet VPN–virtual private wireless service (EVPN-VPWS) network using segment routing over a Segment Routing for IPv6 (SRv6) underlay.

    [See Overview of VPWS with EVPN Signaling Mechanisms.]

  • EVPN-VXLAN to EVPN-VXLAN seamless stitching for EVPN Type 5 routes (EX4100-24T, EX4400-24MP, EX4400-24P, EX4400-48F, EX4650, MX204, MX240, QFX10002-60C, QFX10002, QFX10008, QFX10016, QFX5120-32C, QFX5120-48T, QFX5120-48Y, QFX5120-48Y-VC, QFX5120-24YM, and QFX5120-48YM)—Starting in Junos OS Release 22.4R1, you can configure Ethernet VPN–Virtual Extensible LAN (EVPN-VXLAN) to EVPN-VXLAN seamless stitching with EVPN Type 5 (IP prefix) routes between two interconnected data centers or between two points of delivery (pods) in a data center.

    In the EVPN-VXLAN fabric, border leaf or border spine devices act as interconnection gateways. You enable EVPN Type 5 routes in virtual routing and forwarding (VRF) instances on both sides of the interconnection. For each VRF instance, the server leaf devices in the first data center create VXLAN tunnels for Type 5 routes (with corresponding virtual network identifiers [VNIs]) toward their local gateway devices. The gateway devices map those VXLAN tunnels to an interconnection tunnel (with a new route distinguisher [RD], route target, and VNI) toward the second data center. The gateway devices in the second data center re-create the Type 5 VXLAN tunnels using their local RD.

    We support one-to-one mapping of Type 5 VRF instances across the interconnection.

  • Support for VXLAN group-based policy with ingress and egress configuration (EX4100, EX4400, EX4650, QFX5120-32C, and QFX5120-48Y)—Starting in Junos OS Release 22.4R1, we've added enhancements to the group-based policy (GBP) feature and made some changes to the CLIs.

    The enhancements are:

    • You can enforce the policy on the ingress endpoint or the egress tunnel endpoint. Ingress enforcement optimizes the network bandwidth. To configure policy enforcement at the ingress endpoint, use the set fowarding-options evpn-vxlan gbp ingress-enforcement command.

    • We support these match conditions for GBP tagging:

  • Pure EVPN Type 5 routes with EVPN-VXLAN (SRX Series and vSRX)—Starting in Junos OS Release 22.4R1, you can configure pure Type 5 routes in an Ethernet VPN–Virtual Extensible LAN (EVPN-VXLAN) environment. These devices use EVPN Type 5 routes to advertise IP prefixes for intersubnet connectivity within and across data centers.

    [See Understanding EVPN Pure Type 5 Routes and ip-prefix-routes.]

  • Routing protocols on EVPN-VXLAN overlay IRB interfaces in the default routing instance (EX4400, EX4650, EX9200, EX9253, QFX5110, QFX5120, QFX10002, QFX1008, and QFX10016)—Starting in Junos OS Release 22.4R1, you can run routing protocols on Ethernet VPN–Virtual Extensible LAN (EVPN-VXLAN) overlay integrated routing and bridging (IRB) interfaces in the IPv4 or IPv6 default routing instance associated with the underlay (default.inet.0 or default.inet6.0). To perform this task, you can set and export a policy with the install-next-hop except overlay-vxlan-interfaces policy qualifier option. The policy configuration avoids routing loops that can happen if the device uses overlay IRB routes for underlay VTEP reachability. To support this use case in releases prior to 22.4R1, you can configure the IRB interface in a routing instance of type vrf instead of in the default routing instance.

    [See install-nexthop.]

  • Support for Microsoft load-balancing node's static ARP entries with unicast MAC addresses (EX9208, MX-Series, and VMX)—Starting in Junos OS Release 22.4R1, you can configure a Microsoft load-balancing node's static Address Resolution Protocol (ARP) entries for unicast MAC addresses on integrated routing and bridging (IRB) interfaces. On your provider edge (PE) device, you can create a static ARP entry for the Microsoft load-balancing node’s virtual IP address and its unicast virtual MAC address. This static ARP configuration enables your PE devices to flood traffic for the Microsoft load-balancing node’s virtual IP address to the virtual MAC address in an EVPN Layer 2 domain or any other Layer 2 domain.

    To enable unicast MAC addresses on IRB interfaces, enable the flood-as-unknown-unicas option in the [edit interfaces irb unit <logical-interface-number> family inet address <local-ip-address>/<prefix-length> arp <MSLB-virtual IP address> mac <MSLB-unicast-VMAC>] hierarchy. The flood-as-unknown-unicast option enables flooding of virtual IP addresses and virtual MAC traffic flows from a Microsoft load-balancing cluster.

    [See EVPN User Guide.]

  • Remote port mirroring for EVPN-VXLAN with pure IPv6 underlay (QFX10002, QFX10002-60C, QFX10008, and QFX10016)—Starting in Junos OS Release 22.4R1, you can configure remote port mirroring in an Ethernet VPN–Virtual Extensible LAN (EVPN-VXLAN) environment with a pure IPv6 underlay. Remote port mirroring copies the packets of a traffic flow and delivers the mirrored packets to one or more destination hosts.

    [See MAC Filtering, Storm Control, and Port Mirroring Support in an EVPN-VXLAN Environment.]

  • Protect core support for EVPN-VXLAN (EX4300-MP, EX4400-48MP, EX4650, QFX5110, QFX5120-32C, QFX5120-48T, QFX5120-48Y, and QFX5120-48YM)—Starting in Junos OS Release 22.4R1, you can configure the protect core feature in an EVPN-VXLAN environment. You can use the protect core feature to install a route in the forwarding table for use as an alternative path when an existing route fails or if connectivity is lost.

    [See protect core.]

  • Overlay and CE-IP ping and traceroute support for EVPN-VXLAN (EX4300-MP, EX4400, EX4650, QFX5110, QFX5120, QFX5200, QFX10002, QFX10002-60C, QFX10008, and QFX10016)—Starting in Junos OS Release 22.4R1, you can perform ping and traceroute operations within an EVPN-VXLAN overlay or to a specific customer edge (CE) device IP address (CE-IP) across an EVPN-VXLAN overlay. You can use ping, traceroute, CE-IP ping, and CE-IP traceroute utilities to detect and isolate faults in overlay networks.

    [See Understanding Overlay Ping and Traceroute Packet Support.]

  • EBGP and IBGP support over IRB interfaces across PE-CE links for EVPN-MPLS (ACX5448)—Starting in Junos OS Release 22.4R1, you can configure external BGP (EBGP) and internal BGP (IBGP) over an integrated routing and bridging (IRB) interface which spans a provider edge (PE) device to customer edge (CE) device (PE-CE) link.

    [See EVPN with IRB Solution Overview.]

  • VXLAN filter group prioritization (QFX5110, QFX5120-32C, QFX5120-48T, QFX5120-48Y, QFX5120-48YM, and QFX5200)—Starting in Junos OS Release 22.4R1, when your device boots up, the device initializes VXLAN dynamic filter groups before the CLI filter groups. If you configure a CLI filter group before the VXLAN dynamic filter group, only the CLI filter group might be programmed in the TCAM space after you reboot your device. This situation might cause problems in your fabric.

    [See EVPN User Guide.]

  • Persistent MAC learning (sticky MAC) with EVPN-VXLAN (EX4400-24MP, EX4400-24P, EX4400-24T, EX4400-24X, EX4400-48F, EX4400-48MP, EX4400-48P, EX4400-48T)— Starting in Junos OS Release 22.4R1, you can enable network interfaces to retain dynamically learned MAC addresses when the switch is restarted or when an interface goes down and comes back up again.

    Note:

    We don’t support persistent MAC learning on virtual tunnel endpoint (VTEP) interfaces.

    [See Understanding and Using Persistent MAC Learning.]