E-Tree
Last updated
Last updated
E-Tree is a simulated layer 2 P2MP service. There are two types of AC ports in an E-Tree service: root ports, and leaf ports.
The AC ports are also called UNI (user to network interface) in the literature. Think of a UNI as an AC (attachment circuit) that connects to a customer device. In contrast an NNI (network to network interface) is a port where an ISP connects to another ISP.
In E-Tree, root ports can communicate with all other ports (other root ports and leaf ports). Leaf ports can only communicate with root ports. Leaf ports cannot communicate with other leaf ports.
This creates a hub-and-spoke topology, in which there are several spokes (leafs) and one or more hubs (roots).
We will reuse our topology from the E-LAN lab, and set CE1 and CE2 as leafs, and CE3 as the root:
In order to achieve this setup, we will run VPLS just as last time, except we will not form a pseudowire between PE1 and PE2. This will be a partial mesh VPLS instead of a full mesh VPLS. In this context, regular VPLS is basically E-Tree with all ports as “root.”
To make this slightly more realistic, we will pretend that CE1 and CE2 are two completely different internet-access customers that should not be able to reach each other. CE3 will be the common internet gateway for the shared subnet. By doing this, we conserve IP address space by using a large subnet like a /24 instead of a /30 or /31 for every single customer.
The configuration in the MPLS core is the same as VPLS, but with no pseudowire between PE1 and PE2
y
Let’s configure CE3 as a DHCP server, and CE1 and CE2 as customer routers that will obtain a public IP via DHCP.
CE1 obtains the IP 123.1.1.2 and CE2 obtains the IP 123.1.1.3. Each customer can ping the default gateway, but not each other
Now we can have up to 253 customers in this /24. Quite an efficient use of address space!
You may have noticed a flaw in configuring the E-Tree service this way. What happens if you want multiple leafs connected to a single PE? You would have to add both UNIs into the same bridge domain, and now they will be able to communicate.
If you’ve worked on real SP networks you know this would be a huge problem, and would completely prevent you from deploying E-Tree like this. In the real word, every single customer does not have its own dedicated PE. What we’ve done here in this lab, is essentially treated each PE as a leaf or root, not each AC or UNI as a leaf or root.
Unfortunately the solution to this using VPLS is complicated.
RFC 7287 is a framework for E-Tree using MPLS. It mentions VPLS and EVPN but does not state how to actually configure the service. I would recommend reading through this RFC as it is pretty short and a good intro to E-Tree.
RFC 7796 provides a mechanism for supporting E-Tree with VPLS by using updates to 802.1Q in published in 2014. The idea is that customer traffic will have a certain tag, and traffic from the root port(s) will have a different tag. The PE must not allow frames with the customer tag to be forwarded to other customer ports.
So let’s say customer traffic will have a tag of 100, and root traffic will have a tag of 200. The PE must be able to prevent traffic with a tag of 100 from being sent to other customers, and allow traffic with a tag of 200 to be sent to customers.
How exactly this is achieved, I am not sure. It kind of sounds like firewalling/filtering based on 802.1Q tags instead of IPs or ports. I’m not even sure if Cisco supports this. I believe that using EVPN is a much better way to provide this service anyways.
