Support for nexthop-vrf on static routes in the VyOS CLI

General questions
1

Hello,

In native FRR, it is possible to install a static route that uses nexthop-vrf directly on a VRF interface. In the example below, test-vrf is both the VRF name and the associated VRF interface:

vrf client-vrf
 ip route 0.0.0.0/0 test-vrf nexthop-vrf test-vrf

However, I can’t find an equivalent option in the VyOS CLI. The interface completion only lists physical interfaces, bonds, bridges, loopback, and veth interfaces, but not VRF interfaces.

Is there currently a supported way to configure this type of static route through the VyOS CLI without resorting to custom FRR configuration or veth interfaces?

If not, could support for nexthop-vrf on interface-based static routes be considered as a future enhancement to align the CLI with FRR’s native capabilities?

Thank you!

2

In the native FRR CLI (Debian 12), VRF interfaces are available in the interface completion list for static routes:

RTR(config-vrf)# vrf client-vrf
RTR(config-vrf)# ip route 0.0.0.0/0 ?
  A.B.C.D    IP gateway address
  INTERFACE  IP gateway interface name
     bond0 bond1 bond1.110 bond1.111 bond1.800 eno1 eno2 eno3 eno4
     client-vrf test-vrf enp4s0 enp5s0
  Null0      Null interface
  blackhole  Silently discard pkts when matched
  reject     Emit an ICMP unreachable when matched

As shown above, the VRF interfaces client-vrf and test-vrf are available as valid interface names, allowing them to be used together with the nexthop-vrf option.

My goal is to install a default route from one VRF into another using nexthop-vrf. This configuration works on Debian 12 with native FRR, but I can’t find an equivalent way to configure it in the VyOS CLI.

3

VyoS uses VRF-lite meaning it acts on the interface addresses along with a routing table connected to each interface. That is “proper” namespace separation is missing (if you compare VRF with how for example Arista EOS is doing this).

So Im thinking wouldnt something like this then work for you?

eth0: vrf: RED: 10.0.0.1/24
eth1: vrf: BLUE: 10.1.0.1/24

set vrf name RED protocols static route x.x.x.x/yy interface eth1

or:

set vrf name RED protocols static route x.x.x.x/yy next-hop <ip of BLUE>

Eventually you might need to add:

set vrf bind-to-all

At least in 2021 the syntax of defining a next-hop being vrf seems to have existed - dunno what happend to that:

4

Uhh, I didnt run the tab-complete far enough :slight_smile:

What about this one?

set vrf name RED protocols static route x.x.x.x/x interface eth1 vrf BLUE

Im guessing the idea is that a single route should have a single nexthop.

Doing nexthop-vrf is somewhat tricky since you can have more than one interface being part of a single VRF.

On the other hand thats a headache for FRR to take care of.

5

Thank you for the suggestions.

Unfortunately, these approaches do not fit my use case because the target VRF does not have any physical interfaces that can be referenced. The route needs to point directly to the VRF interface itself.

What I am trying to achieve is the same behavior that FRR provides through nexthop-vrf. In native FRR (via vtysh), VRF interfaces are exposed as valid interface names and can be used directly when creating a static route. For example, the interface completion includes VRF interfaces such as client-vrf and test-vrf, allowing configurations like:

ip route 0.0.0.0/0 test-vrf nexthop-vrf test-vrf

In VyOS, however, the CLI completion for static routes only exposes physical interfaces, bonds, bridges, loopbacks, and veth interfaces. VRF interfaces are not available as selectable interface names, even though FRR itself appears to support this functionality underneath.

My observation is that the limitation seems to be in the VyOS CLI abstraction rather than in FRR itself. If you check the underlying vtysh configuration, FRR allows referencing the VRF interface directly, while the VyOS CLI does not provide a way to express the same configuration.

Am I correct in understanding that there is currently no supported way in VyOS to configure a static route that uses a VRF interface together with nexthop-vrf, and that this would require either custom FRR configuration or additional workaround interfaces?

6

I think the current solution is to use:

set vrf name RED protocols static route x.x.x.x/x interface eth1 vrf BLUE

And to me it sounds a bit odd to have VRFs but no interfaces attached to them.

A workaround could perhaps be to create also a loopback interface and attach that to vrf BLUE and then use next-hop [ip] instead of interface [dev]?

Like so:

set interfaces dummy dum0 address 192.0.2.0/32
set interfaces dummy dum0 vrf RED
set interfaces dummy dum1 address 192.0.2.1/32
set interfaces dummy dum1 vrf BLUE
set vrf name RED protocols static route x.x.x.x/x next-hop 192.0.2.1 vrf BLUE

If above workaround works then you could file a feature-request over at https://vyos.dev that you want vrf (without interface configured for that vrf) to be able to be set when there is no IP-address configured on the device as nexthop interface like so:

set vrf name RED protocols static route 0.0.0.0/0 interface BLUE
7

Thanks for the suggestion.

Unfortunately, the dummy interface approach didn’t work in my case.

What did work was creating a pair of virtual Ethernet (veth) interfaces:

set interfaces virtual-ethernet veth0 address '192.0.2.0/31'
set interfaces virtual-ethernet veth0 peer-name 'veth1'
set interfaces virtual-ethernet veth1 vrf 'RED'

set interfaces virtual-ethernet veth1 address '192.0.2.1/31'
set interfaces virtual-ethernet veth1 peer-name 'veth0'
set interfaces virtual-ethernet veth1 vrf 'BLUE'

set vrf name RED protocols static route 0.0.0.0/0 next-hop 192.0.2.1

So this provides a working workaround.

That said, I still think the FRRouting implementation is a much cleaner solution because it doesn’t require creating additional interfaces or assigning IP addresses just to reference another VRF. For example:

ip link add RED type vrf table 10
ip link add BLUE type vrf table 20

vtysh:

vrf RED
 ip route 0.0.0.0/0 BLUE nexthop-vrf BLUE

In my opinion, this is simpler and more elegant than creating a pair of veth interfaces solely to satisfy the routing configuration.

8

I removed the veth interfaces from VyOS and entered the following commands directly in vtysh:

vrf RED
 ip route 0.0.0.0/0 BLUE nexthop-vrf BLUE

This worked exactly as I wanted. The default route in VRF RED was successfully installed using VRF BLUE as the next-hop VRF, without any veth interfaces or interconnecting IP addresses.

So it seems that FRRouting itself supports this configuration correctly, but the current VyOS CLI does not expose this functionality.

9
10

You mentioned that you couldnt use `next-hop x.x.x.x vrf BLUE` because you dont currently have any physical or virtual interface configured for that VRF (before you figured out veth as a workaround).

What is the usecase when you have VRF-lite with a routingtable but no physical or virtual interface connected to this VRF?

Is it like you want eth0 to be part of both VRF RED and BLUE at the same time but not YELLOW and by that for some routes eth0 should use VRF RED routingtable and for some other routes it should use VRF BLUE routingtable?

11

Thanks for the question. Let me explain the actual use case in a bit more detail.

I have two VRFs:

  • RED - a customer VRF.

  • BLUE - an upstream VRF.

The BLUE VRF contains multiple VLAN interfaces (for example bond0.100, bond0.101, etc.), each connected to a different upstream provider. Several Full View BGP sessions are established in this VRF, so BLUE contains the complete Internet routing table.

My goal is simply to make the customer VRF (RED) use BLUE as its default gateway.

Initially, I considered using L2VPN route leaking between the VRFs. However, since BLUE contains around one million routes, importing even a single route from BLUE into RED takes approximately three minutes during every commit. That makes this approach impractical.

The next logical solution was to install a static default route from RED into BLUE. Native FRRouting already provides exactly this functionality:

vrf RED
 ip route 0.0.0.0/0 BLUE nexthop-vrf BLUE

This works perfectly because the route points to the VRF itself, not to any particular interface inside that VRF.

The suggestion to use something like:

set vrf name RED protocols static route 0.0.0.0/0 interface bond0.100 vrf BLUE

would technically work, but it introduces an unnecessary dependency on a specific VLAN interface.

Today the default route might use bond0.100, but tomorrow that VLAN may be removed, replaced, or migrated to another uplink. In that case, the static route would also need to be modified, causing unnecessary configuration changes and potentially interrupting connectivity.

From my perspective, the default route should depend only on the existence of the BLUE VRF, not on which interfaces currently belong to it. The interfaces inside BLUE are implementation details and may change over time, while the VRF itself remains the routing domain that should be used.

This is exactly how FRRouting already behaves. I verified it by configuring the route directly in vtysh on VyOS:

vrf RED
 ip route 0.0.0.0/0 BLUE nexthop-vrf BLUE

The route is installed correctly and works exactly as expected, without any veth interfaces or interconnecting IP addresses.

Because of that, it appears that the limitation is not in FRRouting itself, but in the current VyOS CLI, which does not expose the existing nexthop-vrf functionality.

For this reason, I think it would be valuable if the VyOS CLI could support configuring a static route directly toward a VRF interface, matching FRRouting’s native capabilities.

12

If the community thinks this would be a useful feature, I believe exposing FRRouting’s existing nexthop-vrf capability through the VyOS configuration would provide a cleaner and more maintainable solution than relying on veth-based workarounds. Since this functionality already exists in FRRouting, it seems that only CLI support in VyOS is missing. I’d be happy to test it and provide feedback if such support were ever added.