Using MP-BGP to signal VPLS

Overview

VPLS is a multipoint Layer 2 VPN technology used to emulate an Ethernet broadcast domain across a service provider network. The technology is in many ways similar to traditional Layer 2 VPNs, however the fundamental difference with VPLS is the use of Ethernet MAC addresses to learn the source of frames within the VPLS, storing them in VPLS MAC tables on PE routers.

Using attachment circuits VPLS can support Ethernet untagged or Ethernet-VLAN tagged encapsulation for either a transparent service or a provider provisioned VLAN tagged service.

Draft Kompella BGP Signalling Approach RFC471

Juniper’s preferred signalling approach is to use the MP-BGP auto-provisioning scheme based on theory that by using the existing MP-BGP infrastructure the provider network avoids the potential need for the many targeted LDP sessions that could be required for complex VPLS topologies.

In addition to this a VPLS that’s signalled using MP-BGP can be over provisioned allowing for the addition of new customer connectivity by simplying adding the respective VRF configuration to the PE router serving the newly provisioned site.

Inter-AS operations are also harmonised with the MP-BGP approach, allowing VPLS domains to be easily extended over existing Option B or Option C Interprovider VPNs.

VPLS Instances and BGP NLRI Information

The VRF table handles all of the label allocations and blocks for each VPLS instance and creates a VT interface from transport of label switch packets ingressing and egress the PE.

Each VRF table is populated with information received from other PEs by use of the L2 VPN NLRI. This attribute delivers labels and encapsulation so that each local PE can map local site IDs to remote sites.

The site ID, layer 2 encapsulation, logical attachment circuits and label base parameters are used to associate inbound and outbound traffic to each logical VPLS attachment circuit.

The VPLS label mapping process uses the same approach as the L2VPN NRLI. VPLS label mapping information is distributed for each VPN site between PE routers. The PE routers advertise the label association for all of their local attachment circuits in one label block. The BGP L2VPN calculation is used by each remote site to calculate the labels to use for inter site transport.

BGP NRLI Extended Community

The L2VPN NLRI extended community carries the route target, encapsulation type, MTU (of PE to CE link), control flags and site-preference (used for multi-homing). The MTU must match on each PE to CE link within the VPLS as fragmentation is not supported. The preference value is copied into the BGP local preference field and relates to the preference given to different sites, which is used for resilience or multi-homing.

Each PE receives L2VPN NRLI extended community from all remote PEs that are associated with the VPLS. In order for a PE to calculate the egress label used for forwarding to a remote site, the following calculation is used:

remote label base + local site ID – remote label offset.

For both the BGP and LDP approach Junos creates a logical tunnel interface with the PFE for each remote VPLS site. This allows ingress frames to pass through the PFE twice. The first pass pops the MPLS VPN label from the frame and the second pass carries out MAC address learning and forwarding using the VPLS forwarding tables contained within the VRF.

This approach is different to the L2VPN operation which simply binds labels to attachment circuits and does not rely on MAC learning and forwarding, due to the point to point nature of a traditional L2VPN.

Configurating the Attachment Circuits

To provision a VPLS instance the following parameters must be included in the configuration:

  • Attachment circuit interfaces
  • VPLS routing instance
  • Route Target Community
  • Site ID (unique value in the context of each VPLS)
  • Site range (maximum number of sites to which the local site can connect, this is defined by the label range)
  • Remote sites (labels for remote sites are learnt dynamically via BGP NLRI process)
  • Encapsulation must be VPLS

It’s possible to configure a VPLS using a pre-provisioned VLAN scheme which is presented directly to the CE. The benefit of this approach is that it allows over provisioning, however the control of VLAN tagging in the scenario is governed by the PE.

In the example below unit 513 is encapsulated with vlan-id 513 and family vpls. In this scenario the physical interface must be set to vlan-tagging. The example uses the flexible-ethernet-services encapsulation type which allows for multiple per-unit encapsulation types, allowing the interface to support other transport types such as L2VPN using CCC.

It’s worth noting that all L2VPNs in Junos must use a specific VLAN range, starting from 512.

vpls-vlan-attachment

For transparent attachment circuits a different encapsulation type is used. This approach allows the CE to have the flexibility of pushing any VLAN tag into a frame entering the VPLS

interfaces {
encapsulation ethernet-vpls;
ge-0/0/2 {
unit 0 {
family vpls;
}
}
}
}

VRF Configuration

For BGP NLRI signalling a standard VRF is configured but with a VPLS instance type. Interfaces are configured as the attachment circuits within the VPLS, however only one routing instances is created for one VPLS. If an additional interface is configured within the routing instance it will be used for multi-homing CE sites into the VPLS. Route-targets are used in the same manner as L2 and L3 VPN. The VPLS protocol is configured with a site range value that

routing-instances vpn-a {
instance-type vpls;
interface ge-0/0/1.515;
vrf-target target:65001:100;
protocols {
vpls {
site-range 20;
site ce-a {
site-identifier 1;
}
}
}
}

VPLS Multi-Homing

Multi-homing allows two PEs to connect to a CE device to provide resilience in a multi-homed state. In order to prevent a loop the downstream switch has a primary and secondary forwarding path towards the PEs. This is controlled via BGP with a preference feature configured within each PE routing-instance that’s carried into BGP within the local preference attribute.

The primary PE is configured as follows :

routing-instances vpn-a {
instance-type vpls;
interface ge-0/0/1.515;
route-distinguisher 192.168.2.2:100;
vrf-target target:65001:100;
protocols {
vpls {
site-range 20;
site ce-b {
site-identifier 2;
multi-homing;
site-preference 300;
}
}
}
}

routing-instances vpn-a {

instance-type vpls;
interface ge-0/0/1.515;
route-distinguisher 192.168.2.3:100;

vrf-target target:65001:100;

protocols {

vpls {

site-range 20;

site ce-b {

site-identifier 2;

multi-homing;

site-preference 100;

}

}

}

}/div>

Primary and Backup Interfaces

If a PE has multiple VPLS interfaces towards one CE device then the primary and backup feature can be used to prevent loops.

routing-instances vpn-a {
instance-type vpls;
interface ge-0/0/1.515;
interface ge-0/0/2.515;
interface ge-0/0/3.515;
vrf-target target:65001:100;
protocols {
vpls {
site-range 20;
site ce-a {
site-identifier 1;
interface ge-0/0/1.515;
}
site ce-c {
site-identifier 3;
active-interface primary interface ge-0/0/2.515;
interface ge-0/0/2.515;
interface ge-0/0/3.515;