Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

EVPN

  • EVPN-VXLAN fabric with an IPv6 underlay (EX4400-24MP, EX4400-24P, EX4400-24T, EX4400-24X, EX4400-48F, EX4400-48MP, EX4400-48P, and EX4400-48T)—Starting in Junos OS Release 23.4R1, 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, include 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

    • Configure a router ID in the routing instance as a 32-bit unsigned integer value in dotted quad decimal notation. You must configure this for BGP handshaking to work in the underlay even though the underlay uses the IPv6 address family.

      set routing-instances mac-vrf-instance-name routing-options router-id router-ID

    • Enable the Broadcom VXLAN flexible flow feature, which is required in Junos OS Release 21.2R2 where the feature is not enabled by default:

      set forwarding-options vxlan-flexflow

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

    [See EVPN-VXLAN with an IPv6 Underlay.]

  • Backup liveness detection on EVPN dual homed peers (EX4100-48MP, EX4100-H-12P-DC, EX4100-H-24P, EX4100-H-24F-DC, 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, and EX4650)—Starting in Junos OS Release 23.4R1, we've added support for backup liveness detection for EVPN peers. This feature addresses a gap in the core isolation feature that halts traffic within a data center with two spine devices when the BGP session between those devices goes down. You can configure backup liveness detection to track the state of the adjacent peer in conjunction with core isolation to ensure that the links to one of the spine devices stay up even during a BGP session failure. This configuration allows traffic within the data center to continue.

    [See Backup Liveness Detection on EVPN Dual Homed Peers]

  • Enhanced OISM with IGMPv2, IGMPv3, and IGMP snooping for IPv4 multicast traffic in EVPN-VXLAN fabrics (EX4100-24MP, EX4100-48MP, EX4100-24P, EX4100-48P, EX4100-24T, EX4100-48T, EX4400-24MP, EX4400-24P, EX4400-24T, EX4400-48F, EX4400-48MP, EX4400-48P, EX4400-48T, and EX4650)—Starting in Junos OS Release 23.4R1, we support an enhanced optimized intersubnet multicast (OISM) model with IGMPv2, IGMPv3, and IGMP snooping for IPv4 multicast traffic in EVPN-VXLAN edge-routed bridging (ERB) overlay fabrics. With enhanced OISM, on each device, you have the option to configure only the revenue VLANs that device hosts. You don’t need to configure all revenue VLANs in the fabric on all OISM leaf devices as you do with the regular OISM symmetric bridge domains model. This asymmetric bridge domains model enables OISM to scale well when your network has leaf devices that host a large number of different VLANs.

    Enhanced OISM operates similarly to the OISM symmetric bridge domains model, but with differences to account for the asymmetric bridge domains model, such as the following:

    • The source devices forward east-west multicast traffic:
      • On the source VLAN to multihoming peer leaf devices.
      • On the OISM supplemental bridge domain (SBD) for all other destinations (whether they host the source VLAN or not).
    • For north-south multicast traffic from external sources and to external receivers:

      • The border leaf PIM EVPN gateway (PEG) devices exchange EVPN Type 10 Selective P-Multicast Service Interface (S-PMSI) Auto-Discovery (A-D) routes.

      • With the S-PMSI A-D routes, the PEG devices can reliably signal multicast (S,G) PIM registration to the external multicast rendezvous point (RP) only for sources within the fabric.

    • You must configure:
      • The enhanced-oism option instead of the oism option (both options are at the [edit forwarding-options multicast-replication evpn irb] hierarchy level).
      • Matching revenue VLANs on any OISM leaf devices that are multihoming peer devices.

    [See Optimized Intersubnet Multicast in EVPN Networks.]

  • Enhanced OISM with MLDv1, MLDv2, and MLD snooping for IPv6 multicast traffic in EVPN-VXLAN fabrics (EX4100-24T, EX4300-MP, EX4400-24MP, EX4400-24P, EX4400-48F, EX4400-48MP, and EX4650)—Starting in Junos OS Release 23.4R1, we support the enhanced optimized intersubnet multicast (OISM) model with MLDv1, MLDv2, and MLD snooping for IPv6 multicast traffic in EVPN-VXLAN edge-routed bridging (ERB) overlay fabrics. Enhanced OISM uses an asymmetric bridge domains model that enables OISM to scale well when your network has leaf devices that host a large number of different VLANs.

    [See Optimized Intersubnet Multicast in EVPN Networks.]

  • Support for static VXLAN with MC-LAG using service provider interface configuration (EX4650)—Starting in Junos OS Release 23.4R1, you can use service provider style interface to configure static VXLAN in a spine-and-leaf network where the leaf devices support MC-LAG and Q-in-Q VLAN tunnels (VLAN translation). Junos OS supports Q-in-Q VLAN tunnels only when you use service provider interface configurations.

    [See Q-in-Q Tunneling in Leaf-Spine Network with Static VXLAN Tunnels.]

  • Support for 802.1X assignment of GBP tags using the RADIUS server (EX4100, EX4400, and EX4650) —Starting in Junos OS Release 23.4R1, we've added these enhancements to the group-based policy (GBP) micro segmentation feature:

    • Support for a new VSA "Juniper-Group-Based-Policy-Id" to assign GBP tags dynamically from RADIUS.

    • Support for these new CLI statements:

      • set protocols dot1x authenticator interface [interface-name] server-fail gbp-tag gbp-tag

        Specify the GBP tag to apply on the interface when the server is inaccessible.

      • set protocols dot1x authenticator interface [interface-name] server-reject-vlan gbp-tag gbp-tag

        Specify the GBP tag to apply when RADIUS rejects the client authentication.

      • set protocols dot1x authenticator interface [interface-name] guest-gbp-tag gbp-tag

        Specify the GBP tag to apply, when an interface is moved to a guest VLAN when no 802.1X supplicants are connected on the interface.

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

  • Range and list support for VLAN, port, and port+VLAN GBP filter matches (EX4100, EX4400, and EX4650)—Starting in Junos OS Release 23.4R1, the EX4400, EX4100, and EX4650 switches support multiple entries in the VLAN, port, and port+VLAN type GBP filters of same type in a term. The EX4100 switches do not support the VLAN and port+VLAN GBP filter match options.

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

  • EVPN-VXLAN pure T5 host-route auto-generated community (EX4100-24T, EX4300-MP, EX4400-24MP, EX4400-24P, EX4400-48F, EX4400-48MP, EX4650, and MX960)—Starting in Junos OS Release 23.4R1, we added support for EVPN-VXLAN pure T5 host-route auto-generated community. This feature adds a community to MAC-IP ARP/NDP based pure Type 5 host routes. Border leaf devices in ERB topologies with Type 5 connectivity to other leaf devices in the data center and Type 5 connections to external networks need to advertise aggregate routes to the external network instead of individual Type 5 routes. Border leaf devices can use this community to identify these routes and create an aggregate route to advertise to external EVPN networks.

    [See EVPN-VXLAN Pure T5 Host-Route Auto-Generated Community]

  • Static configuration of MAC-IP bindings with EVPN-VXLAN (EX4100-24MP, EX4300-MP, EX4400-48MP, EX4650, MX204, MX240, MX480, MX960, MX10004, MX10008, MX2010, and QFX10002-60C)—Starting in Junos OS Release 23.4R1, we’ve added the functionality to allow static configuration of MAC-IP bindings on an interface, similar to configuring static MACs on an interface. This feature enables the static configuration of IP and MAC entries for crucial services provided by management and infrastructure hosts. It proves particularly advantageous in Internet Exchange Point (IXP) networks where participant Customer Edge routers (CEs) remain well-known and static, not transitioning to different Provider Edge (PE) devices.

    You can now utilize a new feature that establishes a static link between an IP address and a MAC for a logical interface within a bridge domain or VLAN. When you provision a static MAC-IP entry on a PE, the PE will initiate a probe following an exponential backoff pattern. The probe will use an all-zero sender IP address on the associated interface. If the entity owning the IP to MAC entry responds to the probe, the system will learn the IP to MAC binding as static. Subsequently, it will be propagated to remote PEs through the BGP/EVPN Type 2 MAC advertisement route. The corresponding MAC will be recognized as a dynamic entry. If you want to deactivate the probing mechanism for learning the IP to MAC binding, you can do so by configuring a new configuration option [arp-nd-probe-disable]. Without probing, both the MAC and IP to MAC binding will be acquired from network traffic and communicated using EVPN.

    We’ve introduced the following commands and configuration statements:

    • Configuration of static IP to MAC bindings

      Note:

      A maximum of 8 MACs can be configured per static IP address.

      • QFX:

        set vlans vlan-name switch-options interface interface-name static-mac-ip ip-address [MAC1 MAC2 … MACn]

      • MX instance-type virtual-switch:

        set routing-instances routing-instance-name bridge-domains bridge-domain-name bridge-options interface interface-name static-mac-ip ip-address [MAC1 MAC2 … MACn]

      • MX instance-type evpn:

        set routing-instances routing-instance-name protocols evpn interface interface-name static-mac-ip ip-address [MAC1 MAC2 … MACn]

      The aforementioned commands provide an option to configure router and override bits for IPV6 entries. For example:

      QFX:

      set vlans vlan-name switch-options interface interface-name static-mac-ip ip-address [MAC1 MAC2 … MACn] <router | override>

    • Disable probing on configuration of static IP to MAC entries:

      To turn off the default probing on configuration of static IP to MAC entries, you can use the global configuration statement arp-nd-probe-disable.

      set protocols l2-learning arp-nd-probe-disable

    • Enable logging for failed probing of static IP to MAC entries:

      To turn on the logging, configure the global configuration statement arp-nd-probe-failed-log.

      set protocols l2-learning arp-nd-probe-failed-log

    • Enable GARP/unsolicited-NA for local and remote static entries

      If this feature is required, you must configure the global configuration statement garp-na-enable.

      set protocols l2-learning garp-na-enable

    • Disable dynamic learning [all static provisioning]

      If dynamic learning of MAC-IP entries is not required, configure the statement drop-unknown-macip under BD/VLAN.

      • QFX:

        set vlans vlan-name switch-options drop-unknown-macip

      • MX instance-type virtual-switch:

        set routing-instances routing-instance-name bridge-domains bridge-domain-name bridge-options drop-unknown-macip

      • MX instance-type evpn:

        set routing-instances routing-instance-name protocols evpn drop-unknown-macip

    • Drop unicast ARP request

      To drop unicast address resolution requests (for instance, NUD NS messages), you can configure the statement block-unicast-arp at global level for QFX and per BD level for MX.

      • QFX:

        set protocols l2-learning block-unicast-arp

      • MX instance-type virtual-switch:

        set routing-instances routing-instance-name bridge-domains bridge-domain-name bridge-options block-unicast-arp

      • MX instance-type evpn:

        set routing-instances routing-instance-name protocols evpn block-unicast-arp

    [See EVPN Proxy ARP and ARP Suppression, and Proxy NDP and NDP Suppression and interface-mac-ip-limit.]

  • Access security support in EVPN-VXLAN overlay networks (EX4400-48T, and EX4650)—Starting in Junos OS Release 23.4R1, we support access security features on switches that function as Layer 2 VXLAN gateways in an 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.

  • Loop detection for EVPN-VXLAN fabrics (EX4100-48MP, EX4100-H-12P, EX4100-H-12P-DC, EX4100-H-24P, EX4100-H-24P-DC, EX4100-H-24F-DC, 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)—Starting in Junos OS Release 23.4R1, you can configure loop detection on the server-facing Layer 2 interfaces of the leaf devices in an EVPN-VXLAN fabric. This feature can detect the following types of Ethernet loops:

    • A loop between two interfaces with different Ethernet segment identifiers (ESIs), usually caused if you miswire fabric components.

    • A loop between two interfaces with the same ESI, usually caused if you miswire a third-party switch to the fabric.

    After you enable loop detection, the interfaces periodically send multicast loop-detection protocol data units (PDUs). If a loop detection-enabled interface receives a PDU, the device detects a loop, which triggers the configured action to break the loop. For example, if you configure the interface-down action, the device brings down the interface. After the revert-interval timer expires, the device reverts the action and brings the interface back up again.

    [See loop-detect (EVPN).]