[libvirt] Static Route for IPv6

[Laine Stump]

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