Allow networks to share the same subnet when the ip-ranges do not overlap

fpoirotte commented 1 year ago

Feature request description

I would like to be able to create several networks which share the same base subnet (e.g. 10.44.0.0/16), but use different (non-overlapping) IP ranges (e.g. 10.44.0.0/24, 10.44.1.0/24, etc.).

Currently, this fails when attempting to create the second network:

[me@pc ~]$ podman network create --subnet 10.44.0.0/16 --ip-range 10.44.0.0/24 subnet1
subnet1
[me@pc ~]$ podman network create --subnet 10.44.0.0/16 --ip-range 10.44.1.0/24 subnet2
Error: subnet 10.44.0.0/16 is already used on the host or by another config

A manual workaround is available (see below), but I'm looking for a way to make this more user-friendly.

Suggest potential solution

The commands given above should work without erroring out.

Have you considered any alternatives?

The following workaround works but is a bit tedious and error prone:

Create the first network using podman network create ... as usual
Go to the folder where the networks for your network backend are stored (e.g. in rootless mode when using the default settings, this will be ~/.config/cni/net.d/ for CNI and ~/.local/share/containers/storage/networks/ for netavark)
Clone the configuration file for the network you previously created (this will be <network>.conflist for CNI & <network>.json for netavark)
Edit the new file:
- edit the network's name (note : the name must match the file's name, minus the extension)
- (netavark only) edit the network's ID (e.g. change a digit) -- the ID must be unique across all configured networks
- edit the allocation range for the subnet

Additional context

podman info:

host:
  arch: amd64
  buildahVersion: 1.31.0
  cgroupControllers:
  - cpu
  - io
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.7-2.fc38.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.7, commit: '
  cpuUtilization:
    idlePercent: 74.03
    systemPercent: 6.37
    userPercent: 19.6
  cpus: 8
  databaseBackend: boltdb
  distribution:
    distribution: fedora
    variant: workstation
    version: "38"
  eventLogger: file
  hostname: pc.local
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1501
      size: 1
    - container_id: 1
      host_id: 7000000
      size: 8665536
    uidmap:
    - container_id: 0
      host_id: 1234
      size: 1
    - container_id: 1
      host_id: 7000000
      size: 8665536
  kernel: 6.4.10-200.fc38.x86_64
  linkmode: dynamic
  logDriver: k8s-file
  memFree: 7953817600
  memTotal: 16605708288
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: Unknown
    package: netavark-1.7.0-1.fc38.x86_64
    path: /usr/libexec/podman/netavark
    version: netavark 1.7.0
  ociRuntime:
    name: crun
    package: crun-1.8.6-1.fc38.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.8.6
      commit: 73f759f4a39769f60990e7d225f561b4f4f06bcf
      rundir: /run/user/1234/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
  os: linux
  pasta:
    executable: /usr/bin/pasta
    package: passt-0^20230625.g32660ce-1.fc38.x86_64
    version: |
      pasta 0^20230625.g32660ce-1.fc38.x86_64
      Copyright Red Hat
      GNU Affero GPL version 3 or later <https://www.gnu.org/licenses/agpl-3.0.html>
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
  remoteSocket:
    exists: true
    path: /run/user/1234/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-12.fc38.x86_64
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.3
  swapFree: 17117229056
  swapTotal: 17179860992
  uptime: 13h 2m 23.00s (Approximately 0.54 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  docker.io:
    Blocked: false
    Insecure: false
    Location: registry-1.docker.io
    MirrorByDigestOnly: false
    Mirrors:
    - Insecure: false
      Location: mirror.internal/docker.io
      PullFromMirror: ""
    Prefix: docker.io
    PullFromMirror: ""
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /home/me/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/me/.local/share/containers/storage
  graphRootAllocated: 229198450688
  graphRootUsed: 213341417472
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 1253
  runRoot: /run/user/1234/containers
  transientStore: false
  volumePath: /home/me/.local/share/containers/storage/volumes
version:
  APIVersion: 4.6.0
  Built: 1689942206
  BuiltTime: Fri Jul 21 14:23:26 2023
  GitCommit: ""
  GoVersion: go1.20.6
  Os: linux
  OsArch: linux/amd64
  Version: 4.6.0

rhatdan commented 1 year ago

@Luap99 PTAL

Luap99 commented 1 year ago

I see the use-case for multiple ip ranges but why do you want multiple networks with different ranges? Wouldn't it better to allow multiple ranges for the same subnet in the same network.

Doing this across multiple networks is much more complicated. We would need to ensure the same bridge interface name is used with the same subnet. And even then I think the iptables rules would still be duplicated as we use the name, this should not cause problems but still adds unnecessary work.

github-actions[bot] commented 1 year ago

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

fpoirotte commented 1 year ago

@Luap99 : you mean something like: podman network create --subnet 10.44.0.0/24 --subnet 10.44.1.0/24 subnet ? I seem to have missed this possibility in my initial testing, and I think this would indeed solve my problem.

Given your previous answer, feel free to close this issue.

Luap99 commented 1 year ago

you mean something like: podman network create --subnet 10.44.0.0/24 --subnet 10.44.1.0/24 subnet ?

This would create an interface with two ipv4 addresses, one from each subnet.

I don't understand why do you want two networks for this? To me this sounds like you want multiple ip range per network: --subnet 10.44.0.0/16 --ip-range 10.44.0.0/24 --ip-range 10.44.1.0/24

containers / podman