Virtual Routing and Forwarding (VRF)

Virtual Routing and Forwarding (VRF)

Version Info

RouterOS 7.16 | Min: v7.0+ | 30 minutes | Advanced

Tested on: 7.16 7.14

Version-specific notes

• v7.15: DHCP Relay VRF support added
• v7.14: Virtual VRF interfaces auto-created; firewall interface matching changed
• v7.0: New /ip vrf menu structure (replaces routing-mark approach from v6)

TL;DR (Quick Start)

For the impatient: isolate an interface into its own routing domain.

# Create VRF and assign interface
/ip vrf add name=customer1 interfaces=ether2

# Add IP address (automatically uses VRF's routing table)
/ip address add address=192.168.100.1/24 interface=ether2

# Verify VRF routes
/ip route print where routing-table=customer1

Overview

What this does: Virtual Routing and Forwarding (VRF) creates multiple independent routing tables on a single router. Each VRF operates as if it were a separate router, with its own routing table, interfaces, and forwarding decisions. Traffic in one VRF cannot reach another VRF unless explicitly configured (route leaking).

When to use this:

• Service provider networks - Isolate customer traffic on shared infrastructure
• Multi-tenant environments - Separate routing for different clients
• Management networks - Isolate management traffic from production
• Overlapping IP spaces - Support multiple networks using the same address ranges
• BGP/MPLS VPNs - L3VPN implementation with route distinguishers

Prerequisites:

• RouterOS 7.0 or newer (v6 uses different routing-mark approach)
• Understanding of routing tables and IP addressing
• For BGP VPN: BGP package and MPLS configuration

7.14 Firewall Changes

RouterOS 7.14 introduced significant changes to how VRFs interact with firewalls. When interfaces are added to a VRF, firewall rules must reference the VRF virtual interface instead of individual physical interfaces. Review the Firewall Integration section if upgrading.

Key Concepts

VRF vs Routing Table

In RouterOS, creating a VRF automatically creates a corresponding routing table with the same name. The VRF defines which interfaces belong to the isolated network domain, while the routing table holds the routes for that domain.

Route Distinguisher (RD)

For BGP/MPLS VPN configurations, the Route Distinguisher makes routes globally unique even when IP prefixes overlap between VRFs. Format: ASN:number or IP:number (e.g., 65000:1 or 10.0.0.1:1).

Route Targets (RT)

Control which routes are imported/exported between VRFs in BGP VPN configurations. Import RT determines which routes a VRF accepts; export RT tags routes leaving a VRF.

Configuration Steps

Step 1: Create a VRF Instance

/ip vrf add name=customer1 interfaces=ether2,ether3

This creates:

• A VRF named “customer1”
• Associates ether2 and ether3 with this VRF
• Automatically creates a routing table named “customer1”

Step 2: Verify VRF Creation

/ip vrf print

Expected Output:

Flags: X - disabled
 #   NAME        INTERFACES
 0   customer1   ether2,ether3

Step 3: Check Routing Table Created

/routing table print

Expected Output:

 #   NAME        FIB
 0   main
 1   customer1

Step 4: Add Routes to the VRF

Routes for VRF interfaces are automatically added to the VRF’s routing table. To add static routes:

/ip route add dst-address=10.0.0.0/24 gateway=192.168.1.1 routing-table=customer1

Step 5: Verify Routes in VRF

/ip route print where routing-table=customer1

Common Configuration Scenarios

Scenario 1: Basic VRF Isolation

Isolate two customer networks on the same router:

# Create VRFs
/ip vrf add name=customer1 interfaces=ether2
/ip vrf add name=customer2 interfaces=ether3

# Add addresses (each in its own VRF context)
/ip address add address=192.168.1.1/24 interface=ether2
/ip address add address=192.168.1.1/24 interface=ether3

# Note: Same IP range works because they're in different VRFs

Scenario 2: VRF with Internet Access (Route Leaking)

Provide internet access to a VRF using the main routing table’s default gateway:

# Create VRF
/ip vrf add name=customer1 interfaces=ether2

# Add customer gateway address
/ip address add address=192.168.100.1/24 interface=ether2

# Add default route that resolves in main table (note @main)
/ip route add dst-address=0.0.0.0/0 gateway=10.0.0.1@main routing-table=customer1

# Configure NAT for customer traffic
/ip firewall nat add chain=srcnat out-interface=ether1-wan action=masquerade

Key syntax: gateway=IP@table specifies which routing table resolves the gateway.

Scenario 3: VRF with DHCP Server

Run a DHCP server within a VRF:

# Create VRF and assign interface
/ip vrf add name=customer1 interfaces=ether2

# Add IP address
/ip address add address=192.168.100.1/24 interface=ether2

# Create DHCP pool
/ip pool add name=customer1-pool ranges=192.168.100.100-192.168.100.200

# Configure DHCP server (uses VRF automatically via interface)
/ip dhcp-server add name=customer1-dhcp interface=ether2 address-pool=customer1-pool

# Add DHCP network
/ip dhcp-server network add address=192.168.100.0/24 gateway=192.168.100.1 dns-server=8.8.8.8

Scenario 4: BGP VPN with Route Distinguisher

For MPLS L3VPN configurations:

# Create VRF with route distinguisher
/ip vrf add name=customer1 interfaces=ether2

# Configure route distinguisher and targets
/ip route vrf
add vrf=customer1 route-distinguisher=65000:1 \
    import-route-targets=65000:1 export-route-targets=65000:1

Scenario 5: Services Bound to VRF

Bind services to listen on specific VRF:

# DNS server in VRF
/ip dns set servers=8.8.8.8 vrf=customer1

# SSH listening on VRF
/ip service set ssh address=0.0.0.0/0 vrf=customer1

# Or use @vrf syntax for one-off operations
/tool fetch url="http://example.com" vrf=customer1

Firewall Integration

RouterOS 7.14+ Changes

Starting with RouterOS 7.14, when interfaces are added to a VRF, a virtual VRF interface is automatically created. Firewall rules must reference this VRF interface instead of individual physical interfaces.

Before 7.14:

# Matched individual interfaces in VRF
/ip firewall filter add chain=input in-interface=ether2 action=accept

After 7.14:

# Must match VRF virtual interface
/ip firewall filter add chain=input in-interface=customer1 action=accept

Matching Specific Interfaces Within VRF

To match specific physical interfaces within a VRF (7.14+), use connection marking:

# Mark connections from specific interface
/ip firewall mangle add chain=prerouting in-interface=ether2 action=mark-connection new-connection-mark=from-ether2

# Then filter based on connection mark
/ip firewall filter add chain=forward connection-mark=from-ether2 action=accept

NAT with VRF

# Masquerade traffic from VRF going to internet
/ip firewall nat add chain=srcnat out-interface=ether1-wan src-address=192.168.100.0/24 action=masquerade

Verification

Check 1: Verify VRF Configuration

/ip vrf print

Expected: VRF listed with correct interfaces.

Check 2: Verify Routing Tables

/routing table print

Expected: Each VRF has a corresponding routing table.

Check 3: Check Routes in VRF

/ip route print where routing-table=customer1

Expected: Routes specific to the VRF, including connected routes for assigned interfaces.

Check 4: Test Connectivity from VRF

/ping 8.8.8.8 vrf=customer1

Expected: Successful if VRF has internet access configured.

Check 5: Verify Interface Assignment

/ip address print detail where interface=ether2

Expected: Shows actual-interface reflecting VRF membership.

Troubleshooting

Symptom	Cause	Solution
Routes not active in VRF	Gateway looking in wrong routing table	Use gateway=IP@main to specify table for gateway resolution
VRF interface not in firewall list (7.14+)	7.14 changed interface behavior	Use VRF name as interface: in-interface=customer1
Services not accessible in VRF	Service not bound to VRF	Configure vrf= parameter on service
Overlapping addresses conflicting	Interface not in VRF when address added	Create VRF before adding IP addresses
Wrong VRF matched	VRF matching is top-to-bottom	Reorder VRFs with /ip vrf move
Firewall rules broken after 7.14 upgrade	Interface matching changed	Use VRF virtual interface or connection marks
Ping fails from VRF	Tool using main table	Specify VRF: /ping 8.8.8.8 vrf=customer1

Debug: Gateway Resolution

If routes show inactive, check gateway resolution:

# Wrong - gateway looks in customer1 table where it doesn't exist
/ip route add dst-address=0.0.0.0/0 gateway=10.0.0.1 routing-table=customer1

# Right - gateway explicitly resolves in main table
/ip route add dst-address=0.0.0.0/0 gateway=10.0.0.1@main routing-table=customer1

Debug: VRF Order

Check current VRF order:

/ip vrf print

Move specific VRF to top for priority matching:

/ip vrf move [find name=specific-vrf] destination=0

Common Mistakes

• Forgetting @table for gateway resolution - Use gateway=10.0.0.1@main when the gateway is in a different routing table
• Adding address before VRF assignment - Always create VRF and assign interface first, then add IP addresses
• Using physical interface in firewall (7.14+) - After 7.14, use VRF name (in-interface=customer1) not physical interface
• Expecting automatic NAT isolation - NAT rules must explicitly reference VRF source addresses
• Not specifying VRF for diagnostic tools - Use vrf= parameter: /ping 8.8.8.8 vrf=customer1
• Assuming services automatically use VRF - Most services require explicit vrf= configuration

Tips

Gateway Syntax: Use gateway=IP@table to specify which routing table resolves the gateway. This is essential for route leaking.

VRF Order: VRF matching is top-to-bottom like firewall rules. Use /ip vrf move to reorder if needed.

Service Testing: Always test services with vrf= parameter to ensure they use the correct routing table:

/tool fetch url="http://example.com" vrf=customer1

Services with VRF Support

Service	VRF Parameter	Notes
BGP	Per-connection	Full VRF support
OSPF	vrf	Per-instance
DNS	vrf	Client and server
DHCP Relay	vrf	Added in 7.15
SSH/Telnet/WWW	vrf	Via /ip service
NTP	vrf	Client and server
SNMP	vrf
RADIUS	vrf
Ping/Traceroute	vrf	Diagnostic tools
Fetch	vrf	HTTP client
Netwatch	vrf	Monitoring

Limitations

• Maximum 1024 VRF instances (routing table limit)
• Not all services support VRF (check documentation)
• VRF order matters - matching is top-to-bottom
• RouterOS 7.14+ changed firewall interface matching behavior
• Some features require specific RouterOS versions for VRF support

Related Topics

Routing

• Static Routes - basic routing configuration
• Routing Tables - multiple routing table management
• Routing Rules - policy-based routing
• BGP - BGP configuration for VPN

Network Services

• DHCP Relay - DHCP relay with VRF support (7.15+)
• DHCP Server - per-VRF DHCP services
• DNS Server - DNS with VRF

Security

• Firewall Basics - firewall rules with VRF
• IP Services - VRF-bound management services

Reference

• MikroTik VRF Documentation
• RFC 4364 - BGP/MPLS IP VPNs

VRF Properties (/ip vrf)

Property	Type	Default	Description
name	string	-	VRF identifier (also becomes routing table name)
interfaces	list	-	Interfaces assigned to this VRF
disabled	yes/no	no	Disable VRF

Route VRF Properties (/ip route vrf)

Property	Type	Default	Description
vrf	string	-	VRF name reference
route-distinguisher	string	-	RD format: ASN:number or IP:number
import-route-targets	list	-	Route targets to import
export-route-targets	list	-	Route targets to export

Common VRF Parameters for Services

Parameter	Usage	Example
vrf=	Specify VRF for service/command	/ping 8.8.8.8 vrf=customer1
@table	Gateway resolution in specific table	gateway=10.0.0.1@main
routing-table=	Target routing table for routes	routing-table=customer1

Commands

Command	Description
/ip vrf add	Create new VRF
/ip vrf print	List VRF instances
/ip vrf move	Reorder VRF (affects matching priority)
/routing table print	List all routing tables including VRF tables
/ip route print where routing-table=X	Show routes in specific VRF