Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

EVPN

  • Convergence improvements for EVPN-VPWS (ACX7020-AC, ACX7020-AC-C, ACX7020-DC, ACX7020-DC-C, ACX7024, ACX7024X, ACX7100-32C, ACX7100-48L, ACX7332, ACX7348, ACX7509, PTX10001-36MR, PTX10002-36QDD, PTX10003, PTX10004, PTX10008, and PTX10016)—We've introduced EVPN-VPWS convergence enhancements on the ACX Series and PTX Series routers. With this feature, the router now supports route acknowledgment for EVPN-VPWS routes, extending the existing mechanism currently used for BGP routes. The router advertises an EVPN-VPWS route to its neighbor only after it confirms that:

    • The route has been successfully installed in the forwarding table of the Packet Forwarding Engine
    • The route version in the routing information base (RIB) matches the version in the forwarding information base (FIB) .

    If there are any acknowledgment errors, the router withdraws the EVPN-VPWS routes from the Packet Forwarding Engine. This ensures that EVPN-VPWS routes are reliably installed in hardware and that the versions are synchronized across the RIB and the FIB.

    By default, required acknowledgment from the PFE prior to advertising the EVPN-VPWS route is automatically enabled. To disable the acknowledgment requirement, include the evpn-vpws-ack-disable statement at the [edit routing-options forwarding-table] hierarchy level. Disabling the acknowledgment requirement only affects new EVPN-VPWS instances and does not impact the network.

    [See forwarding-table.]

  • Lightweight PE-CE loop detection in EVPN-VXLAN fabrics (PTX10002-36QDD)—You can enhance network reliability on EVPN-VXLAN fabrics by implementing lightweight PE-CE loop detection. This feature assists in preventing routing loops between provider edge (PE) and customer edge (CE) devices, ensuring efficient data flow and maintaining network integrity. By detecting loops early, you minimize disruptions and optimize network performance, supporting stable and consistent connectivity.

    [See EVPN-VXLAN Lightweight Leaf to Server Loop Detection.]

  • OISM with a default IRB routing instance (PTX10001-36MR)—You can now configure optimized intersubnet multicast (OISM) using a default Layer 3 (L3) integrated routing and bridging (IRB) routing instance. We support this feature with:

    • IPv4 underlay peering in the EVPN-VXLAN network.

    • IPv4 multicast traffic with IGMPv1/v2 and IGMP snooping.

    With a default L3 routing instance, you configure L3 OISM parameters at the global level instead of at a VRF instance level. For example, configure the L3 EVPN protocol statements at the [edit protocols evpn ...] hierarchy level instead of at the [edit routing-instances name protocols evpn ...] hierarchy level. Also, to prevent routing loops when you use a default routing instance, you must set a forwarding table export policy that includes the install-nexthop except overlay-vxlan-interfaces policy option.

    [See OISM Support with Tenant L3 VRF Instances or the Default L3 Routing Instance.]

  • Weighted ECMP for EVPN-MPLS Type 5 routes (PTX10002-36QDD, PTX10004, and PTX10008)—Use weighted ECMP (WECMP) for EVPN-MPLS Type 5 routes by advertising generalized weights from gateway counts with the EVPN link bandwidth extended community. This advertisement distributes traffic across next hops and prevents congestion when leaf capacities differ. To configure an export policy, use set policy-options policy-statement policy-name then aggregate-weight [multiplier one through 32] and set routing-instances instance-name protocols evpn ip-prefix-routes export policy-name. Use show evpn ip-prefix-database extensive to verify weights, balance factors, and feature state. If weights are missing or inconsistent from the Type 5 route of any leaf device, the border leaf device generates a debug log and follows regular ECMP forwarding to the leaf devices.

    [See policy-statement.]