[RFC] ifupdown - change of default route metric in favour of network-manager
asac at jwsdot.com
Fri Sep 21 12:59:07 BST 2007
As previously discussed in  we don't manage any interfaces
configured in /etc/network/interfaces through network-manager
anymore. As discussed in bug 139403  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
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
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
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
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
- 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
- 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.
 - https://lists.ubuntu.com/archives/ubuntu-devel/2007-September/024224.html
 - https://launchpad.net/bugs/139403
More information about the ubuntu-devel