HomeGuides › VRFs

How VRFs, RDs and route targets fit together

A VRF gives one router several routing tables. Two of the three acronyms around it are constantly confused with each other.

Virtual Routing and Forwarding puts more than one routing table on a device. Interfaces are assigned to a VRF, and routes in one are invisible to the others. Two customers can both use 10.0.0.0/24 on the same router without ever meeting.

What a VRF gives you

Separation without separate hardware. It is how a service provider carries many customers over one network, and how an enterprise keeps a guest network, a building-management network and a card-payment environment genuinely apart rather than apart-by-firewall-rule.

Route distinguisher: uniqueness

When routes from many VRFs travel together in one BGP session, two customers' 10.0.0.0/24 routes would be indistinguishable. So each route is prefixed with a route distinguisher, making it 65000:100:10.0.0.0/24 — unique, and carryable alongside the other.

That is the whole job. An RD does not decide where a route goes. Two VRFs sharing an RD is a uniqueness problem, not a policy one.

Route target: policy

A route target decides which VRFs receive a route. Each VRF exports its routes tagged with one or more RTs, and imports any route carrying an RT on its import list.

Reachability is the intersection of those lists and nothing else. If VRF A imports 65000:200 and VRF B exports 65000:200, then A sees B's routes.

Why the confusion is expensive

Because people change an RD expecting traffic to change, and nothing happens. Or they assume matching RDs mean shared routes, and are surprised either way. The rule worth memorising: RD makes a route unique, RT decides who gets it.

Reachability is directional

In a hub-and-spoke design each spoke imports only the hub's target while the hub imports every spoke's. Spokes reach the hub, the hub reaches everything, spokes cannot reach each other. That asymmetry is usually the intention — and it is worth confirming rather than assuming, because the import and export lists that produce it are easy to get subtly wrong.

Overlapping address space between VRFs is safe precisely while the VRFs stay separate. The moment a route-target change lets them import from each other, the overlap becomes a routing problem — which is why a leak and an overlap are so often the same incident.

Frequently asked questions

What is the difference between an RD and an RT?

An RD makes a route unique when routes from many VRFs are carried together. An RT decides which VRFs import it. Only the RT affects reachability.

Can two VRFs use the same subnet?

Yes, and that is a large part of why VRFs exist. It stops being safe if the two VRFs are later allowed to import each other's routes.

Why can my spokes not reach each other?

Because each imports only the hub's route target, so spoke routes never reach another spoke. That is the standard hub-and-spoke behaviour and usually intentional.

Is a VRF a security boundary?

It is a routing separation, and a strong one. It is not a substitute for filtering — anything that deliberately joins two VRFs, such as a shared-services design, needs the same scrutiny as any other path between them.

Open the VRF planner →