Summary

Add support for propagating VyOS interface VRF assignment to VPP dataplane FIB tables for LCP-managed interfaces.

Currently, when a VPP/LCP-managed interface or Ethernet VIF is assigned to a VyOS VRF, the Linux/control-plane state is updated correctly, but the corresponding VPP interface remains bound to the default IPv4 FIB table 0.

Example configuration:

vyos
set vpp settings interface eth1
set vrf name mgmt table 1000
set interfaces ethernet eth1 vif 20 address 100.100.100.1/24
set interfaces ethernet eth1 vif 20 vrf mgmt

Linux state is correct:

ip a show master mgmt

shows eth1.20 as a member of VRF mgmt.

However, in VPP the connected route remains in the default table:

vppctl show ip fib | grep 100.100.100

while the expected table is empty:

vppctl show ip fib table 1000 | grep 100.100.100

VPP already has the FIB table:

vppctl show ip table

shows:

text
table_id:1000 ipv4-VRF:1000

The missing part appears to be binding the VPP interface to the corresponding FIB table, similar to:

text
sw_interface_set_table(sw_if_index=<eth1.20>, is_ipv6=False, vrf_id=1000)

Use case

VRF separation is commonly used for management, tenant separation, routing isolation, and multi-table forwarding. VyOS already supports VRF configuration in the regular Linux dataplane, and VPP supports multiple IPv4/IPv6 FIB tables.

When using the VPP dataplane, users expect this VyOS configuration:

vyos
set interfaces ethernet eth1 vif 20 vrf mgmt

to place both the Linux/LCP interface and the corresponding VPP dataplane interface into the same routing table.

This is especially important for management VRF scenarios, where SSH, routing, and connected interfaces must be isolated from the default routing table.

Additional information

Observed behavior:

vyos
set vrf name mgmt table 1000
set interfaces ethernet eth1 vif 20 address 100.100.100.1/24
set interfaces ethernet eth1 vif 20 vrf mgmt
commit

Linux/control-plane result:

ip a show master mgmt

Correctly shows:

text
eth1.20 master mgmt
inet 100.100.100.1/24

VPP result:

vppctl show ip fib table 1000 | grep 100.100.100

No output.

But:

vppctl show ip fib | grep 100.100.100

shows the connected routes in the default VPP table:

text
100.100.100.0/24 ... eth1.20
100.100.100.1/32 ... eth1.20

A lab proof-of-concept confirmed that calling VPP PAPI sw_interface_set_table() for the affected interface moves the interface to the correct VPP FIB table. After this, LCP can recreate the connected routes in the correct table.

However, the implementation must be careful when changing or deleting VRF assignment. Simply deleting all VPP interface addresses, changing the table, and relying on lcp_resync() is not sufficient in all cases. In one lab test, deleting the VRF assignment caused the address to remain in Linux but disappear from VPP. A proper implementation should preserve and restore interface addresses when moving an interface between VPP FIB tables.

Expected behavior:

1. Add VRF to VPP-managed VIF:

vyos
set interfaces ethernet eth1 vif 20 vrf mgmt
commit

Expected VPP state:

vppctl show ip fib table 1000 | grep 100.100.100

should show connected routes for 100.100.100.0/24 and 100.100.100.1/32.

2. Delete VRF from VPP-managed VIF:

vyos
delete interfaces ethernet eth1 vif 20 vrf
commit

Expected VPP state:

vppctl show ip fib table 0 | grep 100.100.100

should show the connected routes again in the default table. The address must not disappear from VPP.

3. Change VRF:

vyos
set vrf name test1 table 2000
set interfaces ethernet eth1 vif 20 vrf test1
commit

Expected VPP state:

vppctl show ip fib table 2000 | grep 100.100.100

should show the connected routes in table 2000, and they should no longer be present in table 1000 or table 0.

Suggested implementation direction:

• Detect VRF assignment for VPP/LCP-managed interfaces.
• Resolve VyOS VRF name to table-id.
• Bind the corresponding VPP interface to the correct FIB table using VPP PAPI sw_interface_set_table().
• Preserve and restore interface IP addresses when changing the VPP interface table.
• Support at least Ethernet interfaces and Ethernet VIFs, for example eth1 and eth1.20.
• Ideally handle both IPv4 and IPv6 tables.

Next
I am continuing to test this behavior in a lab environment and will update this task with additional findings, command outputs, and edge cases.

Any comments, implementation suggestions, or guidance from maintainers are very welcome.