EVPN
-
Support for blocking asymmetric EVPN Type 5 routes (MX960, QFX5110, and QFX10002)—Starting in Junos OS Release 22.2R1, you can configure the local node to reject asymmetric EVPN Type 5 routes on EVPN-VXLAN networks. The local node examines the incoming EVPN Type 5 route packets and rejects the route when the virtual network identifier (VNI) in the ingress route differs from the locally configured VNI.
To block asymmetric EVPN Type 5 routes, include the
reject-asymmetric-vni
statement at the[edit routing-instance routing-instance-name protocols evpn ip-prefix-routes]
hierarchy level.[See EVPN Type 5 Route with VXLAN encapsulation for EVPN-VXLAN and ip-prefix-routes.]
-
Automatically derived ESI configuration (MX Series, QFX5100, QFX5110, QFX5120-32C, QFX5120-48T, QFX5120-48Y, QFX10002, QFX10002-60C, QFX10008, and QFX10016)—In the current implementation, Junos OS derives the Ethernet segment identifier (ESI) from the system ID and the administrative key on the local multihomed provider edge (PE) device that is a part of the LACP link (actor). Starting in Junos OS Release 22.2R1, you can also configure the multihomed devices on an EVPN-VXLAN network to automatically generate the ESI from:
-
The system ID and administrative key on the remote customer edge (CE) device (partner).
-
The locally configured
mac
and local discriminator values.
To automatically derive the ESI using the system ID and administrative key on the remote CE device, include
type-1-lacp
at the[edit interfaces aeX aggregated-ether-options lacp auto-derive]
hierarchy level.To automatically derive the ESI using locally configured values, configure
mac
andlocal-discriminator
at the[edit interfaces aeX aggregated-ether-options lacp auto-derive type-3-system-mac]
hierarchy level.[See Understanding Automatically Generated ESIs in EVPN Networks.]
-
-
EVPN/VXLAN MAC filtering and transit VNI match support for pure IPv6 underlay (QFX10002, QFX10008, and QFX10016)—Starting in Junos OS Release 22.2R1, we support MAC filtering on a Layer 2 interface in the EVPN-VXLAN context. We've also implemented VXLAN network identifier (VNI) matching on source and destination IP outer headers for transit traffic on a Layer 3 interface. The device matches VNI values on outer headers only, and on ingress traffic only. On transit devices that are routing tunnel packets, MAC filtering must support matching the VNI in the outer header, along with outer header source and destination IPv6 addresses as match conditions. Use the VNI match filter under the
vxlan match
CLI option for theset firewall family inet6 filter term from vxlan vni vni-id
command. Use theshow firewall filter
command to display statistics.[See MAC Filtering, Storm Control, and Port Mirroring Support in an EVPN VXLAN Environment.]
-
Support for service provider style CLI in EVPN-VXLAN Layer 3 gateways (EX4650, QFX5110, QFX5120-32C, QFX5120-48T, QFX5120-48Y, and QFX5120-48YM)—Starting in Junos OS Release 22.2R1, you can use the service provider style CLI to configure a Layer 3 gateway in an edge-routed bridging scenario. In this scenario, you can map an IRB interface to a virtual network identifier and perform VXLAN routing.
You can use the service provider CLI when the interface VLAN ID is the same or different from the VLANs VLAN-ID. If the VLAN ID is different, the VLAN ID can be “none” or between 1 and 4,000.
[See EVPN User Guide.]
-
Optimized intersubnet multicast (OISM) with MAC-VRF instances and IGMPv2 or IGMPv3 in an EVPN-VXLAN fabric (EX4650, QFX5110, QFX5120, QFX10002, QFX10008, and QFX10016)—Starting in Junos OS Release 22.2R1, you can configure OISM on leaf devices and border leaf devices in an EVPN-VXLAN ERB overlay fabric with:
-
MAC-VRF routing instances or the default switch instance with IGMPv2 or IGMPv3.
-
IGMP snooping and selective multicast Ethernet tag (SMET) forwarding optimizations with IGMPv2 or IGMPv3.
When you configure OISM, you must enable OISM and IGMP snooping on all the server leaf and border leaf devices in the EVPN-VXLAN fabric. With a MAC-VRF instance configuration, you configure the OISM supplemental bridge domain (SBD) and all revenue VLANs in the MAC-VRF instances on all leaf and border leaf devices in the fabric.
-
-
Assisted replication (AR) integrated with optimized intersubnet multicast (OISM) in an EVPN-VXLAN ERB fabric (QFX5110, QFX5120, QFX10002-32Q, QFX10002-72Q, QFX10008, and QFX10016)—Starting in Junos OS Release 22.2R1, you can configure AR and OISM together in an EVPN-VXLAN ERB overlay fabric.
You can configure the following devices in each AR role in an integrated AR and OISM environment:
-
AR replicator: QFX10002-32Q, QFX10002-72Q, QFX10008, and QFX10016
-
AR leaf: QFX5110, QFX5120, QFX10002-32Q, QFX10002-72Q, QFX10008, and QFX10016
Here is a summary of integrated AR and OISM support:
-
AR leaf devices can be OISM server leaf or border leaf devices.
-
AR replicator devices can operate in either collocated mode (the device is both an AR replicator and an OISM border leaf device) or standalone mode (the device is an AR replicator but not an OISM border leaf or server leaf device). In ERB fabrics, a standalone mode AR replicator is usually a lean spine device.
-
AR replicator devices must be running Junos OS software that supports OISM (even when operating in standalone mode).
When you configure AR devices:
-
You can configure the EVPN instances using the default switch instance or using MAC-VRF instances (with
vlan-based
orvlan-aware
service types only). -
With standalone mode, you must configure the AR replicator devices with the same tenant VRF instances, corresponding IRB interfaces, and member VLANs as the OISM border leaf and server leaf devices.
[See Assisted Replication Multicast Optimization in EVPN Networks and Optimized Intersubnet Multicast in EVPN Networks.]
-