Interop IP infusion and MikroTik: part 2 – VPLS

VPLS is a pretty common technology in ISPs to either sell layer 2 services or backhaul traffic to a centralized aggregation point to conserve IPv4 space; check out more on that here.

How can I take advantage of segment routing but still deliver the same services? We already looked at how to setup the label switched paths utilizing IP Infusion as a segment routing mapping server in this interop post. Now let’s see how we can deliver a VPLS service over this with mikrotik as a provider edge router.

Delivering a service with a L2VPN

After setting up the IGP and label distribution between the PEs we will start building the L2VPN.

Why a BGP signaled VPLS session instead of LDP signaled VPLS?

In the segment-routing domain there is no LDP running. However, some vendors support static pseudowires or other methods to bring up a targeted LDP session for VPLS. I did some basic testing here couldn’t easily identify the right combination of knobs to make this work. Don’t worry; I’ll come back to it.

BGP signaled VPLS is a standards based technology that both vendors support.

First thing we need to do after having loopback reachability is to build the BGP sessions.

router bgp 65000
 neighbor remote-as 65000
 neighbor update-source lo
 address-family l2vpn vpls
 neighbor activate

/routing bgp peer
add address-families=l2vpn name=OCNOS1 nexthop-choice=force-self \
    remote-address= remote-as=65000 update-source=Lo0

After establishing the BGP peering we need to build the vpls instance.

mpls vpls TEST 10
 signaling bgp
  ve-id 10

/interface vpls bgp-vpls
add bridge=VPLS-TEST export-route-targets=65000:10 import-route-targets=\
    65000:10 name=TEST route-distinguisher= site-id=2 \

On OcNOS the route-target and route distinguisher is automatically derived from the vpls instance creation. While you explicitly set it on MikroTik. show mpls vpls TEST
Virtual Private LAN Service Instance: TEST, ID: 10
 SIG-Protocol: BGP
  Route-Distinguisher :65000:10
  Route-Target :65000:10
  VE-ID :10

The site-id (Tik) or VE-ID (OcNOS) are the vpls endpoint identifiers which uniquely identify each PE.

The final step before we can start to test is to setup the attachment circuit. On OcNOS we will have to setup a service template to pair with the vpls instance on attachment circuit. Then you can assign the vpls instance and the service template to a switchport. We will match vlan tag 10 on our service template. Anything coming in with dot1q 10 from the CCR2004 will enter the VPLS tunnel.

service-template TEST
 match outer-vlan 10
interface xe2
 mpls-vpls TEST service-template TEST

On the MikroTik side we need to setup a bridge for the autocreation of the tunnels and assign appropriate interfaces to it. Again, we will match on dot1q 10.


/interface bridge
add name=Lo0
add name=LoVOICE
add mtu=1500 name=VPLS-TEST protocol-mode=none

/interface bridge port
add bridge=VPLS-TEST interface=ether10 pvid=10

/interface bridge vlan
add bridge=VPLS-TEST tagged=VPLS-TEST untagged=vlan10,ether10 vlan-ids=10

Finally, we can do testing and verification. We want to look for the mesh peer which is the autodiscovered PE also in this vpls instance. mpls vpls TEST
Virtual Private LAN Service Instance: TEST, ID: 10
 SIG-Protocol: BGP
  Route-Distinguisher :65000:10
  Route-Target :65000:10
  VE-ID :10
 Attachment-Circuit :UP
 Learning: Enabled
 Control-Word: Disabled
 Group ID: 0, Configured MTU: 1500
 Description: none
 service-tpid: dot1.q
 Operating mode: Raw
 Configured interfaces:
  Interface: xe2
 Service-template : TEST
  Match criteria : 10

 Mesh Peers: (Up)

Then we want to make sure we are learning mac-addresses. As you can see the MACs not learned from the attached device are learned from the BGP peer at mpls vpls mac-address
VPLS-ID     MAC address       Learned from   Vlan-Id          Peer address   Tim
10          027b.6866.7831    xe48           -          300

10          488f.5a00.4f87    xe2            10               -              300

10          4c5e.0c6f.4476    xe48           -          300

Next we can test reachability. I did have a strange issue where if the AC went down on the MikroTik-1 the mesh wouldn’t form on reattachment. This was resolvable with the following command on IPI-1: clear bgp l2vpn vpls

This image has an empty alt attribute; its file name is IPA-Blog-ad-template-network.jpg

I’ll be doing more testing on interop here. Let us know in the comments what you’d like to see next.

Let’s talk MPLS-VPLS, part 1 – use cases

Hey guys, today we’ll be taking a look at what are the main reasons that MPLS – and in particular VPLS – is a useful technology tool to get traffic from point A to point Z. There’s really 2 major use cases that I deal with regularly: IPv4 conservation and L2VPN.

Why am I talking about VPLS specifically? Well, mostly because many times I end up working with Mikrotik routers, which only support VPLS. What is VPLS? It stands for Virtual Private Line Service, and it’s a way to deliver layer 2 services over a layer 3 network. Said another way, it connects a single broadcast domain to multiple endpoints across a routed network. I’ll discuss why MPLS is better for you and your network than switching/bridging in part 2 of this series – for now just know that MPLS/VPLS will allow you to offer enhanced services without the risks of extending layer 2 (I’ll talk more about that below, and why that’s bad in part 2, also).

Use case 1: IPv4 Conservation

OK, so let’s visualize the problem with IP conservation on a small /24 allocation.

Subnetted /24 network

If you’re like most other service providers, you have a limited capacity of IPv4 and constantly using subnetting to carve out IP space for various locations. Inevitably, you end up needing a bigger network somewhere (like A) and in other places you’ve allocated too many IPs and they’re going wasted and unused (like B). Not to mention, with subnetting we’re forced to burn a network ID and broadcast each time we pull out the network scalpel – ouch!

As you can see, in this network, subnetting has resulted in 16 IPs used for IDs and subnets, 8 more for gateways, and over in area B let’s say there’s 37 unassigned IPs – that’s 60 IPs out of 254 that customers can’t use, almost 25% of this expensive revenue generating resource is tied up!

Here’s a solution based on MPLS/VPLS that efficiently leverages the entire /24 allocation:

/24 used efficiently with VPLS

Now we’re only using 1 network ID, 1 broadcast, and 1 gateway for our /24. The entire rest of the allocation can be delivered to any endpoint that’s connected the MPLS cloud – leaving 253 addresses available for customer assignments! And growth can happen at any tower – we no longer have to care which customers are on which tower, and how much IP space is available at the tower layer.

Compared to the above scenario, our IP allocation overhead went down from 25% to just over 1%! Now that’s efficient use of IPv4 space.

Use case 2: L2VPN

Connecting multiple offices across a service provider network can often be a very lucrative way to offer transparent LAN service to customers. The reason we call it transparent is because it allows whatever customer traffic is input in one end of the network to be seen at another end of the network. In a typical routed network, BUM traffic (which I’ll cover more in part 2) gets isolated at layer 3, routed boundaries. With VPLS, your network gets the full benefits of the layer 3 boundaries, and your customer gets the connectivity benefits of being connected layer 2!

Some of the more common customers looking for a L2VPN service include government, energy and banks. But really, any customer who’d like to connect the same subnet at several different physical locations that are served by different equipment across your network are a great candidates. Sometimes they’d like to pass their own VLAN traffic, other times they need multicast for a video conferencing application, or even something as simple as a small network with only 1 DHCP server / firewall / internet gateway and they want to force all traffic through that central point. Regardless of the reason, this premium service can bring in great revenue.

Can’t I just provide L2 service by extending a VLAN? Absolutely, you can. Should I just extend my bridged/switched network to provide this service? NO! You should absolutely avoid this as much as possible! As we’ll see in part 2, isolating fault domains and adding L3 boundaries are key to protecting your network from bad days.

Let’s see an example:

Don’t bridge to customers

Here, we’ve extended the network using bridging and switching (L2) constructs to connect customer locations A B and C. When we have a bad day on this network, the scope of our network meltdown includes the entirety of ALL the gear and ALL our customers. Ouch!

Whether it’s a customer introduced loop, infected customer device, or a customer host spewing garbage onto to their network, there’s no protection between the customer edge (CE) and provider edge (PE) and no boundaries to stop that bad traffic.

Fortunately, there’s a better way:

Friends don’t let friends bridge networks

With MPLS/VPLS, you can see that the scope of our outage is isolated to the customer edge (the port handoff to A, B, and C), or at worst only the VPLS router endpoints, depending on the gear, QoS policies, and configuration. Now, a bad day on the customer’s network isn’t necessarily a bad day for our service provider network.

I hope you enjoyed this article and keep an eye out for part 2 where I’ll talk more in depth about L2 (bridging/switching) vs L3 (routing) and why MPLS/VPLS is referred to as layer 2.5.