netavark icon indicating copy to clipboard operation
netavark copied to clipboard

Potentially avoid round-robin routing among default gateways

Open mheon opened this issue 2 years ago • 7 comments

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.

mheon avatar Aug 09 '22 17:08 mheon

(To be clear, this would probably be optional; the kernel's default round-robin algorithm seems quite sane)

mheon avatar Aug 09 '22 17:08 mheon

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.

HidingCherry avatar Aug 22 '22 16:08 HidingCherry

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) ?

astenmco avatar Sep 22 '22 12:09 astenmco

An internal network should not have a default gateway, if this is the case please file a separate bug

Luap99 avatar Sep 22 '22 13:09 Luap99

You're right @Luap99 : just opened the issue #415.

astenmco avatar Sep 22 '22 13:09 astenmco

@mheon whats going on here

baude avatar Mar 23 '23 02:03 baude

@mheon whats going on here

baude avatar Jun 29 '23 14:06 baude