Closed avlec closed 7 months ago
When creating and deleting networks to test behaviour I was able to create a network without an ip-range and then replace it with one with an ip-range and it did not hand out ip addresses from that range
Steps to reproduce the issue
podman network create -d ipvlan --ipam-driver host-local -o parent=eth1 --subnet 192.168.1.0/24 --gateway 192.168.1.0 myipvlan
podman run -it --network myipvlan busybox
podman network rm -f myipvlan
podman network create -d ipvlan --ipam-driver host-local -o parent=eth1 --subnet 192.168.1.0/24 --ip-range 192.168.1.10-192.168.1.20 --gateway 192.168.1.0 myipvlan
When recreating the network after deletion it appears to not be picking up on the ip-range provided when recreating the network.
I would expect the recreated network to use the new ip-range settings.
host: arch: amd64 buildahVersion: 1.33.5 cgroupControllers: - cpuset - cpu - cpuacct - blkio - memory - devices - freezer - net_cls - perf_event - net_prio - hugetlb - pids - rdma - misc cgroupManager: cgroupfs cgroupVersion: v1 conmon: package: conmon-2.1.10-1.fc39.x86_64 path: /usr/bin/conmon version: 'conmon version 2.1.10, commit: ' cpuUtilization: idlePercent: 98.88 systemPercent: 0.44 userPercent: 0.68 cpus: 20 databaseBackend: sqlite distribution: distribution: fedora variant: container version: "39" eventLogger: journald freeLocks: 2046 hostname: RDFW-W-022 idMappings: gidmap: null uidmap: null kernel: 5.15.146.1-microsoft-standard-WSL2 linkmode: dynamic logDriver: journald memFree: 10677223424 memTotal: 16771399680 networkBackend: netavark networkBackendInfo: backend: netavark dns: package: aardvark-dns-1.10.0-1.fc39.x86_64 path: /usr/libexec/podman/aardvark-dns version: aardvark-dns 1.10.0 package: netavark-1.10.3-1.fc39.x86_64 path: /usr/libexec/podman/netavark version: netavark 1.10.3 ociRuntime: name: crun package: crun-1.14.3-1.fc39.x86_64 path: /usr/bin/crun version: |- crun version 1.14.3 commit: 1961d211ba98f532ea52d2e80f4c20359f241a98 rundir: /run/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^20240220.g1e6f92b-1.fc39.x86_64 version: | pasta 0^20240220.g1e6f92b-1.fc39.x86_64 Copyright Red Hat GNU General Public License, version 2 or later <https://www.gnu.org/licenses/old-licenses/gpl-2.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/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: false seccompEnabled: true seccompProfilePath: /usr/share/containers/seccomp.json selinuxEnabled: false serviceIsRemote: true slirp4netns: executable: /usr/bin/slirp4netns package: slirp4netns-1.2.2-1.fc39.x86_64 version: |- slirp4netns version 1.2.2 commit: 0ee2d87523e906518d34a6b423271e4826f71faf libslirp: 4.7.0 SLIRP_CONFIG_VERSION_MAX: 4 libseccomp: 2.5.3 swapFree: 4294967296 swapTotal: 4294967296 uptime: 20h 47m 42.00s (Approximately 0.83 days) variant: "" plugins: authorization: null log: - k8s-file - none - passthrough - journald network: - bridge - macvlan - ipvlan volume: - local registries: search: - docker.io store: configFile: /usr/share/containers/storage.conf containerStore: number: 1 paused: 0 running: 0 stopped: 1 graphDriverName: overlay graphOptions: overlay.imagestore: /usr/lib/containers/storage overlay.mountopt: nodev,metacopy=on graphRoot: /var/lib/containers/storage graphRootAllocated: 1081101176832 graphRootUsed: 1760743424 graphStatus: Backing Filesystem: extfs Native Overlay Diff: "false" Supports d_type: "true" Supports shifting: "false" Supports volatile: "true" Using metacopy: "true" imageCopyTmpDir: /var/tmp imageStore: number: 23 runRoot: /run/containers/storage transientStore: false volumePath: /var/lib/containers/storage/volumes version: APIVersion: 4.9.3 Built: 1708357294 BuiltTime: Mon Feb 19 07:41:34 2024 GitCommit: "" GoVersion: go1.21.7 Os: linux OsArch: linux/amd64 Version: 4.9.3
No
Privileged
Windows 11 with WSL configured with networkingMode=mirrored
networkingMode=mirrored
Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting
I can reproduce, will open create a fix later.
Issue Description
When creating and deleting networks to test behaviour I was able to create a network without an ip-range and then replace it with one with an ip-range and it did not hand out ip addresses from that range
Steps to reproduce the issue
Steps to reproduce the issue
podman network create -d ipvlan --ipam-driver host-local -o parent=eth1 --subnet 192.168.1.0/24 --gateway 192.168.1.0 myipvlan
podman run -it --network myipvlan busybox
IP address it should be within the subnetpodman network rm -f myipvlan
this should remove the old configurationpodman network create -d ipvlan --ipam-driver host-local -o parent=eth1 --subnet 192.168.1.0/24 --ip-range 192.168.1.10-192.168.1.20 --gateway 192.168.1.0 myipvlan
podman run -it --network myipvlan busybox
IP address should be within the IP range but it isn'tDescribe the results you received
When recreating the network after deletion it appears to not be picking up on the ip-range provided when recreating the network.
Describe the results you expected
I would expect the recreated network to use the new ip-range settings.
podman info output
Podman in a container
No
Privileged Or Rootless
Privileged
Upstream Latest Release
No
Additional environment details
Windows 11 with WSL configured with
networkingMode=mirrored
Additional information
Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting