Two VRFs need to reach a shared DNS server in the global table. How do you leak routes between them on VRF-lite?
Show the answer
Say this first
With static routes you point a route in one table at a next hop or interface in another: global at the
end of an ip route vrf makes the next hop resolve in the global table, and a global route can point at
an interface that sits in a VRF. For anything bigger, use BGP locally: export and import route targets
between VRFs on the same router, no neighbors needed. Leaking needs return routes both ways and unique
addresses; overlapping ranges need NAT. Inter-VRF traffic that needs policy belongs on a firewall.
Go deeper
Static leaking
GUEST hosts are 10.50.0.0/24 on Gi0/0/1.50. The DNS server 10.200.0.53 sits in the global table behind 10.0.99.2.
ip route vrf GUEST 10.200.0.53 255.255.255.255 10.0.99.2 global
ip route 10.50.0.0 255.255.255.0 GigabitEthernet0/0/1.50The first line gives GUEST a route to the DNS server, resolved in the global table. The second gives the global table a route back to the GUEST hosts through their VRF interface. Without the second line, queries reach the server and the replies are dropped.
Leaking with BGP on one router
Route targets work between VRFs, not with the global table, so in this design the shared servers live in their own VRF called SHARED.
vrf definition GUEST
rd 65000:50
address-family ipv4
route-target export 65000:50
route-target import 65000:50
route-target import 65000:200
exit-address-family
!
vrf definition SHARED
rd 65000:200
address-family ipv4
route-target export 65000:200
route-target import 65000:200
route-target import 65000:50
exit-address-family
!
router bgp 65000
address-family ipv4 vrf GUEST
redistribute connected
exit-address-family
address-family ipv4 vrf SHARED
redistribute connected
exit-address-familyEach VRF imports the other's route target, so their connected routes appear in both tables as BGP routes.
In production, add an import map so only the shared server prefixes are leaked, not whole VRFs.
Design choices
| Need | Approach |
|---|---|
| A few prefixes, simple | static leaks with global or a cross-VRF interface |
| Many prefixes or many VRFs | BGP route targets with import and export maps |
| Overlapping addresses | VRF-aware NAT (ip nat inside source ... vrf GUEST) |
| Security policy between VRFs | route each VRF to a firewall (a fusion design) and let it decide |
They will ask next
Why is the return route the part people forget?
Leaking is one-way per route. The VRF gets a path to the server, but the server's table needs a path back to the VRF's hosts. Ping from inside the VRF, sourced from a host subnet, to test both directions.
Traps
- Leaking whole VRFs into each other, which quietly undoes the separation the VRFs were built for.
- Leaking overlapping ranges. Two identical prefixes cannot both live in one table.