VRF-Lite and Inter-VRF Routing

Introduction

When a single physical router needs to serve multiple customers or departments while keeping their traffic completely separate, Virtual Routing and Forwarding (VRF) is the technology that makes it possible. In enterprise and service provider environments, VRF-Lite provides Layer 3 traffic isolation without requiring a full MPLS backbone, making it one of the most practical segmentation tools available to network engineers.

This lesson covers VRF-Lite configuration on IOS-XE routers, the critical difference between legacy VRF commands and the modern address-family aware syntax, and how inter-VRF routing allows controlled communication between otherwise isolated routing domains. By the end of this lesson, you will be able to configure VRF-Lite for multiple customers on a Provider Edge (PE) router, assign interfaces to VRF instances correctly, understand the role of VRF-Lite in campus and data center handoff scenarios, and recognize how policy-based routing can complement VRF deployments for granular traffic steering.

Key Concepts

What Is VRF-Lite?

VRF-Lite is a mechanism that allows a single physical router to maintain multiple independent routing tables. Each VRF instance acts as a virtual router with its own routing table, its own interfaces, and its own forwarding decisions. Traffic in one VRF cannot reach another VRF unless you explicitly configure route leaking or inter-VRF routing.

The term "Lite" distinguishes this from full MPLS VRF, which relies on label switching and VPNv4 address families across a provider core. VRF-Lite operates without MPLS, using standard IP routing between PE routers and Customer Edge (CE) routers. This makes it ideal for campus networks, data center border handoffs, and multi-tenant environments.

Legacy vs. Address-Family Aware VRF

There are two syntax styles for configuring VRF on IOS-XE devices. Understanding the difference is essential for the CCNP ENARSI exam and for real-world deployments.

Feature	Legacy VRF (`ip vrf`)	Address-Family Aware VRF (`vrf definition`)
Command to create VRF	`ip vrf Cust_A`	`vrf definition Cust_A`
Protocol support	IPv4 only	IPv4 and IPv6
Address-family declaration	Not required	Required (`address-family ipv4` / `address-family ipv6`)
Interface assignment	`ip vrf forwarding Cust_A`	`vrf forwarding Cust_A`
Route distinguisher	`rd 10:1` under `ip vrf`	`rd 10:1` under `vrf definition`

The address-family aware syntax using vrf definition is the modern, preferred approach. It supports both IPv4 and IPv6 under a single VRF definition. When configuring VRF-Lite for dual-stack environments, you must use the vrf definition command with explicit address-family ipv4 and address-family ipv6 sub-configurations.

Important: The address-family aware VRF-Lite configuration must include the address-family ipv4 (or ipv6) statement under the VRF definition. Without it, the VRF will not process traffic for that protocol family.

Key Terminology

PE (Provider Edge): The router that connects to customer networks and maintains VRF instances for each customer.
CE (Customer Edge): The customer-side router that peers with the PE router. It typically runs standard routing protocols without VRF awareness.
RD (Route Distinguisher): A value such as 10:1 that makes routes from different VRFs unique when carried in BGP VPNv4 updates. In VRF-Lite without MPLS, the RD is still configured but is primarily relevant when extending into an MPLS core.
Inter-VRF Routing: The process of allowing controlled traffic flow between two or more VRF instances, often called route leaking.

How It Works

VRF-Lite Traffic Isolation

When you assign an interface to a VRF, that interface is removed from the global routing table and placed into the VRF-specific routing table. Any IP address configured on that interface becomes part of the VRF's address space, not the global table.

Consider a PE router (PE1) serving two customers: Cust_A and Cust_B. Each customer connects via a dedicated interface. PE1 creates separate VRF instances for each customer. When Cust_A sends a packet into PE1, the router performs a lookup in the Cust_A routing table only. It never consults the Cust_B table or the global table. This separation ensures complete traffic isolation at Layer 3.

In a typical deployment, the traffic flow looks like this:

The CE router for Cust_A sends traffic to PE1 via interface Ethernet0/0.
PE1 receives the packet on an interface assigned to VRF Cust_A.
PE1 looks up the destination in the Cust_A routing table.
If the destination is reachable through another PE-facing interface in the same VRF, PE1 forwards accordingly.
The remote PE (PE2) delivers the traffic to the remote Cust_A CE router.

At no point does Cust_A traffic cross into Cust_B's routing domain.

VRF-Lite in Campus and Data Center Handoff

VRF-Lite plays a critical role in modern campus architectures. At the border of a fabric domain, VRF-Lite with EBGP peering provides the handoff mechanism between the fabric overlay and external networks. In campus environments migrating from traditional designs to BGP EVPN VXLAN overlays, VRF-Lite EBGP peering connects distribution-layer PE routers to the MPLS core or to new spine-border nodes.

A phased migration approach typically works as follows:

Phase 1: Isolate distribution switches and bring them up with VRF-Lite EBGP peering toward the existing MPLS core through a shim layer. EIGRP VPNv4 runs between the core routers, while OSPF operates in specific areas. Controlled mutual redistribution manages route exchange between domains.
Phase 2: Configure border-spine functionality on distribution switches for BGP EVPN VXLAN, extending the fabric overlay while maintaining VRF-Lite handoff at the border.

This staged approach allows networks to transition without disrupting existing services.

Interface Assignment Order

A critical operational detail when assigning an interface to a VRF: the vrf forwarding command must be applied to the interface before configuring the IP address. When you apply vrf forwarding Cust_A to an interface, any existing IP address on that interface is automatically removed. You must then re-apply the IP address after the VRF assignment.

The correct sequence under the interface is:

Enter interface configuration mode.
Apply vrf forwarding Cust_A.
Configure the IP address.

Reversing steps 2 and 3 results in the loss of the IP address without warning, which is a common mistake in lab and production environments alike.

Configuration Example

Configuring VRF-Lite for Customer A on PE1

The following configuration creates a VRF for Cust_A using the address-family aware syntax and assigns interface Ethernet0/0 with IP address 10.10.1.1/30.

vrf definition Cust_A
 !
 address-family ipv4
 !
!
interface Ethernet0/0
 description Cust_A
 vrf forwarding Cust_A
 ip address 10.10.1.1 255.255.255.252

Let us break down each element:

vrf definition Cust_A creates the VRF instance using the modern syntax that supports both IPv4 and IPv6.
address-family ipv4 enables IPv4 routing within this VRF. Without this statement, the VRF will not handle IPv4 traffic.
vrf forwarding Cust_A assigns the interface to the Cust_A VRF. Note that this uses vrf forwarding (not ip vrf forwarding, which is the legacy syntax).
ip address 10.10.1.1 255.255.255.252 assigns the IP address after the VRF assignment, following the required order of operations.

Best Practice: Always configure vrf forwarding before the ip address command on the interface. Applying VRF forwarding to an interface that already has an IP address will remove the address silently.

Verification Commands

To verify VRF configuration and routing table isolation, use the following commands:

show vrf

This displays all configured VRF instances and their associated interfaces and address families.

show ip route vrf Cust_A

This shows the routing table specific to the Cust_A VRF. You will see only routes that belong to this VRF instance, including connected, static, and any dynamically learned routes.

show ip interface brief | include Ethernet0/0

This confirms the interface status and IP address assignment within the VRF context.

Policy-Based Routing for Traffic Steering

When you need to direct specific customer traffic to a preferred next-hop regardless of the routing table, policy-based routing (PBR) provides the solution. The following configuration directs traffic from the 10.10.10.0/24 network (premium customers) toward ISP1 at next-hop 10.10.34.1:

access-list 1 permit ip 10.10.10.0 255.255.255.0
!
interface e0/0
 ip policy route-map premium_cust
!
route-map premium_cust permit 10
 match ip address 1
 set ip default next-hop 10.10.34.1
!
ip route 172.16.1.0 255.255.255.0 10.10.35.1
ip route 0.0.0.0 255.255.255.0 10.10.35.1

Key details in this configuration:

access-list 1 identifies the premium customer traffic (10.10.10.0/24).
ip policy route-map premium_cust applies the policy to inbound traffic on interface e0/0.
set ip default next-hop 10.10.34.1 sends matched traffic to ISP1. The keyword default is critical here: it means the policy only applies when there is no explicit route for the destination in the routing table. If a specific route exists, normal routing takes precedence.
The static routes point other traffic toward 10.10.35.1 (ISP2), ensuring a fallback path.

Note: The difference between set ip next-hop and set ip default next-hop is significant. Using set ip next-hop overrides the routing table unconditionally, while set ip default next-hop only applies when no explicit route exists for the destination.

Real-World Application

Multi-Tenant Campus Networks

VRF-Lite is widely deployed in campus environments where different departments, tenants, or security zones require traffic isolation on shared physical infrastructure. A university, for example, might use VRF-Lite to separate student, faculty, and administrative traffic across the same distribution and core switches.

Healthcare Network Segmentation

In healthcare environments, VRF-Lite with EBGP peering provides the isolation required between clinical networks, medical device networks, and guest access. The phased migration approach from traditional EIGRP/OSPF campus designs to BGP EVPN VXLAN fabrics relies heavily on VRF-Lite at the border for controlled route exchange during transition periods. Distribution switches acting as PE routers maintain VRF-Lite EBGP peering toward the MPLS core while new spine-border nodes are brought online.

SD-Access Fabric Border Handoff

In SD-Access deployments using BGP EVPN, VRF-Lite serves as the handoff mechanism at spine-border or border group nodes. The border node uses VRF-Lite to extend tenant segmentation from the fabric overlay into external networks or shared services blocks. This allows the fabric to maintain end-to-end segmentation while connecting to traditional network segments.

Design Considerations

Use the address-family aware vrf definition syntax for all new deployments to support dual-stack IPv4/IPv6.
Plan your route distinguisher (RD) values carefully if the VRF-Lite deployment will later integrate with an MPLS VPNv4 backbone.
When combining VRF-Lite with PBR, test failover behavior thoroughly. Ensure that the set ip default next-hop behavior aligns with your redundancy design.
Document VRF-to-interface mappings clearly, as troubleshooting VRF issues often starts with verifying which interfaces belong to which VRF.

Summary

VRF-Lite provides Layer 3 traffic isolation on a single router without requiring MPLS, making it essential for multi-tenant and segmented campus networks.
The address-family aware syntax (vrf definition with address-family ipv4/ipv6) is required for modern deployments and must include the address-family declaration to function properly.
The vrf forwarding command must be applied to an interface before the IP address, as assigning a VRF removes any existing IP configuration from the interface.
Policy-based routing complements VRF-Lite by enabling traffic steering based on source addresses, with set ip default next-hop providing conditional forwarding only when no explicit route exists.
VRF-Lite with EBGP peering is the standard handoff mechanism at fabric borders in SD-Access and BGP EVPN VXLAN campus architectures.

Next, continue to the following lesson where we build on these VRF concepts by exploring route redistribution and mutual distribution control between routing domains.