[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[libvirt] Static Route for IPv6

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.


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?

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. I am not sure that it is a good idea that folks fiddle with default routes in libvirt virtual-network definitions but I am sure that someone, sometime will have a valid reason to do so.

BTW, just because some static route variation is not implemented as part of the libvirt definition does not mean that a user cannot issue the ip-route-add command manually.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]