Before beginning this blog post, make sure to read How-To: MPLS configuration from a service provider perspective | Part 2

Introduction

Sometimes enterprises want or need layer-2 connectivity between sites. By-and-large, we don’t want to run large layer-2 networks in the provider space. High-capacity links are expensive and there’s no reason to leave them in blocking state. Seeing xe-0/0/1.0 or even et-0/0/1.0 status: blocked by STP is disappointing to say the least. Using our MPLS and OSPF based backbone, we can make use of ECMP and keep these links alive and in use while retaining them for failover purposes.

VPLS & BGP

Using our MPLS and BGP-enabled network, we can create intelligent layer-2 bridges across the layer-3 network using MPLS as our transport protocol. To do this, we’ll use a protocol called VPLS. VPLS, or Virtual Private LAN Service is a way to create multipoint-to-multipoint layer-2 bridges across service provider MPLS backbones. BGP comes in handy here as a way to distribute information about how to connect into the VPLS service to each PE device.

Topology

I’ve left our layer-3 VPN intact for reference purposes and decided to place another device on our Access{1,3}’s ether3 link. In this case, we’ll use ether3 as the customer-facing interface and keep ether2 alive as a L3VPN CE-PE peering point.

Screen Shot 2016-08-25 at 12.28.05 PM

Bridges

In Mikrotik’s RouterOS, it’s necessary to create bridges which our customers and VPLS tunnel endpoints connect together inside. Let’s start by creating a bridge on each of Access{1,2}

# Create Bridge Customer2
/interface bridge add name=Customer2
# Add ether3 to that bridge
/interface bridge port add bridge=Customer2 interface=ether3

Now let’s add the a BGP-VPLS interface to that bridge. We need to choose a unique Route-Distinguisher for this link, for which I’ve chosen 65530:2. Further, we need unique Site-IDs for each PE we terminate on.

On Access1:

# Create BGP-VPLS Interface attached to Customer2 bridge with 65530:2 on Site-ID 1
/interface vpls bgp-vpls add bridge=Customer2 bridge-horizon=1 route-distinguisher=65530:2 import-route-targets=65530:2 export-route-targets=65530:2 site-id=1

On Access2:

# Create BGP-VPLS Interface attached to Customer2 bridge with 65530:2 on Site-ID 1
/interface vpls bgp-vpls add bridge=Customer2 bridge-horizon=1 route-distinguisher=65530:2 import-route-targets=65530:2 export-route-targets=65530:2 site-id=2

Let’s verify these were created. On Access1 or Access2, run the following:

# Display VPLS tunnels
/interface vpls print

The output should be as follows if run from Access1:

Flags: X - disabled, R - running, D - dynamic, B - bgp-signaled, C - cisco-bgp-signaled
0 RDB name="vpls1" mtu=1500 l2mtu=1500 mac-address=02:F2:EC:FA:B1:BB arp=enabled disable-running-check=no remote-peer=10.101.0.8 cisco-style=no cisco-style-id=0 advertised-l2mtu=1500 pw-type=raw-ethernet use-control-word=yes vpls=bgp-vpls1

This line indicates we have a Running, Dynamic, BGP-Signalled VPLS tunnel to the peer 10.101.0.8 (Access3’s loopback). At this point, our tunnel should be running! Let’s create some layer-2 based links on our Customer routers e.g. Cust2Site{1,2}

On Cust2Site1:

# Create IP Address on provider-facing interface
/ip address add interface=ether1 address=192.168.1.1/24

On Cust2Site2:

# Create IP Address on provider-facing interface
/ip address add interface=ether1 address=192.168.1.2/24

Now we should be able to talk with the other end of the connection just like there was a wire between them.

On Cust2Site1:

# Ping Cust2Site2
/ping 192.168.1.2 count=5

You should see responses as follows:

SEQ HOST SIZE TTL TIME STATUS
0 192.168.1.2 56 64 2ms
1 192.168.1.2 56 64 2ms
2 192.168.1.2 56 64 2ms
3 192.168.1.2 56 64 2ms
4 192.168.1.2 56 64 2ms
sent=5 received=5 packet-loss=0% min-rtt=2ms avg-rtt=2ms max-rtt=2ms

And just for fun, let’s verify this is true layer-2 communication by creating a PPPoE server on Cust2Site1 and scanning for it on Cust2Site2:

On Cust2Site1:

# Create PPPoE Server
/interface pppoe-server server add disabled=no interface=ether1 service-name=Cust2PPPoETest

On Cust2Site2:

# Scan for a PPPoE Server on the provider-facing interface
/interface pppoe-client scan interface=ether1 duration=10s

A successful connection will show output as follows:

SERVICE MAC-ADDRESS AC-NAME
Cust2PPPoETest 00:00:AB:F1:98:00 Cust2Site1

We now have a running layer-2 VPLS-based VPN signalled over BGP between the two endpoints. Adding another site for Cust2 is as simple as running the commands that were run on Access{1,2} with a different site-id.