Re: [libvirt] Static Route for IPv6
On 05/06/2013 02:41 PM, Gene Czarcinski wrote:
In the process of adding the code to support static routes for IPv4
and IPv6, I hit a problem when I tried to specify a static route for
::/0 (that is "default") ... the error was "file exists." and the
problem is that this is a feature and not a bug. Here is the comment
from the bugzilla report which explains things:
-------------------------------------------------------------------------------------------------------------
yeah, this isn't a bug as far as I can see. The magic that your
looking for is
in fib6_add_rt2node(). When adding a new route, we search for duplicate
routes, and should we find one, we compare them to ensure that when
the ipv6
stack does a route lookup, they have some way to select which route
should be
used. To do that they use the metric/preference number (I admit that
use of
the term metric in the iproute2 tool is a bit misleading, but if you
check the
ip-route(8) man page, you'll see its a synonym for preference). At
any rate,
since you already have a default gateway (which the stack sees as a
duplicate
for the one your adding), and the existing route has the same
metric/preference
as the one you are adding, you get the EXIST error.
Ways to work around this:
1) Use the src option in the ip route add command to differentiate and
prevent
the existing default gw from being used (might be useful if you want
different
virt guests to use different default gw).
2) instead of using ip route add, use ip route replace, which will
overwrite
the existing default gw.
3) Use a different metric value than the existing default gw. Both
routes will
be added, but only the higest priority route will be used.
-----------------------------------------------------------------------------------------
As I understand the situation now, the error I got for ::/0 was valid
and should not be ignored or overriden by default. However, there is
bound to be someone who has a valid reason to do this so there needs
to be a way to do it.
Proposal:
Add a new attribute metric to the <route> subelement. The default for
metric will be metric='1' so that it will be the same as it is now.
However, the use will be able to specify an arbitrary unsigned 32 bit
number.
There are two other suggestions up there. Any comments?
Adding a metric that defaults to 1 sounds like a reasonable idea to me.
Replacing the existing route sounds like a bad idea, because it will
then be impossible to restore the previous state of the routing table
when the network is destroyed. If someone wants to setup a situation
where a route on a particular network will override an existing route,
they can just make sure that the other route has a higher metric, so
that the route added by libvirt takes precedence over the other when it
is in place (and the original will come back in force when the libvirt
network is destroyed).
As for using source routing, that might be something interesting to
support, but I think adding metric would be more immediately useful.
In the meantime, I think in light of this explanation of your troubles
with ::/0, the existing patch is perfectly valid, and adding metric
could be seen as an enhancement to that.
(BTW, I can think of a very good reason to have a default route pointing
to a guest - several times people have asked for a recipe to setup a
firewall in a guest and force all host traffic to go through the guest.)
When I started this, my goal was simply to get some static routes for
"regular" networks so that the virtualization host would know where to
route packets.
Nothing ever turns out as simple as the pre-game predictions, does it? :-)