MPLS VPN VRF Source Selection

It's been a while since I did some labs. Recently I received a comment from someone in the VRF Basics entry regarding importing the loopbacks from the CE routers to a VRF for management purposes. I'm in the middle of my BGP review but I'm curious anyway. I created a lab and tried a way and it seems I found a way how to. The feature is called VRF source selection, in which you can have multiple VRF's in an interface and VRF mapping is based on the source ip address. As we all know, CE routers usually don't have VRF's configured on them and usually for MPLS VPN setup one customer is assigned to one VRF. For MPLS Basics check my previous entry.

The diagram below shows 2 PE's and 3 CE's. I have preconfigured the PE's with BGP peering on both ipv4 and vpnv4 address-families and the necessary IP configuration with the CE's having a default route toward the directly connected PE. VPNv4 address-family on BGP by the way, is used for MPLS VPN. Configured MPLS on the link between PE1 and PE2.

Scenario:

We have 2 Customers, Customer1 and Customer2. The branch offices needs to connect to the other branches in PE2(I have created Loopback addresses for these). They need to have their own VRF's configured. Customer1 and Customer2 should have loopback0 ip addresses configured on the CE's for the NOC to use as management ip to access from their hopping server which is in ISP NOC router. VRF named "Management" should be used on the CE's. Customer's LAN networks are represented as Loopback10. The RD's of the Customers should be Customer1 - 1234:1, Customer2 - 1234:2 and Management - 1234:100. Click the image below for a bigger view.



The scenario requires 2 VRF's from every Customer CE. The Command "ip vrf forwarding" only uses one VRF per interface. We only have 1 interface and this command is not a feasible solution. We need to use VRF source selection in order to use multiple VRF's in an interface.

Provided that we already created the VRF's, first we would need to map a source IP address to a VRF. The PE will know which VRF a packet will be through the source IP.

PE1(config)#vrf selection source 1.1.1.1 255.255.255.255 vrf Management 
PE1(config)#vrf selection source 2.2.2.2 255.255.255.255 vrf Management 
PE1(config)#vrf selection source 11.11.11.11 255.255.255.255 vrf Customer1 
PE1(config)#vrf selection source 22.22.22.22 255.255.255.255 vrf Customer2  

PE2(config)#vrf selection source 3.3.3.3 255.255.255.255 vrf Management

After that, we would need to configure the interfaces in the PE's to use source selection. As mentioned, a while ago, "ip vrf forwarding" command is used if there is only one VRF used so in this scenario there is no need for the command.

PE1(config)#interface Serial1/1 
PE1(config-if)#ip vrf select source 
PE1(config-if)#ip vrf receive Customer1 
PE1(config-if)#ip vrf receive Management

PE1(config)#interface Serial1/2 
PE1(config-if)#ip vrf select source 
PE1(config-if)#ip vrf receive Customer2 
PE1(config-if)#ip vrf receive Management

PE2(config)#interface Se1/3
PE2(config)#ip vrf select source
PE2(config)#ip vrf receive Management

The commands mean that on the corresponding interfaces the VRF are activated based on the "vrf selection source" commands. It's the equivalent of "ip Vrf forwarding" command but in the sense that its for multiple vrfs.

Well now the question is, how will the VRF's know which subnets will come from what interface. Simple, through routing.:) In our case since we are not configuring dynamic routing, we will configure static vrf routes.

PE1(config)#ip route vrf Customer1 11.11.11.11 255.255.255.255 192.168.10.1 
PE1(config)#ip route vrf Customer2 22.22.22.22 255.255.255.255 192.168.20.2 
PE1(config)#ip route vrf Management 1.1.1.1 255.255.255.255 192.168.10.1 
PE1(config)#ip route vrf Management 2.2.2.2 255.255.255.255 192.168.20.2  

PE2(config)#ip route vrf Management 3.3.3.3 255.255.255.255 192.168.30.3

It's obvious that the "vrf " keyword there points to what VRF this route belongs to.:) MPLS VPN requires that the routes be learned by Multiprotocol BGP. Since these are static routes we need to redistribute them into BGP on the ipv4 VRF address-family. Output pasted below from the running config.

PE1
! 
address-family ipv4
neighbor 10.10.10.2 activate 
no auto-summary 
no synchronization
exit-address-family 
! 
address-family vpnv4
neighbor 10.10.10.2 activate 
neighbor 10.10.10.2 send-community extended 
exit-address-family 
!
address-family ipv4 vrf Management 
redistribute static metric 1 
no auto-summary  no synchronization 
exit-address-family 
!
address-family ipv4 vrf Customer2
redistribute static metric 1
 no auto-summary 
no synchronization 
exit-address-family 
!
 address-family ipv4 vrf Customer1 
redistribute static metric 1  no auto-summary  no synchronization  exit-address-family

PE2
!
 address-family ipv4 vrf Management
redistribute static metric 1
no auto-summary
no synchronization
exit-address-family

If you notice, we didn't redistribute it on the "ipv4" global address-family but instead we did it on their corresponding VRF address-families. We learned that VRF's are like separate routing tables in a single router, and that exactly is the reason why we advertise this in different address-families.

We are not done yet, remember we have 2 loopback's in PE2 representing the other sites of Customer1 and Customer2. Lets configure those.

PE2
!
interface Loopback1
 ip vrf forwarding Customer1
 ip address 111.111.111.111 255.255.255.255
!
interface Loopback2
 ip vrf forwarding Customer2
 ip address 222.222.222.222 255.255.255.255

Now let's advertise this in BGP.
!
 address-family ipv4 vrf Customer2
 no auto-summary
 no synchronization
 network 222.222.222.222 mask 255.255.255.255
 exit-address-family
 !
 address-family ipv4 vrf Customer1
 no auto-summary
 no synchronization
 network 111.111.111.111 mask 255.255.255.255
 exit-address-family

Ok, now lets check BGP peering on the VPNv4 address family. The "show ip bgp vpnv4 all summary" command will display the summary of the prefixes learned through all the VRF's.

PE1#sh ip bgp vpnv4 all sum | beg Neighbor
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.2      4  1234      93     106       15    0    0 01:14:47        3

PE2#sh ip bgp vpnv4 all sum | beg Neighbor
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.1      4  1234     106      93       20    0    0 01:14:56        4

Let's check the VRF routing tables on R1.

PE1#sh ip route vrf Customer1 | beg Gateway
Gateway of last resort is not set

C    192.168.10.0/24 is directly connected, Serial1/1
     111.0.0.0/32 is subnetted, 1 subnets
B       111.111.111.111 [200/0] via 10.10.10.2, 00:23:02
     11.0.0.0/32 is subnetted, 1 subnets
S       11.11.11.11 [1/0] via 192.168.10.1
PE1#sh ip route vrf Customer2 | beg Gateway
Gateway of last resort is not set

     222.222.222.0/32 is subnetted, 1 subnets
B       222.222.222.222 [200/0] via 10.10.10.2, 00:24:04
     22.0.0.0/32 is subnetted, 1 subnets
S       22.22.22.22 [1/0] via 192.168.20.2
C    192.168.20.0/24 is directly connected, Serial1/2
PE1#sh ip route vrf Management | beg Gateway
Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
S       1.1.1.1 [1/0] via 192.168.10.1
     2.0.0.0/32 is subnetted, 1 subnets
S       2.2.2.2 [1/0] via 192.168.20.2
     3.0.0.0/32 is subnetted, 1 subnets
B       3.3.3.3 [200/1] via 10.10.10.2, 01:02:10
C    192.168.10.0/24 is directly connected, Serial1/1
C    192.168.20.0/24 is directly connected, Serial1/2

We can see the routes that should be there. Now let's test the Customer1 VRF first if we achieved our objective. It should be able to reach the network 111.111.111.111/32 in PE2.

Customer1#ping 111.111.111.111 source 11.11.11.11

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

Cool its working! We need to specify the source ip so that it will be in the correct VRF. Network 111.111.111.111/32 is in vrf Customer1, if we don't use a source ip, by default it will use the exit interface's ip address as the source and will not be using any vrf since we don't have a source selection mapping for that. Instead it will use the "global routing table" which doesn't have entries for 111.111.111.111/32. Let's see what happens.

Customer1#ping 111.111.111.111

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 111.111.111.111, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)

As expected! Let's do a test for Customer2.

Customer2#ping 222.222.222.222 source 22.22.22.22

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

And for our final objective, the Loopback0 should be reachable through vrf "Management" from ISP NOC router. By the way, since we are only using one VRF for this, it was not necessary to use source selection. It's only for example sake!:) Now for the testing.

ISPNOC#ping 1.1.1.1 source 3.3.3.3

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

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 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 168/231/292 ms

Success!!! Whew, I don't like long blog entries but sure this will be helpful for myself in case I forget this feature. More on route-target import and export next time. Cheers!