If you’re cool, hip, and “with it”, you’ll know there’s one thing millennials just can’t stop talking about: MPLS VPNs.
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.
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:
Now, let’s go through the steps to configure it all.
STEP 1- CREATE OUR ISP NETWORK
First, we’ll put IP addresses on the interfaces connecting Routers 1 2 3 and 4. We’ll also add loopbacks on each router.
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.
ROUTER 1: interface Loopback0 ip address 126.96.36.199 255.255.255.255 ! interface GigabitEthernet2/0 ip address 188.8.131.52 255.255.255.252 negotiation auto ! router ospf 1 log-adjacency-changes redistribute connected subnets redistribute static subnets network 184.108.40.206 0.0.0.255 area 0 network 220.127.116.11 0.0.0.255 area 0 !
ROUTER 2: interface Loopback0 ip address 18.104.22.168 255.255.255.255 ! interface GigabitEthernet2/0 ip address 22.214.171.124 255.255.255.252 negotiation auto ! interface GigabitEthernet3/0 ip address 126.96.36.199 255.255.255.252 negotiation auto ! router ospf 1 log-adjacency-changes network 188.8.131.52 0.0.0.255 area 0 network 184.108.40.206 0.0.0.255 area 0
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 route to 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.
ROUTER 1: interface GigabitEthernet2/0 mpls ip
ROUTER 2: interface GigabitEthernet2/0 mpls ip ! interface GigabitEthernet3/0 mpls ip !
In the future I’ll write a separate post about how to check neighbors and labels, and how to troubleshoot problems. For now, just know that if it worked, you should get a console message like this:
*Nov 22 15:36:57.095: %LDP-5-NBRCHG: LDP Neighbor 220.127.116.11:0 (1) is UP
STEP 3.1: ADD MULTI-PROTOCOL BGP TO THE PE ROUTERS
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:
router bgp 64512 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 18.104.22.168 remote-as 64512 neighbor 22.214.171.124 update-source Loopback0 neighbor 126.96.36.199 remote-as 64512 neighbor 188.8.131.52 update-source Loopback0 ! address-family ipv4 redistribute connected redistribute static redistribute ospf 1 neighbor 184.108.40.206 activate neighbor 220.127.116.11 send-community extended neighbor 18.104.22.168 activate neighbor 22.214.171.124 send-community extended no auto-summary no synchronization exit-address-family ! address-family vpnv4 neighbor 126.96.36.199 activate neighbor 188.8.131.52 send-community extended neighbor 184.108.40.206 activate neighbor 220.127.116.11 send-community extended exit-address-family !
STEP 3.2: CONFIGURE OUR P ROUTERS AS BGP ROUTE REFLECTORS
In case you don’t know what a route reflector is, read this post I wrote (post to come):
We don’t really need to use them in a network this small, but hey: let’s live our lives to the absolute fullest, and make Routers 2 and 3 route reflectors. Let’s make our grandparents proud!!
The config on Router 2 is very similar to Router 1, apart from the fact that we put Routers 2 and 3 into a cluster, and then tell them that Routers 1 and 4 are clients.
ROUTER 2: router bgp 64512 no bgp default ipv4-unicast bgp cluster-id 100 bgp log-neighbor-changes neighbor 18.104.22.168 remote-as 64512 neighbor 22.214.171.124 update-source Loopback0 neighbor 126.96.36.199 remote-as 64512 neighbor 188.8.131.52 update-source Loopback0 neighbor 184.108.40.206 remote-as 64512 neighbor 220.127.116.11 update-source Loopback0 ! address-family ipv4 neighbor 18.104.22.168 activate neighbor 22.214.171.124 send-community extended neighbor 126.96.36.199 route-reflector-client neighbor 188.8.131.52 activate neighbor 184.108.40.206 send-community extended neighbor 220.127.116.11 activate neighbor 18.104.22.168 send-community extended neighbor 22.214.171.124 route-reflector-client no auto-summary no synchronization exit-address-family ! address-family vpnv4 neighbor 126.96.36.199 activate neighbor 188.8.131.52 send-community extended neighbor 184.108.40.206 route-reflector-client neighbor 220.127.116.11 activate neighbor 18.104.22.168 send-community extended neighbor 22.214.171.124 activate neighbor 126.96.36.199 send-community extended neighbor 188.8.131.52 route-reflector-client exit-address-family
Do a show ip bgp summary to 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.
ROUTER 1: ip vrf CUSTOMER_B rd 64512:200 route-target export 64512:200 route-target import 64512:200 ! ip vrf SUSAN_SARANDON rd 64512:300 route-target export 64512:300 route-target import 64512:300 ! router bgp 64512 address-family ipv4 vrf SUSAN_SARANDON redistribute connected redistribute static no synchronization exit-address-family ! address-family ipv4 vrf CUSTOMER_B redistribute connected redistribute static no synchronization exit-address-family !
STEP 5: ADD IN OUR CUSTOMER WAN LINKS
Adding a customer’s WAN circuit into their VPN is as simple as adding one line of command. See if you can spot it!
these three interfaces on Router 1:
interface FastEthernet5/0 description WAN link to Customer A ip address 184.108.40.206 255.255.255.252 duplex auto speed auto ! interface FastEthernet5/1 description WAN link to Customer B ip vrf forwarding CUSTOMER_B ip address 192.168.1.1 255.255.255.252 duplex auto speed auto ! interface FastEthernet6/0 description WAN Link to Susan Sarandon ip vrf forwarding SUSAN_SARANDON ip address 192.168.1.9 255.255.255.252 duplex auto speed auto
STEP 6: CONFIGURE THE ROUTERS AT OUR CUSTOMER SITES
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.
CUSTOMER B SITE 1: interface FastEthernet0/0 description Link to ISP ip address 192.168.1.2 255.255.255.252 duplex auto speed auto ! interface FastEthernet1/0 description LAN ip address 10.1.1.1 255.255.255.0 duplex auto speed auto ! ip route 0.0.0.0 0.0.0.0 192.168.1.1
COMPUTER ON THE LAN AT CUSTOMER B SITE 1: ip 10.1.1.2/24 10.1.1.1
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!