> For the complete documentation index, see [llms.txt](https://ccie-sp.gitbook.io/ccie-spv5.1-labs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ccie-sp.gitbook.io/ccie-spv5.1-labs/labs/nat/internet-reachability-between-vrfs.md).
# 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.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://ccie-sp.gitbook.io/ccie-spv5.1-labs/labs/nat/internet-reachability-between-vrfs.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.