Re: RFE: multiple default gateways

[Dan Williams <dcbw redhat com>]

On Wed, 2011-05-11 at 13:12 +0200, Ferry Huberts wrote:
> Hi list/Dan
> 
> Yesterday I by accident looked at the routing table of a Windows 7 laptop
> with both ethernet and wlan connected and I saw something interesting:
> 
> Both connections set up a default gateways in the routing table!
> Each default gateway takes the metric of the connection to which it
> belongs, so for for example for the ethernet a metric of 0, for the wlan a
> metric of 100, etc.
> 
> Which is quite logical in fact and made me wonder why we don't do that?
> It seems obvious now that I've seen it done, or am I missing something?
> 
> I've tested it on my F15 laptop and seems to work
> 
> This would also make any code handling the default gateway go away!
> You'd just need to clean up all entries belonging to the connection that's
> going away, and not touch other routing entries :-)
> 
> 
> Example routing table:
> 
> Destination     Gateway         Genmask         F  Metric R U Iface
> 192.168.1.0     0.0.0.0         255.255.255.0   U  0      0 0 eth0
> 192.168.1.0     0.0.0.0         255.255.255.0   U  1000   0 0 wlan0
> 0.0.0.0         192.168.1.1     0.0.0.0         UG 0      0 0 eth0
> 0.0.0.0         192.168.1.1     0.0.0.0         UG 1000   0 0 wlan0

I think this has come up before, and we certainly could do it.  I think
we'd want to run with it a bit more though and see what the behavior is
really like.  The usual use for this is failover for multi-homed systems
(which of course systems with > 1 device active are by definition).
This could actually allow a quicker switch of the 'default' interface
because there wouldn't be a window (however short) in which there is no
default route while NM sets up the other one.

So if you keep playing around with it, and it seems to work out, would
you be interested in contributing a patch for it?  In the end, we want
each device to keep track of the 'struct rtnl_route' that represents
it's gateway route in the NMDevicePrivate structure.  We'd want to add
some functions to nm-system.c that would create that structure with
netlink code, and then return it.  Then, in nm-policy.c where the
decision about what device should get the "best" default route is made,
we'd change nm_system_replace_default_ip4_route() to just update the
metric in the given device's 'struct rtnl_route' and tell netlink to
save that value.

Dan