VRF & Segmentation: When VLANs Aren't Enough

November 11, 2025 · 9 min read

VLANs give you Layer 2 separation. Different broadcast domains, different subnets. But they all share the same routing table. When a server in VLAN 10 wants to reach a server in VLAN 20, your router sees both networks, compares the destination to its single routing table, and forwards.

VRF (Virtual Routing and Forwarding) gives you something VLANs can’t: completely separate routing tables. Traffic in VRF “Production” has no idea that VRF “Management” exists. They’re parallel universes on the same hardware.

When do you need this? When VLAN isolation isn’t enough. Multi-tenant environments, management plane separation, compliance requirements, or just wanting to ensure that a routing mistake in one segment can’t affect another.

VRF Fundamentals

A VRF is an isolated routing instance. It has:

Its own routing table
Its own interfaces
Its own routing protocols (BGP, OSPF, static routes)
No visibility into other VRFs unless you explicitly leak routes

Think of it as running multiple virtual routers on one box.

Creating VRFs on VyOS

Basic VRF setup:

configure

# Create VRFs
set vrf name PRODUCTION description 'Production workloads'
set vrf name PRODUCTION table '100'

set vrf name MANAGEMENT description 'Management and monitoring'
set vrf name MANAGEMENT table '200'

set vrf name DMZ description 'Public-facing services'
set vrf name DMZ table '300'

commit

The table parameter is the routing table ID. Each VRF needs a unique one.

Assigning Interfaces to VRFs

Interfaces must be assigned to a VRF. An interface can only belong to one VRF at a time.

configure

# Physical interface in Production
set interfaces ethernet eth1 vrf 'PRODUCTION'
set interfaces ethernet eth1 address '10.1.0.1/24'
set interfaces ethernet eth1 description 'Production LAN'

# VLAN interfaces in different VRFs
set interfaces ethernet eth0 vif 100 vrf 'MANAGEMENT'
set interfaces ethernet eth0 vif 100 address '10.100.0.1/24'

set interfaces ethernet eth0 vif 200 vrf 'DMZ'
set interfaces ethernet eth0 vif 200 address '10.200.0.1/24'

commit

Important: Once an interface is in a VRF, its routes only exist in that VRF’s table. The main routing table won’t see them.

Viewing VRF Status

# List all VRFs
show vrf

# Show routes in a specific VRF
show ip route vrf PRODUCTION

# Show interfaces in a VRF
show vrf PRODUCTION

# Ping from a specific VRF
ping 10.1.0.5 vrf PRODUCTION

Static Routes in VRFs

Static routes can be VRF-specific:

configure

# Default route in Production VRF
set protocols static route 0.0.0.0/0 next-hop 10.1.0.254 vrf 'PRODUCTION'

# Specific route in Management VRF
set protocols static route 10.0.0.0/8 next-hop 10.100.0.254 vrf 'MANAGEMENT'

commit

Running Routing Protocols in VRFs

Each VRF can run its own routing protocol instances:

OSPF per VRF

configure

# OSPF in Production VRF
set protocols ospf vrf PRODUCTION area 0 network '10.1.0.0/24'
set protocols ospf vrf PRODUCTION parameters router-id '10.1.0.1'
set protocols ospf vrf PRODUCTION redistribute connected

# OSPF in Management VRF (completely separate)
set protocols ospf vrf MANAGEMENT area 0 network '10.100.0.0/24'
set protocols ospf vrf MANAGEMENT parameters router-id '10.100.0.1'

commit

BGP per VRF

configure

# BGP for Production (AS 65001)
set protocols bgp vrf PRODUCTION system-as '65001'
set protocols bgp vrf PRODUCTION neighbor 10.1.0.254 remote-as '65000'

# BGP for DMZ (different AS or same, depending on design)
set protocols bgp vrf DMZ system-as '65002'
set protocols bgp vrf DMZ neighbor 10.200.0.254 remote-as '65000'

commit

Inter-VRF Routing (Route Leaking)

Sometimes you need controlled communication between VRFs. A jump host in Management needs to reach Production. A monitoring server needs visibility into all VRFs.

Option 1: Static route leaking

configure

# Leak Production network into Management VRF
set protocols static route 10.1.0.0/24 interface 'eth1' vrf 'MANAGEMENT'
set protocols static route 10.1.0.0/24 next-hop-vrf 'PRODUCTION' vrf 'MANAGEMENT'

commit

This tells the Management VRF: “to reach 10.1.0.0/24, look in the Production VRF’s routing table.”

Option 2: Import/Export with BGP (MP-BGP)

For complex scenarios, use BGP to import/export routes between VRFs:

configure

# Define route distinguisher and route targets
set protocols bgp vrf PRODUCTION address-family ipv4-unicast rd '65000:100'
set protocols bgp vrf PRODUCTION address-family ipv4-unicast route-target export '65000:100'
set protocols bgp vrf PRODUCTION address-family ipv4-unicast route-target import '65000:200'

set protocols bgp vrf MANAGEMENT address-family ipv4-unicast rd '65000:200'
set protocols bgp vrf MANAGEMENT address-family ipv4-unicast route-target export '65000:200'
set protocols bgp vrf MANAGEMENT address-family ipv4-unicast route-target import '65000:100'

commit

This is the MPLS VPN model applied to VRFs. Routes tagged with RT 65000:100 (from Production) get imported into Management, and vice versa.

Firewalling Between VRFs

Leaking routes doesn’t mean allowing all traffic. Use firewall rules to control inter-VRF communication:

configure

# Zone-based approach
set firewall zone PRODUCTION interface 'eth1'
set firewall zone MANAGEMENT interface 'eth0.100'
set firewall zone DMZ interface 'eth0.200'

# Policy: Management can reach Production (SSH only)
set firewall ipv4 name MGMT-TO-PROD default-action 'drop'
set firewall ipv4 name MGMT-TO-PROD rule 10 action 'accept'
set firewall ipv4 name MGMT-TO-PROD rule 10 destination port '22'
set firewall ipv4 name MGMT-TO-PROD rule 10 protocol 'tcp'
set firewall ipv4 name MGMT-TO-PROD rule 10 state 'new'

# Policy: Production cannot initiate to Management
set firewall ipv4 name PROD-TO-MGMT default-action 'drop'
set firewall ipv4 name PROD-TO-MGMT rule 10 action 'accept'
set firewall ipv4 name PROD-TO-MGMT rule 10 state 'established,related'

# Apply zone policies
set firewall zone PRODUCTION from MANAGEMENT firewall name 'MGMT-TO-PROD'
set firewall zone MANAGEMENT from PRODUCTION firewall name 'PROD-TO-MGMT'

commit

VRF for Management Plane Separation

A common pattern: keep management traffic completely separate from data traffic.

configure

# Management VRF
set vrf name MGMT table '999'

# Management interface
set interfaces ethernet eth0 vrf 'MGMT'
set interfaces ethernet eth0 address '192.168.255.1/24'
set interfaces ethernet eth0 description 'Out-of-band management'

# SSH binds to Management VRF
set service ssh vrf 'MGMT'

# SNMP in Management VRF
set service snmp vrf 'MGMT'
set service snmp community public authorization 'ro'

# NTP in Management VRF
set service ntp vrf 'MGMT'
set service ntp server 192.168.255.10

commit

Now SSH, SNMP, and NTP only work through the management interface. Someone on the production network can’t SSH to the router’s production-facing IP — that IP isn’t listening.

The Mental Model

VRF makes complex networks manageable, but only if you maintain a clear mental model. Here’s how to think about it:

1. Draw Your VRF Topology

Before configuring, diagram:

What VRFs exist
What interfaces belong to each
What routes leak between them
What firewall rules control inter-VRF traffic

┌─────────────────────────────────────────────────────┐
│                    VyOS Router                      │
├─────────────┬─────────────────┬────────────────────┤
│    MGMT     │   PRODUCTION    │        DMZ         │
│  Table 999  │    Table 100    │     Table 300      │
├─────────────┼─────────────────┼────────────────────┤
│ eth0        │ eth1            │ eth2               │
│ 192.168.x.x │ 10.1.0.0/16     │ 10.200.0.0/24      │
├─────────────┴─────────────────┴────────────────────┤
│ Route Leaking:                                      │
│ - MGMT → PROD: 10.1.0.0/24 (monitoring)            │
│ - PROD → DMZ: 10.200.0.0/24 (web backends)         │
│ - DMZ → PROD: NONE (DMZ can't initiate to prod)   │
└─────────────────────────────────────────────────────┘

2. Default to Isolation

Start with VRFs completely isolated. Only leak routes when there’s a documented requirement. Every route leak is a potential security boundary crossing.

3. Document Why

For every inter-VRF route, document:

Why it’s needed
Who approved it
What firewall rules protect it

# In VyOS config, use descriptions
set protocols static route 10.1.0.0/24 next-hop-vrf 'PRODUCTION' vrf 'MANAGEMENT'
# Description: "Monitoring servers in MGMT need to reach Prod for health checks. Approved: 2024-01. Protected by MGMT-TO-PROD firewall rules."

4. Test Isolation

Regularly verify that isolation is working:

# From a host in DMZ VRF, try to reach Management — should fail
ping 192.168.255.1 vrf DMZ
# Should timeout or be rejected

# Verify routes aren't leaking unexpectedly
show ip route vrf DMZ
# Should NOT see Management networks

Real-World Example: Multi-Tenant Router

Service provider scenario: one VyOS router handles multiple customers, each in their own VRF.

configure

# Customer A
set vrf name CUSTOMER-A table '1001'
set interfaces ethernet eth1 vif 100 vrf 'CUSTOMER-A'
set interfaces ethernet eth1 vif 100 address '10.100.1.1/24'
set protocols bgp vrf CUSTOMER-A system-as '65100'
set protocols bgp vrf CUSTOMER-A neighbor 10.100.1.2 remote-as '65100'

# Customer B
set vrf name CUSTOMER-B table '1002'
set interfaces ethernet eth1 vif 200 vrf 'CUSTOMER-B'
set interfaces ethernet eth1 vif 200 address '10.100.2.1/24'
set protocols bgp vrf CUSTOMER-B system-as '65200'
set protocols bgp vrf CUSTOMER-B neighbor 10.100.2.2 remote-as '65200'

# Customers cannot see each other — complete isolation
# Each has their own BGP session, their own routes, their own world

commit

Customer A and B could both use 10.0.0.0/8 internally. No conflict — they’re in different routing tables.

Troubleshooting VRFs

Common issues:

1. Interface not in VRF

show interfaces ethernet eth1
# Check "VRF:" field — should show your VRF name

2. Routes not appearing

show ip route vrf PRODUCTION
# If empty, check interface addresses and that interface is up

3. Traffic not flowing between VRFs

# Check routes exist in source VRF
show ip route vrf MANAGEMENT 10.1.0.0/24

# Check firewall isn't blocking
show firewall statistics

# Check return path — VRF routing must work both directions
show ip route vrf PRODUCTION 10.100.0.0/24

4. Services not binding to VRF

# Verify service is configured for VRF
show configuration commands | grep "vrf"

# Check socket bindings
ss -tlnp | grep sshd

The Lesson

VRF simplifies complex networks if you keep the model in your head.

VLANs isolate at Layer 2. VRF isolates at Layer 3. Combined, they give you complete network segmentation. But VRF adds complexity — every interface, every route, every service needs to be VRF-aware.

The key is maintaining a clear mental model. Know which interfaces are in which VRF. Know what routes leak between them. Know what firewall rules protect those leaks. When you have that model, VRF makes complex multi-tenant or highly-segmented networks manageable. When you lose track of that model, VRF becomes a debugging nightmare.

Start simple. One or two VRFs. Get comfortable with VRF-aware commands. Expand when you need to. And always, always diagram your VRF topology before you build it.