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

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

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

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