[Bug 291144] sysutils/podman: low incoming network performance in running containers

From: <bugzilla-noreply_at_freebsd.org>
Date: Sat, 22 Nov 2025 02:05:36 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291144

            Bug ID: 291144
           Summary: sysutils/podman: low incoming network performance in
                    running containers
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: dfr@FreeBSD.org
          Reporter: william@firstyear.id.au
          Assignee: dfr@FreeBSD.org
             Flags: maintainer-feedback?(dfr@FreeBSD.org)

When using podman containers have extremely slow incoming network performance,
often around 100kb/s.


Example:
podman run -i -t docker.io/freebsd/freebsd-toolchain:15.0.rc3 fetch
https://download.freebsd.org/releases/amd64/amd64/ISO-IMAGES/14.3/FreeBSD-14.3-RELEASE-amd64-disc1.iso
# The download hovers around 100kb/s

I have tried to narrow down as many factors as possible, so I want to quickly
describe the setup:


I am running a bhyve hypervisor (FreeBSD lilly.firstyear.id.au 14.3-RELEASE-p5
FreeBSD 14.3-RELEASE-p5 GENERIC amd64) which is hosting a guest vm (FreeBSD
steph.firstyear.id.au 14.3-RELEASE-p5 FreeBSD 14.3-RELEASE-p5 GENERIC amd64)
that is running podman. 


Running the same fetch command from above on both the hypervisor and the
container host yields ~5MB/s. Internal network testing from the hypervisor to
another machine with iperf3 shows ~190MB/s and from the container host
~160MB/s. Downloading an ISO internally to either the hypervisor or the
container host shows ~155MB/s. This to me eliminates the container host, the
network, or storage as the cause of the performance issues.


Similar I do not think the issue is the container image in use - I have tried
with freebsd-toolchain:15.0.rc3, 15.snap, and --os=linux with opensuse/leap:15 

At this point I think the only possible reason is something about the network
setup with podman in this case. 

Any further advice to diagnose this further would be great, but I think there
may be an issue related to networking in this case. 


# pkg info | grep podman
containers-common-0.64.1_1     Common manpages and config files for podman and
buildah
podman-5.6.1                   Manage Pods, Containers and Container Images
podman-suite-20250905          Metaport of Podman and Buildah toolkit

# ifconfig
vtnet0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0
mtu 1500
        options=80028<VLAN_MTU,JUMBO_MTU,LINKSTATE>
        ether 58:9c:fc:05:26:5a
        inet 172.24.20.12 netmask 0xffffff00 broadcast 172.24.20.255
        inet6 fe80::5a9c:fcff:fe05:265a%vtnet0 prefixlen 64 scopeid 0x1
        inet6 2403:580b:7d88:20:5a9c:fcff:fe05:265a prefixlen 64 autoconf
pltime 86400 vltime 86400
        media: Ethernet autoselect (10Gbase-T <full-duplex>)
        status: active
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384
        options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
        groups: lo
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
cni-podman0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP>
metric 0 mtu 1500
        options=0
        ether 58:9c:fc:10:ff:ea
        inet 10.88.0.1 netmask 0xffff0000 broadcast 10.88.255.255
        id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
        root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
        member: vnet3c5765e9 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 5 priority 128 path cost 2000
        groups: bridge
        nd6 options=9<PERFORMNUD,IFDISABLED>
vnet3c5765e9:
flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0
mtu 1500
        description: associated with jail:
51033da78fd3ffd29fb8880f4e58f70258c2e9e0b18914c45bed71237c503ef8 as nic: eth0
        options=8<VLAN_MTU>
        ether 02:93:86:4c:87:0a
        groups: epair
        media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

# dmesg | tail -n 20
Timecounter "TSC" frequency 2099956708 Hz quality 1000
Timecounters tick every 10.000 msec
ZFS filesystem version: 5
ZFS storage pool version: features support (5000)
usb_needs_explore_all: no devclass
Trying to mount root from zfs:zroot/ROOT/default []...
lo0: link state changed to UP
vtnet0: link state changed to UP
Security policy loaded: MAC/ntpd (mac_ntpd)
lo0: link state changed to UP
bridge0: Ethernet address: 58:9c:fc:10:ff:ea
bridge0: changing name to 'cni-podman0'
epair0a: Ethernet address: 02:cb:de:80:8e:0a
epair0b: Ethernet address: 02:cb:de:80:8e:0b
epair0a: link state changed to UP
epair0b: link state changed to UP
epair0a: changing name to 'vnetfa8aaef3'
epair0b: changing name to 'eth0'
vnetfa8aaef3: promiscuous mode enabled
cni-podman0: link state changed to UP

-- 
You are receiving this mail because:
You are the assignee for the bug.