VRFs¶
VRF (Virtual Routing and Forwarding) is a form of software-defined routing that allows multiple routing tables to exist within the same router. The following page explains how VRFs are integrated in SD-WAN.
Note
For the purposes of the SD-WAN software and documentation, “VRF” or “VRFs” refers to the logical structures that SD-WAN uses to implement virtual routing and forwarding, and not the concept of VRF itself.
![graph {
rankdir=TB;
newrank=true;
fontname="Arial";
splines=ortho;
bgcolor="transparent";
nodesep=0.75;
ranksep=0.75;
node [
shape=box,
style="filled,rounded",
fontname="Arial",
fontsize=12
];
edge [
penwidth=1.5,
fontname="Arial",
fontsize=10
];
lan2_global [label="LAN: 10.1.2.0/24", fillcolor="#FFFFFF", color="#666666"];
lan2_red [label="LAN: 10.2.2.0/24", fillcolor="#FFE0E0", color="#C0392B"];
subgraph cluster_node_beta {
label=" Node: Beta";
labelloc="t";
style="filled,rounded";
fillcolor="#E9F7EF";
color="#1E8449";
beta_global [label="eth0\nVRF Global", fillcolor="#FFFFFF", color="#666666"];
beta_red [label="eth1\nVRF Red", fillcolor="#FFE0E0", color="#C0392B"];
beta_no_vrf [label="eth2\nNo VRF"];
peer2 [label="Peer Connection\n(Tunnel)", fillcolor="#FEF9E7", color="#F1C40F"];
}
subgraph cluster_node_alpha {
label="Node: Alpha ";
labelloc="b";
style="filled,rounded";
fillcolor="#E9F7EF";
color="#1E8449";
alpha_global [label="eth2\nVRF Global", fillcolor="#FFFFFF", color="#666666"];
alpha_no_vrf [label="eth0\nNo VRF"];
alpha_red [label="eth1\nVRF Red", fillcolor="#FFE0E0", color="#C0392B"];
peer1 [label="Peer Connection\n(Tunnel)", fillcolor="#FEF9E7", color="#F1C40F"];
}
lan1_global [label="LAN: 10.1.1.0/24", fillcolor="#FFFFFF", color="#666666"];
lan1_red [label="LAN: 10.2.1.0/24", fillcolor="#FFE0E0", color="#C0392B"];
beta_red -- beta_global;
lan2_red -- beta_red [color="#C0392B"];
beta_no_vrf -- peer2;
peer2 -- peer1 [style=invis];
peer2 -- peer1 [color="#F1C40F"];
peer2 -- peer1 [color="#F1C40F"];
peer2 -- peer1 [labelangle=65, labeldistance=6.5, taillabel="Encapsulated Traffic\n(All VRFs)", color="#F1C40F"];
peer2 -- peer1 [style=invis];
peer1 -- alpha_no_vrf [labelangle=90, labeldistance=14, headlabel="If the interface\nhas no VRF,\ntraffic can be\nforwarded but\nnot routed"];
alpha_red -- lan1_red [color="#C0392B"];
alpha_global -- alpha_red;
{ rank=same; beta_red -- beta_no_vrf }
{ rank=same; lan2_global -- beta_global [color="#666666"] }
{ rank=same; beta_global -- peer2 [style=invis] }
{ rank=same; peer1 -- alpha_global [style=invis] }
{ rank=same; alpha_global -- lan1_global [color="#666666"] }
{ rank=same; alpha_no_vrf -- alpha_red }
}](../../../_images/graphviz-4139c547eafb5d2cf8f1290c8feaf7cff3caa352.png)
VRFs are assigned to interfaces. Traffic entering an interface uses the routing table of the VRF assigned to that interface. If an interface has no VRF assigned to it, traffic enters ephemeral, local-only tables. Such interfaces can establish tunnels and forward client traffic (e.g., for peer connections), but cannot route client traffic.
A global VRF is available by default which is intended to be used for public routing. Fundamentally, this traffic is treated the same as traffic on any private VRF. Furthermore, peers are VRF-agnostic, capable of forwarding traffic for the global VRF and any number of private VRFs through the same tunnel interface, while maintaining strict routing separation between them.
Network prefixes do not need to be unique across VRFs. For example, you can
have separate routes for the same prefix (e.g., 10.1.1.0/24) on multiple
VRFs with different nexthops. The routes will in turn be applied according to
the VRFs of the incoming packets, or the VRF overlay IDs of encapsulated
packets if the traffic is coming from a peer.
Routes must always have a VRF assigned to them. See the route documentation for more information on implementing routes.