Frank Petrilli

Software Developer & Network Engineer

Category: Networking

How-To: MPLS configuration from a service provider perspective | Part 3

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.

How-To: MPLS configuration from a service provider perspective | Part 2

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

Introduction

So after part 1 we have a running MPLS network. Congratulations! It may not seem any different from the OSPF-enabled routed networks you may have experience with before with what we’ve done so far, but now that we have MPLS running, we can make use of its content-agnostic design to transport some more interesting traffic via our topology.

Continue reading

How-To: MPLS configuration from a service provider perspective | Part 1

I often get questions on MPLS use cases and network designs; when we have such accelerated forwarding in modern-day network equipment with massive, rapid TCAM or general-purpose memory in the case of modern virtualized networks, why do we want label-based forwarding?

The Case for MPLS

While forwarding on labels is at its core a more simplistic way to forward data and should be faster, the fact remains that modern hardware sees no or minimal performance increase from moving to an MPLS network. We then must have a better reason for MPLS forwarding.

Though MPLS is a somewhat “old” in its basis (RFC3031, 2001), the modern use case for a transport protocol with no opinion on what is inside has its strengths. For example, in 2016, MPLS-designed networks allow transport of IPv6 over legacy IPv4-enabled cores without any configuration change outside of edge devices. Further, modern protocols make use of MPLS to get their job done, such as MPLS-TE, which allows for reservation of path’s resources (a blog post to come later about that), L3VPNs which allow customers to have simple connectivity between sites, and VPLS which allows for layer 2 connectivity to traverse a purely layer-3 provider backbone.

The Topology

With a little introduction done, let’s begin on making a basic MPLS network in GNS3; I’ll begin with Mikrotik RouterOS as my platform today, and release my versions with Cisco and Juniper configurations soon.

We’ll start with a simplified provider backbone model:

Screen Shot 2016-08-24 at 1.06.32 PM
Continue reading

© 2019 Frank Petrilli

Theme by Anders NorenUp ↑