BGP L2VPN

Overview

This approach uses MP-BGP to signal the VPN across the MPLS backbone. The Kompella approach allows auto provisioning of circuits within a VPN mesh. Circuit ids, VPN labels and notification to other routers in the mesh are all handled by the Kompella BGP signalling approach. The BGP L2 VPN uses the Martini encapsulation approach. A Martini control word is carried instead of the native L2 header when the frames are carried across the MPLS core.

Standards for L2 VPNs

draft-kompella-l2vpn-l2vpn (BGP L2), RFC 4447 (LDP L2 Circuit), RFC 4761 (BGP VPLS), RFC 4762 (LDP VPLS)

BGP NLRI and Control Plane

The PE router provisions the customer circuit as a logical unit towards the CE device within a VRF that’s created for each CE device. The PE provisions four elements for each CE site; local site ID, logical interface, interface encapsulation and a label base. The label base is used to associate inbound traffic with the locally provisioned circuit. Based on this process the PE receives MP-BGP NLRI updates from remote sites with their information for their circuits which would contain remote site ID, remote label base and layer 2 encapsulation.

The VPN NRLI is a subset of the information contained as a connection table in each VRF. One VPN NRLI is sent per VPN site and combination of local and remote NLRI information allows the PE to map traffic and circuits across the LSPs connecting the PEs together.

The following process allows the PE routers to exchange NRLIs and map labels to local circuits within their VRF connection tables. For a single circuit both PEs send NRLIs to each other with their respective label base, block, offset and site id. For auto provisioning the order in which the circuits are provisioned towards the CE is important as labels are allocated locally from the label block in order of circuit.

To provision the L2 VPN the following must be met:

  • A VRF is configured for each local CE site
  • Import and export route targets are configured
  • A site id must specifically identify the local site in context of that particular VPN
  • A label range (or label block) is defined (this defines the maximum number of CE devices remotely connected by the L2 VPN)
  • The label base is defined and assigned to the first sub interface ID. The router reserves at set of contiguous labels that are defined by the label range/block
  • Sub interfaces are configured and a label from the label block is assigned contiguously to each sub interface and advertised outwards to remote VPN members (VLANs)
One VPN can connect many sites together using multiple interfaces towards each CE and then adding them to the VRF configuration as a site.

Layer 2 NRLI

NRLI is sent per label block. Contains a circuit status vector that can detect a failure within a specific local circuit. When a circuit is detected as failed a BGP NRLI is sent to the remote PE to inform them that the remote PE to CE circuit has failed.

Configuration of p2mp L2 VPN with over provisioning

The following configuration demonstrates a point to multipoint L2 VPN that connects to two remote sites and has been over provisioned for two additional sites. The local site is represented by the site-identifier and each remote site is sequentially assigned a site id in the order that the sub interfaces are configured within the VPN. The remote site allocation avoids the local site configuration so the sequential allocation is not duplicated. This process happens with the remote sites, which always begin the allocation from 1 and miss out their local site whilst allocating sub interfaces to site ids.

Additional interfaces representing other sites in the VPN are over provisioned in preparation for the deployment of those sites which are configured with the respective ordered site ids. If all interfaces are ordered correctly the over provisioning will work and sites and interfaces will be allocated appropriately.

routing-instances vpn-a {
instance-type l2vpn;
interface ge-0/0/0.512;
interface ge-0/0/0.513;
interface ge-0/0/0.514;
interface ge-0/0/0.515;
route-distinguisher 172.25.0.1:100;
vrf-target target:65001:100;
protocols {
l2vpn {
encapsulation-type ethernet-vlan;
site CE-A {
site-identifier 1;
interface ge-0/0/0.512;
interface ge-0/0/0.513;
interface ge-0/0/0.514;
interface ge-0/0/0.515;

The configuration below shows how the site 2 would be configured to connect the logical .512 circuit back to site 1.

routing-instances vpn-a {
instance-type l2vpn;
interface ge-0/0/0.512;
route-distinguisher 172.25.0.2:100;
vrf-target target:65001:100;
protocols {
l2vpn {
encapsulation-type ethernet-vlan;
site CE-B {
site-identifier 2;
interface ge-0/0/0.512;

The interface must be configured with vlan-ccc encapsulation at both the physical and logical levels. When using CCC encapsulation VLAN id’s must be above 512.

interfaces {
ge-0/0/1.10 {
vlan-tagging;
encapsulation vlan-ccc;
unit 10 {
encapsulation vlan-ccc;
vlan-id 10;
family inet {
address {
10.100.0.1/30;
}
}
}
}
}

routing-instances {
L2VPN_A {
instance-type l2vpn;
interface ge-0/0/1.10;
vrf-target target:65001:100;
protocols {
l2vpn {
encapsulation-type vlan-ccc;
site-name CE_A {
site-identifier 1;
interface ge-0/0/1.10;
}
}
}
}
}

Interworking Protocol

Interworking is a protocol within Junos that allows layer 2 VPNs to be stitched together. Traditionally a loopback was performed within the tunnel services PIC to provided the stitching of the VPNs together. This is now handled within software via logical iw0 interface. This process removes some of the bandwidth constraints associated with the traditional approach.

The interworking between the two VPNs is carried out on an intermediary PE router. In order to configure this feature two logical iw0 interfaces must be configured with a peer unit statement under each unit to link the units together.

interface {
iw0 {
unit 100 {
encapsulation vlan-ccc;
vlan-id 100;
peer unit 101;
}
unit 101
encapsulation vlan-ccc;
vlan-id 101;
peer-unit 100;
}
}
}
The protocol must be enabled.
protocols {
l2iw {
}
}

The routing instances that require interworking must have the logical iw0 interfaces associate at the VRF level and the l2vpn site level. The routing-instance does not have any association with the interfaces that form part of the existing VPN as the feature is purely enable to interconnect two existing VPN sites from different routing instances.

routing-instances vpn-a {
instance-type l2vpn;
interface iw0.100;
route-distinguisher 172.25.0.1:100;
vrf-target target:65001:100;
protocols {
l2vpn {
encapsulation-type ethernet-vlan;
site CE-3 {
site-identifier 3;
interface iw0.100;
remote-site 1;

routing-instances vpn-b {

instance-type l2vpn;
interface iw0.101;
route-distinguisher 172.25.0.1:101;
vrf-target target:65001:101;
protocols {
l2vpn {
encapsulation-type ethernet-vlan;
site CE-3 {
site-identifier 3;
interface iw0.101;
remote-site 2;

CoS and Path Selection

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s