Virtual Routing and Forwarding (VRF) Tables

This configuration module implements the VRF planning and configuration logic and is used together with BGP, OSPF, and IS-IS configuration modules to implement VRF-aware routing protocols.

Platform Support

VRFs are supported on these platforms:

Operating system






Arista EOS

Aruba AOS-CX

Cisco IOS

Cisco IOS XE

Cisco Nexus OS

Cumulus Linux

Cumulus NVUE

Dell OS10


Juniper vMX

Juniper vPTX

Juniper vSRX 3.0

Mikrotik RouterOS 6

Mikrotik RouterOS 7

SR Linux



  • IS-IS and EIGRP cannot be run within a VRF, but both configuration modules are VRF-aware – they will not try to configure IS-IS or EIGRP routing on VRF interfaces

  • IBGP within a VRF instance does not work. PE-routers and CE-routers MUST HAVE different BGP AS numbers

  • On Mikrotik RouterOS BGP configuration/implementation, a BGP VRF instance cannot have the same Router ID of the default one. The current configuration template uses the IP Address of the last interface in the VRF as instance Router ID.

  • On SR Linux, route leaking is supported only in combination with BGP EVPN


The following parameters can be set globally or per node:

  • vrfs: A dictionary of VRF definitions (see below)

  • vrf.loopback (bool): Create loopback interfaces for all VRFs on this node

  • The default AS number used in RD/RT values when is not set. The system default for is 65000.

VRF Definition

VRFs are defined in a global- or node-specific vrfs dictionary, allowing you to create VRFs that are used network-wide or VRFs that are used only on a single node.


Do not reuse VRF names when defining node-specific VRFs. There’s a subtle interaction between global- and node-specific VRFs needed to implement complex VPN topologies.

The keys of the vrfs dictionary are VRF names, the values are VRF definitions. A VRF definition could be empty or a dictionary with one or more of these attributes:

  • rd – route distinguisher (integer or string)

  • import – a list of import route targets

  • export – a list of export route targets

  • loopback (bool or prefix) – Create a loopback interface for this VRF.

  • links - a list of links within this VRF.

  • A VRF definition can also contain other link- or interface-level parameters (for example, OSPF cost).

Empty VRF definition will get default RD and RT values assigned during the topology transformation process.

Additional VRF Parameters

You can also set these parameters to influence routing protocols running within a VRF.

  • – start an OSPF instance within a VRF even when there are no viable OSPF neighbors on VRF interfaces

  • ospf.area – default OSPF area for VRF OSPF process (default: node ospf.area). This area is configured on OSPF loopback interfaces.

  • bgp.router_id – per-VRF BGP router ID. Needed for inter-VRF EBGP sessions configured between interfaces of the same device.[1]

  • ospf.router_id – per-VRF OSPF router ID. Probably needed for the same reasons as bgp.router_id.

Creating VRF Loopback Interfaces

A loopback interface is created for a VRF whenever you set the or vrf.loopback global or node parameter.

loopback parameter in a VRF definition could be:

  • A boolean value – the address of the loopback interface will be allocated from the vrf_loopback address pool

  • A string specifying the IPv4 prefix of the loopback interface

  • A dictionary of address families specifying IPv4 and/or IPv6 prefixes to be used on the loopback interface


The explicit IPv4/IPv6 loopback addresses should not be used in the global VRF definition. Use them only in node VRF definition.

RD and RT Values

A route distinguisher could be specified in N:N format (example: 65000:1) or as an integer. AS number specified in or will be prepended to an integer RD-value to generate RD value in N:N format.

import and export route targets could be specified as a single value or as a list of values. Each RT value could be an integer (see above), a string in N:N format, or a VRF name. When using a VRF name as an RT value, the VRF RD is used as the route target.

For example, to implement a common services VPN giving red and blue VRFs access to common VRF, use these VRF definitions:

    import: [ red, common ]
    export: [ red ]
    import: [ blue, common ]
    export: [ blue ]
    import: [ common, red, blue ]
    export: [ common ]

Default RD/RT Values

The following default values are used in VRF definitions missing rd, import or export values (including the corner case of empty VRF definition):

  • VRFs specified in nodes inherit missing parameters from the global VRFs with the same name

  • When the rd is missing, it’s assigned a unique value using or value as the high-end of the RD value

  • Missing import and export route targets become a list with the VRF RD being the sole element.

For example, defining a simple VRF red


… results in the following data structure:

    - '65000:1'
    - '65000:1'
    rd: '65000:1'

When using an empty rd value in a node VRF, the rd will be auto-generated, while the import and export route targets will be inherited from the global VRF definition.

For example, defining a red VRF with node-specific RD…


  r1: 65001

… results in the following (VRF-related) data structures:

    - '65000:1'
    - '65000:1'
    rd: '65000:1'

        - '65000:1'
        - '65000:1'
        rd: '65001:2'


  • Global RD/RT values are generated using the system default value (65000).

  • Global RT values for the red VRF are copied into the node data structures. Global RD value is not copied because it’s set in the node VRF definition.

  • Node RD value for the red VRF is generated using the node value (65001).

Interaction with Routing Protocols

BGP, OSPF, and IS-IS configuration modules are VRF aware:

  • VRF interfaces are removed from the IS-IS routing process

  • VRF interfaces that should be part of an OSPF routing process are moved into VRF-specific data structures that are then used to create VRF-specific OSPF instances.

  • EBGP neighbors discovered on VRF interfaces are moved into VRF-specific data structures and used to configure BGP neighbors with a BGP VRF address family.


  • VRF OSPF instances are created only in VRFs that have neighbors using ospf configuration module. To create an OSPF instance in a VRF that would need OSPF based on the lab topology, set node VRF parameter to True.

  • VRF-specific OSPF and BGP configuration is included in the VRF configuration templates.

  • Connected subnets are always redistributed into the BGP VRF address family.

  • If a node has parameter and VRF-specific OSPF instance(s), the VRF configuration templates configure two-way redistribution between VRF-specific OSPF instances and BGP VRF address family.

Creating VRF OSPF Instances

Assume that we want to have OSPF instance in the brown VRF, but the only link in the VRF is a stub link, so the OSPF instance would not be created with default settings. Setting parameter in nodes.r3.vrfs.brown forces the creation of VRF OSPF instance.

    module: [ vrf,ospf ]
      brown: True

- r3:
    vrf: brown


You’ll find a half-dozen examples in the Defining and Using VRFs tutorial.