podman vrf support

[kajtzu]

Hi,

It would be handy if podman supported namespaces and VRFs "natively" rather than via admin having to do "ip netns" and "ip link add ... type vrf ..." as part of starting something up

I was first looking at systemd, which could arguably be the right place for this, but it does not seem to have much traction, either, at least according to systemd/systemd#20451

Thanks.

[Luap99]

I am not familiar with vrf, could you describe exactly what you would want podman to do? I tried reading what vrf does and I am not sure why you would want that in the container namespace?

[kajtzu]

I will try to explain. :)

What I would like to have the ability to run containers in a virtual routing and forwarding instance (VRF). The nice thing with a VRF has its own routing and forwarding table and thus allows overlapping IP addressing. A VRF also enables associating interfaces to it, whether logical (tun, tap, bond0.42, em1.42, ...) or physical (em1, em2, eno1, eno2, etc.). These interfaces are then dedicated to that VRF and not available in another routing and forwarding table (like the global routing and forwarding table which is the default on Linux and many other operating systems).

My network topology is similar to this (very much simplified):

(host1) ==== (PE1) === (IP/MPLS core) === (PE2) --- (customer device)
  ^      ^   ^    ^         ^         ^    ^    ^         ^
  |      |   |    |         |         |    |    |         |
  |      |   |    |         |         |    |    |         consumer for whatever services, inside the same MPLS Layer3 VPN (I will equate this to vrf-222 used in examples below while in real life this is not 1:1)
  |      |   |    |         |         |    |    link, nothing special
  |      |   |    |         |         |    Provider Edge device, pushes/swaps MPLS labels towards the network and customer facing pops labels and forwards traffic withing a MPLS VPN/VRF to the destination interface
  |      |   |    |         |           connectivity to PE2 and core network, outside scope
  |      |   |    |         MPLS packet core, outside scope
  |      |   |    connectivity to PE1, outside scope
  |      |   Provider Edge device, pushes/swaps MPLS labels towards the network and customer facing pops labels and forwards traffic withing a MPLS VPN/VRF to the destination interface
  |      bond0, a set of links between PE1 and the container host, on the bond each VLAN corresponds to a customer connection to a MPLS Layer 3 VPN, outside scope
  the container host running all my happy little containers

with VLANs on bonded interfaces between host1 and PE1. Thus, I have the following interfaces for different customers and of course cannot allow any mixing of them at all.

bond0.200 (VLAN 200) is mapped to vrf-200 on PE1
bond0.201 (VLAN 201) is mapped to vrf-201 on PE1
bond0.202 (VLAN 202) is mapped to vrf-202 on PE1
bond0.222 (VLAN 222) is mapped to vrf-222 on PE1
...

The use case for me is to being able to run containers so that they can be associated with one or more VLAN interfaces on the bond0 and be assured that customers are separated from each other. From a network segmentation perspective the containers in two VRFs are logically separate and can be routed/forwarded by whatever routing is in place upstream from host1. Also, IP addresses can overlap, etc. (I do not expect that this is something that podman should solve, I can manually provision IPs and all of that)

from shell I would do something similar:

# create a vrf named vrf-222, routing table number 42
ip link add vrf-42 type vrf table 42
ip link set vrf-42 up
# associate bond0.200 with the vrf, this removes bond0.200 from the global instance
ip set dev bond0.200 master vrf-222

Now, with containers my goal would be to associate the container with vrf-222 so its "network world" would be inside. A normal service could be started with:

ip netns exec vrf-222 /usr/sbin/httpd blah blah

but, of course, here I am attempting to do this with containers rather than some daemon I have around on disk :)

In the (old?) CNI stack this seemed to be possible with the vrf plugin, https://www.cni.dev/plugins/current/meta/vrf/

[Luap99]

I still don't get it, we setup a bridge on the host then a veth pair to enable attach one side the the bridge on the host and move the other side into the container namesapce. How is setting up a vrf in the container doing anything in this case? Everything still has to go out over the bridge on the host.

I really would need all your podman and ip commands in order to understand what you are doing.

[MrSuicideParrot]

@kajtzu to achieve this kind of setup it is simpler to do it at the bridge level on the host. With podman + cni , I was able to do it, but I was forced to create my own plugin (https://github.com/MrSuicideParrot/cni-bridge-vrf).

Regardless, I think it would be nice to be able to assign a vrf when we create a new network in podman, its bridge would be assign to a vrf and not the container itself.

[Luap99]

If the only task is to do the equivalent of ip link set <bridge> master <vrf-interface> when netavark creates the bridge then I agree it is simple enough for us to support and implement. We could have a network option vrf: podman network create --opt vrf=<name> ....
Please submit a PR to https://github.com/containers/netavark if you are willing to implement such option.

[MrSuicideParrot]

I have opened an issue on netvark (containers/netavark#729) to keep track of this feature request. I hope that I will be able to do a PR soon...

[kajtzu]

In case someone ever stumbles on this in the future, VRF support was added to netavark in containers/netavark#729.