L3 Virtualization and VRFs

I got into an interesting discussion with Johannes Luther on the need for VRFs and he wrote:

If VRF = L3 virtualization technologies, then I saw that link. However, VRFs are again just a tiny piece of the whole story.

Of course he’s right, but it turns out that VRFs are the fundamental building block of most L3 virtualization technologies using a shared infrastructure.

The Basics

Each L3 virtualization technology must implement numerous separate (and optionally isolated) L3 domains (let’s call them tenants). Each tenant (= L3 domain) needs a forwarding table that could be different from any other L3 forwarding table in the system, just like you need a separate MAC table for each virtual L2 domain.

Whether the system uses a single L3 table and makes L3-domain-ID part of the lookup process is an implementation detail, just like some L2 switches use a single MAC lookup table and do lookups based on VLAN+MAC value.

You also need some way of populating that table, usually a routing protocol. Virtual Routing and Forwarding table (VRF) is thus a fundamental building block of every L3 virtualization technology regardless of how you call it.

Alternative Architectures

Obviously you could implement a distributed system where the routing (= collecting and distributing information) decisions are centralized, but forwarding (= sending received packets to correct output ports) decisions are distributed, so there would be a single copy of the tenant routing table and numerous copies of the tenant forwarding table.

You could also run isolated per-tenant control planes and push the results of these control planes to the forwarding tables. VMware NSX is a typical example of such architecture:

  • A dedicated routing VM is run for every tenant using a single routing table. Control-plane VM thus doesn’t use a VRF concept;
  • Routes collected by the control-plane VM are sent to the NSX controller and distributed to L3 forwarding elements in individual hypervisors where every tenant has its own virtual forwarding table.


  1. So ... most people outside networking look at L3 as a solution for NOT needing anything 'virtual' in the network. A single L3 domain with distributed firewalls and IP policy driven by code.
    1. Unless you can force your users to agree on a common IP address plan, using a single L3 domain might be difficult. I would claim that for a hosted environment, multiple L3 domains is a requirement. One can of course build such domains using 464-XLAT or similar.
Add comment