In this article we'll walk through the configuration of a basic BGP signaled VPLS. The VPLS we configure will consist of several sites, one of which is multihomed. The VPLS will also have a BGP signaled L2VPN stitched into it. But before we delve into the configuration, let’s do a brief VPLS overview.
VPLS overview
To quote RFC 4761: ‘In essence, a VPLS glues together several individual LANs across a packet switched network to appear and function as a single LAN.’
By emulating an Ethernet LAN across an MPLS network and by connecting different customer sites in a transparent way, VPLS customers ‘feel’ as though the service providers’ network is a switch:
By using the BGP L2VPN address family, the service-providers’ PE routers can signal VPLS membership and exchange the routing information required to setup VPLS connections. Often, the quality ‘auto-discovery’ is attributed to the VPLS technology. This is a reference to the fact that all PE routers configured with a VPLS instance will be able to discover the other PE routers involved in the same instance through BGP signaling. The PE routers involved in the same VPLS instance will automatically setup pseudowires to all of the other PE routers, enabling a multipoint to multipoint connection. To enable this connection, all of the PE routers involved with the offering of VPLS services need to have a full mesh of LSPs between them. This full mesh of LSPs can be either RSVP or LDP signaled.
The MAC learning in a VPLS is a data plane operation, not a control plane operation as is the case with EVPN for example. What's more is that the PE performs MAC learning in a way that is similar to that of a switch. The PE creates a separate MAC table for each VPLS. The PE then builds the MAC table by examining the addresses of the frames it receives. These frames can be coming from other PE routers or from local ce devices. Frames with unknown destination MAC addresses are flooded across the VPLS.
Since we’ll be stitching an L2VPN into the VPLS, let’s briefly touch the major differences between the two technologies. Even though they are using the same BGP address family for signaling, they are not the same. An L2VPN is an emulation of a point-to-point layer 2 connection of which both sides can connect to dissimilar media. A VPLS is multipoint to multipoint and it can only connect sites that use similar (Ethernet) media.
VPLS configuration.
The scenario we’ll be configuring here is the following:
We will configure a VPLS for a customer with three sites. Site 1 and 2 will be configured as regular sites connected to a single PE. Site 3 will be a multihomed location with a primary and a secondary connection. We’ll finish up with a BGP signaled L2VPN location, c1-s4. This location will be stitched into the VPLS on the PE that is connected to c1-s1. In this walkthrough, I’ll focus on the configuration that is required for the VPLS itself and I’ll skip the configuration of the underlying MPLS network.
Before we start the configuration of the routing-instances, let’s make sure that the peering sessions between the PE routers and the route-reflectors are configured with the correct address-family. If the route-reflectors are configured in a BGP group called ‘rr-cluster’, we would need to add the following configuration command:
set protocols bgp group rr-cluster family l2vpn signaling
This enables BGP sessions configured for that group with the necessary address family. After configuring this on all the PE routers, the route-reflectors have to be configured with this address family as well.
Next, we configure the proper encapsulation for the customer facing interfaces on the PE routers. The interface configuration is the same for all Ethernet interfaces that are configured to be a part of a VPLS routing-instance. The following is an example configuration of a customer facing interface:
set interfaces xe-0/3/0 flexible-vlan-tagging set interfaces xe-0/3/0 encapsulation flexible-ethernet-services set interfaces xe-0/3/0 unit 3002 description c1-s1 set interfaces xe-0/3/0 unit 3002 encapsulation vlan-vpls set interfaces xe-0/3/0 unit 3002 vlan-id 3002
By configuring the main interface with ‘flexible-vlan-tagging’ and ‘encapsulation-flexible-ethernet-services’ we accomplish two things. We can use single-tagged and dual-tagged frames on logical interfaces. It also allows us to configure multiple per-unit Ethernet encapsulations. If you use ‘encapsulation vlan-vpls’ on the main interface, every unit will be usable for VPLS only. With ‘vlan-tagging’ configured, you’re stuck with only being able to use a single-tag on each logical unit. Even though it’s not really necessary for this scenario, leaving other future options open is always nice.
After configuring the BGP address-family and the customer-facing interfaces, we can proceed with the configuration of the actual routing-instances. Let’s start with site 1 and 2:
The configuration of the VPLS can be divided into two parts. The first part is the configuration of the vrf routing-instance. This could be done as follows:
set routing-instances c1-vpls instance-type vpls set routing-instances c1-vpls vlan-id 3002 set routing-instances c1-vpls interface xe-0/3/0.3002 set routing-instances c1-vpls route-distinguisher 65000:605 set routing-instances c1-vpls vrf-target target:65000:605
The instance type is set to ‘vpls’. In this case, the customer can only use 1 VLAN-id. As an alternative, you could also work with a list of VLANs or simply configure it with ‘vlan-id all’. Whatever you configure has to match on all sites for the pseudowires to come up. In a live network, it’s good to think about what’s needed in advance. This is because an alteration to the number of VLANs in the VPLS will cause for the pseudowire to (briefly) go down.
The third statement places the interface in the routing instance. The fourth and fifth statements are the route-distinguisher and route-target. The route-target community is the extended BGP community that signifies what VPN membership the routes have. The route-distinguisher enables BGP to distinguish overlapping routes in different VPNs and treat them as unique routes.
On to the second part of the VPLS configuration, which is configured under the [routing-instances c1-vpls protocols vpls] stanza. This part could be configured like this:
set routing-instances c1-vpls protocols vpls no-tunnel-services set routing-instances c1-vpls protocols vpls site c1-s1 site-identifier 1
The first statement is the ‘no-tunnel-services’ statement. On an MX, this statement is required only if there is no tunnel services PIC installed. Instead of having a VT-interface, this statement will provide us with an LSI- interface per remote site. The MX will automatically create LSI-interfaces for every other site that is active in the VPLS.
The second statement indicates that this is site c1-s1 and that the identifier for this site is 1. Every site is giving a unique identifier. Apart from a site-identifier, a site-range could also be specified. When a site-range is specified, it specifies an upper-limit to the value that the site-identifier can have within the entire VPLS. For instance, a site-range of 4 would effectively impose an upper limit of 4 sites inside a VPLS. Not specifying a site-range, which is the recommended approach, will provide the VPLS with the default value of 65354.
Site 2 is also going to be a ‘regular’ site and it is configured as follows:
set routing-instances c1-vpls instance-type vpls set routing-instances c1-vpls vlan-id 3002 set routing-instances c1-vpls interface ge-0/1/0.3002 set routing-instances c1-vpls route-distinguisher 65000:605 set routing-instances c1-vpls vrf-target target:65000:605 set routing-instances c1-vpls protocols vpls no-tunnel-services set routing-instances c1-vpls protocols vpls site c1-s2 site-identifier 2
The only real difference between site 1 and site 2 is the ‘site-identifier’ part of the configuration, making this a unique site.
Let’s move on to the multihomed site:
VPLS multihoming allows us to connect site 3 to multiple PE routers while we prevent a layer 2 loop at the same time. The basic configuration of a multihomed site does not differ much from the previously configured standard sites:
primary:
set routing-instances c1-vpls instance-type vpls set routing-instances c1-vpls vlan-id 3002 set routing-instances c1-vpls interface ae1.3002 set routing-instances c1-vpls route-distinguisher 65000:605 set routing-instances c1-vpls vrf-target target:65000:605 set routing-instances c1-vpls protocols vpls no-tunnel-services set routing-instances c1-vpls protocols vpls site c1-s3 site-identifier 3 set routing-instances c1-vpls protocols vpls site c1-s3 multi-homing set routing-instances c1-vpls protocols vpls site c1-s3 site-preference primary
backup:
set routing-instances c1-vpls instance-type vpls set routing-instances c1-vpls vlan-id 3002 set routing-instances c1-vpls interface xe-0/2/0.3002 set routing-instances c1-vpls route-distinguisher 65000:605 set routing-instances c1-vpls vrf-target target:65000:605 set routing-instances c1-vpls protocols vpls no-tunnel-services set routing-instances c1-vpls protocols vpls site c1-s3 site-identifier 3 set routing-instances c1-vpls protocols vpls site c1-s3 multi-homing set routing-instances c1-vpls protocols vpls site c1-s3 site-preference backup
A multihomed site is one site. Therefore, when you configure multihomed sites, the site-identifier needs to be the same on both PE routers. Further configuration that is required to make a site multihoming is added under the ‘protocols vpls’ stanza. The first extra statement is the ‘multihoming’ statement. This statement specifies to the PE router that the site is multihomed to another PE router. It will make the PE router track BGP peers. When there are no peers available, by default, the PE will deactivate all interfaces for the VPLS site.
The second statement indicates whether or not the site is serving as the primary or backup connection. These statements influence the local preference of the routes advertised by the PE. The route towards the primary location will be preferred by other PE routers due to this higher local preference.
Let’s add one more customer location to our VPLS. What we’ve created this far is a VPLS with three sites, one of which is multihomed. Now, instead of adding another VPLS location, let’s stitch a BGP signaled L2VPN into our VPLS:
This BGP signaled L2VPN is configured between two PE routers. On the PE router where the VPLS is not active, the configuration of the L2VPN is as follows:
set interfaces ge-0/0/0 flexible-vlan-tagging set interfaces ge-0/0/0 encapsulation flexible-ethernet-services set interfaces ge-0/0/0 unit 3002 encapsulation vlan-ccc set interfaces ge-0/0/0 unit 3002 vlan-id 3002 set routing-instances l2vpn-stitch instance-type l2vpn set routing-instances l2vpn-stitch interface ge-0/0/0.3002 set routing-instances l2vpn-stitch route-distinguisher 192:192 set routing-instances l2vpn-stitch vrf-target target:4567:32435 set routing-instances l2vpn-stitch protocols l2vpn encapsulation-type ethernet-vlan set routing-instances l2vpn-stitch protocols l2vpn interface ge-0/0/0.3002 set routing-instances l2vpn-stitch protocols l2vpn site cpe site-identifier 2 set routing-instances l2vpn-stitch protocols l2vpn site cpe interface ge-0/0/0.3002
The L2VPN will be stitched into the VPLS on the router where site 1 is active. In order to do so, we will need to configure the L2VPN instance on that router as well. In addition to this, we will also need to outfit that same router with tunnel interfaces. Let’s start with the configuration of those tunnel interfaces:
set chassis fpc 0 pic 2 tunnel-services set interfaces lt-0/2/0 unit 0 encapsulation vlan-vpls set interfaces lt-0/2/0 unit 0 vlan-id 3002 set interfaces lt-0/2/0 unit 0 peer-unit 1 set interfaces lt-0/2/0 unit 1 encapsulation vlan-ccc set interfaces lt-0/2/0 unit 1 vlan-id 3002 set interfaces lt-0/2/0 unit 1 peer-unit 0
Tunnel interfaces can be used for a variety of reasons. They can be used for route-leaking, labbing or for the creation of certain tunneling interfaces, such as GRE interfaces. Here, we will use these tunnel interfaces for something else. The tunnel interfaces will be used to stitch the VPLS and the L2VPN together. Under the [ chassis ] stanza, we have just configured the MX FPC for tunnel-services. As a result, the MX will automagically create a tunnel interface called ‘lt-x/x/x’. We then configured two logical units for the tunnel interface and peered them together. Unit 1 is peered to unit 0 and vice versa. Together, they form a cross-connection allowing traffic to flow between the L2VPN and the VPLS:
Traffic between the L2VPN and the VPLS will not happen until the lt-interfaces are placed inside the proper routing-instance. Unit 0, configured with vlan-vpls encapsulation, can be placed inside a VPLS routing-instance. Unit 1, configured with encapsulation ‘vlan-ccc’, can be placed inside an L2VPN instance.
Let’s finish the configuration of the L2VPN connection first:
set routing-instances l2vpn-stitch interface lt-0/2/0.1 set routing-instances l2vpn-stitch route-distinguisher 192:192 set routing-instances l2vpn-stitch vrf-target target:4567:32435 set routing-instances l2vpn-stitch protocols l2vpn encapsulation-type ethernet-vlan set routing-instances l2vpn-stitch protocols l2vpn interface lt-0/2/0.1 set routing-instances l2vpn-stitch protocols l2vpn site stitch site-identifier 1 set routing-instances l2vpn-stitch protocols l2vpn site stitch interface lt-0/2/0.1
Note that the L2VPN is configured with its own unique site-identifiers. These site-identifiers have nothing to do with the VPLS we configured. Site-identifiers are unique per routing-instance.
The last configuration item, placing the other tunnel interface into the VPLS routing-instance, is done as follows:
set routing-instances c1-vpls interface lt-0/2/0.0
The L2VPN site is stitched into the VPLS at site 1. This means that the other PE routers involved with the VPLS need to go through site 1 when they want to reach the L2VPN location.
After stitching the L2VPN site into the VPLS, the ISP can present the customer with four locations connected together. Let’s see if the customer can run ospf across the VPLS:
inetzero@c1-s1> show ospf neighbor Address Interface State ID Pri Dead 192.168.51.4 xe-2/0/1.3002 Full 10.0.0.4 128 7 192.168.51.5 xe-2/0/1.3002 Full 10.0.0.2 128 7 192.168.51.2 xe-2/0/1.3002 Full 10.0.0.3 128 7
This concludes the basic configuration of a VPLS with an L2VPN stitched into it. However, knowing how to verify that everything you configured is working as intended is arguably even more important. Luckily, Junos has a very rich cli that enables you to get to the bottom of just about anything the router is doing. In our next post we discuss the verification of VPLS.
