This test normally fails due to a known issue, but it
has recently started passing in CI ... not sure why, it
still fails locally - so, allow it to unexpeectedly
pass, but collect some debug info to try to undertand
why.
Signed-off-by: Rob Murray <rob.murray@docker.com>
Skip tests that have recently started failing in rootless
mode with error:
failed to start daemon: Error initializing network controller:
error creating default "bridge" network:
cannot restrict inter-container communication or run
without the userland proxy:
stat /proc/sys/net/bridge/bridge-nf-call-iptables:
no such file or directory:
set environment variable DOCKER_IGNORE_BR_NETFILTER_ERROR=1 to ignore
(Perhaps we can ensure the module is loaded before starting
the rootless env - or work out why the failures have only
recently started, and put-back whatever changed. But, for
now, I think we need to skip.)
Signed-off-by: Rob Murray <rob.murray@docker.com>
When a network is created with "-o com.docker.network.enable_ipv4'
(including via "default-network-opts" in daemon config), and
EnableIPv4 is present in the API request (including when CLI option
"--ipv4" is used) - the top-level API value is used and the '-o'
is ignored.
But, the "-o" still shows up in Options in inspect output, which is
confusing if the values are different.
So, drop the "-o" if the top-level API option is set. Ditto IPv6.
Signed-off-by: Rob Murray <rob.murray@docker.com>
It's possible to remove a legacy link from running containers.
When that happens, the Sandbox's Endpoints are removed and
re-added.
Since commit 65120d5 ("Create bridge veth in container netns")
the veth device has been created in the container's netns. When
that happens, a flag is set on the Endpoint to note that it
does not need to be moved into the netns.
But, during the Leave/Join (Sandbox.Refresh) the veth is moved
out of the netns. So, clear the flag during the Leave, to note
that it needs to be moved back in during the Join.
Signed-off-by: Rob Murray <rob.murray@docker.com>
The daemon runs in a separate netns, but when it wants to create
an iptables rule it sends a dbus message to firewalld - which is
running in the host's netns.
Signed-off-by: Rob Murray <rob.murray@docker.com>
With improved IPv6 support, a dual-stack container can map a port using
two different networks -- one IPv4-only, the other IPv6-only.
The daemon was updating containers' `EndpointSettings.Ports` by looking
for the first network providing port-mappings. This was incorrect.
Instead, iterate over the whole list of endpoints, and merge everything
together.
The function doing that, ie. `getEndpointPortMapInfo`, is also
considered exposed ports, and nil the PortMap entry if an exposed port
is found. However, exposed ports are always set on a bridge network, so
this was erasing port-mappings found for other networks.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
Prior to commit fe856b9, containers' network sandbox and interfaces were
created before the containerd task. Now, it's created after.
If this step fails, the containerd task is forcefully deleted, and an
event is sent to the c8d event monitor, which triggers `handleContainerExit`.
Then this method tries to restart the faulty container.
This leads to containers with a published port already in use to be
stuck in a tight restart loop (if they're started with
`--restart=always`) until the port is available. This is needlessly
spamming the daemon logs.
Prior to that commit, a published port already in use wouldn't trigger
the restart process.
This commit adds a check to `handleContainerExit` to ignore exit events
if the latest container error is related to networking setup.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
To support this, a new netlabel is added: `com.docker.network.endpoint.ifname`.
It gives the ability to specify the interface name to be set by
netdrivers when the interface is added / moved into the container's
network namespace.
All builtin netdrivers support it.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
It can only be set on a "--internal" network, and the only difference is
that no address is assigned to the bridge. So, there's no route to a
host address.
Signed-off-by: Rob Murray <rob.murray@docker.com>
The default IPAM allocator is unable to represent subnets larger than
64-bits (subnets with a smaller prefix), because it uses a Bitmap
that's limited to 64-bits.
When it's used to represent a 64-bit subnet, the top address can't
be allocated (because bitmap.Bitmap is initialised with the number
of bits it needs to represent in a uint64, so it's one short).
The rest of the daemon doesn't know about these limitations, so
strange things happen when a large IPv6 subnet is used.
No errors are reported, addresses/subnets are just set up incorrectly.
The IPAM code calculates offsets into the bitmap itself, details it
shouldn't need to understand and, because it's working on offsets
into a range it doesn't always notice when it's asked to set a bit
outside the range.
It's unusual to need a big subnet but, for example, it may be useful
for modelling an ISP network, or an ISP's gateway may be in a "/56"
subnet that's outside a 64-bit range used by hosts.
So, use addrset.AddrSet instead of bitmap.Bitmap.
Signed-off-by: Rob Murray <rob.murray@docker.com>
An "--internal" bridge network will never set up a default route
and, with "-o com.docker.network.bridge.inhibit_ipv4", no Gateway
address will be assigned to the bridge.
So, implement the SkipGwAlloc interface in the bridge driver, and
use it to to indicate that no Gateway address is required in this
specific case.
Signed-off-by: Rob Murray <rob.murray@docker.com>
integration/network/bridge/bridge_linux_test.go:177:3: The copy of the 'for' variable "tc" can be deleted (Go 1.22+) (copyloopvar)
tc := tc
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Also make it Linux-only, as the bridge driver is Linux only and
all of the tests had skips for Windows.
Signed-off-by: Rob Murray <rob.murray@docker.com>
