Featured

VRF Table Label

Section 1: VRF Attachment Circuit Label Allocation

Under normal operation as attachment circuits are added to a VRF Junos will allocate each attachment circuit an additional VPN label when advertising associated IP prefixes into the core MP-BGP protocol.

In certain network deployments this default behaviour could create an unwanted depletion of VPN labels, due to label space limitations (on some hardware), or in other cases PE routers could be carrying large amounts of VRF tables or attachment circuits, which could require a significant amount of VPNv4 memory space.

The vrf-table-label command can help solve these issues, as it can be used to optimise the operation of VPN label allocation in MP-BGP.

Section 1.1: Per VRF Label Allocation

To solve these issues when vrf-table-label is introduced a single VPN label is applied to all prefixes exported from a given VRF into MP-BGP.

This method of label allocation can significantly reduce the amount of labels used on PE, regardless of the amount of prefixes or attachment circuits contained within a given VRF.

Section 2: Reference Topology

I am going to demonstrate how Junos handles this within the CLI, and will also show how the control plane responds to label allocation before vrf-table-label is introduced, and after it has been introduced.

The following topology will be used to demonstrate how this feature works. We will use two CEs deployed across remote PEs and will announce a loopback prefix via eBGP into the core PEs from each CE.

vrf-table-label-jpg

Section 2.1: Demonstrating The Default Behaviour

The outputs below shows an IP prefix announced by eBGP from CE1 in to DC1-PE1

Each output shows a different VPN label being allocated from the two attachment circuits that are used as next hops for each prefix.

The first prefix 20.20.20.20/32 is allocated VPN label 299904:

vpn-b.inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
* 20.20.20.20/32 (1 entry, 1 announced)
BGP group core-as1 type Internal
Route Distinguisher: 172.16.0.2:2
VPN Label: 299904
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [1] I
Communities: target:1:2

The second prefix 12.12.12.12/32 is allocated VPN label 299888:

vpn-b.inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
* 12.12.12.12/32 (1 entry, 1 announced)
BGP group core-as1 type Internal
Route Distinguisher: 172.16.0.2:2
VPN Label: 299888
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [1] I
Communities: target:1:2

Configuration

The example below shows vpn-b with the vrf-table-label command added to the configuration:

routing-instances {
vpn-b {
instance-type vrf;
interface ae0.20;
route-distinguisher 172.16.0.2:2;
vrf-target target:1:2;
vrf-table-label;
}
}

Once the command is applied the two prefixes are checked again to verify the changes in label allocation:

vpn-b.inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
* 20.20.20.20/32 (1 entry, 1 announced)
BGP group core-as1 type Internal
Route Distinguisher: 172.16.0.2:2
VPN Label: 16
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [1] I
Communities: target:1:2

The second prefix 12.12.12.12/32 is also allocated the same label:

vpn-b.inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
* 12.12.12.12/32 (1 entry, 1 announced)
BGP group core-as1 type Internal
Route Distinguisher: 172.16.0.2:2
VPN Label: 16
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [1] I
Communities: target:1:2

Finally the output below shows the LSI interface which also allows ingress packets to be passed twice through the PFE for additional processing:

lab@r1> show interfaces terse lsi
Interface Admin Link Proto Local Remote
lsi up up
lsi.0 up up inet
iso

Section 2: Additional Lookup Functionality

When adding vrf-table-label into the VRF configuration a software based LSI interface is created that can be used as additional means of passing a packet through the PFE.

The LSI interface can be used to provide an additional lookup process when a VPNv4 packet enters the PE from a remote site. This can be useful in scenarios where ingress firewall filters, CoS or additional policy or packet processing is required – to allow the LSI interface to provide a first lookup before ARP, or packet forwarding is carried out via a secondary pass through the PFE.

Note: On older Juniper routers a software lookup was used when a tunnel-services PIC was not present; the tunnel-service PIC provides a hardware based logical vt-interface for additional secondary look up capabilities. On newer MX routers however, the tunnel services is built into the line card and all of the processing is carried out within the PFE.

Section 2.1: Additional Security Functionality

This command is also used to overcome a security feature within Junos that prevents a multiaccess VRF attachment circuit from being advertised into MP-BGP.

Under normal operation a PE router will only announce a multipoint LAN interface when it receives a dynamic route that uses that interface as a next-hop, or a locally configured static route that uses the multiaccess interface as its next hop.

In cases where there is no static or dynamic routing the vrf-table-label command can be added to the VRF configuration. This overrides this default security feature, and forces the interface to be exported into MP-BGP, without the need for a dependent route.

Manipulating the AS

Within Junos several tools are available to manipulate the AS Path, which can be useful when BGP is deployed as a PE to CE routing protocol across multiple VPN sites. Due to the built in loop prevention mechanisms of BGP a VPN site announcing a BGP route into a VRF may cause an AS loop to be detected if the route is advertised into the same AS number again in another VPN site. In order to overcome this limitation several features are available in Junos.

AS Override

AS Override is used by a BGP speaker (normally a PE router) to replace a remote AS number with the AS number of the local router receiving the route. The route is then advertised further downstream with two AS numbers in the path that are identical. This feature is often used in MPLS networks that are providing connectivity to a single AS that is distributed geographically across multiple VPN sites.

Depending on the requirements AS Override can be configured under the BGP global configuration, group configuration or neighbour configuration. The following configuration is an example of the group configuration overriding the remote AS of 2 with the local AS of 1.

protocols {
bgp {
group ASN1 {
neighbor 1.1.1.2 {
local-address 1.1.1.1;
family inet {
unicast;
}
as-override;
peer-as 2;
}
}
}
}

AS Loops

AS Loops is another approach that can be used to overcome the limitations of AS path loops when multiple VPN sites are announcing BGP routes from the same AS. The feature allows a CE device to accept a BGP route that has been advertised with the CE routers’ local AS in the path.

The following example demonstrates how the AS loops function is configured on the CE router. The command will instruct the CE to receive routes with its local AS in the path x amount of times.

protocols {
bgp {
group ASN2 {
neighbor 1.1.1.1 {
local-address 1.1.1.2;
family inet {
unicast;
}
autonomous-system loops 1;
peer-as 1;
}
}
}
}

Configuration is also required on the PE router, to allow the PE to announce a BGP route to a neighbour that is already in the AS path.

protocols {
bgp {
group ASN1 {
neighbor 1.1.1.2 {
local-address 1.1.1.1;
family inet {
unicast;
}
advertise-peer-as;
peer-as 2;
}
}
}
}

 

BGP Independent Domain

What Exactly Does This Feature Do?

Imagine a scenario where a service provider has a requirement to peer their PE to a remote device using iBGP, and this remote device could be a customer CE, or a third party router that needs to send traffic across the service provider core to another remote site.

As the customer routes are sent over the provider core, the service providers AS would be added to the AS path of the customer routes, before these routes are announced to the end site.

There are two issues with this setup. Firstly the BGP Split Horizon rule the would prevent the routes from being announced to the remote site, as the customer AS would already exist in the path. The second issue could be that the provider (or customer) may wish for the routes to announced transparently between the two end points, without the provider AS being seen in the path.

How To Implement An Independant Domain

The VRF on the PE router is configured with the CE routers AS number, however this AS is not carried within the AS path attribute when the customer prefixes are carried across the providers core.

The reason for the above is due to the customer AS being removed from the AS path attribute and added into another attribute called ATTRSET; this effectively means that the customer AS is carried independently through the providers core, and does not affect the AS path used within the providers MPLS network.

When the routes arrive at a remote PE that is configured with the BGP independent domain, the original customer AS is taken from the ATTRSET, and replaced back into the AS path.

Configuration Example

The configuration is applied to the customer VRF under the routing-options heirarchy. The “independent-domain” command is appended to the AS number of the VRF, which in this case is 65501.

The command should be applied at all PE routes that are forming part of the VPN, and independent domain.

routing-instances {
vpn-a {
instance-type vrf;
route-distinguisher 172.21.0.2:4;
vrf-import vpn-a-import;
vrf-export vpn-a-export;
routing-options {
autonomous-system 65501 independent-domain;
}
}
}

Wrapping It Up

This feature is a pretty straight forward way of getting around a problem, however in most operational scenario’s it would probably be more wise to use some sort of layer 2 connection and allow the customer to peer directly between the two end points.

If the remote device is a managed CE, then there might be a case to use BGP independent domain, however other methods offer similar solutions such as AS-override, which I’ll be discussing in another article.

 

VRF Table Label

This command is primarily used to overcome a security feature within Junos that prevents a multiaccess/broadcast attachment circuit from being advertised into MP-BGP. Under normal operation a PE router will only announce a multipoint interface when it receives a dynamic route that uses the link as a next-hop, or a locally configured static route that uses the multiaccess interface as its next hop.

In cases where there is no static or dynamic routing the vrf-table-label command can be added to the VRF configuration. This overrides the default security feature and forces the interface to be exported into MP-BGP without the need for a dependent route.

When the command is applied to a VRF it also adds a second behaviour that changes the way VPN labels are allocated in the core network; normally each prefix is given a different VPN label, however when vrf-table-label is applied a single VRF label is added to all exported prefixes, which has the benefit of optimising the amount of labels used in the provider network.

When adding vrf-table-label into the VRF configuration a software based LSI interface is created. This interface can be used to provide an additional lookup process when a VPNv4 packet enters the PE. This can be useful in scenarios where ingress firewall filters, CoS or additional policy is present, to allow the LSI interface to handle the first lookup before a second ARP lookup is carried out through the PFE.

On older Juniper routers the software lookup was used when a tunnel-services PIC was not present; the tunnel-service PIC provides a hardware based logical vt-interface for additional secondary look up capabilities. On newer MX routers tunnel services is built into the line card.

The example below shows a VRF with the command configured and the output showing the LSI interface

routing-instances {
green-vpn-a {
instance-type vrf;
interface ae0.20;
route-distinguisher 172.25.1.1:200;
vrf-target target:45501:200;
vrf-table-label;
}
}
lab123@r1> show interfaces terse lsi
Interface Admin Link Proto Local Remote
lsi up up
lsi.0 up up inet
iso

RIB Groups

Section 1: The Requirement For RIB Groups

This article is going to take you through the process of setting up a RIB group, and will help to clear up any misunderstanding of how this feature works, and how it differs from other methods of routing leaking.

Due to the way in which Juniper uses certain terminology, this feature can seem confusing and convoluted. What’s more confusing is that both auto-export and RIB groups can provide route leaking, so why bother having both?

Well, the answer is simply that RIB groups are more powerful than traditional route leaking methods. RIB groups effectively leak routes by using a router’s RIB-in/import process, as opposed to the more commonly understood method of using route-target import and export leaking policies between VRFs.

The benefit of using a RIB group over traditional configuration is that by decoupling the policy away from the VRF import/export policy, and associating the route leaking at a protocol level (which is how a RIB group works), you have more flexibility to apply granular policy, that is not convoluted and tied into another process the router is handling.

So by design, it makes more sense to use VRF policies for their sole purpose (which is to control routes that are being imported and exported into MP-BGP), and to apply route leaking policies at a local protocol level, using a different set of policies and commands.

Section 2: Setting Up The Lab

In order to demonstrate how this works I’m going to use the lab environment detailed below to leak a number of routes between two VRFs.

The lab will consist of these elements:

  • Two PE routers known as r2 and r4 connected using MP-BGP
  • Two VRFs known as vpn-b and vpn-c configured on each of the PEs
  • Site A CPE2 attached to the r2 PE
  • Site B CPE1 attached to the r4 PE

The IP addresses and associated VRFs shown below will be used to simulate route leaking between the two VRFs known as vpn-b and vpn-c:

  • Site A CPE2 Lo.10 172.18.0.1/32 inside vpn-b
  • Site B CPE1 Lo.11 172.18.1.2/32 inside vpn-c

Figure 2.1: Lab Topology

The diagram below shows the network topology with each CPE attached to each PE. The CPE in site A has an interface in vpn-b, and the CPE in site B has an interface in vpn-c.

physical_rib

The purpose of the lab will be to provide connectivity between the loopback addresses on each of the CPEs; this will require bidirectional route leaking on each local PE, using a RIB group.

I will document each step of the configuration, and will explain how each step relates to the process of route leaking within the RIB group.

At the end of the lab some pings will be sent between the two CPEs, to confirm the RIB group configuration has been successful.

Section 3: Creating The RIB Group

Under the global routing-options heirarchy the name of the RIB group should be configured first. The RIB group can be referenced at various protocol and RIB levels, so having the main policy and configuration location at global level makes sense.

Once the RIB group has been named subsequent parameters should define the source RIB that routes should be taken from, and the destination RIB they should be sent to.

As shown in figure 3.1 the import-rib statement is used to name the RIB group on PE r2, and is followed by a list of RIBs that are in scope for route leaking.

The router interpretes the first RIB in the square brackets (vpn-b) as the source table, (which is where routes are copied from), and any subsequent RIBs as the destination tables where the routes will be copied to.

Note: The configuration created here includes an optional import policy – this is to be used to explicitly state the prefix and protocol that will be imported into the RIB group.

Figure 3.1

routing-options {
vpn-b-to-vpn-c {
import-rib [ vpn-b.inet.0 vpn-c.inet.0 ];
import-policy rib-group-vpn-b-to-c;
}
}

Figure 3.2

The import-policy referenced in the above configuration is shown below. Applying this gives granularity to the routes that are going to be leaked into vpn-c.

Without this policy all routes in vpn-b would be leaked into vpn-c.

policy-options {
policy-statement rib-group-vpn-b-to-c {
term 10 {
from {
protocol bgp;
route-filter 172.18.0.1/32 exact;
}
then accept;
}
term 100 {
then reject;
}
}
}

Figure 3.3

I have included some outputs of the current VRFs on PE r2. The outputs are specifically  querying the route that I wish to leak into vpn-c.

lab@r2# run show route table vpn-b.inet.0 172.18.0.1/32 exact
vpn-b.inet.0: 11 destinations, 12 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
172.18.0.1/32 *[BGP/170] 03:54:32, localpref 100
AS path: 65501 I, validation-state: unverified
> to 172.17.0.2 via ge-0/0/0.30

Figure 3.4

As we can see PE r2’s vpn-c table currently has no route to 172.18.0.1/32, because this route is learnt via an attached CPE in vpn-b.

lab@r2# run show route table vpn-c.inet.0 172.18.0.1/32 exact
[edit]
lab@r2#

Section 4: Applying The Configuration To BGP

As previously explained route leaking using RIB groups is carried out at the protocol level, as routes enter RIB-in.

Based on that theory, the configuration shown in figure 4.1 will be applied to the BGP protocol in vpn-b, under the respective address family; applying at the address family level makes sense, as Junos stores address families in different RIBs, such as inet0 for IPv4, and inet6 for IPv6.

The configuration calls the RIB group previously setup under the global routing-options heirarchy, thus inheriting all policy defined within that configuration.

Figure 4.1

routing-instances vpn-b {
protocols {
bgp {
group vpn-b {
neighbor 172.17.0.2 {
description vpn-b-test-ebgp;
mtu-discovery;
family inet {
unicast {
rib-group vpn-b-to-vpn-c;
}
}
peer-as 65501;
}
}
}
}
}

Figure 4.2

Once the above configuration has been commited the vpn-c routing tables on the r2 PE can be checked again.

The output shown below confirms that the route leaking configuration has been successful, as vpn-c now has a route to the loopback address of site A CPE2.

This isn’t the end of this task though, as there are a number of additional steps that need to be taken to successfully ping from site B CPE1 (via vpn-c), to the route that has just been leaked from vpn-b.

lab@r2# run show route table vpn-c.inet.0 172.18.0.1/32 exact
vpn-c.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
172.18.0.1/32 *[BGP/170] 01:14:50, localpref 100
   AS path: 65501 I, validation-state: unverified
> to 172.17.0.2 via ge-0/0/0.30
[edit]
lab@r2#

Section 5: Next Hop Interfaces

The previous steps have enabled the loopback address of 172.18.0.1/32 from site A CPE2 to be successfully route leaked into vpn-c, with a next hop of address of 172.17.0.2, via ge-0/0/0.30.

This next hop interface presents a problem though, as it exists exclusively in vpn-b, and we need this next hop interface available in vpn-c, otherwise routing to the destination loopback address in vpn-b is not going to be possible.

Figure 5.1

To confirm the current situation, the output below from PE r2 shows there is currently no route in vpn-c to the next hop address of 172.17.0.2.

lab@r2# run show route table vpn-c 172.17.0.2
[edit]
lab@r2#

Section 6: Understanding Interface Routes

Because RIB groups act on protocols using RIB-in, some additional configuration is going to be needed to route leak the connected next hop interface into vpn-c – this is taken care of using the interface-routes command.

Now we know that RIB groups operate at a protocol RIB-in level, so it should be expected that when handling connected routes, the commands are going to look slightly different to that of importing from a dynamic routing protocol.

Figure 6.1

Below you can see the interface-routes command being applied under the routing options heirarchy within the source RIB, which in our case is vpn-b.

This command will use the previously defined RIB group policy setup under the global routing-options heirarchy to match any directly connected routes within vpn-b, thus leaking them into vpn-c.

routing-instances vpn-b {
routing-options {
interface-routes {
rib-group inet vpn-b-to-vpn-c;
}
}
}

Figure 6.2

Because the interface-routes command references the main RIB group configuration it will of course inherit any policy that’s previously been applied to the RIB group.

In order to allow the next hop address to leak into vpn-c a change is also going to be required to the initial policy I created to control which routes can be leaked into vpn-c.

Shown below is an additional term (term 20) that has been added to that policy to enable this requirement.

policy-options {
policy-statement rib-group-vpn-b-to-c {
term 20 {
from {
protocol direct;
route-filter 172.17.0.0/30 exact;
}
then accept;
}
}
}

Figure 6.3

Once the configuration is committed vpn-c has aquired the next hop route 172.17.0.0/30.

lab@r2# run show route table vpn-c 172.17.0.0
vpn-c.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
172.17.0.0/30 *[Direct/0] 00:47:50
> via ge-0/0/0.30
[edit]
lab@r2#

Section 7: Final Steps

Theoretically vpn-c now has all of the required routes to forward packets towards the CPE2 loopback address in vpn-b at site A.

To establish end to end connectivity routing has to work in both directions, and in order to achieve this the steps we have take above (from vpn-c’s perspective) will need to be implemented from vpn-b’s perspective; so a loopback address that’s originated in vpn-c can also be reached from the CPE at site A.

Because the fundamental steps of route leaking have been detailed in the previous sections I’m going to summarise this configuration in a few figures below.

Figure 7.1

Here you can see the creation of the RIB group on PE r2 at site B, where everything is effectively reversed to leak back into vpn-b.

routing-options {
vpn-c-to-vpn-b {
import-rib [ vpn-c.inet.0 vpn-b.inet.0 ];
import-policy rib-group-vpn-c-to-b;
}
}

Figure 7.2

The RIB group policy that stipulates route leaking of the loopback address and next-hop interface at site B in vrf-c is shown below.

policy-options {
policy-statement rib-group-vpn-c-to-b {
term 10 {
from {
protocol bgp;
route-filter 172.18.1.2/32 exact;
}
then accept;
}
term 20 {
from {
protocol direct;
route-filter 172.17.1.4/30 exact;
}
then accept;
}
term 100 {
then reject;
}
}
}

Figure 7.3

The final configuration step is to apply the RIB group on PE r2 under the BGP protocol heirarchy in vpn-c, which is shown below.

routing-instances vpn-c {
protocols {
bgp {
group vpn-c {
neighbor 172.17.1.6 {
description vpn-c-test-ebgp;
mtu-discovery;
family inet {
unicast {
rib-group vpn-c-to-vpn-b;
}
}
peer-as 65503;
}
}
}
}
}

Section 8: Testing Connectivity

Now that everything is in place we can test connectivity using a ping sourced from the site A CPE1 device, pinging from the test loopback address to the test loopback address at site B on CPE2.

The results of which are shown below in figure 8.1.

Figure 8.1

lab123@site-a-cpe-1# …rce 172.18.0.1 routing-instance vpn-b
PING 172.18.1.2 (172.18.1.2): 56 data bytes
64 bytes from 172.18.1.2: icmp_seq=0 ttl=62 time=24.225 ms
64 bytes from 172.18.1.2: icmp_seq=1 ttl=62 time=20.661 ms
64 bytes from 172.18.1.2: icmp_seq=2 ttl=62 time=20.334 ms
64 bytes from 172.18.1.2: icmp_seq=3 ttl=62 time=20.884 ms

Appendix A: Link-State Protocols (OSPF/ISIS)

Because route leaking with RIB groups is applied at the RIB in (or import) level, configuring this feature with link-state protocols is effectively the same process as when using BGP.

For this reason I have not included an example of how to this with OSPF or ISIS. One can assume that the configuration is exactly the same, you simply create the RIB group at the global routing-options heirarchy and then apply it directly under the protocol heirarchy.

Appendix B: Notes regarding BGP Split Horizon

One important aspect of RIB groups that differs from auto export is that the BGP split horizon rule is not considered when leaking routes. When configuring RIB groups it’s considered best practice to change the vrf export policy on the destination table to stop the announcement of the leaked routes. This protects from any potential routing loops or sub optimal routing. It may not always be required, it depends on the VPN topology and requirements for applying route leaking.

Continue reading “RIB Groups”

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;