JNCIS-SP: MPLS part 2.

After going through MPLS basics, label distribution protocols and L3-VPN, I decided to do another lab on Layer 2 MPLS applications. I’ll focus on all four possibilities mentioned in the study guide and create a (very) basic scenario for all of them.

The picture below shows the four types of layer 2 connections on the left side and the lab topology on the right side.


The lab setup is similar as other labs. R2, R3, R6 and R7 are logical systems on an MX80. I have configured LDP and OSPF in advance. The PE routers are R2 and R3. This is where we will configure the different Layer 2 VPNs.

On the one side, there is an EX4500 with four routing-instances. All have the same IP address configured and for each scenario there is a different vlan. On the other side, there is an MX480 with four logical systems. All have the same IP address configured and every logical-system has a different vlan.

What I will do is provide layer 2 connectivity between the MX480’s logical-systems and the EX4500’s routing-instances in four different ways. In two cases, we will utilize LDP, and in the other two cases we will utilize BGP.

MP-BGP signaled VPLS.

The end-goal of the scenario is to have connectivity between R11 and EX4500_1 by making use of a BGP signaled VPLS over LDP signaled LSPs. The focus here is the BGP signaled VPLS:


VPLS enables multiple endpoints in a service provider's network to act as a single-LAN segment to the customer. Unknown MAC addresses are flooded throughout the VPLS.

When you construct a VPLS and utilize BGP as signaling protocol, BGP will handle the connections to already existing endpoints in the VPLS. This means that a new addition to a VPLS only requires some configuration on the customer-interface-facing PE on which the new connection is added. Unlike L2 VPNs, each site in a VPLS must use Ethernet.

Because BGP is designed to be a large scale routing-protocol, it’s not likely you have issues with the number of routes added in your network.

The PE routers connect the customer sites together and hold all VPLS specific information. The PE’s perform MAC learning and store all information in a VPLS-specific MAC table.

In our case, to R6 and R7 all traffic is just MPLS traffic (this goes for all 4 scenarios). In order to provide for Layer 2 connectivity between R11 and the EX4500_1, the PE routers will need to form a BGP neighbor-relationship.

This BGP neighbor relationship has to be configured to carry the ‘l2-vpn signaling’ address family. This way, they will be able to exchange VPLS NLRI.

The PE’s need to have a full mesh of IBGP sessions. On a bigger network, this can be alleviated through the use of RRs.
Let’s look at the next-picture, which will describe the end-result of our BGP signaled VPLS:


R2 will have an IBGP neighbor relationship with R3. Both routers will be configured with the l2vpn-signaling address family. R2 will use this address family to signal the information depicted in the left. That information will tell R3 that R2 has a member interface in the VPLS and it will give R3 enough information to calculate the VPN label it will need to use to forward traffic.

Let’s walk through the configuration of this setup on R3 and start with BGP;


This configuration will suffice for our lab. The address family l2vpn is really all that’s needed. The session between R2 and R3 will, when established, list the l2vpn-signaling:


Let’s move on and create a basic routing-instance on R3 and configure the CE-facing interface;


The instance type has to be a vpls. In our case, only vlan 560 will be part of this VPLS, but configuration-wise it is very flexible. You can configure ‘vlan-id all’ or specify a list. Also, with ‘flexible ethernet services’ configured under the interface, you can mix all sorts of encapsulation on subinterfaces configured under 1 physical interface.

Every BGP signaled VPLS needs to have its own unique route-target and route-distinguisher. The ‘site-range’ specifies an upper limit to the number of site identifiers that will be allowed to bring up a pseudowire with this VPLS. In our case, the range is 10, meaning there can be no other site with a value greater than 10.

Mac table size is obvious. The ‘no-tunnel-services’ command is in case there is no services PIC installed, which is the case in my lab. This configuration command will create a Label-Switched-Interface (LSI) to provide for the VPLS functionality.

The connectivity type permanent is to have the VPLS remain up at all times, unless specifically taken down.
The last two commands are the interface configuration commands. The vlan-id, 560, and the encapsulation type ‘vlan-vpls’.

This information is enough to bring up a basic VPLS between the PE’s and establish connectivity in our lab between the EX4500_1 and R11.
Let’s examine some printouts and start with the command ‘show vpls connections instance VPLS extensive’;


From top-to-bottom, you see the following pieces of information;

    • Local instance name and local site
    • Number of interfaces, and interface placed into the VPLS
    • The label-base, offset and range sent to the R2 neighbor
    • The information received from the R2 neighbor
    • The recorded VPLS history

The other interesting commands to observe are the following;


At the top we see the received BGP information. Second it the LDP information that is used to reach R2 via our MPLS network. At the bottom, we can see what the router installed into the forwarding table. VPN label 262232 (as previously calculated) and LDP label 300576 will be pushed onto frames destined to R2 VPLS site.

LDP signaled VPLS.

Same setup as in the previous scenario, only LDP will be used to signal the VPLS:


Since all routers are already running OSPF and LDP, very little additional configuration is required in the case of LDP-signaled VPLS.
The configuration of an LDP signaled VPLS involves the configuration of an interface and a routing-instance.

The interface is the same as when using BGP as a signaling protocol;


The routing-instance configuration differs and requires less configuration statements. For a basic LDP-signaled VPLS, the following is required;


The configuration of the instance-type and the interface is pretty much the same as with a BGP signaled VPLS. The thing you’ll notice is the lack of a route-distinguisher and a route-target. These two items are used by BGP and therefore only required in instances that are setup by BGP.
The only other requirements are the vlan(s) and the LDP neighbor. This configuration is enough to have the routers establish the pseudowire between each other.
Let’s examine some output on R2 and start with the ‘show vpls connections instance VPLS-LDP extensive’ command;


In this printout, we see the status, remote PE address, incoming and outgoing label and the connection history.
Let’s look at the label information in towards PE-R3 and then at the R13 entry installed into the forwarding table:


The label towards the remote PE can be acquired by examining the table filled by LDP. This label will be the top label pushed onto packets sent from EX4500_3 towards R13. The top label, 800001, was obtained earlier by examining the connection status.

BGP signaled L2VPN.

The third option is BGP signaled L2VPN.


This type of Layer 2 VPN has a lot of similarities to the BGP signaled VPLS. Some of the similarities are;

    • the BGP address-family
    • the auto provisioning when a new site is added

The VPLS and L2VPN solutions differ from each other as well. Most notably, the L2VPN;

    • enables point-to-point VPNs only
    • enables the connection of dissimilar protocols (requires ‘protocols l2vpn encapsulation-type interworking’)

In this scenario, the focus will be on the most basic L2VPN possible, requiring an ‘l2vpn’-type instance, ‘ethernet-vlan’ encapsulation and ‘vlan-ccc’ interface encapsulation. Let’s observe the configuration on R2:


The configuration of a BGP signaled L2VPN is very similar to the configuration of a BGP signaled VPLS. Examining the status of this BGP signaled L2VPN is too.
The ‘show l2vpn connections instance L2-VPN extensive’ should look familiar:


A look at the routing table shows this part will offer no surprises as well. The top label is the LDP label. This is the label to reach R3 as we have already seen in the previous example. The additional VPN label was acquired from the BGP neighbor:


LDP signaled layer 2 circuits.

The last of four options;


A layer 2 circuit is always point-to-point. On the two endpoints, in our case R2 and R3, the encapsulation type is either ‘vlan-ccc’ or ‘vlan-tcc’. In this lab, vlan-ccc will be used. Vlan-tcc (translation cross-connect) allows the end-points on both sides to have different media.

Signaling wise, LDP is used to create a virtual circuit (VC) between the PE’s. This VC will provide layer 2 connectivity between the EX4500 and R12.
Since we are using LDP here, again, no route-distinguisher or route-target is required. Additionally, l2circuits do not even require a routing-instance.

R2 and R3 need to form an extended LDP-neighbor relationship for the vc –labels to be exchanged. For this to happen, LDP must be enabled on the loopback interface of both PE’s. This is not necessary for the P-routers; they only need to have LDP enabled on the core-facing interfaces to provide LSPs between the PE’s.
Let’s have a look at the configuration that is required for this scenario;


The interface is pretty self-explanatory. The thing to notice is the place where the circuit is defined. Under the [ protocols l2circuit] hierarchy, you can specify (at a minimum) the following three vc-properties;
    •the neighbor PE
    •the interface forming the layer 2 circuit
    •the VC identifier

Under the [protocols ldp] hierarchy, the only configuration that was needed was the core-facing interface (to setup LSPs with the rest of the network) and the lo0.2 interface, for an extended LDP neighbor relationship with the other PE.
The interface, the l2circuit and the ldp configuration is all that is required to successfully establish a layer 2 circuit across an MPLS network. After the interface was committed, the targeted LDP session will show up immediately;


If the hello seems a bit long, this is easily changed with ‘set protocols ldp targeted-hello hello-interval 2 hold-time 6’. Without changing anything on R3, the timers changed;


To observe details regarding the state of the l2circuit, or some history, we can issue the command ‘show l2circuit connections extensive’:


That is really all there is to establishing a basic l2circuit on Junos MX-series.