Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

EVPN E-Tree Overview

You can use the Ethernet VPN (EVPN) Ethernet-Tree (E-Tree) feature to create a rooted-multipoint service supported with EVPN-MPLS in the core, as defined by the Metro Ethernet Forum (MEF) in RFC 8317. In an EVPN E-Tree service, you categorize interfaces as either root or leaf interfaces in a routing instance. You also define each customer edge (CE) device as a root or a leaf device. The EVPN E-Tree service follows these forwarding rules:

  • A leaf can send or receive traffic only from a root.

  • A root can send traffic to another root or any leaf.

Leaf and root CE devices can be single-homed or multihomed to the provider edge (PE) devices in the network.

Figure 1: EVPN E-Tree Service Network topology diagram showing Ethernet Virtual Private Network with CE and PE devices. CE1, CE3 are Leafs; CE2 is Root; CE4, CE5 are Multihomed.

The EVPN E-Tree service has all the benefits of EVPN such as all-active multihoming and load balancing loop detection for E-Tree.

In an EVPN E-Tree service, the forwarding rule depends on the traffic source and destination for known unicast traffic or unknown unicast, broadcast, and multicast (BUM) traffic. Table 1 shows the forwarding rules within the E-Tree service.

Note:

We don't support IGMP snooping, MLD snooping, or PIM snooping multicast optimizations with EVPN E-Tree.

Table 1: EVPN E-Tree Forwarding Rule Based on Traffic Source and Destination

Type of Traffic

Allowed/Not-Allowed

Filtering Location

Known Unicast Traffic from Root to Root

Allowed

-

Known Unicast Traffic from Root to Leaf

Allowed

-

BUM Traffic from Root to Root

Allowed

-

BUM Traffic from Root to Leaf

Allowed

-

Known Unicast Traffic from Leaf to Leaf

Not Allowed

At the ingress Packet Forwarding Engine

Known Unicast Traffic from Leaf to Root

Allowed

-

BUM Traffic from Leaf to Leaf

Not Allowed

At the Egress Packet Forwarding Engine

BUM Traffic from Leaf to Root

Allowed

-

If you don't configure a leaf or root role for an interface, it will be assigned the “root” role by default. All leaf interfaces are assigned a new mesh group with no local switching set to TRUE, which:

  • Enables ingress filtering for unicast traffic.

  • Drops all the leaf-to-leaf traffic at the ingress leaf interface.

For BUM traffic, the egress PE does the filtering based on the root or leaf label carried in the packet.

NSR and Unified ISSU Support for EVPN E-Tree

Nonstop active routing (NSR) and graceful Routing Engine switchover (GRES) minimize traffic loss when a Routing Engine switchover occurs. When a Routing Engine fails, NSR and GRES enable a routing platform with redundant Routing Engines to switch over from a primary Routing Engine to a backup Routing Engine and continue forwarding packets. With unified in-service software upgrade (ISSU), you can upgrade your Junos OS software on your MX Series router with no disruption on the control plane, and with minimal disruption of traffic. You must enable both GRES and NSR to use unified ISSU.

To enable GRES, include the graceful-switchover statement at the [edit chassis redundancy] hierarchy level.

Junos OS mirrors essential data when NSR is enabled. For EVPN E-Tree, the local EVPN E-Tree leaf label that is advertised to other PE as part of the E-Tree extended community will be mirrored on the standby Routing Engine. For information on other mirrored data and NSR data flow, see NSR and Unified ISSU Support for EVPN.

To enable NSR, include the nonstop-routing statement at the [edit routing-options] hierarchy level and the commit synchronize statement at the [edit system] hierarchy level.

Platform-Specific EVPN E-Tree Behavior

Use the following table to review platform-specific behaviors for your platforms.

Platform

Difference

ACX5448 Routers

When you enable EVPN E-Tree on ACX5448 routers, you must also set the system profile option evpn-mh-profile at the [edit system packet-forwarding-options firewall-profile] hierarchy level and commit the configuration. To start the new profile, run the restart chassis-control CLI command to restart the chassis management process (mgd). You will see a syslog warning to restart the Packet Forwarding Engine.