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

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