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)
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.
- 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.
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 188.8.131.52 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.
system-view int gig 2/0/26 port link-mode bridge service-instance 1000 encapsulation s-vid 10 xconnect peer 184.108.40.206 pw-id 1121 service-instance 1001 encapsulation s-vid 20 xconnect peer 220.127.116.11 pw-id 1222
system-view int gig 2/0/26 port link-mode bridge service-instance 1000 encapsulation s-vid 10 xconnect peer 18.104.22.168 pw-id 1121 service-instance 1001 encapsulation s-vid 20 xconnect peer 22.214.171.124 pw-id 1222
– 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 126.96.36.199 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.
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:
system-view int gig 2/0/26 port link-mode bridge service-instance 1000 encapsulation port-based xconnect peer 188.8.131.52 access-mode ethernet pw-id 1121
system-view int gig 2/0/26 port link-mode bridge service-instance 1000 encapsulation port-based xconnect peer 184.108.40.206 access-mode ethernet pw-id 1121
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.
- 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).
system-view int gig 2/0/26 port link-mode bridge port link-type trunk port trunk permit vlan 100 200
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.
bgp 100 l2vpn-family peer 220.127.116.11 enable
bgp 100 l2vpn-family peer 18.104.22.168 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:
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
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
– 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.
- 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.
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.
#Remote LDP session to PE2 mpls ldp remote-peer 1 remote-ip 22.214.171.124 quit mpls ldp remote-peer 2 remote-ip 126.96.36.199 quit
#Interface to the MPLS Cloud interface Ten-GigabitEthernet 1/0/25 ip address 188.8.131.52 24 mpls mpls ldp quit #basic attributes of VPLS instance customer_a vsi customer_a static pwsignal ldp vsi-id 501 peer 184.108.40.206 peer 220.127.116.11 quit quit vsi customer_b static pwsignal ldp vsi-id 874 peer 18.104.22.168 peer 22.214.171.124 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:
#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.
#First configure the BGP with activation of vpls-family bgp 100 peer 126.96.36.199 as-number 100 peer 188.8.131.52 connect-interface loopback 0 peer 184.108.40.206 as-number 100 peer 220.127.116.11 connect-interface loopback 0 vpls-family peer 18.104.22.168 enable peer 22.214.171.124 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 126.96.36.199 122883 122892 1 up 1 100:1 188.8.131.52 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 : 184.108.40.206 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 : 220.127.116.11 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 ---
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.