Route Leaking Between VRFs: Controlled Connectivity

January 13, 2026 · 8 min read

VRFs isolate routing tables. Customer A can’t reach Customer B. But what about shared services? The DNS server, the management network, the internet gateway — they need to be reachable from all VRFs.

Route leaking imports routes from one VRF into another. Not all routes — just the ones you explicitly allow. DNS server in VRF SHARED becomes reachable from VRF CUSTOMER-A without full interconnection.

Route leaking provides controlled cross-VRF connectivity.

Why Route Leaking

Without Route Leaking

VRF CUSTOMER-A:  10.1.0.0/16
VRF CUSTOMER-B:  10.2.0.0/16
VRF SHARED:      10.100.0.0/16 (DNS, NTP, etc.)

Problem: Customers can't reach shared services
Solution 1: NAT (complex, breaks some apps)
Solution 2: Route leaking (cleaner)

With Route Leaking

VRF CUSTOMER-A:
  - 10.1.0.0/16 (local)
  - 10.100.0.0/16 (leaked from SHARED)

VRF SHARED:
  - 10.100.0.0/16 (local)
  - 10.1.0.0/16 (leaked from CUSTOMER-A, if needed)

Basic Route Leaking

VRF Configuration

configure

# Create VRFs
set vrf name CUSTOMER-A table 10
set vrf name SHARED table 20

# Assign interfaces
set interfaces ethernet eth1 vrf CUSTOMER-A
set interfaces ethernet eth2 vrf SHARED

# Configure addresses
set interfaces ethernet eth1 address 10.1.0.1/24
set interfaces ethernet eth2 address 10.100.0.1/24

commit

Leak Routes from SHARED to CUSTOMER-A

configure

# Define what to leak (prefix list)
set policy prefix-list SHARED-SERVICES rule 10 prefix 10.100.0.0/16
set policy prefix-list SHARED-SERVICES rule 10 action permit

# Route map for import
set policy route-map IMPORT-SHARED rule 10 match ip address prefix-list SHARED-SERVICES
set policy route-map IMPORT-SHARED rule 10 action permit

# Import into CUSTOMER-A from SHARED
set vrf name CUSTOMER-A protocols static route 10.100.0.0/16 interface eth2 vrf SHARED

commit

Using BGP for Route Leaking

configure

# BGP in each VRF
set vrf name CUSTOMER-A protocols bgp system-as 65000
set vrf name SHARED protocols bgp system-as 65000

# Route distinguisher (unique per VRF)
set vrf name CUSTOMER-A protocols bgp address-family ipv4-unicast rd 65000:10
set vrf name SHARED protocols bgp address-family ipv4-unicast rd 65000:20

# Route targets for import/export
# CUSTOMER-A imports from SHARED
set vrf name CUSTOMER-A protocols bgp address-family ipv4-unicast route-target import 65000:20
set vrf name CUSTOMER-A protocols bgp address-family ipv4-unicast route-target export 65000:10

# SHARED exports to all customers
set vrf name SHARED protocols bgp address-family ipv4-unicast route-target export 65000:20

commit

Selective Route Leaking

Leak Only Specific Routes

configure

# Only leak DNS server
set policy prefix-list DNS-ONLY rule 10 prefix 10.100.0.10/32
set policy prefix-list DNS-ONLY rule 10 action permit

# Route map for selective import
set policy route-map IMPORT-DNS rule 10 match ip address prefix-list DNS-ONLY
set policy route-map IMPORT-DNS rule 10 action permit

# Apply to import
# (Implementation depends on leaking method)

commit

Leak with Modified Attributes

configure

# Import but with lower preference
set policy route-map IMPORT-BACKUP rule 10 action permit
set policy route-map IMPORT-BACKUP rule 10 set local-preference 50

# Routes leaked as backup paths

commit

Bidirectional Leaking

Customer Needs to Reach Shared, Shared Needs to Reach Customer

configure

# CUSTOMER-A → SHARED
set vrf name SHARED protocols static route 10.1.0.0/24 interface eth1 vrf CUSTOMER-A

# SHARED → CUSTOMER-A
set vrf name CUSTOMER-A protocols static route 10.100.0.0/24 interface eth2 vrf SHARED

commit

With Route Targets (Symmetric)

configure

# CUSTOMER-A
set vrf name CUSTOMER-A protocols bgp address-family ipv4-unicast route-target import 65000:20
set vrf name CUSTOMER-A protocols bgp address-family ipv4-unicast route-target export 65000:10

# SHARED
set vrf name SHARED protocols bgp address-family ipv4-unicast route-target import 65000:10
set vrf name SHARED protocols bgp address-family ipv4-unicast route-target export 65000:20

# Now bidirectional

commit

Common Patterns

Pattern 1: Shared Services VRF

        ┌─────────────────┐
        │   VRF SHARED    │
        │  DNS, NTP, etc  │
        └────────┬────────┘
                 │ (leaked to all)
    ┌────────────┼────────────┐
    │            │            │
┌───┴───┐   ┌───┴───┐   ┌───┴───┐
│ VRF A │   │ VRF B │   │ VRF C │
└───────┘   └───────┘   └───────┘

# Leak SHARED to all customer VRFs
# Each customer VRF imports 65000:SHARED
# SHARED exports to all

Pattern 2: Internet Gateway

        ┌─────────────────┐
        │   VRF INTERNET  │
        │   (default gw)  │
        └────────┬────────┘
                 │ (default route leaked)
    ┌────────────┼────────────┐
    │            │            │
┌───┴───┐   ┌───┴───┐   ┌───┴───┐
│ VRF A │   │ VRF B │   │ VRF C │
└───────┘   └───────┘   └───────┘

configure

# Internet VRF has default route
set vrf name INTERNET protocols static route 0.0.0.0/0 next-hop 203.0.113.1

# Leak default to customers
set vrf name CUSTOMER-A protocols static route 0.0.0.0/0 next-hop 10.100.0.1 vrf INTERNET

commit

Pattern 3: Management VRF

        ┌─────────────────┐
        │   VRF MGMT      │
        │  (admin access) │
        └────────┬────────┘
                 │ (limited leak)
    ┌────────────┼────────────┐
    │            │            │
┌───┴───┐   ┌───┴───┐   ┌───┴───┐
│ VRF A │   │ VRF B │   │ VRF C │
└───────┘   └───────┘   └───────┘

Management can reach all VRFs
VRFs cannot reach management

# Asymmetric: MGMT can reach customers
set vrf name MGMT protocols static route 10.1.0.0/16 interface eth1 vrf CUSTOMER-A
set vrf name MGMT protocols static route 10.2.0.0/16 interface eth2 vrf CUSTOMER-B

# But customers don't have route to MGMT
# (no reverse leak)

Preventing Leakage Problems

Problem: Overlapping Addresses

# CUSTOMER-A: 10.0.0.0/8
# CUSTOMER-B: 10.0.0.0/8  (same!)

# Can't leak between them - address collision

# Solution: NAT before leaking, or don't overlap

Problem: Routing Loops

# VRF A leaks to VRF B
# VRF B leaks to VRF C
# VRF C leaks to VRF A

# If routes propagate, possible loop

# Solution: Mark leaked routes, don't re-leak

Problem: Unintended Connectivity

# Leaked too much - customers can now reach each other

# Solution: Use strict prefix lists
set policy prefix-list SHARED-ONLY rule 10 prefix 10.100.0.0/24
set policy prefix-list SHARED-ONLY rule 10 action permit
set policy prefix-list SHARED-ONLY rule 999 action deny

# Only leak exactly what's needed

Verifying Route Leaking

Check VRF Routes

# Show routes in specific VRF
show ip route vrf CUSTOMER-A

# Look for routes with different VRF next-hop
# 10.100.0.0/24 via 10.100.0.1, eth2 (vrf SHARED)

Check BGP VPN Routes

# If using BGP for leaking
show bgp ipv4 vpn
show bgp ipv4 vpn rd 65000:10

Test Connectivity

# Ping across VRFs
ping 10.100.0.10 vrf CUSTOMER-A

# Traceroute across VRFs
traceroute 10.100.0.10 vrf CUSTOMER-A

Troubleshooting

Routes Not Appearing

# Check source VRF has the route
show ip route vrf SHARED

# Check route target configuration
show vrf CUSTOMER-A
# Look for RT import/export

# Check prefix list matches
show policy prefix-list SHARED-SERVICES

Connectivity Not Working

# Routes exist but traffic fails

# Check return path exists
show ip route vrf SHARED 10.1.0.0/24
# Shared must have route back to customer

# Check firewall allows cross-VRF
show firewall

BGP VPN Not Working

# Check RD uniqueness
show bgp ipv4 vpn summary

# Check RT import/export match
# Export RT on one side must match import RT on other

Best Practices

1. Document Leaking Policy

# Route Leaking Policy

## VRF SHARED (10.100.0.0/16)
- Leaked TO: All customer VRFs
- Leaked FROM: None (customers can't reach each other via SHARED)

## VRF INTERNET (0.0.0.0/0)
- Leaked TO: Customer VRFs with internet package
- Leaked FROM: All (for return traffic)

2. Use Prefix Lists

# Never leak "everything"
# Explicit prefix lists only

set policy prefix-list LEAK-TO-CUSTOMER rule 10 prefix 10.100.0.0/24
set policy prefix-list LEAK-TO-CUSTOMER rule 20 prefix 10.100.1.0/24
set policy prefix-list LEAK-TO-CUSTOMER rule 999 action deny

3. Consider Security

# Leaked routes bypass VRF isolation
# Firewall rules should exist at leak points

set firewall ipv4 name SHARED-TO-CUSTOMER rule 10 action accept
set firewall ipv4 name SHARED-TO-CUSTOMER rule 10 destination port 53
set firewall ipv4 name SHARED-TO-CUSTOMER rule 10 protocol udp
# Only DNS allowed

4. Monitor Leaked Routes

# Regular check that only expected routes are leaked
show ip route vrf CUSTOMER-A | grep "vrf SHARED"

# Alert if unexpected routes appear

The Lesson

Route leaking provides controlled cross-VRF connectivity.

VRFs isolate by default. Sometimes you need controlled exceptions:

Shared DNS server
Internet gateway
Management access

Route leaking gives you:

Selective connectivity (only what you allow)
Clear separation (customers still isolated from each other)
Flexibility (import/export per VRF)

The key word is controlled. Leak only what’s necessary. Use prefix lists. Verify bidirectional if needed.

VRFs without route leaking: Perfect isolation VRFs with careless leaking: No isolation VRFs with careful leaking: Controlled exceptions

Design your leaking policy before implementing. Document what goes where and why.