In this lab I’m going to go over the config for an MPLS VPN.

MPLS VPN

The network has been configured with OSPF 100 for the client, and OSPF 200 for the ISP backbone and basic reachability has been confirmed within each of those OSPF domains.

The most logical next step would be to create the VRF’s for each site.

Side Note: Where it says 67.67.67.0:24, I actually meant to use 36.36.36.0:24 to keep everything consistent. However the configuration still works because this is just an arbitrary value used to import and export routes. It’s simply just a kind of “note” to identify that traffic is from a particular location. So just pretend its 36.36.36.0:24 to help your mind work out what’s going on more easily.

R4(config)#ip vrf Google_London_Branch
rd 64512:1
route-target export 14.14.14.0:24
route-target import 25.25.25.0:24
route-target import 67.67.67.0:24

R5(config)#ip vrf Google_Manchester_Branch
rd 64512:1
route-target export 25.25.25.0:24
route-target import 14.14.14.0:24
route-target import 67.67.67.0:24

R6(config)#ip vrf Google_Leeds_Branch
rd 64512:1
route-target export 67.67.67.0:24
route-target import 25.25.25.0:24
route-target import 14.14.14.0:24
The VRF names are always locally significant. So you can see that I’ve put different vrf names, however the route distinguisher has stayed the same. There’s no right or wrong way to name your vrf’s, it’s just a preference thing that can be used to help you identify which site belongs to which customer. So if you had ten Google sites in London, you might change the naming convention to Google_London_OxfordStreet and another vrf to Google_London_RegentStreet etc.

It’s worth noting here that the way I’ve decided to configure the route distinguisher is by using the same value for the whole of Google’s network. The only purpose of the route distinguisher is simply to ensure that subnets are globally unique (so the route distinguisher is therefore globally significant). Let’s say Google are using the 14.14.14.0/24 network (as shown in my diagram), then say we have a new client – Microsoft who also need to use the 14.14.14.0/24 network within their routing domain, then providing we configure Microsoft to use a different route distinguisher (say 64512:2) this is going to keep the subnets globally unique within the vpnv4 routing table. Google’s routes will appear as 64512:1:14.14.14.0/24, and Microsoft’s will appear as 64512:2:14.14.14.0/24. So there is not any real need to use different route-distinguishers within the same customer network, as there tends to be no need for duplicate subnets within the same customer network (this would be a very bespoke design if it did). Another added benefit of using the same route distinguisher on a per customer basis is that you will be able to easily pick out all the routes that belong to that particular customer in the vpnv4 table. Say you had 1000 customers, and you wanted to see what routes belong to Google. Then if you did a #show ip bgp vpnv4 rd 64512:1, and this would would show you all routes you are learning for the Google network on that router. So basically it really makes managing customer routes a lot easier in a wide scale deployment of an MPLS network.

For the route-target, I’ve just used the subnet that is connected between the provider edge router and the customer edge router as the route-target export value. The export value can then be imported at another site & that way the new site will learn these prefixes. It gives granular control to the MPLS provider in that if Google only wanted London to communicate with Leeds for example, we would just remove the line of configuration that says #route-target import 25.25.25.0:24 from both the London and Leeds vrf’s. This means the Manchester prefixes would no longer get into the routing table at both London and Leeds.

When you configure these vrf’s you need to then apply them to the interfaces on the PE router interfaces that connect to the customer. When you do this, it wipes the ip address configuration off the interface, so you actually need to reconfigure the ip address on the interface again (as you will see the error msg below). Let’s do that now.

R4(config-if)#ip vrf forwarding Google_London_Branch
% Interface FastEthernet0/1 IP address 47.47.47.4 removed due to enabling VRF Google_London_Branch
R4(config-if)#ip address 47.47.47.4 255.255.255.0

R5(config)#int fa0/0
R5(config-if)#ip vrf forwarding Google_Manchester_Branch
R5(config-if)#ip address 25.25.25.5 255.255.255.0

R6(config-vrf)#int fa0/0
R6(config-if)#ip vrf forwarding Google_Leeds_Branch
R6(config-if)#ip address 36.36.36.6 255.255.255.0
Next is the OSPF instances on the PE routers. So we need to now put an ospf instance that runs in a specific vrf for each site. Let’s configure that now.

R4(config)#router ospf 50 vrf Google_London_Branch
R4(config-router)# network 47.47.47.4 0.0.0.0 area 0

R5(config)#router ospf 50 vrf Google_Manchester_Branch
R5(config-router)#network 25.25.25.2 0.0.0.0 area 0

R6(config)#router ospf 50 vrf Google_Leeds_Branch
R6(config-router)#network 36.36.36.6 0.0.0.0 area 0
At this point, it’s worth sending pings to verify ospf connectivity between the PE and CE routers, just do a ping to the loopbacks on the CE routers. Next is the MPLS config. It is really very straight forward, as shown below.

R4(config)#mpls label range 400 4000
R4(config)#int fa0/1
R4(config-if)#mpls ip

R5(config)#mpls label range 500 5000
R5(config)#int fa0/1
R5(config-if)#mpls ip

R6(config)#mpls label range 600 6000
R6(config)#int fa0/1
R6(config-if)#mpls ip

R7(config)#mpls label range 700 7000
R7(config)#int range fa0/0 – 1,fa1/0
R7(config-if-range)#mpls ip
I’ve configured a label range so that it’s clear what label came from what router when we look at the mpls forwarding table later on (I’ll go through the mpls in more detail in a video embedded in this post). It was a tip I picked up from Keith Barker when I met him at Cisco live & just helped tremendously when trying to explain how mpls works. The final configuration is to configure the BGP side of things as well as the redistribution.

R4(config)#router bgp 1
R4(config-router)# no synchronization
R4(config-router)# neighbor 5.5.5.5 remote-as 1
R4(config-router)# neighbor 5.5.5.5 update-source Loopback0
R4(config-router)# neighbor 6.6.6.6 remote-as 1
R4(config-router)# neighbor 6.6.6.6 update-source Loopback0
R4(config-router)# no auto-summary
R4(config-router)# !
R4(config-router)# address-family vpnv4
R4(config-router-af)# neighbor 5.5.5.5 activate
R4(config-router-af)# neighbor 5.5.5.5 send-community extended
R4(config-router-af)# neighbor 6.6.6.6 activate
R4(config-router-af)# neighbor 6.6.6.6 send-community extended
R4(config-router-af)# exit-address-family
R4(config-router)# !
R4(config-router)# address-family ipv4 vrf Google_London_Branch
R4(config-router-af)# redistribute ospf 50 vrf Google_London_Branch
R4(config-router-af)# no synchronization
R4(config-router-af)# exit-address-family
R4(config-router)#
R4(config-router)#router ospf 50 vrf Google_London_Branch
R4(config-router)#redistribute bgp 1 subnets

R5(config)#router bgp 1
R5(config-router)# no synchronization
R5(config-router)# neighbor 4.4.4.4 remote-as 1
R5(config-router)# neighbor 4.4.4.4 update-source Loopback0
R5(config-router)# neighbor 6.6.6.6 remote-as 1
R5(config-router)# neighbor 6.6.6.6 update-source Loopback0
R5(config-router)# no auto-summary
R5(config-router)# !
R5(config-router)# address-family vpnv4
R5(config-router-af)# neighbor 4.4.4.4 activate
R5(config-router-af)# neighbor 4.4.4.4 send-community extended
R5(config-router-af)# neighbor 6.6.6.6 activate
R5(config-router-af)# neighbor 6.6.6.6 send-community extended
R5(config-router-af)# exit-address-family
R5(config-router)# !
R5(config-router)# address-family ipv4 vrf Google_Manchester_Branch
R5(config-router-af)# redistribute ospf 50 vrf Google_Manchester_Branch
R5(config-router-af)# no synchronization
R5(config-router-af)# exit-address-family
R5(config-router)#
R5(config-router)#router ospf 50 vrf Google_Manchester_Branch
R5(config-router)# redistribute bgp 1 subnets

R6(config)#router bgp 1
R6(config-router)# no synchronization
R6(config-router)# neighbor 4.4.4.4 remote-as 1
R6(config-router)# neighbor 4.4.4.4 update-source Loopback0
R6(config-router)# neighbor 5.5.5.5 remote-as 1
R6(config-router)# neighbor 5.5.5.5 update-source Loopback0
R6(config-router)# no auto-summary
R6(config-router)# !
R6(config-router)# address-family vpnv4
R6(config-router-af)# neighbor 4.4.4.4 activate
R6(config-router-af)# neighbor 4.4.4.4 send-community extended
R6(config-router-af)# neighbor 5.5.5.5 activate
R6(config-router-af)# neighbor 5.5.5.5 send-community extended
R6(config-router-af)# exit-address-family
R6(config-router)# !
R6(config-router)# address-family ipv4 vrf Google_Leeds_Branch
R6(config-router-af)# redistribute ospf 50 vrf Google_Leeds_Branch
R6(config-router-af)# no synchronization
R6(config-router-af)# exit-address-family
R6(config-router)#
R6(config-router)#router ospf 50 vrf Google_Leeds_Branch
R6(config-router)# redistribute bgp 1 subnets
So here I’ve configured the iBGP in the provider core network between PE routers. I will point out that it is absolutely necessary to use loopbacks as the update source in order for mpls to work. Otherwise it kind of breaks the way mpls works as I’ll explain in the video i intend to embed on this page. Another key point is that you must send the extended community in the vpnv4 address family to other PE routers, as this is where the route-target’s get pulled from. At the end of the config then, is just the redistribution. You need your routes to get into BGP so you can create the MLPS VPN & populate the vpnv4 table. To verify you can do a quick check on the vpnv4 routing table and send some pings between loopbacks on the CE routers.

R4#show ip bgp vpnv4 all | b Route
Route Distinguisher: 64512:1 (default for vrf Google_London_Branch)
*> 1.1.1.1/32 14.14.14.1 2 32768 ?
*>i2.2.2.2/32 5.5.5.5 2 100 0 ?
*>i3.3.3.3/32 6.6.6.6 2 100 0 ?
*> 14.14.14.0/24 0.0.0.0 0 32768 ?
*>i25.25.25.0/24 5.5.5.5 0 100 0 ?
*>i36.36.36.0/24 6.6.6.6 0 100 0 ?

R1#ping 3.3.3.3 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/66/96 ms
R1#ping 2.2.2.2 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/69/92 ms