Run a Command in a Linux VRF with ip vrf exec

ip vrf exec launches a command against a chosen routing table. This guide gets you a repeatable way to inspect Linux VRFs and run a command inside one.

The examples use iproute2 6.1.0, Ubuntu package version 6.1.0-1ubuntu6.4, following the installed ip-vrf(8) contract. Allow about fifteen minutes.

1. Confirm the installed command

Start with the local command's help and version. This is read-only and needs no sudo:

$ ip -Version
ip utility, iproute2-6.1.0, libbpf 1.3.0
$ ip vrf help
Usage:  ip vrf show [NAME] ...
        ip vrf exec [NAME] cmd ...
        ip vrf identify [PID]
        ip vrf pids [NAME]

The subcommands are deliberately small:

Checkpoint: if ip vrf help does not show exec, stop and check which ip binary is first in PATH. Do not assume another host has the same iproute2 version.

2. List the VRFs that actually exist

Ask the kernel for configured VRF devices:

$ ip vrf show
Name              Table
-----------------------
red               1001

The names and table IDs are host-specific. On a machine with no VRF, the command exits successfully but reports that none is configured: that is not a failed network test, and inventing a name such as red will not create one.

To query one VRF, pass its exact name:

$ ip vrf show red
Name              Table
-----------------------
red               1001

Use the table ID as a clue when investigating routing, but not as a device name. A VRF is a separate layer 3 routing domain: network devices must already be associated with it, and its addresses and connected routes are local to that domain.

3. Check the current process association

With no PID, ip vrf identify checks the current process:

$ ip vrf identify
red

No output means the process is not associated with a VRF, which is the normal default. To inspect another process, pass a numeric PID:

$ ip vrf identify 1234
red

Replace 1234 with a real PID. The command does not move the process or change its sockets, it only reports the association already visible for that process. If the process has exited, or the PID is not readable under your account, investigate that condition rather than adding privilege automatically.

4. Find processes attached to a VRF

Once you have an exact VRF name, list its associated process IDs:

$ ip vrf pids red
1234
1288

An empty result is valid: it means no process was reported for that VRF at scan time. PIDs are transient, so inspect or signal one only after checking it still belongs to the service you expect:

$ ps -o pid,user,comm,args -p 1234

Warning: do not kill a PID merely because it appears in this list. Stopping a service is disruptive and separate from VRF inspection. If you need to stop one, use the service's documented control path and record an undo procedure first.

5. Run a harmless child command in the VRF

ip vrf exec takes the VRF name, then the command and its arguments. Prove that argument handling and process launch work with a harmless command before testing a real client:

$ ip vrf exec red /usr/bin/printf '%s\n' 'vrf-child-started'
vrf-child-started
$ printf 'exit status: %s\n' "$?"
exit status: 0

The zero status here means printf ran and returned zero. It does not prove a route, address, firewall rule, DNS resolver, or remote service is usable in the red VRF.

For a network check, use a command appropriate to your environment and quote values that may contain shell characters:

$ ip vrf exec red /usr/bin/ping -c 1 10.100.1.254

The destination is an example placeholder. Replace it with a host that should be reachable through that VRF, and do not use a production address as a first test unless the owner has approved the traffic.

6. Understand privilege and prerequisites

The installed manpage says ip vrf exec requires cgroup v2 and a kernel built with cgroups and cgroup BPF support. This host uses cgroup v2, but that alone does not prove every target host meets the requirement:

$ stat -fc '%T' /sys/fs/cgroup
cgroup2fs

The execution path also requires root, or all of CAP_SYS_ADMIN, CAP_NET_ADMIN and CAP_DAC_OVERRIDE. If a normal invocation fails with a capability or cgroup error, check the host's deployment model and container restrictions.

Security boundary: do not grant broad capabilities to the ip binary as a quick fix. Capability configuration changes the security boundary and needs an explicit rollback plan.

Run the command without sudo first. If the intended service already has the necessary capabilities, preserve its existing launch method. If you must test as root, make the elevation visible and keep the command narrow:

$ sudo ip vrf exec red /usr/bin/printf '%s\n' 'privileged-vrf-test'
privileged-vrf-test

This does not alter VRF configuration. The child exits immediately, so there is no persistent state to undo, though a long-running command can generate traffic or hold sockets in the selected routing domain: stop it using its normal service controls.

7. Use the default VRF explicitly when needed

If the current shell is associated with another VRF, pass default to run a command against the default VRF and main routing table:

$ ip vrf exec default /usr/bin/printf '%s\n' 'main-table-child'
main-table-child

This is useful for a management shell that must reach a service through the main table. It is not a command to create or select a new VRF. If a program opens sockets before the helper can apply the association, check that program's launch behaviour and test it separately: the helper affects network layer sockets, not every operation the process performs.

Done means