UPDATED: L2 MPLS VPN introduction and H3C configuration examples (Martini and Kompella VLLs/VPLS)

In this article we will have a quick look at all basic MPLS L2 VPNs (CCC/Martini/Kompella) and also one that is by far the most coolest, the VPLS (or sometimes called MPLS L2 VPN). I already made some basic introductory MPLS VPN (Layer 3) on H3C example in previous post, now it is time to do some a little more interesting stuff and utilize MPLS to do L2 VPNs.

UPDATE: This article was updated from the original version published in May 2012 and now it contains much more configuration examples and also will streamline the vlan and port-based customer access to an L2 tunnel or VPLS.

Let’s start with the basic overview of what L2 connectivity you can provide via MPLS and what does the Martini and Kompella words mean.

  • Martini VLL (Virtual Leased Line) – this is a method of providing one point to point L2 link between two endpoints in the MPLS network by using LDP as a signaling protocol to transfer tunnel identification.
  • Kompella VLL (Virtual Leased Line) – this is exactly the same L2 point-to-point service as previous Martini VLL has, the difference is this one uses BGP as a signaling protocol to transfer tunnel identificaiton.
  • Martini VPLS (Virtual Private LAN Service) – in this service, you create an illusion that the entire MPLS cloud is a giant switch for the customer, the “Martini” again means using LDP as signaling protocol.
  • Kompella VPLS (Virtual Private LAN Service) – in this service you again create an illusion of a giant switch to the customer, but internally it will use BGP for signalling.

Virtual Leased Lines

Ok, lets start with the basic Virtual Leased Lines (or VLLs). The point of these is to sell to the customer an L2 connection between two endpoints. Look at the picture below called “MPLS L2 path from LSP”. The CE-2 and CE-3 has a layer 2 reachability between each other over MPLS cloud. However, this is strictly point-to-point.

MPLS L2 path from LSP

MPLS L2 path from LSP

You can achieve this L2 point-to-point connection in three different ways. First we have the option to create this kind of tunnel statically by assigning a complete LSP (label Switch Path) manually. This basic architecture is called Circuit Cross Connect (CCC) and is a method of creating L2 via static configuration.

Basic characteristics of static L2 point-to-point VLL creation:

  • No inner lable, only single MPSL label per packet.
  • Static MPLS label assignment
  • Configuration task must be completed also on P routers!
  • There can be switching both local (two interfaces on two PEs) and remote switching.

Example of statical CCC VLL will not be shown here as it is practically not really useful and will take a lot of space with all the assignments, and I do not consider it much interesting (yes, I stand for this)

Martini VLLs

Next variation of L2 MPLS VLL is called Martini VLL (Virtual Leased Line) and this one is essentially utilize LDP to signal Virtual Circuit (VC) identification across two PE nodes. The other tunnel can be either LSP or even GRE tunnel. In this L2 VPN, the local switching function (two interfaces on single PE) is not supported on H3Cs and everything that comes to the PE is switched across.

Martini MPLS L2 VLL

Martini MPLS L2 VLL

Basic characteristic:

  • Inner tunnel MPLS label identifies unidirectional tunnel
  • Outer tunnel is classical MPLS LSP between PEs.
  • Remote manual LDP session has to be created between the two remote PEs.
  • Requires LDP extension for LDP remote sessions. RFC 4906 defines new LDP Forwarding Equivalency Class type “128” -> Virtual Circuit FEC Element that is carrying identification of the VLL tunnel.
  • RFC 4905 describes packet encapsulation

Configuration Example of Martini L2 VLL

First, lets have a look on the lab diagram, in this scenario, we will have two customers (A and B) and both want L2 point-to-point service for their L3 servers. As it is common scenario, the customer will be coming via aggregation layer switch to save ports on our PE machines. We will use this to capture vlan tagging per customer to the tunnels.

Martini VLL architecture example topology

Martini VLL architecture example topology

In configuration example, we will skip activating basic MPLS on H3C routers as this can be found in previous posts here. Let’s start with Martini VLL configuration, first thing to do is activate mpls l2vpn functions on H3C.

Now I expect that basic MPLS with directly connected LDP sessions are up and working, we need the Martini remote LDP session that can be created as this:

You can verify that the LDP sessions has come up by looking at standard LDP output commands:

Next, this one comes in a single example. For both PEs in our example, we will configure two service instances for two customers. Both ports connecting to the CEs via aggregation switch and are marked for VLAN 10 and VLAN 20 by encapsulation s-vid (service vlan ID) command and PWs are manually configured to a remote LDP peer with PW-ids configured as well. This example will therefore work by transporting incoming tagged VLAN 10 and VLAN 20 traffic on the port to the other side. NOTE: The port itself doesn’t have to be trunk to capture the VLAN 10 and VLAN 20 traffic.

PE1

PE2

Syntax Explanation:
service-instance is one customer service being served on the port, you can consider the number behind “service-instance” command as local identifier on the port, it doesn’t have to match on the other side.
encapsulation s-vid 10, this command specifies which vlan tagged traffic is to be taken and transported to the other side of this L2 tunnel.
xconnect peer 4.3.2.1 pw-id 1222 is telling the router to what remote LDP peer the L2 VLL should go to and a unique pw-id (PseudoWire ID) that has to match on both ends and is unique identifier of the tunnel.

NOTE:
s-vid is the id of the customer VLAN to be transported by the PW (VLAN 10 and VLAN20 in this case).
pw-id is the id of the pseudo-wire that is being defined. You can check the L2 VLL circuit status by looking at:

After configuring this L2 VLL in Martini mode, you can for example start a RIP process on two CE routers and you will see that the two CE routers become RIP neighbors with each other! This is strong L2 connectivity and you can also run broadcast and multicast protocols over this!

ADDON: Martini port-mode VLL to support customer dot1Q trunks

As you noticed, we used vlan for input of the particular customer via aggregation switch. However, you can also support a customer that wants full dot1Q trunk between two CE routers as visible on the picture below:

Martini VLL in port mode to support CE to CE trunk

Martini VLL in port mode to support CE to CE trunk

To change the previous example from the per-vlan for one customer, you only need to change the encapsulation mode as shown here:

PE1

PE2

Kompella VLLs

As we very well know from MPLS L3 VPNs, MP-BGP can carry MPLS labels, so Kampella VLLs implementation take this capability and use it to create L2 point-to-point Virtual Circuit between to PEs. This is mostly identical to the previous Martini VLLs, but much easier to scale in large networks than having remote LDP peers.

Kompella MPLS L2 VLL

Kompella MPLS L2 VLL

Basic characteristics:

  • MP-BGP is used for VC label distribution and implements dynamic distribution, withdrawal or error handling.
  • The outer tunnel can be shared by multiple VCs as the outer tunnel is basic LSP between PEs.

To configure Kompella VLL, we will recreate the scenario we used in Martini with aggregation switch for better understanding of the vlan use.

Kompella VLL example topology with aggregation switch

Kompella VLL example topology with aggregation switch

To configure the same topology using Kompella, first we create the the interface as trunk (this is different than on Martini that the port must be trunk as we will use vlan interfaces).

PE1

PE2

Now for both PE1 and PE2, enter into BGP configuration mode and activate “l2vpn-family” towards the other peer.

PE1

PE2

NOTE: On some platforms, enabling new address-family under BGP resets the BGP session, so take care!
VERIFICATION: You can check the status and Kompella being exchanged with display bgp l2vpn all

Now we continue by configuring the Kompella VLL tunnels themselves:

PE1

PE2

Syntax Explanation:
mpls l2vpn customer_a encapsulation vlan
this creates for you the Kompella definition for one customer that we called “customer_a” and “customer_b”. Encapsulation part can be configured as vlan or ethernet. vlan tells the router that to the VLLs, traffic will be putted based on vlan membership. If you configured encapsulation ethernet, then to the VLL tunnels only untagged traffic will be placed.
route-distinguisher is logical extension to the BGP-MP to differentiate between LSP tunnels of multiple customers inside BGP-MP.
vpn-target, based on this value you import and expert tunnel information on a particular PE router. If you export a tunnel information with “1:1”, it will be imported (or lets say visible) only on a PE where the target is also “1:1”.
ce ACE1 id 1 range 10, now this one is interesting. First “ACE1” is our name for the CE router of customer A and this is locally significant. “id 1” is numerical identification of the local CE1. This number goes to the MP-BGP and has to be matched on the other side in the “ce-offset 1” command. Range is telling a router to allocate up to 10 LDP label values for L2 tunnels to the ACE1. This range has to be at minimum one number higher than the id or ce-offset configured. To make the connection more visible, I created color coded values in the example above to guide the id to ce-offset relation.

 

Virtual Private LAN Service (VPLS)

Fundamentally different approach than the L2 Virtual Leased Line is with VPLS  (Virtual Private LAN Service). This solution cam with the idea of taking the MPLS L3 VPN principles and moving them to L2 and provide the customers one big and transparent switch. This is great because if you manage to do this, 90% of all the interaction and management between your network and customer simply drops down. The customer can run for example RIP between routers that are on different continents and all the sites will still be single hop away and the network will handle the rest. So this provides very big “value-added” service to the operator of VPLS networks. Packet transition is L2 end to end, and with using virtual switching instances on PE routers, everything can be transparent yet usable in leveraged environment.

Virtual Private LAN Service

Virtual Private LAN Service

Basic characteristics:

  • For CE, the VPLS cloud is like a switch
  • The PE encapsulates a VC label in the user PDU according to the user’s VPN and send it based on the MAC lookup to the proper PE on the other side of the MPLS cloud.
  • For loop prevention, basic deployment utilizes a full mesh of VPLS enabled MP-BGP/LDP sessions for transporting MAC to VC bindings and utilizes split-horizon for both the updates and forwarding.
  • Signalling can be of two types, LDP or MP-BGP.
  • LDP extension conforms to RFC 4762. LDP uses remote LDP session between PE routers.
  • MP-BGP signalling is extended by RFC 4761. With MP-BGP the protocol enables automatic topology discovery of where the virtual switching instances are found for a customer.
  • In LDP signaling mode, PE peers must be statically specified.

LDP signaling implementation

  • Martini VPLS
  • Two PEs establish a neighborhood via extended LDP over remote TCP connection. They exchange VPN control information via LDP including PW (Pseudo Wire) label allocation.
  • PW label is equivalent to L3 VPN label in MPLS VPNs.
  • A PE and a P still need to establish a common LDP session to exchange standard LSP labels.
  • On PE, Virtual Switch Instance (VSI) for each VPN and is assigned an ID in configuration.
  • For each VSI the PE builds a pair of unidirectional PWs to opposite PEs.

BGP signaling implementation

  • Kompella VPLS
  • Two PEs establish a neighborhood with each other via the extended BGP. They are added with a VPLS family and exchange VC signaling via the extended BGP.
  • A PE is configured with VSI for each VPN (customer).
  • Similarly to MPLS L3 VPNs, each VSI is configured with RD and Target.

Forwarding:

VSI is bound to an interface (preferably L3)  facing the CE router of the customer.When this interface gets an L2 packet, it consults the VLAN mac-address table the interface is assigned to. If the MAC address is local on some interface, it forwards it there. If the MAC address is unknown, it is sent to all normal interfaces/trunks for that VLAN, but also via all PWs assigned to the VSI on that interface in so called “broadcast” mode. On PWs, there is no spanning tree for loop protection and the overall protection is split-horizon on a full mesh of PW tunnels.

Configuration Example of Martini and Kompella VPLS

Let’s start with an overview of what we will configure here, we will create two customers together, again called Customer A and Customer B. After showing you what the topology look like and what is the target, I will show you configuration on how to achieve this in both Martini and Kompella VPLS.

Our network physical topology to do VPLS

Our network physical topology to do VPLS

The target is very simple and that is that all the customers will see the MPLS cloud only as a dedicated switch for their own purposes.

Customer view on the VPLS connectivity

Customer view on the VPLS connectivity

 

 

Martini VPLS configuration example

First we start with what we already know from the Martini VLL and that is the remote LDP session needs to be created between all the PE peers. On the following picture, you can see the extension of LDP remote peers on our MPLS network.

Martini VPLS LDP sessions

Martini VPLS LDP sessions

Let’s start with the configuration, to make this a bit shorter, I will be using only PE1 for most of examples.

PE1:

ADDON: If you would like to have a complete dedicated port for one CE and allow the customer to transport any dot1Q tagged vlans between his CEs, you can adjust the configuration as shown below:

PE2:

Kompella VPLS configuration example

Again lets start with topology map with the BGP-MP sessions shown.

Kompella BGP-MP based VPLS topology

Kompella BGP-MP based VPLS topology

To extend the previous example to Kompella BGP based VPLS, we need to add in BGP, where you have to activate vpls-family. Then we create a new VSI for Kompella. VSI is someting like a vrf/vpn-instance in MPLS L3 VPN architecture. So this is how it looks like in the configuration.

PE1:

Also generate a mirror configuration to the other PE in you topology and when the tunnel establish itself, you will have the ability to ping between your CE routers as if they were on directly connected subnets!.

VERIFICATION: Look at the three outputs below, you will notice that the BGP-MP sessions are transporting MAC addresses bounded to the PE1/2/3 based on vpn-targets. Also the last output of display mac-address vsi customer_a is absolutely great as you will see how the distributed mac-address table works.

Summary

In summary VPLS is a very strong technology as it is able to hide all the internal complexity behind the single idea that the customer only has one giant switch across the world! In this article, I have only scratched the surface and I would recommend reading and excellent resource for VPLS configuration on H3C 9500 series to see some information on advanced configurations like “Hub-and-Spoke” topology and H-VPLS where one provider can support other providers VPLS cloud.

Further reading:

MPLS/VPLS guide for H3C 5800 series PDF

VPLS configuration guide from H3C for 9500E

If you enjoyed this blog, please share.

About Peter Havrila

Author's Profile