Provider Backbone Bridging Ethernet VPN (PBB-EVPN) is a new way of providing Layer 2 Services to enterprises, B2B customers, etc. I’m not going to drill down much on the theory part, as there’s plenty of articles and blog posts out there. Instead, we are going to see more the implementation side of PBB-EVPN technology.
Let’s see the components that make up the PBB-EVPN:
Briefly let’s see what each of these components role within PBB-EVPN is.
Bridge Group: is a group of one or more bridge domains. Same concept and applicability as with VPLS.
BD: A Bridge Domain is nothing new here (similar to traditional VPLS type of BD). When it comes to PBB-EVPN though, there’s two types of BDs, the Edge Bridge Domain and the Core Bridge Domain. Edge-BD is where the Attachment Circuits (interfaces connected towards customers) are included as part of the BD. That means all the Customer-MAC address (C-MAC) are part of this broadcast domain. Core-BD mainly contains the B-MAC, basically the Mac-Addresses of each Provider Edge devices (for reachability purposes) within the same MPLS network.
EVI: Is an EVPN instance that identifies a VPN service on an IP/MPLS based network. Here you are able to import/export routes/mac-addresses based on Route Targets (similar to L3 VPN Services).
i-SID: Service Instance Identifier, serves the purpose of identifying the service instance. It is a best practice to keep the i-SID values unique per customer service instance.
Let’s see how PBB-EVPN is implemented on IOS-XR based network device. We will be using four PE routers (as per diagram below) part of the same MPLS based network, and our focus is only the L2VPN service based on PBB-EVPN. This example assumes a customer needs to connect 4 different locations (geographically apart), and the Service Provider is here to connect those locations to the same E-LAN (referred to Metro Ethernet Forum naming convention).
Assuming that we have already MPLS network up and running (Segment Routing or LDP based), assuming that iBGP is also implemented correctly, let’s see the PBB-EVPN configuration:
! interface TenGigE0/0/0/2.101 l2transport description E-LAN 101 encapsulation dot1q 101 rewrite ingress tag pop 1 symmetric ! evpn evi 100 bgp route-target import 65001:100 route-target export 65001:100 ! l2vpn bridge group EVC101 bridge-domain PBB-EVPN-EDGE-EVC101 interface TenGigE0/0/0/2.101 ! pbb edge i-sid 10101 core-bridge PBB-EVPN-CORE ! ! bridge group CORE100 bridge-domain PBB-EVPN-CORE pbb core evpn evi 100 ! ! router bgp 65001 address-family l2vpn evpn !
Apply the same configuration on other PEs where you have ACs of the same interest (customer) connected, and verify the L2 Service. As we can see, it is quite easy when it comes to the configuration part of PBB-EVPN, but that’s not why you should choose going for it. The real reason is the flexibility of PBB-EVPN based L2 Services, the way how it reduces the BGP MAC advertisement by aggregating the C-MAC via B-MAC addresses (Mapping of Customer Mac addresses to Backbone Mac addresses). It is definitely the next generation L2VPN architecture.