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.

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.

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.

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.

mpls l2vpn

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:

system-view
 mpls ldp remote-peer PE2
 remote-ip 1.2.3.4
 return

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

 display mpls ldp remote-peer
 display mpls ldp peer

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

system-view
 int gig 2/0/26
  port link-mode bridge
  service-instance 1000
     encapsulation s-vid 10
     xconnect peer 1.2.3.4 pw-id 1121
   service-instance 1001
     encapsulation s-vid 20
     xconnect peer 1.2.3.4 pw-id 1222

PE2

system-view
 int gig 2/0/26
   port link-mode bridge   
   service-instance 1000
    encapsulation s-vid 10
    xconnect peer 4.3.2.1 pw-id 1121
   service-instance 1001
    encapsulation s-vid 20
    xconnect peer 4.3.2.1 pw-id 1222

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:

  display mpls l2vc

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:

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

PE1

system-view
 int gig 2/0/26
  port link-mode bridge
  service-instance 1000
     encapsulation port-based
     xconnect peer 1.2.3.4 access-mode ethernet pw-id 1121

PE2

system-view
 int gig 2/0/26
   port link-mode bridge   
   service-instance 1000
    encapsulation port-based
    xconnect peer 4.3.2.1 access-mode ethernet pw-id 1121

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.

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.

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

system-view
 int gig 2/0/26
  port link-mode bridge
  port link-type trunk
  port trunk permit vlan 100 200

PE2

system-view
 int gig 2/0/26
  port link-mode bridge   
  port link-mode bridge
  port link-type trunk
  port trunk permit vlan 100 200

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

PE1

bgp 100
  l2vpn-family
    peer 1.2.3.4 enable

PE2

bgp 100
  l2vpn-family
    peer 4.3.2.1 enable

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

mpls l2vpn customer_a encapsulation vlan
 route-distinguisher 100:100
 vpn-target 1:1
 ce ACE1 id 1 range 10
   connection ce-offset 2 interface vlan-interface 100
mpls l2vpn customer_b encapsulation vlan
 route-distinguisher 200:200
 vpn-target 2:2
 ce BCE1 id 11 range 23
   connection ce-offset 22 interface vlan-interface 200

PE2

mpls l2vpn customer_a encapsulation vlan
 route-distinguisher 100:100
 vpn-target 1:1
 ce ACE2 id 2 range 10
   connection ce-offset 1 interface vlan-interface 100
mpls l2vpn customer_b encapsulation vlan
 route-distinguisher 200:200
 vpn-target 2:2
 ce BCE2 id 22 range 23
   connection ce-offset 11 interface vlan-interface 200

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.

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.

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.

 

 

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.

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

PE1:

#Remote LDP session to PE2
mpls ldp remote-peer 1
 remote-ip 3.3.3.3
 quit
mpls ldp remote-peer 2
 remote-ip 2.2.2.2
 quit

#Interface to the MPLS Cloud
interface Ten-GigabitEthernet 1/0/25
  ip address 5.100.12.1 24
 mpls
 mpls ldp
 quit

#basic attributes of VPLS instance customer_a
vsi customer_a static
 pwsignal ldp
  vsi-id 501                
   peer 3.3.3.3
   peer 2.2.2.2
   quit
 quit
vsi customer_b static
 pwsignal ldp
  vsi-id 874                
   peer 3.3.3.3
   peer 2.2.2.2
   quit
 quit

# Interesting point is that the vlan 10 and vlan 20 interface has to exist, 
# otherwise it can happen this will not work correctly
vlan 10
  quit
vlan 20
  quit
interface vlan 10
  quit
interface vlan 20
  quit
# Then we bind the VSI (interface vlan 10 and vlan 20) to the vlan10 facing 
# Customer "A" and vlan 20 to the Customer "B".
interface gigabiteEthernet 1/0/1
 service-instance 1000      # The service-instance is local to the interface.
  encapsulation s-vid 10    # This means what tagged vlan is entering the VPLS cloud. 
                            # This is usually used when there is an aggregation 
                            # switch in front of PE. 
                            # If you want to allow a complete trunk between CE 
                            # and PE, you need to configure port-mode VPLS that will 
                            # be shown further below for PE2. 
  xconnect vsi customer_a
  quit
 service-instance 1001      
  encapsulation s-vid 20   
  xconnect vsi customer_b
  quit
 quit

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:

#Interface dedicated completely to one CE of one customer
interface gigabiteEthernet 1/0/1
 service-instance 1000      
  encapsulation port-based
  xconnect vsi customer_a access-mode ethernet
  quit
 quit

Kompella VPLS configuration example

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

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:

#First configure the BGP with activation of vpls-family
bgp 100
 peer 3.3.3.3 as-number 100
 peer 3.3.3.3 connect-interface loopback 0
 peer 2.2.2.2 as-number 100
 peer 2.2.2.2 connect-interface loopback 0
 vpls-family
  peer 3.3.3.3 enable
  peer 2.2.2.2 enable
  quit

#Configure VSI with signaling set to BGP and configure route-distinquisher 
#and route-targets
vsi customer_a auto
 pwsignal bgp
  route-distinguisher 100:1
  vpn-target 111:1
  site 501    #again this is a site identifier, 
              #and has to be unique for every CE router connected by our VPLS
  quit
 quit
vsi customer_b auto
 pwsignal bgp
  route-distinguisher 200:2
  vpn-target 222:2
  site 874    #again this is a site identifier, and has to be unique for 
              #every CE router connected by our VPLS
  quit
 quit

#Apply it to the interfaces the same way we applied it for the Martini VPLS
interface gigabiteEthernet 1/0/1
 service-instance 1000
  encapsulation s-vid 10
  xconnect vsi customer_a
  quit
 service-instance 1001      
  encapsulation s-vid 20   
  xconnect vsi customer_b
  quit
 quit

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.

[PE2-GigabitEthernet1/0/10]display vpls connection vsi customer_a

Total 2 connection(s),
connection(s): 2 up, 0 block, 0 down, 0 ldp, 2 bgp, 0 static

VSI Name: customer_a                            Signaling: bgp
SiteID    RD                    PeerAddr        InLabel OutLabel LinkID  VCState
3         100:1                 3.3.3.3         122883  122892   1       up
1         100:1                 1.1.1.1         122881  122999   2       up

[PE2-GigabitEthernet1/0/10]display vpls connection verbose vsi customer_a
VSI Name: customer_a                          Signaling: bgp
  **Remote Site ID     : 503
    VC State           : up
    RD                 : 100:1
    Encapsulation      : vlan
    MTU                : 1500
    Peer Ip Address    : 3.3.3.3
    PW Type            : label
    Local VC Label     : 122883
    Remote VC Label    : 122892
    Link ID            : 1
    Tunnel Policy      : --
    Tunnel ID          : 0xc0003
    Remote Label Block : 122890/10/0
    Export vpn target  : 111:1
  **Remote Site ID     : 501
    VC State           : up
    RD                 : 100:111
    Encapsulation      : vlan
    MTU                : 1500
    Peer Ip Address    : 1.1.1.1
    PW Type            : label
    Local VC Label     : 122881
    Remote VC Label    : 122999
    Link ID            : 2
    Tunnel Policy      : --
    Tunnel ID          : 0xc0000
    Remote Label Block : 122997/10/0
    Export vpn target  : 111:1

[PE2-GigabitEthernet1/0/10]display mac-address vsi customer_a
MAC ADDR       VSI INDEX STATE    PEER IP                          AGING TIME(s)
001c-0f09-2703 0         Learned  LinkId 1                         AGING
001c-0f09-2740 0         Learned  LinkId 1                         AGING
001c-0f09-2741 0         Learned  LinkId 1                         AGING
001c-0f09-2744 0         Learned  LinkId 1                         AGING
3ce5-a684-d567 0         Learned  Port-Based,GE1/0/10              AGING
3ce5-a684-d591 0         Learned  LinkId 2                         AGING

  ---  6 mac address(es) found  ---

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