MPLS Labs – VRFs and MP-BGP

So at this point, you might be thinking to yourself, “this is cool and all, but why do I need it”.  Great question!  MPLS was initially designed to be faster than normal IP switching.  The idea was that a label lookup was faster than an IP lookup.  These days, that’s no longer the case.  We have 10 gig line rate interfaces that can do a lot of their functions in hardware.  So what else can MPLS do?  In my opinion, the biggest plus you get from MPLS is running it in conjunction with MP-BGP and VRFs.  Rather than spend a lot of time explaining this, let’s just jump into the config so you can see how cool this is.  Another look at our diagram…

Shows that we are looking at service provider network with two customers sharing the same provider infrastructure.  That being said, let’s put the finishing touches on the PE routers to allow them to participate in MP-BGP.

PE1 router bgp 65000 
no bgp default ipv4-unicast 
neighbor 7.7.7.7 remote-as 65000 
neighbor 7.7.7.7 update-source l0 
neighbor 3.3.3.3 remote-as 65000 
neighbor 3.3.3.3 update-source l0 
address-family vpnv4 
neighbor 7.7.7.7 activate 
neighbor 3.3.3.3 activate

PE2 router bgp 65000 
no bgp default ipv4-unicast 
neighbor 1.1.1.1 remote-as 65000 
neighbor 1.1.1.1 update-source l0 
neighbor 7.7.7.7 remote-as 65000 
neighbor 7.7.7.7 update-source l0 
address-family vpnv4 
neighbor 1.1.1.1 activate 
neighbor 7.7.7.7 activate

PE3 router bgp 65000 
no bgp default ipv4-unicast 
neighbor 1.1.1.1 remote-as 65000 
neighbor 1.1.1.1 update-source l0 
neighbor 3.3.3.3 remote-as 65000 
neighbor 3.3.3.3 update-source l0 
address-family vpnv4 
neighbor 1.1.1.1 activate 
neighbor 3.3.3.3 activate

So this should look pretty familiar to anyone that’s worked with BGP minus a few of the commands.  Let’s break those down…

no bgp default ipv4-unicast – Tells the router that for this BGP instance, we aren’t interested in normal IPv4 unicast routing.  This being said, take a look at a ‘show ip bgp summary’.  Nothing comes up however a look at ‘show ip protocol’ shows BGP running.  It is running, we just aren’t looking at the right place now.

address-family vpnv4 – This command configures the BGP routing process for MP-BGP and the associate neighbor ‘activate’ commands activate each neighbor for VPNV4 routing.

So now you might be wondering, what is VPNV4.  Before that comes up, we need to discuss a couple of other terms.  VRFs,or Virtual Routing and Forwarding, allow you to make completely separate routing information based on a physical router.  These are commonly used by service providers to keep different customer router segregated within their infrastructure.  Along with VRFs come RDs, or route designators.  Route designators get assigned to a VRF; so for now just think of a route designator as a way to identify a particular VRF.  Also keep in mind that both of these items are locally significant to a router.  The last item is a route target, or RT, and is considered to BGP to be an extended community string.  The RT looks very similar to an RD but is what actually gets attached (exported) with the route when they are shared between MP-BP peers.  So a VPNV4 route is a customers IPv4 router, with a RD attached to it.  By adding the RD to the front of the route advertisement, we can make multiple advertisements for the same IPv4 network unique across common infrastructure.  VRFs, RDs, and RTs are all ways to keep customer routes separate on shared infrastructure.  Hopefully the rest of this config will clear things up for you.  

PE1 ip vrf customer1 
rd 65100:100 
route-target export 65100:100 
route-target import 65100:100

router bgp 65000 
address-family ipv4 vrf customer1 
neighbor 192.168.10.2 remote-as 65100 
neighbor 192.168.10.2 activate 
neighbor 192.168.10.2 as-override

int faste0/1 
description Interface to CE1 – Customer1 
ip vrf forwarding customer1 
ip address 192.168.10.1 255.255.255.0 
no shut

PE2 ip vrf customer2 
rd 65200:200 
route-target export 65200:200 
route-target import 65200:200

router bgp 65000 
address-family ipv4 vrf customer2 
neighbor 192.168.20.2 remote-as 65200 
neighbor 192.168.20.2 activate 
neighbor 192.168.20.2 as-override

int faste0/1 
description Interface to CE2 – Customer2 
ip vrf forwarding customer2 
ip address 192.168.20.1 255.255.255.0 
no shut

PE3 ip vrf customer1 
rd 65100:100 
route-target export 65100:100 
route-target import 65100:100

ip vrf customer2 
rd 65200:200 
route-target export 65200:200 
route-target import 65200:200

router bgp 65000 
address-family ipv4 vrf customer1 
neighbor 192.168.30.2 remote-as 65100 
neighbor 192.168.30.2 activate 
neighbor 192.168.30.2 as-override 
address-family ipv4 vrf customer2 
neighbor 192.168.40.2 remote-as 65200 
neighbor 192.168.40.2 activate 
neighbor 192.168.40.2 as-override

interface FastEthernet0/1.11 
description Interface to CE3 – Customer1 
encapsulation dot1Q 12 
ip vrf forwarding customer1 
ip address 192.168.30.1 255.255.255.0

interface FastEthernet0/1.12 
description Interface to CE4 – Customer2 
encapsulation dot1Q 13 
ip vrf forwarding customer2 
ip address 192.168.40.1 255.255.255.0

So let’s take a quick look at what we just did…

ip vrf customer1 – Creates a VRF called customer1 
rd 65100:100 – Assings RD 65100:100 to that VRF 
route-target export 65100:100 – Tells the router to export routes from this VRF with a RT of 65100:100 
route-target import 65100:100 - Tells the router to import any VPNV4 routes that have a RT of 65100:100 into this VRF

router bgp 65000 
address-family ipv4 vrf customer1 – Create a routing instance for this VRF within BGP 
neighbor 192.168.10.2 remote-as 65100 – Configure the peering to the customer (CE) router 
neighbor 192.168.10.2 activate – Activate that router for VPNV4 
neighbor 192.168.10.2 as-override – The customer is going to use the same AS number at all locations.  I need to tell the BGP process to allow the same AS in multiple locations.  Recall that if the BGP router sees it’s own AS in the AS-PATH of an incoming route, it will drop the route update as part of loop prevention.

int faste0/1 
description Interface to CE1 – Customer1 
ip vrf forwarding customer1 – In this case we are assigning a physical interface to the customer1 VRF.  NOTE – When you assign a interface to a VRF, it clears the interface IP so you’ll need to reassign it.  
ip address 192.168.10.1 255.255.255.0 – Configure the IP address that the customer will be peering with 
no shut

The only thing left to do at this point is configure the customer CE routers.  That config is pretty easy so let’s rip through that so we can dig into looking at how things are working.

CE1 
hostname ce1 
ip routing 
ip cef

no ip domain-lookup 
line vty 0 15 
password cisco 
login

int faste0/0 
ip address 192.168.10.2 255.255.255.0 
no shut

int faste0/1 
ip address 10.10.10.1 255.255.255.0 
no shut

router bgp 65100 
neighbor 192.168.10.1 remote-as 65000 
network 10.10.10.0 mask 255.255.255.0

CE2 hostname ce2 
ip routing 
ip cef

no ip domain-lookup 
line vty 0 15 
password cisco 
login

int faste0/0 
ip address 192.168.20.2 255.255.255.0 
no shut

int l99 
ip address 172.16.1.1 255.255.255.0 
no shut

ip route 172.16.1.0 255.255.255.0 null0

router bgp 65200 
neighbor 192.168.20.1 remote-as 65000 
neighbor 192.168.20.1 allowas-in 
network 172.16.1.0 mask 255.255.255.0

CE3 hostname ce3 
ip routing 
ip cef

no ip domain-lookup 
line vty 0 15 
password cisco 
login

int faste0/0 
ip address 192.168.30.2 255.255.255.0 
no shut

int l99 
ip address 10.10.20.1 255.255.255.0 
no shut

ip route 10.10.20.0 255.255.255.0 null0

router bgp 65100 
neighbor 192.168.30.1 remote-as 65000 
neighbor 192.168.30.1 allowas-in 
network 10.10.20.0 mask 255.255.255.0

CE4 hostname ce4 
ip routing 
ip cef

no ip domain-lookup 
line vty 0 15 
password cisco 
login

int faste0/0 
ip address 192.168.40.2 255.255.255.0 
no shut

int l99 
ip address 172.16.2.1 255.255.255.0 
no shut

ip route 172.16.2.0 255.255.255.0 null0

router bgp 65200 
neighbor 192.168.40.1 remote-as 65000 
neighbor 192.168.40.1 allowas-in 
network 172.16.2.0 mask 255.255.255.0

Soa s you can see, there’s nothing crazy about the CE config.  Just basic IP and BGP configuration.  We’ve defined a loopback 99 address as part of the larger class C network that we are advertising through BGP.  Taking a look at the routing table of our CE router and we should see…

C    192.168.10.0/24 is directly connected, FastEthernet0/0 
     10.0.0.0/24 is subnetted, 2 subnets 
C       10.10.10.0 is directly connected, FastEthernet0/1 
B       10.10.20.0 [20/0] via 192.168.10.1, 00:03:04

Not only do we have our local routes, but we now have our route from our other customer router CE3.  Cool huh?  In addition, take a look at the routing table on a P router….

P1#show ip route 
Codes: L – local, C – connected, S – static, R – RIP, M – mobile, B – BGP 
       D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area 
       N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2 
       E1 – OSPF external type 1, E2 – OSPF external type 2 
       i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2 
       ia – IS-IS inter area, * – candidate default, U – per-user static route 
       o – ODR, P – periodic downloaded static route, l – LISP 
       + – replicated route

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets 
O        1.1.1.1 [110/2] via 172.172.172.1, 05:34:02, FastEthernet0/0.1 
      2.0.0.0/32 is subnetted, 1 subnets 
C        2.2.2.2 is directly connected, Loopback0 
      3.0.0.0/32 is subnetted, 1 subnets 
O        3.3.3.3 [110/2] via 172.172.172.5, 05:33:52, FastEthernet0/0.2 
      4.0.0.0/32 is subnetted, 1 subnets 
O        4.4.4.4 [110/2] via 172.172.172.18, 05:34:29, FastEthernet0/0.5 
      5.0.0.0/32 is subnetted, 1 subnets 
O        5.5.5.5 [110/2] via 172.172.172.22, 05:34:59, FastEthernet0/0.6 
      6.0.0.0/32 is subnetted, 1 subnets 
O        6.6.6.6 [110/3] via 172.172.172.22, 05:34:39, FastEthernet0/0.6 
                 [110/3] via 172.172.172.18, 05:34:29, FastEthernet0/0.5 
      7.0.0.0/32 is subnetted, 1 subnets 
O        7.7.7.7 [110/3] via 172.172.172.22, 05:33:32, FastEthernet0/0.6 
      172.172.0.0/16 is variably subnetted, 15 subnets, 2 masks 
C        172.172.172.0/30 is directly connected, FastEthernet0/0.1 
L        172.172.172.2/32 is directly connected, FastEthernet0/0.1 
C        172.172.172.4/30 is directly connected, FastEthernet0/0.2 
L        172.172.172.6/32 is directly connected, FastEthernet0/0.2 
O        172.172.172.8/30 
           [110/2] via 172.172.172.18, 05:34:29, FastEthernet0/0.5 
           [110/2] via 172.172.172.1, 05:34:02, FastEthernet0/0.1 
O        172.172.172.12/30 
           [110/2] via 172.172.172.22, 05:34:59, FastEthernet0/0.6 
           [110/2] via 172.172.172.5, 05:33:52, FastEthernet0/0.2 
C        172.172.172.16/30 is directly connected, FastEthernet0/0.5 
L        172.172.172.17/32 is directly connected, FastEthernet0/0.5 
C        172.172.172.20/30 is directly connected, FastEthernet0/0.6 
L        172.172.172.21/32 is directly connected, FastEthernet0/0.6 
O        172.172.172.24/30 
           [110/2] via 172.172.172.22, 05:34:59, FastEthernet0/0.6 
           [110/2] via 172.172.172.18, 05:34:29, FastEthernet0/0.5 
O        172.172.172.28/30 
           [110/2] via 172.172.172.18, 05:34:29, FastEthernet0/0.5 
O        172.172.172.32/30 
           [110/2] via 172.172.172.22, 05:34:59, FastEthernet0/0.6 
O        172.172.172.36/30 
           [110/3] via 172.172.172.22, 05:33:32, FastEthernet0/0.6 
           [110/3] via 172.172.172.18, 05:33:32, FastEthernet0/0.5 
O        172.172.172.40/30 
           [110/2] via 172.172.172.22, 05:34:59, FastEthernet0/0.6 
P1#

Notice anything weird?  No customer routes!  This post is getting a little long so I’m going to kill it here.  In the next post, we’ll talk about how all of this works.