Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

EVPN

  • Support for EVPN E-Tree service (ACX5448)—Starting with Junos OS Release 21.1R1, you can configure an EVPN Ethernet Tree (E-Tree) service on ACX5448 routers.

    [See EVPN-ETREE Overview.]

  • Support for inter-DC connectivity over a Layer 3 network (ACX5448)—Starting with Junos OS Release 21.1R1, you can configure the ACX5448 router to support IRB interfaces in an EVPN-MPLS network. This feature supports EVPN Type 2 (MAC/IP advertisement) and EVPN Type 5 (IP prefix) routes.

    [See EVPN with IRB Solution Overview.]

  • Support for single-active multihoming redundancy in EVPN-VPWS with flexible cross-connect support (ACX5448)—Starting with Junos OS Release 21.1R1, you can configure the interfaces on the ACX5448 router in an Ethernet VPN–virtual private wire service (EVPN-VPWS) network with flexible cross-connect (FXC) or legacy cross-connect (non-FXC) service to support single-active multihoming redundancy for traffic that flows from customer edge devices to the core. EVPN-VPWS also supports load balancing with equal-cost multipath (ECMP) fast reroutes (FRR) on IGP and over BGP multipaths that face the core.

    [See Overview of Flexible Cross-Connect Support on VPWS with EVPN and Configuring EVPN Active-Standby Multihoming.]

  • Tunnel endpoint in the PMSI tunnel attribute field for EVPN Type 3 routes (ACX5448, EX4600, EX4650, EX9200, and QFX10002)—Starting in Junos OS Release 21.1R1, you can set the tunnel endpoint in the provider multicast service interface (PMSI) tunnel attribute field to use the ingress router’s secondary loopback address. When you configure multiple loopback IP addresses on the local provider edge (PE) router and the primary router ID is not part of the MPLS network, the remote PE router cannot set up a PMSI tunnel route back to the ingress router.

    To configure the router to use a secondary IP address that is part of the MPLS network, include the pmsi-tunnel-endpointpmsi-tunnel-endpoint statement at the [edit routing-instances routing-instance-name protocols evpn] hierarchy level for both EVPN and virtual-switch instance types.

    [See EVPN.]

  • Support for EVPN-MPLS (Junos fusion for provider edge)—Starting in Junos OS Release 21.1R1, Junos fusion for provider edge supports EVPN-MPLS. EVPN-MPLS is a solution that extends Layer 2 VPN services over an MPLS network. Junos fusion for provider edge supports the connection of a customer edge (CE) device on the extended port of the satellite device in an EVPN-MPLS network.

    [See Junos Fusion Provider Edge Supported Protocols.]

  • EVPN-VXLAN tunnel inspection (SRX4100, SRX4200, SRX4600, SRX5400, SRX5600, SRX5800, and vSRX)—Starting in Junos OS Release 21.1R1, we've introduced the following enhancements to the VXLAN support for SRX Series devices:

    • Support for SRX5000 line of devices in addition to the SRX4000 line and vSRX

    • Enhancements to tunnel inspection for VXLAN-encapsulated traffic by applying Layer 4 or Layer 7 security services to the tunnel traffic. The supported services are:

      • Application identification
      • IDP
      • Juniper Advanced Threat Prevention (ATP Cloud)
      • Unified threat management (UTM)

    Layer 7 security services provide application-level security and protect users from security threats through VXLAN tunnel.

    [See Configuring Tunnel Traffic Inspection.]

  • Security policy enhancement for EVPN-VXLAN tunnel inspection (SRX4100, SRX4200, SRX4600, SRX5400, SRX5600, SRX5800, and vSRX)—Starting in Junos OS Release 21.1R1, we've enhanced EVPN-VXLAN tunnel inspection by adding zone-level policy control for the inner traffic. When you create a policy that applies to the inner session created by VXLAN inner header, you can define the following parameters as match conditions for the inner traffic:

    • Source zone
    • Destination zone
    • URL category
    • Dynamic applications

    Additional matching criteria in the security policy provide granular control and extensibility to manage traffic.

    [See Configuring Tunnel Traffic Inspection.]

  • Flow-aware transport pseudowire support for EVPN-VPWS (MX Series routers and EX9200 switches)—Starting in Junos OS Release 21.1R1, you can statically configure provider edge (PE) devices to use flow-aware transport (FAT) pseudowire labels in an EVPN virtual private wire service (VPWS) routing instance with an IP/MPLS underlay fabric. PE devices use these labels to load-balance EVPN-MPLS packets across ECMP paths or link aggregation groups (LAGs) without needing to do deep packet inspection of the payload.

    To enable FAT pseudowire load balancing in an evpn-vpws routing instance:

    • Configure flow-label-transmit-static on PE devices to insert FAT flow labels into VPWS pseudowire packets sent to remote PE devices.

    • Configure flow-label-receive-static on PE devices to remove FAT flow labels from VPWS pseudowire packets received from remote PE devices.

    You can configure these statements for all pseudowires in the routing instance or for pseudowires associated with a specific interface in the routing instance.

    [See FAT Flow Labels in EVPN-VPWS Routing Instances, flow-label-receive-static, and flow-label-transmit-static.]

  • EVPN-VXLAN fabric (EX9200 switches with EX9200-15C line cards)—Starting in Junos OS Release 21.1R1, EX9200 switches with EX9200-15C line cards support the following features in an EVPN-VXLAN fabric:

    • Layer 2 VXLAN

      • Multihoming in active/active mode, an Ethernet segment identifier (ESI) per interface, and preference-based designated forwarder (DF) election

      • MAC pinning, MAC move, MAC limiting, and MAC aging

      • QoS

      • DHCP and DHCP relay

      • Prevention of broadcast, unknown unicast, and multicast (BUM) traffic loops when a leaf device is multihomed to more than one spine device

    • Layer 3 VXLAN

      • IRB interfaces

      • IPv6 over IRB interfaces

      • Support for OSPF, IS-IS, BGP, and static routing over IRB interfaces

      • Proxy ARP and ARP suppression, and proxy NDP and NDP suppression with and without IRB interfaces

      • IPv6 underlay

      • Virtual machine traffic optimization (VMTO) for ingress traffic

    • Data Center Interconnect (DCI)

      • Pure EVPN Type 5 routes only

    • High availability

      • Nonstop active routing (NSR)

      • GRES

      • Graceful restart from a routing process restart or Routing Engine switchover without NSR enabled

    • Operations and management

      • Core isolation feature

      • Ping over EVPN Type 5 tunnel

    • Static VXLAN

      • Overlay ping and traceroute

    [See EVPN User Guide.]

  • Loop detection for EVPN-VXLAN fabrics (EX4300-48MP)—Starting in Junos OS Release 21.1R1, you can configure loop detection on the server-facing Layer 2 interfaces on EX4300-48MP 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.]

  • Macro Segmentation using Group Based Policy (EX4400)—Starting in Junos OS Release 21.1R1. Juniper EX4400 series switches support the use of existing layer 3 VXLAN network identifiers (VNI) in conjunction with firewall filter policies to provide micro-segmentation at the level of device or tag, independent of the underlying network topology. IoT devices, for example, typically only need access to specific applications on the network. VXLAN-GBP can keep this traffic isolated by automatically applying security policies without the need for L2 or L3 lookups or ACLs.

    To use VXLAN-GBP, enable group-based policies at the global hierarchy level: [chassis forwarding-options vxlan-gbp-profile] on the tunnel termination endpoint. Two new match condition terms, gbp-src-tag and gbp-dst-tag, are introduced at the [firewall family ethernet-switching filter name term name from ] level of the hierarchy. You can configure the tags manually or get them from the RADIUS server upon authentication by the host.

    [See https://www.juniper.net/documentation/us/en/software/junos/evpn-vxlan/topics/example/micro-segmentation-using-group-based-policy.html Example: Micro and Macro Segmentation using Group Based Policy in a VXLAN.]

  • Support for remote port mirroring based on VNI match conditions (QFX10002, QFX10008, QFX10016)—Starting in Junos OS Release 21.1R1, You can use VXLAN network identifier (VNI) values as a match condition when filtering traffic for remote port mirroring. VNI packets that match the configured VNI will be mirrored, with the VNI packet contents, on the designated interface. This addition extends functionality introduced in previous releases.

    [See Filter-based forwarding in EVPN-VXLAN networks and Remote port mirroring to an IP address.]

  • Explicit congestion notification (ECN) over VXLAN tunnels (EX4650 and QFX5120)—Starting in Junos OS Release 21.1R1, by default, standalone EX4650 and QFX5120 switches support explicit congestion notification (ECN) for packets that are encapsulated across VXLAN tunnels, as follows:

    • During VXLAN encapsulation at the source virtual tunnel endpoint (VTEP), the switch copies the ECN bits of the Type-of-Service (ToS) field from the original packet IP header to the outer VXLAN encapsulation IP header.

    • During VXLAN de-encapsulation at the remote VTEP, the switch copies the ECN bits of the ToS field from the outer VXLAN encapsulation IP header to the original packet IP header.

    You can configure the vxlan-disable-copy-tos-encap statement or the vxlan-disable-copy-tos-decap statement at the [edit forwarding-options] hierarchy on the encapsulation or de-encapsulation ends of the tunnel, respectively, to disable the ECN copy operation.

    Note:

    These switches also copy the differentiated services code point (DSCP) bits in the ToS field of the IP header upon VXLAN encapsulation and de-encapsulation by default, and the same statements disable copying both the DSCP and ECN bits.

    [See vxlan-disable-copy-tos-encap and vxlan-disable-copy-tos-decap.]

  • Aliasing for all-active multihoming with EVPN-MPLS (ACX5448)—Starting in Junos OS Release 21.1R1, ACX5448 routers support aliasing for EVPN-MPLS all-active multihoming with ELAN services. Aliasing enables remote provider edge (PE) devices to load balance Layer 2 traffic toward a multihomed customer edge (CE) device among the PEs that have the same EVPN segment ID (ESI) for that CE device.

    You enable aliasing when you configure the load-balance per-packet routing policy statement at the [edit policy-options policy-statement] hierarchy and export the policy statement at the [edit routing-options forwarding-table] hierarchy. This feature is supported in routing instances of type evpn with VLAN-based and VLAN bundle services.

    [See EVPN Multihoming Overview.]