[RFC] ifupdown - change of default route metric in favour of network-manager

[Alexander Sack]

Hi,

As previously discussed in [1] we don't manage any interfaces
configured in /etc/network/interfaces through network-manager
anymore. As discussed in bug 139403 [2] I had to tweak the _default_
metric of ifupdown managed interfaces in order to prevent randomness
in routing of packets when there exist two default routes.

So now the default route set by network-manager wins over the one set
by ifupdown.

Technically, the patch i uploaded for ifupdown changes the _default_
metric to 100 while the default route setup by network-manager still
has a metric of 0.

Of course, your metric options configured /etc/network/interfaces are
still being honoured.

For example, with eth1 using ifupdown and eth0 being network-manager
managed you end up with a routing table like this:

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref
Use Iface
10.0.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     0      0 0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0 0 eth1
0.0.0.0         10.0.1.1        0.0.0.0         UG    0      0 0 eth0
0.0.0.0         192.168.1.1     0.0.0.0         UG    100    0 0 eth1

(See the Metric: 100 for eth1)

However, there have been questions asked which I want to address in
this post.

Feel free to raise other issue in this thread.

------------

Here my comments on issues raised so far (by mdz):

- What is the use case we're trying to address with this change?  It's
  not entirely clear from the bug.  Is it "I want to maintain my wired
  interface in /e/n/i but roam to wireless using network-manager"?  If
  the user opts to use /e/n/i, shouldn't they be expected to run
  ifdown when they stop using the interface?

- Is "network-manager wins" the right default policy?  Why?

 Yes, its about the use-case you outline. People that have configured
 a ifupdown connection and then connect to wireless would experience
 random package droppage if we don't prioritize one of the default
 routes.

 I think its logical to prefer network-manager over ifupdown routes,
 because in this use-case network-manager would only be used when the
 user _explicitly_ wants to connect to another network.

 Another point that supports the network-manager wins over ifupdown
 approach is the fact that network-manager can be disabled through GUI
 by just right clicking on the applet and disabling wireless/networking.

- If that is the right policy, wouldn't it be simpler to delete the
  existing  default route?

 The current approach is technically cleaner to implement in
 network-manager ... deleting the existing routes and setting them up
 again would require more significant code-changes without any real
 benefit imo.

- What about routes other than default?  In particular, the implicit
  route to the local subnet?  It's not unusual for different networks
  to use the same RFC1918 nets.

I am not sure about local subnets at the moment and I have to admit
that I haven't considered this special case of two interfaces
providing a route to the same local subnet before you raised this. Now
my question: Is this a real issue? Would this really cause packets
being dropped? How do you approach this with /etc/network/interfaces
only?

- Won't people currently using route metrics be hopelessly confused?
  (granted, that's a very small group of folks, but they're doing this
  because their system is a router)

Users that currently make use of the metric option most likely have
that configured in in /e/n/i. This option is still considered, so
there should be no unexpected change in behaviour for them.

[1] - https://lists.ubuntu.com/archives/ubuntu-devel/2007-September/024224.html
[2] - https://launchpad.net/bugs/139403

 - Alexander