Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

EVPN

  • Default discard policy for GBP filters (EX4100, EX4400, EX4650, and QFX5120)—Starting in Junos OS Release 24.2R1, you can configure group-based policy (GBP) firewall filters with a default discard policy that is applicable when a packet fails to meet any of the match conditions.

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

  • MAC/IP inter-tagging for GBP filters (EX4100, EX4400, EX4650, and QFX5120)—Starting in Junos OS Release 24.2R1, you can apply media access control (MAC)-based GBP firewall filters to routed traffic and IP-based GBP firewall filters to switched traffic. This is called inter-tagging. Previously, MAC-based GBP filters applied to switched traffic and IP-based GBP filters applied to routed traffic. By enabling inter-tagging, your MAC-based and IP-based GBP filters apply to both switched and routed traffic.

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

  • Ingress policy enforcement and tag propagation (EX9204, EX9208, and EX9214)—Starting in Junos OS Release 24.2R1, the EX9204, EX9208, and EX9214 switches support ingress policy enforcement of group-based policy (GBP) firewall filters and GBP tag propagation for /32 IP routes. Ingress policy enforcement and GBP tag propagation save network bandwidth by discarding tagged packets at the ingress that would otherwise be discarded at the egress.

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

  • GBP tag propagation using EVPN Type 5 route advertisements (EX4400, EX4650, and QFX5120)—Starting in Junos OS Release 24.2R1, we support group-based policy (GBP) tag propagation using EVPN Type 5 route advertisements of IP prefixes. Switches and routers typically use EVPN Type 5 advertisements for exchanging routes between data centers. Prior to this release, we supported EVPN Type 2 to Type 5 route conversion between data centers, which resulted in /32 IP routes being exchanged instead of IP prefix routes.

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

  • Access security support in EVPN-VXLAN overlay networks (EX4650, QFX5120-32C, QFX5120-48T, QFX5120-48T-VC, QFX5120-48Y, QFX5120-48Y-VC, and QFX5120-48YM)—Starting in Junos OS Release 24.2R1, we support access security features on certain EX Series and QFX Series switches that function as Layer 2 VXLAN gateways in an Ethernet VPN–Virtual Extensible LAN (EVPN-VXLAN) centrally-routed overlay network (two-layer IP fabric). We support the following features on Layer 2 server-facing interfaces that are associated with VXLAN-mapped VLANs:

    The access security features function the same and you configure them in the same way in an EVPN-VXLAN environment as you do in a non-EVPN-VXLAN environment. However, keep these differences in mind:

    • We do not support these features on multihomed servers.

    • These features do not influence the VXLAN tunneling and encapsulation process.

  • MAC-VRF instances with EVPN-VXLAN (EX4100-48MP, EX4100-24MP, EX4100-48P, EX4100-48T, EX4100-24P, EX4100-24T, EX4100-F-48P, EX4100-F-24P, EX4100-F-48T, EX4100-F-24T, EX4100-F-12P, EX4100-F-12T, and EX4300-MP)—Support for the mac-vrf instance type includes vlan-based, vlan-aware, and vlan-bundle service types for EVPN unicast routes only.

    [See MAC-VRF Routing Instance Type Overview, mac-vrf, and service-type.]

  • MAC-VRF with EVPN-VXLAN (EX9204 and EX9208 switches)—Data center service providers must support multiple customers with their own routing and bridging policies in the same physical network. To accommodate this requirement, you can now configure multiple customer-specific EVPN instances (EVIs) of type mac-vrf, each of which can support a different EVPN service type. This configuration results in customer-specific virtual routing and forwarding (VRF) tables with MAC addresses on each Juniper Networks device that serves as a virtual tunnel endpoint (VTEP) in the Ethernet VPN–Virtual Extensible LAN (EVPN-VXLAN) network.

    Note:

    We support MAC-VRF routing instances for EVPN unicast routes only.

    To support this feature, we introduce a uniform routing instance configuration that complies with RFC 7432, BGP MPLS-Based Ethernet VPN. The uniform configuration eliminates hardware restrictions that limit the number of EVIs and the combinations of EVIs with their respective policies that can simultaneously exist. The common configuration includes the following new CLI elements:

    • The mac-vrf keyword at the [edit routing-instances name instance-type] hierarchy level.

    • The service-type configuration statement at the [edit routing-instances name] hierarchy level. We support VLAN-based, VLAN-aware, and VLAN-bundle service types.

    • (QFX10000 line of switches only) The forwarding-instance configuration statement at the [edit routing-instances name] hierarchy level. With this optional configuration statement, you can map multiple routing instances to a single forwarding instance. If you don’t include this configuration statement, the default forwarding instance is used.

      We continue to support the existing method of routing instance configuration along with the new uniform routing instance configuration.

      [See EVPN User Guide.]

  • sFlow support for EVPN-VxLAN multicast (EX4100-48MP, EX4100-24MP, EX4100-48P, EX4100-48T, EX4100-24P, EX4100-24T, EX4100-F-12P, EX4400-24MP, EX4400-24P, EX4400-24T, EX4400-24X, EX4400-48F, EX4400-48MP, EX4400-48P, and EX4400-48T)—Starting in Junos OS Release 24.2R1, you can use the sFlow technology to sample EVPN-VxLAN multicast traffic configured at the interface level.

    We support sampling with collector to be reachable through normal Layer 3 (L3) gateway (underlay), management IP (reachable through default or non-default routing-instance), or VXLAN tunnel (overlay).

    To enable known multicast sampling, use the CLI command set forwarding-options sFlow egress-multicast enable.

    [See Overview of sFlow Technology.]

  • EVPN-VXLAN fabric with an IPv6 underlay (EX4100-48MP, EX4100-24MP, EX4100-48P, EX4100-24P, and EX4100-24T)—Starting in Junos OS Release 24.2R1, you can configure an Ethernet VPN–Virtual Extensible LAN (EVPN-VXLAN) fabric with an IPv6 underlay. You can use this feature only with MAC-VRF routing instances (all service types). You must configure either an IPv4 or an IPv6 underlay across the EVPN instances in the fabric; you can’t mix IPv4 and IPv6 underlays in the same fabric.

    To enable this feature, perform these steps when you configure the EVPN underlay:

    • Configure the underlay VXLAN tunnel endpoint (VTEP) source interface as an IPv6 address:

      set routing-instances mac-vrf-instance-name vtep-source-interface lo0.0 inet6

    • Even though the underlay uses the IPv6 address family, for BGP handshaking to work in the underlay, you must configure the router ID in the routing instance with an IPv4 address:

      set routing-instances mac-vrf-instance-name routing-options router-id ipv4-address

    We support the following EVPN-VXLAN features with an IPv6 underlay:

    [See Understanding EVPN with VXLAN Data Plane Encapsulation and EVPN User Guide.]

  • L2PT with Q-in-Q over VXLAN tunnels in EVPN-VXLAN bridged overlay networks (EX4100-48P, EX4400-48F, QFX5120-32C, QFX5120-48T, QFX5120-48Y, and QFX5120-48YM)—Starting in Junos OS Release 24.2R1, we support Layer 2 protocol tunneling (L2PT) with Q-in-Q for traffic from an access interface to VXLAN tunnel destinations in a bridged overlay (BO) Ethernet VPN–Virtual Extensible LAN (EVPN-VXLAN) network. You can use this feature with service-provider style or enterprise-style access interface configurations.

    You can use L2PT over VXLAN tunnels with all of the Q-in-Q use cases we support for an EVPN-VXLAN network. For Q-in-Q, the device tunnels tagged frames over VXLAN using the VNI of the VLAN in the frame, and tunnels untagged frames using the VNI of the native VLAN.

    To enable this feature, configure the l2pt statement at the [edit protocols layer2-control] hierarchy level with the access interface name interface name and the following required options:

    • destination vxlan-tunnel—Enable L2PT for traffic toward a VXLAN tunnel destination.

    • protocol protocol-name—Specify a protocol to tunnel. Include additional protocol statements for each protocol you want to tunnel.

    [See Layer 2 Protocol Tunneling over VXLAN Tunnels in EVPN-VXLAN Bridged Overlay Networks, Examples: Tunneling Q-in-Q Traffic in an EVPN-VXLAN Overlay Network, and l2pt (Destination Tunnels).]

  • Suppress EVPN Type 5 host routes from DCI to DC (EX4400-24MP, EX4400-48F, MX304, QFX5120-32C, QFX5120-48T, QFX5120-48T-VC, QFX5120-48Y, QFX5120-48Y-VC, and QFX5120-48YM)—Starting in Junos OS Release 24.2R1, you can suppress EVPN Type 5 host route advertisements that re-originate from the data center interconnect (DCI) to the local DC. You can achieve better scaling and performance on leaf devices with this feature.

    [See suppress-host-routes-from-dci-to-dc.]

  • Enhanced OISM in EVPN-VXLAN ERB overlay networks with an IPv6 underlay (EX4100-48MP, EX4100-24MP, EX4100-48P, EX4100-48T, EX4100-24P, EX4100-24T, EX4100-F-48P, EX4100-F-24P, EX4100-F-48T, EX4100-F-24T, EX4100-F-12P, EX4100-F-12T, EX4400-24MP, EX4400-24P, EX4400-24T, EX4400-24X, EX4400-48F, EX4400-48MP, EX4400-48P, EX4400-48T, EX4650, QFX5120-32C, QFX5120-48T, QFX5120-48Y, and QFX5120-48YM)—Starting in Junos OS Release 24.2R1, you can configure enhanced optimized intersubnet multicast (OISM) for IPv4 and IPv6 multicast data traffic with an Ethernet VPN–Virtual Extensible LAN (EVPN-VXLAN) edge-routed bridging (ERB) overlay network that has an IPv6 underlay. To configure this feature:

    • Set up the EVPN-VXLAN fabric with an IPv6 underlay:

      • You can use either external BGP (EBGP) or OSPFv3 with IPv6 addressing for the IPv6 underlay.

      • Use the inet6 option when you set the VXLAN tunnel endpoint (VTEP) source interface to the device loopback interface in the EVPN instance (EVI):

    • Configure the enhanced OISM elements for your multicast EVPN-VXLAN environment in the same way you would configure these elements in an EVPN-VXLAN network with an IPv4 underlay.

      You can configure any of the supported platforms as enhanced OISM server leaf devices, and only EX4650 and QFX5120 switches as enhanced OISM border leaf devices.

    [See EVPN-VXLAN with an IPv6 Underlay and Optimized Intersubnet Multicast in EVPN Networks.]

  • Statically identify multihoming peer OISM leaf devices in an EVPN-VXLAN network running enhanced OISM (EX4100-24T, EX4300-MP, EX4400-24MP, EX4400-24P, EX4400-48F, EX4400-48MP, EX4650, QFX5120-32C, QFX5120-48T, QFX5120-48T-VC, QFX5120-48Y, QFX5120-48Y-VC, and QFX5120-48YM)—Starting in Junos OS Release 24.2R1, you can statically configure a multihoming peer leaf device to identify its peers in an Ethernet VPN–Virtual Extensible LAN (EVPN-VXLAN) network running enhanced optimized intersubnet multicast (OISM). EVPN-VXLAN provider edge (PE) leaf devices are multihoming peers when they share an Ethernet segment (ES) for a multihomed host. With enhanced OISM, if the leaf devices have static information about their multihoming peers, they can avoid multicast traffic loss when their peer devices go down and up again.

    On each multihoming peer leaf device, to identify the device’s multihoming peers, configure the multihoming-peer-gateways [peer-device-IPv4-address … ] statement at the [edit protocols evpn] hierarchy level. Specify a list of peer addresses within square brackets, or specify a single peer address without any brackets.

    [See Statically Identify Multihoming Peers With Enhanced OISM To Improve Convergence.]

  • Non-revertive preference-based DF election in EVPN-MPLS networks (EX4400-24P, MX960, and vMX)—Starting in Junos OS Release 24.2R1, you can configure non-revertive preference-based designated forwarder (DF) election for an Ethernet segment identifier (ESI) in an Ethernet VPN—MPLS (EVPN-MPLS) network. By default, preference-based DF election for an Ethernet segment identifier (ESI) is revertive, which means:

    • If the EVPN provider edge (PE) device currently in the DF role goes down, the next preferred PE device becomes the new DF.

    • When the old DF comes back up, the DF role reverts to the old DF.

    Changing the current DF role for an ESI frequently can impact traffic flow. To avoid revertive DF role changes, you can now set the non-revertive option at the [edit interfaces name esi df-election-type preference] hierarchy level.

    We also provide new options you can configure to load-balance DF election per EVPN instance (EVI) or per ESI based on the lowest configured preference value or the highest configured preference value, as follows:

    • At the EVI level—Use the designated-forwarder-preference-least option or the designated-forwarder-preference-highest option at the [edit routing-instances evpn-instance-name protocols evpn] hierarchy level.

    • At the ESI level—Use the least option at the [edit interfaces interface-name esi df-election-type preference] or [edit protocols evpn interconnect esi df-election-type preference] hierarchy level.

    [See df-election-type and evpn].

  • EVPN-VXLAN DCI multicast support with enhanced OISM (EX4400-24MP, EX4400-24P, EX4400-48F, EX4400-48MP, EX4650, QFX5120-32C, QFX5120-48T, QFX5120-48Y, and QFX5120-48YM)—Starting in Junos OS Release 24.2R1, we support Ethernet VPN–Virtual Extensible LAN (EVPN-VXLAN) to EVPN-VXLAN seamless Data Center Interconnect (DCI) with enhanced optimized intersubnet multicast (OISM). Without this feature, the DCI gateway devices flood multicast traffic across the interconnecting WAN. Flooding consumes significant WAN bandwidth if your network has many multicast flows or high multicast traffic rates. This feature seamlessly replaces the multicast flooding behavior. To optimize multicast forwarding across a DCI, OISM leaf devices in each network:

    • Advertise selective multicast Ethernet tag (SMET) routes (EVPN Type 6 routes) when a receiver subscribes to a multicast flow. The DCI gateways seamlessly propagate the SMET routes across the DCI on the OISM SBD.

    • Send multicast traffic based on the received SMET routes only to the remote receivers across the DCI who subscribed to that multicast flow.

    To configure this feature:

    • Configure the DCI gateway devices the same way you would configure the devices without multicast support.

    • Configure enhanced OISM in the networks on both sides of the DCI.

      • With enhanced OISM, you can configure each OISM device with only the VLANs that the device hosts, except on multihoming peer OISM devices and the peer DCI gateways in each data center network. On those peer devices, you must configure the OISM revenue VLANs symmetrically.

      • Configure the same OISM supplemental bridge domain (SBD) in the matching tenant virtual routing and forwarding (VRF) instances on both sides of the DCI.

    As OISM devices, the DCI gateways follow the enhanced OISM operational model to forward traffic to other OISM devices in their own network or across the DCI. They send the multicast traffic:

    • Across the DCI to the other DCI gateways only on the OISM SBD.

    • To other non-multihoming peer provider edge (PE) devices in their network only on the OISM SBD.

    • To their multihoming peer PE devices only on the source VLAN.

    You can also configure a DCI gateway as an OISM PIM EVPN gateway (PEG). The device acts as a DCI gateway and also as an OISM PEG border leaf device to exchange multicast traffic with devices outside of either network.

    [See Optimized Intersubnet Multicast in EVPN Networks.]

  • Generation of EVPN Type 3 routes on 802.1X dynamically mapped interfaces (EX4100-24MP, EX4300-MP, EX4400-24P, QFX5120-32C, QFX5120-48T, and QFX5120-48Y)—Starting in Junos OS Release 24.2R1, we support generating Ethernet VPN (EVPN) Type 3 routes across interfaces dynamically mapped by the 802.1X protocol to a Virtual Extensible LAN (VXLAN) extended bridge domain (BD).

    [See dot1x.]