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!

Comments

3 Responses to "MPLS VPN VRF Source Selection"

Steven said... January 8, 2010 at 5:59 AM

Question:
Shouldn't the following line be added:
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
!!! add next line !!!
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

Thanks!!

Pete said... January 8, 2010 at 9:29 AM

Good observation, its actually there, but I think I missed pasting the line
PE1(config)#interface Serial1/2 all I had was

PE1(config-if)#ip vrf select source
PE1(config-if)#ip vrf receive Customer2
PE1(config-if)#ip vrf receive Management

I'm editing it and thanks for pointing it out...

Anonymous said... January 27, 2012 at 11:33 PM

So this will only work via static from PE pointing to CE for VRF source selection to work?

Post a Comment

Certifications

Certifications

The Dreamer

A fun loving person who enjoys learning new things. Currently working as a Network Engineer supporting the global network of a Fortune 500 company. This blog serves as my notes for the labs I created for my CCIE journey. I can guarantee there are errors in my posts. If you spot them, please let me know.

Join my Facebook Page I WANT TO BE A CCIE

Donate to the Cause

My aim is to create materials for free and possibly a free lab. If you wish to help out, please send any amount. Thanks.

Join my Bandwagon

Blogs that I Read