In this final part, we will use RTs to provide shared services to multiple customer VPNs.
By importing and exporting multiple RTs into a VRF, we can share routes between VRFs to easily provide the same routes to multiple customer VPNS. This exercise will help you understand exactly how import and export RTs work.
In this lab, we will provide internet access to the CUSTOMER_A and CUSTOMER_B VRFs by importing a 0/0 route from our INTERNET VRF into the customer VPNs. The customers will need to source NAT their own traffic from a public /32 IP that we give them, and we’ll need to import their public /32s into the internet VRF.
Lab
We’ll re-use the existing topology from part 3, but now PE4 connects to an internet transit peer. 20.20.20.0/30 is used for BGP peering, and there is a loopback, 8.8.8.8 on the peer which we will use to verify internet connectivity. PE4 advertises 100.1.1.0/24 to the peer, which is the service provider’s own address space which it will hand out to customers.
The CUSTOMER_A and CUSTOMER_B VRFs use the same RD and RTs values of 123:100 and 123:200, respectively, as in the previous lab.
Here’s the PE4 and Internet peer configuration:
#PE4
vrf INTERNET
address-family ipv4 unicast
import route-target 123:1000
export route-target 123:1000
!
int gi0/0/0/1
vrf INTERNET
ip address 20.20.20.2/30
!
router bgp 123
vrf INTERNET
rd 123:1000
address-family ipv4 unicast
network 100.1.1.0/24
neighbor 20.20.20.1
remote-as 456
address-family ipv4 unicast
route-policy DEFAULT_ROUTE in
route-policy PEERING_OUTBOUND out
!
route-policy DEFAULT_ROUTE
if destination in ( 0.0.0.0/0 ) then
pass
endif
end-policy
!
prefix-set INTERNET_PREFIXES
100.1.1.0/24
end-set
!
route-policy PEERING_OUTBOUND
if destination in INTERNET_PREFIXES then
pass
endif
!
router static vrf INTERNET address-family ipv4 unicast
100.1.1.0/24 null0
end-policy
#Internet_peer
int Gi1
ip address 20.20.20.1 255.255.255.252
!
int lo0
ip address 8.8.8.8 255.255.255.255
!
router bgp 456
neighbor 20.20.20.2 remote-as 123
neighbor 20.20.20.2 default-originate
As you can see, we’re running the internet routing table as a VRF. This allows us to easily import/export routes to and from this INTERNET VRF into customer VRFs.
We’ll allocate public IP address for the CEs as follows:
CE Number
Public IP
CE1
100.1.1.1/32
CE2
100.1.1.2/32
CE3
100.1.1.3/32
CE4
100.1.1.4/32
IOS-XR
The public IPs will be added as a loopback (Lo100) on the CEs. On PE2 we’ll add static routes with a next-hop-vrf of the Customer VRF, with the next-hop-address as the MPLS transit IP for that CE.
#CE3
int lo100
ip address 100.1.1.3 255.255.255.255
#CE4
int lo100
ip address 100.1.1.4 255.255.255.255
#PE2
vrf INTERNET
address-family ipv4 unicast
import route-target 123:1000
export route-target 123:1000
!
router bgp 123 vrf INTERNET
rd 123:1000
address-family ipv4 unicast
redistribute static
!
router static vrf INTERNET address-family ipv4 unicast
100.1.1.3/32 vrf CUSTOMER_A 100.64.1.6
100.1.1.4/32 vrf CUSTOMER_B 100.64.2.6
!
Because PE2 redistributes those statics into the BGP table for the INTERNET VRF, PE4 has learned the routes to 100.1.1.3 and 100.1.1.4. But CE3 and CE4 do not have a default route to the internet yet.
RP/0/0/CPU0:PE4#show route vrf INTERNET | beg Gateway
Sat Jul 23 18:26:00.926 UTC
Gateway of last resort is 20.20.20.1 to network 0.0.0.0
B* 0.0.0.0/0 [20/0] via 20.20.20.1, 14:20:18
C 20.20.20.0/30 is directly connected, 14:23:28, GigabitEthernet0/0/0/1
L 20.20.20.2/32 is directly connected, 14:23:28, GigabitEthernet0/0/0/1
S 100.1.1.0/24 is directly connected, 03:17:56, Null0
B 100.1.1.3/32 [200/0] via 2.2.2.2 (nexthop in vrf default), 03:20:41
B 100.1.1.4/32 [200/0] via 2.2.2.2 (nexthop in vrf default), 00:00:07
CE3#show bgp ipv4 uni | beg Network
Network Next Hop Metric LocPrf Weight Path
*> 10.0.0.0/24 100.64.1.5 0 123 65000 i
*> 10.0.1.0/24 0.0.0.0 0 32768 i
*> 10.10.10.0/24 100.64.1.5 0 123 65000 i
*> 10.20.0.0/16 100.64.1.5 0 123 65000 i
CE4#show bgp ipv4 uni | beg Network
Network Next Hop Metric LocPrf Weight Path
*> 10.0.0.0/24 100.64.2.5 0 123 65000 i
*> 10.0.1.0/24 0.0.0.0 0 32768 i
*> 10.10.10.0/24 0.0.0.0 0 32768 i
In order to inject the 0/0 route from the INTERNET VRF, we’ll simply import the route-target that the INTERNET VRF exports, which is 123:1000. We cannot just advertise a default route to the customers under BGP in the Customer VRFs (such as default-originate). This is because we need the default route to actually be from the INTERNET VRF, and to point to PE4 in the INTERNET VRF.
We’re getting the full INTERNET VRF routing table on the CEs now, which is not what we want. We want just a default route to be injected from the INTERNET VRF into the Customer VRFs.
CE3#show bgp ipv4 uni | beg Network
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 100.64.1.5 0 123 456 i
*> 10.0.0.0/24 100.64.1.5 0 123 65000 i
*> 10.0.1.0/24 0.0.0.0 0 32768 i
*> 10.10.10.0/24 100.64.1.5 0 123 65000 i
*> 10.20.0.0/16 100.64.1.5 0 123 65000 i
*> 100.1.1.0/24 100.64.1.5 0 123 i
r> 100.1.1.3/32 100.64.1.5 0 123 ?
*> 100.1.1.4/32 100.64.1.5 0 123 ?
We’ll add a route-policy to the import of all routes into the VRF in order to control which routes we are actually importing into the Customer VRFs. This will let us block everything except for the 0/0 coming from the INTERNET VRF.
Oops, we have just our 0/0 from the INTERNET VRF now, but we lost all of our customer routes on the CEs as well!
CE3#show bgp ipv4 uni | beg Network
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 100.64.1.5 0 123 456 i
*> 10.0.1.0/24 0.0.0.0 0 32768 i
We’ll need to change our route-policy to pass along any RFC1918 prefixes. Feel free to try alternative methods, such as matching the RT value and filtering traffic based on that.
#PE2
prefix-set RFC1918
10.0.0.0/8 le 32, 172.16.0.0/12 le 32, 192.168.0.0/16 le 32
end-set
!
route-policy DEFAULT_PLUS_RFC1918
if destination in RFC1918 then
pass
endif
if destination in ( 0.0.0.0/0 ) then
pass
endif
end-policy
!
vrf CUSTOMER_A
address-family ipv4 unicast
import route-policy DEFAULT_PLUS_RFC1918
!
vrf CUSTOMER_B
address-family ipv4 unicast
import route-policy DEFAULT_PLUS_RFC1918
Perfect, we now have our customer routes plus the 0/0 from the INTERNET VRF.
CE3#show bgp ipv4 uni | beg Network
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 100.64.1.5 0 123 456 i
*> 10.0.0.0/24 100.64.1.5 0 123 65000 i
*> 10.0.1.0/24 0.0.0.0 0 32768 i
*> 10.10.10.0/24 100.64.1.5 0 123 65000 i
*> 10.20.0.0/16 100.64.1.5 0 123 65000 i
The CEs see the 0/0 route as just another prefix advertised by the PE. The CEs have no idea that this actually came from another VRF.
On PE2, the 0/0 route in the Customer VRFs points to PE4. PE2 will put the VPN label on traffic matching this route before forwarding it to PE4, just as if the 0/0 route was another route in the customer VRF itself. Once you import the prefix into the customer VRF, there is really no difference between routes imported from the same VRF on another PE, or a different VRF. Meaning, on PE2, it doesn’t have the nexthop in the INTERNET VRF, and then that nexthop in the default VRF. Looking at the RIB, you have no idea which routes came from RT 123:100 and which from RT 123:1000. The PE simply matches prefixes with RT vales that match the import statement and puts those into the VRF.
RP/0/0/CPU0:PE2#show route vrf CUSTOMER_A | beg Gateway
Sat Jul 23 18:41:09.071 UTC
Gateway of last resort is 4.4.4.4 to network 0.0.0.0
B* 0.0.0.0/0 [200/0] via 4.4.4.4 (nexthop in vrf default), 00:12:08
B 10.0.0.0/24 [200/0] via 1.1.1.1 (nexthop in vrf default), 00:02:13
B 10.0.1.0/24 [20/0] via 100.64.1.6, 1d12h
B 10.10.10.0/24 [200/0] via 1.1.1.1 (nexthop in vrf default), 00:02:13
B 10.20.0.0/16 [200/0] via 1.1.1.1 (nexthop in vrf default), 00:02:13
C 100.64.1.4/30 is directly connected, 5d18h, GigabitEthernet0/0/0/1
L 100.64.1.5/32 is directly connected, 5d18h, GigabitEthernet0/0/0/1
Success! CE3 and CE4 can ping 8.8.8.8 from Lo100.
CE3#ping 8.8.8.8 source lo100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 100.1.1.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/11 ms
CE4#ping 8.8.8.8 source lo100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 100.1.1.4
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 7/8/11 ms
Remember that PE2 is redistributing the static routes into BGP in the INTERNET VRF. This is how PE4 has a route back to Lo100 of CE3 and CE4.
RP/0/0/CPU0:PE4#show bgp vrf INTERNET ipv4 uni | beg Network
Sat Jul 23 18:43:42.573 UTC
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 123:1000 (default for vrf INTERNET)
*> 0.0.0.0/0 20.20.20.1 0 456 i
*> 100.1.1.0/24 0.0.0.0 0 32768 i
*>i100.1.1.3/32 2.2.2.2 0 100 0 ?
*>i100.1.1.4/32 2.2.2.2 0 100 0 ?
IOS-XE
On IOS-XE there is not a one-line command to set a static route in a VRF to use a next-hop in another VRF. Instead, the CE1 and CE2 will advertise their Lo100 to the PE, and PE4 will import these routes into the INTERNET VRF.
We’ll use an import map which is the IOS-XE version of the import route-policy we used on PE2. This will filter routes from the INTERNET VRF so that we only get a 0/0 from the INTERNET VRF plus the RFC1918 prefixes from the customer VRFs.
#PE1
vrf definition INTERNET
rd 123:1000
address-family ipv4 unicast
route-target import 123:1000
route-target export 123:1000
!
vrf definition CUSTOMER_A
route-target import 123:1000
address-family ipv4 unicast
import map DEFAULT_PLUS_RFC1918
!
vrf definition CUSTOMER_B
route-target import 123:1000
address-family ipv4 unicast
import map DEFAULT_PLUS_RFC1918
!
ip prefix-list RFC1918 permit 10.0.0.0/8 le 32
ip prefix-list RFC1918 permit 172.16.0.0/12 le 32
ip prefix-list RFC1918 permit 192.168.0.0/16 le 32
!
ip prefix-list DEFAULT permit 0.0.0.0/0
!
route-map DEFAULT_PLUS_RFC1918 permit 10
match ip address prefix-list RFC1918 DEFAULT
#CE1
int lo100
ip address 100.1.1.1 255.255.255.255
!
router bgp 65000
network 100.1.1.1 mask 255.255.255.255
#CE2
int lo100
ip address 100.1.1.2 255.255.255.255
!
router bgp 65000
network 100.1.1.2 mask 255.255.255.255
PE4 does not have the two Customer VRFs defined, so it is automatically filtering out the vpnv4 routes from the CUSTOMER_A and CUSTOMER_B VRF.
RP/0/0/CPU0:PE4#show bgp vpnv4 uni | beg Network
Sat Jul 23 19:16:27.579 UTC
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 123:1000 (default for vrf INTERNET)
*> 0.0.0.0/0 20.20.20.1 0 456 i
*> 100.1.1.0/24 0.0.0.0 0 32768 i
*>i100.1.1.3/32 2.2.2.2 0 100 0 ?
*>i100.1.1.4/32 2.2.2.2 0 100 0 ?
However, when we import the RTs that these Customer VRFs are exporting into the INTERNET VRF, PE4 will stop filtering those prefixes automatically.
#PE4
vrf INTERNET
address-family ipv4 unicast
import route-target 123:100
import route-target 123:200
import route-policy INTERNET_PREFIXES_ONLY
!
route-policy INTERNET_PREFIXES_ONLY
if destination in ( 100.1.1.0/24 le 32 ) then pass endif
end-policy
We now have the public IPs of CE1 and CE2 in the RIB
RP/0/0/CPU0:PE4(config)#do sho route vrf INTERNET | beg Gateway
Sat Jul 23 19:20:31.902 UTC
Gateway of last resort is 20.20.20.1 to network 0.0.0.0
B* 0.0.0.0/0 [20/0] via 20.20.20.1, 15:14:49
C 20.20.20.0/30 is directly connected, 15:17:59, GigabitEthernet0/0/0/1
L 20.20.20.2/32 is directly connected, 15:17:59, GigabitEthernet0/0/0/1
S 100.1.1.0/24 is directly connected, 04:12:27, Null0
B 100.1.1.1/32 [200/0] via 1.1.1.1 (nexthop in vrf default), 00:00:29
B 100.1.1.2/32 [200/0] via 1.1.1.1 (nexthop in vrf default), 00:00:29
B 100.1.1.3/32 [200/0] via 2.2.2.2 (nexthop in vrf default), 00:00:29
B 100.1.1.4/32 [200/0] via 2.2.2.2 (nexthop in vrf default), 00:00:29
Success! Both CE1 and CE2 can ping 8.8.8.8
CE1#ping 8.8.8.8 source lo100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 100.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/12/34 ms
CE2#ping 8.8.8.8 source lo100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 100.1.1.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/6/8 ms
The CEs can also ping each other.
CE2#ping 100.1.1.1 source lo100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 100.1.1.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 10/11/13 ms
CE2#ping 100.1.1.3 source lo100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.1.1.3, timeout is 2 seconds:
Packet sent with a source address of 100.1.1.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 14/14/15 ms
Conclusion
The purpose of this article was to give you a real-world example of importing and exporting multiple RT values in order to offer shared services to customer VPNs. In order to accomplish this we had to rely on quite a few extra features, such as the import map and static routes using a different next-hop VRF. Along the way we defined prefix-sets and route-policies which, while taking away some attention from the overall goal of this article, is still great practice in terms of learning the exam topics.
I hope that you feel extremely confident with RDs and RTs now.
To sum it up, RDs distinguish routes to make them unique in the global vpnv4 (or vpnv6) table. You can use the same RD for the same VRF among multiple PEs, or you can use a unique RD per PE for the same VRF. As we saw in part 3, this technique can be used to facilitate multipathing.
RTs are used to import prefixes into a VRF. A VRF can have multiple import RTs and/or multiple export RTs. Normally you will see a single import RT and export RT on a VRF, and this will often be the same value as the RD. But now you’ve seen how you can import/export multiple RT values in order to provide shared services to multiple customer VPNs, as we did in this article (part 4).
