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
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-familyOk, 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!
