# 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.
