In the previous blog post on this topic, I described how node and global VRFs work in netlab.

TL&DR: If you use the same VRF on multiple devices, it’s better to define it globally.

However, you might not need every VRF on every lab device in a more complex lab topology. Considering that, netlab tries to minimize the number of VRFs configured on lab devices using a simple rule: a VRF is configured on a lab device only if the device has at least one interface in that VRF.

Simple Scenarios

Let’s start with the simplest scenario: two PE routers using a single VRF¹.

provider: clab
module: [ vrf, bgp, mpls, ospf ]
bgp.as: 65000
mpls.vpn: True

vrfs:
  red:
    links: [ r1-h1, r2-h2 ]

nodes:
  r1:
    device: frr
  r2:
    device: frr
  h1:
    device: linux
  h2:
    device: linux

links: [ r1-r2 ]

Each PE router has an interface in VRF red (the link to the attached host). Red VRF is thus configured on both routers.

What about a more complex topology with inter-VRF route leaking?

provider: clab
module: [ vrf, bgp, mpls, ospf ]
bgp.as: 65000
mpls.vpn: True

vrfs:
  red:
    links: [ r1-h1 ]
    import: [ red, blue ]
  blue:
    links: [ r2-h2 ]
    import: [ red, blue ]

nodes:
  r1:
    device: frr
  r2:
    device: frr
  h1:
    device: linux
  h2:
    device: linux

links: [ r1-r2 ]

There’s no need to configure the red VRF on R2 or the blue VRF on R1, and that’s precisely what netlab does. The instantiate the VRF if it has an interface rule works as expected.

Loopback-Only VRFs

Sometimes, you’d like to check the PE-to-PE VRF connectivity without adding external devices to the lab topology. That is no problem; netlab can add loopback interfaces to VRFs. You can create VRF loopbacks with loopback links² or set the vrf.loopback parameter to automatically create loopback interfaces in all- or in the specified VRFs.

The simplest way to build a loopback-only-VRF topology is to set the loopback parameter in a VRF definition on every node:

provider: clab
defaults.device: frr

module: [ vrf, bgp, mpls, ospf ]
bgp.as: 65000
mpls.vpn: True

vrfs:
  red:

nodes:
  r1:
    vrfs.red.loopback: True
  r2:
    vrfs.red.loopback: True

links: [ r1-r2 ]

Pushing the Limits

Can we simplify the above topology? We could set the vrf.loopback global parameter and hope for the best, but that wouldn’t work. netlab would decide the red VRF has no interfaces on any of the nodes, find no reason to use the global VRF definition on any node, and consequently not configure the red VRF.

The minimum you must do is to mention the VRF in the node definition. That mention would (combined with the global vrf.loopback parameter) trigger the creation of a loopback interface in the VRF, giving netlab a reason to instantiate and configure it.

provider: clab
defaults.device: frr

module: [ vrf, bgp, mpls, ospf ]
bgp.as: 65000
mpls.vpn: True

vrf.loopback: True

vrfs:
  red:

nodes:
  r1:
    vrfs.red:
  r2:
    vrfs.red:

links: [ r1-r2 ]

Want to make the topology a bit more cryptic? Let’s move the these nodes use red VRF definition into a group:

provider: clab
defaults.device: frr

module: [ vrf, bgp, mpls, ospf ]
bgp.as: 65000
mpls.vpn: True

vrf.loopback: True

vrfs:
  red:

groups:
  red_group:
    members: [ r1, r2 ]
    vrfs.red:

nodes: [ r1, r2 ]

links: [ r1-r2 ]