Yes, whether it’s a gang of street-teens stood on the corner trying to sell you a gram of VRF, or whether it’s a bunch of uni graduates celebrating their birthdays by piling into the local BGP Shack and eating their weight in prefix lists, the youth of today cannot get enough of what the French call “un VPN du MPLS, sacré bleu”.

Okay, sure, fine. Yes. Okay. Absolutely. Yes. There’s no doubt that everything I’ve said so far is completely true. But: how do you configure MPLS VPNs? Well, it’s a good job you came to me – because in this article you’ll learn exactly how. We’ll configure it together, we’ll type some show commands to learn exactly what’s going on – and then we’ll look at how to troubleshoot it when it breaks.

OUR TOPOLOGY:

In our ISP network we have:

— Two core routers (which MPLS calls P routers, for Provider)
— Two access routers (PE routers, or Provider Edge) that our customer WAN circuits connect to
— Six routers at customer sites, at the other end of the WAN circuit.

Let’s find out about our three customers:

— Customer A is a standard internet customer. No MPLS VPN, just typical public connectivity.
— Customer B is an MPLS VPN customer.
— The third MPLS VPN customer is Susan Sarandon.

Now, I know what you’re thinking: why does Susan Sarandon have an MPLS VPN? Well, actually, that’s none of your business. Why do you need to know what Susan Sarandon gets up to? Just because you loved her in movies such as The Banger Sisters, and A Bad Moms Christmas, doesn’t mean she owes you an explanation. Susan Sarandon is entitled to her privacy. In fact, she wants an MPLS VPN specifically because of privacy it can offer. You should respect that. Shame on you. Shame on you for asking.

MPLS VPN EXAMPLE CONFIGURATIONS IN GNS3

If you want to put this into GNS3, you can either click here to download the topology (zip file), or click here to see the individual router configs:

Then, we’ll run OSPF to get full connectivity for public IPs within our service provider’s core network.

We’ll mainly be looking at the configs on Router 1 (a PE router), and Router 2 (a P router). We won’t show Routers 3 and 4 because they’re basically the same commands, but you can see the full config above if you’re #curious.

Once you’ve set it up, you can do a show ip ospf neighbor to check that everything’s “hunky dory”, and a show ip routeto see if Routers 1 and 4 have learned about each other’s interface IP addresses via OSPF.

STEP 2: TURN ON MPLS

As with most networking stuff, there’s a ton of theory to learn – but actually turning on MPLS involves just one command: mpls ip. We’ll talk about exactly what this does in a separate post. For now, just know that it enables the router to search on that interface for an MPLS neighbor – or more specifically, an LDP (Label Distribution Protocol) neighbor.

We run OSPF to get full connectivity within our Autonomous System. But of course, OSPF can’t handle the internet’s full routing table. That’s where we bring BGP in. We also use BGP to make the MPLS VPN magic happen.

Multi-Protocol BGP has a slightly different configuration to standard BGP: as well as defining your neighbors, you then make “Address Families” for each protocol you want to run.

Notice how you define the neighbor AS at the start, but you then “activate” the neighbor under each protocol you want to run. This allows you to do very specific things – for example, you could define your neighbor with an IPv4 address at the start, but then turn off IPv4 prefix advertisements, and turn on IPv6 advertisements.

On router 1, we turn on IPv4 public advertisements, then we turn on IPv4 MPLS VPNs:

Do a show ip bgp summaryto check that all the neighbor relationships came up.

STEP 4: MAKE THE VRFs

Customer A is using public IPs, so they don’t need a VRF – they’ll just use the default public routing table.

The other two customers are using private IPs in a VPN. So, we need to make a VRF for them on every PE router that they connect to.

In the config below, we first make the VRF by giving it a name. You can call it whatever you like. The VRF name never actually leaves the router, so you could even call your VRFs different things on different routers! As long as the route-targets match, it’s all good. Then, we make BGP address families for each VRF.

By the way, if you don’t know what route targets and route distinguishers are, click here to read my explanation. It’s well worth understanding it before we carry on, because a lot of people get confused by it!

Interestingly, we don’t have to configure the individual VRFs and address families on our core P routers. We configured our Multi-Protocol BGP for VPNv4, and that’s all they need. They’ll happily pass on the prefixes, using the magic of MPLS label switching.

Even though Customer B has an MPLS VPN, the configuration of the router at the site is a totally standard basic router config! IPs on the WAN interface, IPs on the LAN interface, and a default route out.

That means that we don’t need NAT. Yes, we’re using public IPs – but remember, this is a VPN. We don’t want to NAT the private IPs; we want full private connectivity across our huge network.

It also means that we don’t need to specify the VRF. This router isn’t running multiple routing tables, like the routers at the ISP end – Customer B just has the one network.

On Customer B’s router at site 1, try pinging 192.168.1.1 – the IP address at the other end of the WAN link – to check that connectivity works.

STEP 7: ADVERTISE THE CUSTOMER’S LAN THROUGHOUT THE MPLS VPN NETWORK

Now that we’ve configured both ends of the WAN connection, we can add in a static route to tell our PE router how to get to the customer’s LAN. In our BGP config we’re redistributing subnets, which means that the LAN will (slowly) get advertised throughout our service provider network.

The config is super easy: it’s just a standard static route, referencing the VRF, telling our Router 1 that all traffic destined to the LAN should be sent to Customer B’s router at the other end of the WAN link.

ROUTER 1:
ip route vrf CUSTOMER_B 10.1.1.0 255.255.255.0 192.168.1.2

STEP 8: TEST!

All the core network configuration we’ve seen so far is on Router 1. So, let’s head over to Router 4, and do a show ip route vrf CUSTOMER_B:

Success! We see both the LAN and WAN IPs at Site 1, in Router 4’s routing table.

Now, can the computer at Site 2 ping the computer at Site 1?

Darn tootin’ we can!

Thank you so much for reading this post! I hope you found it useful, and I hope you’ll download the GNS3 topology to configure it even further. If you found it useful, please make a Facebook/LinkedIn/Twitter post sharing it around. The more people that read my blog, the more motivation I have to keep on making more posts!

Your email address will not be published. Required fields are marked *

Comment

Name *

Email *

Website

Hi!

I’m Chris, a network engineer from London. This is a blog of random knowledge I’ve acquired while studying for some sweet sexy network engineering certifications. Technically vendor neutral, but as you’ll soon find out, I love Junos very much.

As I learn cool new stuff, I try to write it up with plenty of jokes, and a generous dollop of silliness, so that you’ll have as much fun learning about networking as I do.