PBB EVPN – A new flexible L2VPN Service

By Leonir Hoxha on April 23, 2017 • ( 0 )

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:

PBB EVPN Components

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).

PBB EVPN

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.

I hope you enjoyed this, and if you want to know more, check out here. Or the official RFC 7623.