Feature Request: add subinterface creation

[jberkus]

/kind feature

Description

docker network create allows automated creation of trunk bridge mode vitual IPs that map to each created container if you call a new subinterface name, such as "eth0.2". This is useful for running services under podman that might normally get their own virtual IP, such as serving DNS.

It would be nice to have this option in podman as well, particularly for folks who are moving services from native executables to podman containers.

Realistically, it will take a significant amount of work to make this happen since CNI is more complicated than whatever docker is doing, but I wanted to get this in the queue in case someone was looking for networky things to hack on.

While you're implementing this, it would be nice to have podman support the --parent switch for syntax compatibility with docker network create

References

• https://docs.docker.com/network/macvlan/
• https://github.com/containers/libpod/blob/master/docs/source/markdown/podman-network-create.1.md

[mheon]

I know we do support macvlan mode right now, but the flags (and overall functionality) are very different from what I'm seeing in the Docker docs.

[jberkus]

if there is a way to create the virtual IP from podman generate network, then maybe this just requires a doc patch. tell me how to do it and I'll write the docs

[mheon]

I don't think we can now - our macvlan support is primarily intended to source IPs from an external DHCP server

[rhatdan]

@baude @mccv1r0 PTAL

[mccv1r0]

if there is a way to create the virtual IP from podman generate network

podman run support --ip string lets the interface get a static IPv4 (from host-local IPAM) which can be used for such things as DNS Server, web server, etc. Would this suffice? There is also the CNI static IPAM too, which (iirc) lets you avoid the need for --ip string

[jberkus]

I'm talking about a virtual interface on the host, not just an internal IP address in the podman network.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@giuseppe @mheon @mccv1r0 Any movement on this? Any new Ideas?

[rhatdan]

@giuseppe @mheon @mccv1r0 Any movement on this? Any new Ideas?

[mccv1r0]

I'm talking about a virtual interface on the host, not just an internal IP address in the podman network.

Has anyone tried / considered adding the virtual interface on the host first, then using the host-device CNI plugin? You can put a real interface inside the container this way. CNI just moves the netdev so virtual interface should work as if it was a real one.

CNI itself expects to find the "host-device" already exists before it can be used. podman network create could possibly have a flag to create sub-interface (eth0.2) first, then use host-device instead of bridge plugin.

[rhatdan]

@giuseppe @mheon WDYT?

[rhatdan]

@baude @mheon @giuseppe WDYT?

[mheon]

Serious amount of effort would be required here, probably a new CNI plugin.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@mheon @baude As we come out of Bug fix mode, is this a feature we should prioritize?

[mheon]

I think other parts of networking have priority over this (improvements to dnsname, for example)

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[MrZXR]

Hi, I'm new to PodMan.
I am wondering, why don't we just create the subinterface eth2.1 if it doesn't exists,
when we call podman network create --driver macvlan -o parent=eth2.1.

As far as I know, the job of creating a network should be to create a CNI configuration file, and then CNI is responsible for the processing of the corresponding network stack. It would be better if it could be more compatible with docker's usage habits.

[mheon]

That sounds like a reasonable feature request for the network stack rewrite.

[MrZXR]

OK, I get it. Is this a WIP rewrite or should we wait for a long time?
I'd like to join and do some work for a deeper understanding of PodMan.

[mheon]

The early stages have already been done by @Luap99 and we're now finalizing the architecture for the remaining bits; target is to have it ready for Podman 4.0 in January.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@mheon @Luap99 will this work in 4.0?

[Luap99]

No, I am not sure what docker does in this case.
It would be helpful if someone could provide more details, e.g device type, additional properties, ip address assignment, etc..
Also how is this device routed on the host, are there any special firewall rules?

[amar-bhosale]

Is this feature added in any of Podman releases so far? If not, what's the plan? We are using Podman 4.02 on RHEL-8.4.
What are alternatives to achieve this behaviour?
Can we create a sub interface manually on RHEL-8 and then use it as an argument for --parent? Does this option has any security concerns?

Appreciate if anyone could guide on this topic. Thanks!

[mheon]

Not implemented. The problem as mentioned by @Luap99 still exists: we don't really know what the use case is here.

Can you provide details as to what your use case is, what exactly you expect Podman to do, etc?

[jberkus]

My original use-case was just to run CoreDNS to supply local DNS on my laptop. This required it to have a virtual IP in the same range as my laptop's HW interface.

[amar-bhosale]

@mheon ,
Our solution provides an ability to spin up various applications using docker container technology on RHEL-7 at customer site.
Customer can have VLANs for different department and using different VLAN tags in lab infrastructure. When our solution is deployed at customer site (in their lab), then employees from different department can create various applications using our solution and would like to restrict access to specific VLAN tag.

Each application container is associated to different physical/virtual interface using docker macvlan driver. For example:
1] Application-I from HR department connects to eth0.102 virtual interface
2] Application-II from Finance department connects to eth0.211 virtual interface

As per docker documentation, it create sub interface automatically when specified as --parent. But same command does not work with Podman.

Considering above use case,
Is it possible to fix an issue on RHEL-8.4 and onwards on priority?
If not possible to fix, then can you suggest alternative if any (which has no security related issues/constraints) but still fulfilling my use case?

[mheon]

Please file a Bugzilla to get priority for a RHEL fix, but be aware that 8.4 and 8.5 are low likelyhood; to me, this sounds like a Netavark feature, which means 8.6 and up.

[Luap99]

But this only describes a use case, it would help if someone could tell us what does docker do exactly?

[mheon]

@Luap99 Sounds like https://docs.docker.com/network/macvlan/#8021q-trunk-bridge-mode - we'll need to create subinterfaces with appropriate VLAN tags.

[amar-bhosale]

@mheon,
Our plan is to consume Podman supported version on RHEL-8 only. However, we are using CNI as networking backend for Podman and not Netavark.

Does this mean above feature (if at all supported on RHEL-8), will work only when someone use Netavark as Podman networking backend?

[mheon]

Netavark will be fully supported on RHEL 8 as of 8.7; it's tech preview in 8.6. Given our deprecation of the CNI stack and the requirement that changes would be made to CNI as part of this I do not see us adding this to CNI.

[mccv1r0]

As per docker documentation, it create sub interface automatically when specified as --parent. But same command does not work with Podman.

Have you tried manually creating the sub interface?

I use macvlan with sub-interfaces all the time, but without vlan. What I've read is a bit confusing so can you clarify?

Is the ask to just automatically create the sub interface on the host (and assume that .x is to be used for vlan id x on the parent interface.) Or is there more to it?

[mheon]

Going to transfer this to Netavark, as the fix can live there