E-Tree implementation scenarios

You can implement E-Tree using these scenarios; however, only scenario 1a and scenario 2 are supported:

• Scenario 1: All ACs at a particular PE device for a given Ethernet VPN instance (EVI) or bridge domain (BD) are either root or leaf sites. In this scenario, all traffic for an EVI from a PE in the network originates from either a root or a leaf site. You have two configuration options:

  • Scenario 1a: Configure E-Tree with route-target (RT) constraints using two RTs per EVI.

  • Scenario 1b: Configure E-Tree without RT constraints by using the E-Tree leaf label.

• Scenario 2: Configure a PE device to have both root and leaf sites for a given EVI.

EVPN E-Tree using route-target (RT) constraints allows you to configure BGP RT import and export policies for each AC. This configuration defines the communication pattern between root and leaf nodes within a BD. Layer 2 L2 traffic can flow only between root and leaf nodes—either from root to leaf or leaf to root—for a given BD. Direct L2 communication between leaf ACs is prevented, ensuring traffic isolation among leaf sites. Each EVI uses two distinct BGP RTs: one set associated with root ACs and another set associated with leaf ACs. This separation enforces the communication restrictions and maintains the E-Tree service topology.

In EVPN EVI instances, BGP import and export policies govern the distribution of RTs to control Layer 2 communication between root and leaf PE devices.

• Root PE behavior:

  • Exports its ROOT-RT using the BGP export policy.

  • Imports other ROOT-RTs from corresponding root PEs for the same EVI.

    This aspect is essential in scenarios with multiple roots for a BD and EVPN EVI, such as multihome active-active, port-active, and single-active modes.

  • Imports LEAF-RT through the BGP import policy. This allows the root PE to learn all remote L2 MAC addresses advertised by leaf PEs through EVPN RT2.

• Leaf PE behavior:

  • Exports its LEAF-RT using the BGP export policy, and informs the root PE of the reachability of its directly connected L2 endpoints through EVPN RT2.

  • Imports ROOT-RT using the BGP import policy, which enables the leaf PE to discover L2 endpoints reachable through the root PE’s AC under the EVPN EVI instance.

  • Must not import LEAF-RT to prevent L2 communication between leaf PEs.

• General policy application:

  • These BGP import and export policies apply to all EVPN RTs, including RT2 advertisements, ensuring proper isolation and communication paths within the E-Tree topology.

    This policy framework enforces the E-Tree service model by allowing L2 traffic only between root and leaf nodes, preventing direct leaf-to-leaf communication, and supporting multi-root scenarios for enhanced redundancy and scalability.

• L2 MAC addresses are learned on the AC of a specific BD on a leaf PE device as type LOCAL.

• The leaf PE advertises the learned MAC address to the root PE as an EVPN route target 2 (RT2).

• On the remote root PE, the MAC address entry is replicated in the MAC table with the learning type L2VPN.

• The root PE associates the MAC entry with the MPLS label of its BGP peer that advertises RT2 to the root PE node.

• Similarly, L2 MAC addresses learned on the AC of a BD on the root PE are marked as type LOCAL.

• The root PE advertises these MAC addresses to peer root or leaf PEs as EVPN RT2.

• On the remote root or leaf PE, the MAC table replicates the MAC entry with learning type L2VPN and associates it with the MPLS label of the BGP peer advertising RT2.

• For root PEs, the MAC table of a peer root node synchronizes the replicated MAC entry with learning type L2VPN for the same Ethernet Segment Identifier (ESI) and uses the same AC as the next hop.

• This synchronization prevents flooding and duplication of known unicast traffic, ensuring efficient MAC address learning and forwarding within the EVPN E-Tree topology.

Customer sites represented by ACs can be designated as either root or leaf nodes. For a given EVI, a PE device may receive traffic from both root and leaf ACs originating from a remote node. An EVI can be associated with both root and leaf sites simultaneously. If an AC is not explicitly configured as a leaf in the E-Tree topology, it defaults to being a root.

A PE device supports having both root and leaf sites within the same EVI. This scenario provides finer granularity by allowing root or leaf designation at the individual AC level, as opposed to scenario 1 where the designation is at the bridge domain level. Consequently, traffic for an EVI from a PE can originate from either root or leaf sites, enabling flexible and granular traffic segregation within the network.

• Remote PE devices perform ingress filtering to avoid unnecessary traffic traversing the core network only to be filtered at the egress PE.

• Each PE marks MAC addresses to indicate whether they are associated with a root or a leaf node.

• MAC address advertisements from leaf sites include a leaf-indication flag within an extended community attribute; routes lacking this flag originate from root sites.

• When remote PEs program MAC addresses with the leaf-indication flag, they cross-check the originating AC. If the AC is also a leaf, packets are not forwarded, preventing leaf-to-leaf traffic.

• The solution supports E-Tree extended community type 0x06 (EVPN) with sub-type 0x05 for leaf-indication on both known unicast and BUM traffic.

• Unknown unicast suppression should be enabled on EVIs connected to both root and leaf sites. This prevents unknown unicast traffic arriving at an EVI from being flooded to ACs, effectively eliminating leaf-to-leaf traffic during bridge domain MAC flush events.

• MAC addresses advertise the local ESI and do not include a leaf indicator when originating from root nodes.

• During processing of root synchronization routes, the root or leaf status is evaluated at the individual AC level rather than the entire bridge domain. If a root MAC with a matching local ESI is received but the corresponding AC is configured as a leaf, a syslog message is generated to indicate a misconfiguration.

• PE devices perform egress filtering on BUM traffic. BUM traffic originating from leaf sites is filtered at the egress PE if the destination is also a leaf, preventing leaf-to-leaf BUM traffic.

• A PE with leaf sites assigns a leaf label and advertises this label to remote PEs through an Ethernet Segment/EVPN Auto-Discovery (ES/EAD) route with ESI set to 0, including the E-TREE extended community.

• BUM traffic handling based on AC type and homing:

  • Single-homed leaf AC: BUM traffic is tagged with the destination ETREE leaf label.

  • Single-homed root AC: BUM traffic is not tagged with any ESI or ETREE leaf label.

  • Multihomed leaf AC: BUM traffic is tagged with the destination ETREE leaf label.

  • Multihomed root AC: BUM traffic is tagged with the ESI label.

• The ingress PE tags MPLS frames originating from leaf sites with the ETREE leaf label. This label enables the egress PE to perform filtering based on native EVPN ESI label, ensuring proper BUM traffic segregation.

• To prevent intra-PE forwarding between leaf sites, all leaf ACs within a bridge domain are placed in a single split-horizon group, effectively isolating leaf-to-leaf BUM traffic within the same PE.