[RFE] Support bridges created outside of netavark

[mwinters0]

Some users want to connect containers to a bridge that they have created outside of podman/netavark , e.g. so that VMs and containers can talk to each other. According to the comments in #868 we do not currently support this configuration:

Our current code always assumes that we created the bridge and we will also remove it once all interfaces connected to the bridge are removed.

The patch in that PR does work, but only coincidentally due to implementation details, and it leaves some cruft behind such as tables/chains that are left empty due to no IPs. We instead should explicitly support this configuration and not call the firewall code at all if the interface has no netavark-assigned IP.

[RushingAlien]

I'd like to add that my case is for a bridge-to-lan setup where the bridge acts as an L2 layer so VMs and Containers can access the campus LAN directly instead of adding another L3 virtual net

[RushingAlien]

I'm thinking of adding a boolean property: managed

true is default and means netavark will manage the bridge
false means netavark will not manage the bridge, for when bridge is setup externally.

Upon podman network create if interface-name already exists, then managed becomes false automatically

[mwinters0]

@RushingAlien FYI your use case can be handled by using the macvlan driver in bridge mode or the ipvlan driver (depending on what networking hardware you're connecting to and the policy that was set there). This issue is for people who specifically want to use the bridge driver to accomplish the same and/or other use cases. (Maybe that's you - I'm not sure. Just wanted to make you and any others who might drive by aware.)

Have a look at podman-network-create(1) and/or this docker macvlan tutorial.

[RushingAlien]

It worked, thanks :D.

On another note, Will rootless containers be able to use the exisitng bridge? if so can dhcp work for these rootless containers connected to the bridge?

[Luap99]

No rootless networking cannot use any host interfaces, be it macvlan or bridge, we simply have no privileges and thus the dhcp proxy will also never work there. Rootless networking runs always in a isolated namesapce, see containers/podman#22943 (comment) for the architecture

[M1cha]

@Luap99 What do you think about unmanaged bridge support? I also need it, because macvlans can't communicate with the host (which in my case is a router, so it has to. And forwarding is not an option because I want NAT-free IPv6).

I can implement this, once we agreed on the details. What's not yet clear to me is what we want to do with the firewall rules and all the sysctl settings which are currently changed(I don't fully understand why that's done). If we disable too much one could ask why we even want to use the bridge driver instead of a new one(a plugin?).

[Luap99]

I was thinking of a network option like mode that could bet set to l2 (layer2) or l3 (layer3), in the layer2 code we simply skip the firewall code and skip the remove bridge step on last container shutdown (well once technically when there are no other interfaces attached to the bridge). For the sysctls I would need to take a closer looks, we still would want to turn on routing I guess. But maybe we should disable ipv6 dad and SLAAC sysctls.

In this case all firewall rules would need to be managed by users which I think is the normal expected use case if you share a bridge with VMs and containers.

[Luap99]

cc @mheon In case you have onions here

[mheon]

My only question is user experience. How do we expose this in a way that makes sense and doesn't introduce a lot of complexity?

[Luap99]

podman network create --opt mode=l2 if we just parse it as normal option like mtu for example.

[mheon]

Fair enough... I'm not crazy about the idea, but code-wise it shouldn't be much burden to maintain