Internet Reachability between VRFs

Load nat44.vpn.lab3.init.cfg

#IOS-XE
config replace flash:nat44.vpn.lab3.init.cfg

#IOS-XR
configure
load bootflash:nat44.vpn.lab3.init.cfg
commit replace
y

The R2-R1 link is now in the INET VRF. R8, the CE for VPN_A, has been given 100.8.8.8/32 as a public address it can use to reach the internet. This is already set on R8 as loopback100.

Configure route leaking so that R8 can ping 8.8.8.8 sourced from 100.8.8.8/32.

Answer

#R2
ip route vrf INET 0.0.0.0 0.0.0.0 100.1.2.1
!
router bgp 100
 add ipv4 vrf INET
  redistribute static
  default-information originate
!
!
ip extcommunity-list standard INET_RT permit rt 100:0
ip extcommunity-list standard VPN_A_RT permit rt 100:1
ip prefix-list VPN_A_PUBLICS permit 100.8.8.8/32
!
route-map IMPORT_VPN_PUBLICS permit 10
 match ip address prefix-list VPN_A_PUBLICS
 match extcommunity VPN_A_RT
route-map IMPORT_VPN_PUBLICS permit 1000
 match extcommunity INET_RT
!
vrf definition INET
 address-family ipv4
  route-target import 100:1
  import map IMPORT_VPN_PUBLICS
  
#R5
ip prefix-list DEFAULT_ONLY permit 0.0.0.0/0
ip extcommunity-list standard INET_RT permit rt 100:0
ip extcommunity-list standard VPN_A_RT permit rt 100:1
!
route-map IMPORT_INET_DEFAULT permit 10
 match ip address prefix-list DEFAULT_ONLY
 match extcommunity INET_RT
route-map IMPORT_INET_DEFAULT permit 20
 match extcommunity VPN_A_RT
!
vrf definition VPN_A
 route-target import 100:0
 !
 address-family ipv4
  import map IMPORT_INET_DEFAULT

Explanation

This lab does not use NAT, but instead demonstrates how a customer can use public address space to reach the internet within their L3VPN.

First R2 configures and originates a 0/0 into the INET VRF so that other PEs can import this into their customer VRFs.

#R2
ip route vrf INET 0.0.0.0 0.0.0.0 100.1.2.1
!
router bgp 100
 add ipv4 vrf INET
  redistribute static
  default-information originate

Next, R2 imports the public 100.8.8.8/32 route into the INET VRF. To do this, we must use an import map to control which prefixes are imported. We only want to import this one /32 from the VPN_A VRF, and we still need to import all other INET prefixes (with a 100:0 RT).

ip extcommunity-list standard INET_RT permit rt 100:0
ip extcommunity-list standard VPN_A_RT permit rt 100:1
ip prefix-list VPN_A_PUBLICS permit 100.8.8.8/32
!
route-map IMPORT_VPN_PUBLICS permit 10
 match ip address prefix-list VPN_A_PUBLICS
 match extcommunity VPN_A_RT
route-map IMPORT_VPN_PUBLICS permit 1000
 match extcommunity INET_RT
!
vrf definition INET
 address-family ipv4
  route-target import 100:1
  import map IMPORT_VPN_PUBLICS

On R5, we do the opposite. We import only the 0/0 route from the INET VRF into the customer VRF.

ip prefix-list DEFAULT_ONLY permit 0.0.0.0/0
ip extcommunity-list standard INET_RT permit rt 100:0
ip extcommunity-list standard VPN_A_RT permit rt 100:1
!
route-map IMPORT_INET_DEFAULT permit 10
 match ip address prefix-list DEFAULT_ONLY
 match extcommunity INET_RT
route-map IMPORT_INET_DEFAULT permit 20
 match extcommunity VPN_A_RT
!
vrf definition VPN_A
 route-target import 100:0
 !
 address-family ipv4
  import map IMPORT_INET_DEFAULT

R8 now has a 0/0 route in its BGP table:

On R5, this points to R2 in the INET VRF:

R2 routes back to 100.8.8.8/32 via the VPN_A route that it is importing into the INET VRF.

The end result is that R8 can ping 8.8.8.8, but only if sourced from Lo100.

Conclusion

This lab shows a basic example of extranets. VPN routes can be leaked between VRFs by importing the RT of the remote VRF. Import route-maps control which routes are imported from each VPN.