netavark
netavark copied to clipboard
Potentially avoid round-robin routing among default gateways
Presently, when a container is connected to multiple networks, Netavark adds each network's default route to the container's routing table. The kernel then automatically round-robins between these routes, as they are identical aside from their destinations.
However, this behavior may not be desirable for all users; having a single exit point for all traffic leaving the container could be desirable for writing firewall rules or similar.
We could only add a single default route, but this would make connecting and disconnecting networks much more difficult (we'd have to determine if a default was already present and create if not). Alternatively, we could use route priority to prefer one of the default gateways, but this runs into similar difficulties.
(To be clear, this would probably be optional; the kernel's default round-robin algorithm seems quite sane)
Not entirely sure if this belongs here. If I use podman network to create an internal network, that network also has a default route. I have several issues with containers randomly not being able to connect outside - I guess this would be the cause.
edit: Yup - this was definitely my issue. After deleting the internal network and recreate it as a normal network, the container could connect outside again.
edit2: Nope - after it worked after starting the container (nextcloud 23 in this case) - it worked at the beginning and stopped later.
This is definitly a problem for me. I have what I believe to be a very simple case :
- I have multiple containers on a "backend" network. This network is a bridge internal.
- I have a reverse proxy both on the default network (in order to be able to communicate with the outside world) and the "backend" network (to communicate with the other containers). But I found out that my reverse proxy does not work because it has two default gateways. It seems to me that the logical behavior would be that my "backend" network would not offer a default gateway as it is internal. Moreover, when connecting a container to multiple networks, I would expect a way to define which one should offer a default gateway...
Am I missing something in the way I see things, or is it just a bug (for the internal network offering a gateway) / a feature that should be added (a way to select the default gateway) ?
An internal network should not have a default gateway, if this is the case please file a separate bug
You're right @Luap99 : just opened the issue #415.
@mheon whats going on here
@mheon whats going on here