Cisco IOS VRF Lite Configuration Guide

A router normally maintains a single global routing table shared by every interface. VRF (Virtual Routing and Forwarding) breaks that assumption: each VRF gets its own fully independent routing and forwarding table, invisible to the global table and to every other VRF. VRF lite is the plain-IP version of this technology - no MPLS, no MP-BGP - used on a single router or a chain of routers to keep customer A and customer B completely separate, even when they use overlapping IP space. This guide walks through VRF definition, interface binding, per-VRF static routing and the verification commands, including the interface-assignment pitfall that clears your IP address.

VRF Lite vs MPLS L3VPN

How VRF Separation Actually Works

Every VRF owns a separate RIB and a separate FIB. Inside a VRF, a router behaves exactly as it would in the global table: connected routes appear as interfaces are bound, static routes are added, and a routing protocol instance can run there. What changes is that routes from one VRF are never installed into another, and an inbound packet is only looked up in the table its ingress interface belongs to.

That last point is the whole security model. A packet arriving on an interface in CUSTOMER-A is looked up only in CUSTOMER-A's FIB. Even if CUSTOMER-B's interface is reachable from a purely physical standpoint, there is no route to it from within CUSTOMER-A, so traffic simply cannot cross. Two customers can both use 10.0.0.0/24 and neither will ever see the other's hosts.

What VRF lite deliberately does not require: route distinguishers, route targets, MP-BGP, labelled forwarding, or any coordination with a provider core. Those exist in MPLS L3VPN to carry VRF context between routers over a shared backbone. On a single router — or a chain where each hop is configured independently — plain interface binding is enough. The trade-off is operational: every router in the chain needs the same VRF definitions and per-VRF routing, and there is no protocol automatically exchanging routes between them.

Step 1: Define the VRF

Classic IOS uses ip vrf; newer IOS XE supports the vrf definition form with explicit address families. Both are shown:

Router(config)# ip vrf CUSTOMER-A
Router(config-vrf)# description Customer A routing domain
Router(config-vrf)# exit

! IOS XE modern syntax
Router(config)# vrf definition CUSTOMER-A
Router(config-vrf)# address-family ipv4
Router(config-vrf-af)# exit-address-family

Prefer vrf definition on any platform that supports it. It is the syntax that carries forward, it supports IPv4 and IPv6 in the same VRF with explicit address families, and it is what ip vrf is translated into internally. The legacy ip vrf form still works and is what you will find in most existing customer configurations, so know both.

Step 2: Assign an Interface to the VRF

Critical: ip vrf forwarding must come BEFORE ip address, because binding an interface to a VRF clears any IP address already configured on it:

Router(config)# interface GigabitEthernet0/0
Router(config-if)# ip vrf forwarding CUSTOMER-A
Router(config-if)# ip address 10.0.0.1 255.255.255.0

Overlapping addresses between customers are now legal, because each VRF is an isolated table: both CUSTOMER-A and CUSTOMER-B can use 10.0.0.0/24 on their own interfaces.

The order matters enough to repeat: if you reverse those two lines, IOS prints a message telling you the address was removed, and the interface silently ends up with no IP. In a change window that looks like an outage with no obvious cause. Always verify with show ip interface brief after binding an interface that already carried an address.

Step 3: Add Routes Inside the VRF

Static routes, routing protocols and even ping must name the VRF explicitly:

Router(config)# ip route vrf CUSTOMER-A 0.0.0.0 0.0.0.0 203.0.113.1
Router(config)# router ospf 100 vrf CUSTOMER-A
Router# ping vrf CUSTOMER-A 10.0.0.2

Note the pattern: the VRF name is a keyword on almost every command that touches routing. The same applies to traceroute vrf, telnet vrf, copy from a VRF-sourced TFTP server, and ip route vrf for every static route. If a command seems to work but reaches nothing, the missing VRF keyword is the first thing to check.

Per-VRF Routing Protocols

Running a routing protocol inside a VRF is a one-line change on IOS — the process number is still global, but the instance is bound to the VRF:

Router(config)# router eigrp CUSTOMER-A
Router(config-router)# address-family ipv4 vrf CUSTOMER-A autonomous-system 100

Router(config)# router bgp 65001
Router(config-router)# address-family ipv4 vrf CUSTOMER-A
Router(config-router-af)# neighbor 203.0.113.9 remote-as 65002

The EIGRP configuration above is the modern named mode; the classic form is router eigrp 100 followed by address-family ipv4 vrf CUSTOMER-A. For OSPF the process is per-VRF as shown earlier (router ospf 100 vrf CUSTOMER-A), and a single physical router can run several OSPF processes, one per customer, with no interaction between them.

Each protocol instance has its own neighbours, its own database, and its own timers. That isolation is the point — and it is also why a loopback in the global table is not reachable from inside a VRF without an explicit route.

Verifying VRFs

Router# show ip vrf
Router# show ip route vrf CUSTOMER-A
Router# show ip vrf interfaces
Router# show ip vrf interfaces CUSTOMER-A

show ip vrf lists every VRF and the interfaces bound to it; show ip route vrf displays only that VRF's routing table. With all interfaces inside VRFs, the global table's connected routes disappear - that is normal, and it is exactly why the management interface is usually left in the global table.

Reading the output of show ip vrf:

• Name — the VRF label. Spaces are allowed but make every command harder to type; use hyphens.
• Default RD — auto-generated even in VRF lite. It is harmless and can be ignored.
• Protocols — which address families are active in the VRF, e.g. ipv4 for a legacy ip vrf definition.
• Interfaces — every interface bound to that VRF. An empty list means the VRF exists but nothing is using it.

Management Access and the Global Table

The management interface is normally left in the global table, and that creates a practical problem: an SSH session arriving on the global table cannot be answered if the return path lives in a VRF. Two things fix it.

! Source management traffic from a global interface
Router(config)# ip tftp source-interface GigabitEthernet0/1

! Or move management into its own VRF and tag the source
Router(config)# interface GigabitEthernet0/0.100
Router(config-subif)# encapsulation dot1Q 100
Router(config-subif)# ip vrf forwarding MGMT
Router(config-subif)# ip address 192.0.2.10 255.255.255.0

Router(config)# ip route vrf MGMT 0.0.0.0 0.0.0.0 192.0.2.1
Router(config)# ip ssh source-interface GigabitEthernet0/0.100

For AAA and syslog, remember that the source address the router uses depends on the VRF the traffic is sent from. If your RADIUS server has an ACL keyed on the loopback address, add that loopback to the server-side ACL for every VRF that needs to authenticate.

Common Pitfalls

• Binding clears the IP address — covered above, and by far the most common mistake.
• Missing VRF keyword on a command — ping, traceroute, show ip route and static routes all need it.
• No route between VRFs — by design. If CUSTOMER-A must reach a shared service, you need route leaking, a shared services VRF, or a firewall; there is no implicit path.
• DHCP relay inside a VRF — ip helper-address vrf MGMT 192.0.2.5 is required when the DHCP server is reachable only from another table.
• NAT and VRF — NAT inside/outside interfaces must be in the same VRF, or use ip nat inside source ... vrf where supported.
• NetFlow and SNMP — per-VRF collections only work if the exporter is reachable from that VRF.

Route Leaking Between VRFs

Sometimes isolation is too effective: a management VRF needs to reach an NTP server in the global table, or two customer VRFs must both reach a shared DNS anycast address. IOS offers a blunt but workable tool for this — static route leaking.

! Reach the global table from inside the VRF
Router(config)# ip route vrf MGMT 192.0.2.0 255.255.255.0 10.10.10.1 global

! Reach the VRF from the global table
Router(config)# ip route 10.20.20.0 255.255.255.0 Vlan100 10.10.10.2

The global keyword tells IOS to resolve the next hop in the global routing table instead of inside MGMT. The return direction needs a static route whose next hop lives inside the VRF. Both directions are required — a one-way leak looks like an intermittent failure, because requests leave and replies never come back, and the failure appears only for the specific host pairs involved.

Route leaking is not a routing protocol and it does not scale. It creates a dependency that nothing can reconverge: if the leaked path fails, the static route sits in the table until someone removes it. For anything beyond a handful of prefixes, use a shared-services VRF with MP-BGP and route targets, or push the inter-VRF policy to a firewall where it can be logged and audited. Leaking also has a security consequence worth stating plainly — it opens a path between two domains that were separate by construction, and every leaked prefix becomes reachable from a table that previously had no route to it at all.

Use Cases

• Multi-tenant CPE and aggregation routers with overlapping customer addressing.
• Separating production, management and guest traffic on one router.
• Lab replication of MPLS VPN designs without the MPLS core.
• Segregating an out-of-band management network from in-band traffic, so a routing failure cannot take out your only way in.

Related articles: Linux network namespaces (the Linux equivalent of VRF separation) and Dell OS10 out-of-band management VRF. For the MPLS side of the same concept, see Cisco MPLS VPN troubleshooting: VRF, BGP and labels, and plan your overlapping address space with NetBox IPAM: prefixes, VLANs and IP addresses.

原文链接：https://networklessons.com/mpls/vrf-lite-configuration-on-cisco-ios