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.

Enabling Load Balancing Using Fat Labels for EVPN Routing Instances:

• 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-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, 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:

  • interface <interface_name>

  • mac-address <mac address>

  • vlan-id <vlan id>

  • ip-version ipv4 <ip address> or <prefix-list>

  • ip-version ipv6 <ip address> or <prefix-list>

    [See Example: Micro and Macro Segmentation using Group Based Policy in a VXLAN.]

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

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

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.

[See Understanding and Using Persistent MAC Learning.]