EVPN

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

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

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.