EVPN

DHCP security on Layer 3 VXLAN gateways in an EVPN-VXLAN edge-routed overlay (EX4300-MP, EX4300-MP VC, EX4400, EX4400 VC)—Starting in Junos OS Release 22.1R1, you can configure DHCP security features on devices that function as Layer 3 VXLAN gateways in an EVPN-VXLAN edge-routed overlay. DHCP security is supported on customer edge (CE)-facing interfaces, and DHCP relay handles Layer 3 routing. The listed devices support the following features:

• DHCPv4 and DHCPv6 snooping. [See Enabling DHCP Snooping.]
• Dynamic ARP inspection. [See Enabling Dynamic ARP Inspection.]
• Neighbor discovery inspection. [See Enabling ND Inspection.]
• IPv4 and IPv6 source guard. [See Configuring IP Source Guard.]

Graceful restart support for unicast and Type 5 routing on EVPN-VXLAN (MX240, MX480, MX960, MX2010, and MX2020)—Starting in Junos OS Release 22.1R1, the listed MX Series routers support graceful restart protocol extension for high availability (HA) handling of unicast routes on EVPN-VXLAN. The routers also support EVPN Type 5 routing . Graceful restart enables a device to recover from a routing process restart or Routing Engine switchover without nonstop active routing (NSR) enabled. Type 5 routing on MPC10E line cards (IP prefix routing) provides all necessary forwarding information required for sending VXLAN packets in the data plane to the data center's egress network virtual endpoint.

See:

• Availability in EVPN
• EVPN Type 5 Route with MPLS encapsulation for EVPN-MPLS

Loop detection for EVPN-VXLAN fabrics (EX4650)—Starting in Junos OS Release 22.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 (EVPN).]

Preference-based DF election for EVPN (QFX5110, QFX5120-32C, QFX5120-48T, QFX5120-48Y, QFX5200, QFX5210, QFX10002, QFX10002-60C, QFX10008, and QFX10016)—Starting in Junos OS Release 22.1R1, you can enable QFX Series switches to select a designated forwarder (DF) based on the preference value. Provider edge (PE) devices send the preference value to the other multihomed PE devices using the extended community attribute in the EVPN Type 4 route advertisement.

To enable preference-based DF election, include the df-election-type statement at the [edit interfaces interface-name esi] hierarchy level. You can also enable DF election based on the lowest preference value. To do this, include the designated-forwarder-preference-least statement at the [edit routing-instance routing-instance-name protocols evpn] hierarchy level.

[See Designated Forwarder Election.]

[See Multicast Support in EVPN-VXLAN Overlay Networks.]

Support for EVPN/VXLAN filtering and policing capability over a pure IPv6 underlay (QFX10002-60C, QFX10002, QFX10008 and QFX10016)—Starting in Junos OS Release 22.1, Juniper supports filter-based forwarding for both IPV4 and IPV6 on an EVPN/VXLAN topology with added firewall policing of IPV6 packets once the forwarding tunnel terminates.

[See Routing IPv6 Data Traffic through an EVPN-VXLAN Network with an IPv4 Underlay.]

Zero traffic loss when you add new member interfaces ECMP underlay next hop (QFX10002-60C, QFX10002, QFX10008, and QFX10016)—Starting in Junos OS Release 22.1R1, on VXLAN tunnels configured over ECMP underlays, there is no traffic loss when you add new members to the underlay ECMP next hop. Previously on single-FPC devices, when you added a member to the unilist (a pointer to a list of unicast next hops), the new member was installed at the beginning of the list for the egress pipeline. In the ingress pipeline, however, the unilist still pointed the old member but used the new member’s index number. The traffic would then exit the device using the old member but with the index number of the new member. Because the MAC address didn’t match the device from which it was sent, the next-hop device would drop the traffic. To solve this problem, you now add new members to the end of the list so that the existing indexes aren’t affected.

Previously on multiple-FPC devices, each FPC updated its ingress and egress pipelines independently and would be out of sync with each other. For example, if you had two members in the unilist, and then added a third member, the third member had its port on FPC2. The fix for single-FPC devices doesn’t help in this situation. Instead, you can configure a delay timer, which enables you to defer populating the ingress pipeline for a predetermined amount of time while programming the egress pipeline. When the timer expires, you can then program the ingress pipeline.

[See EVPN Overview.]