Re: IPv6 default routes / NM vs. kernel autoconfig



On Mon, 2012-07-23 at 20:12 -0400, Pavel Simerda wrote:
> > ::/0              fe80::21b:2bff:fec1:dcc1   UG   1   0     0 em1
> > ::/0              fe80::217:e0ff:fe43:5941   UGDAe 1024 0     0 em1
> > ::/0              fe80::21b:2bff:fec1:dcc2   UGDAe 1024 0     0 em1
> > 
> > Note that the lower-metric route is for the IPv6 host ending in dcc1,
> > but the two higher-metric routes, which I assume come from the kernel
> > autoconf, are different hosts - dcc1 and 5941.
> 
> The lower-metric route should be from NetworkManager and it should reflect
> the default route for the device that is used for connectivity. In your
> case it seems to be nonsense.

Why does NM do this?  Iv6 autoconf is a dynamic routing protocol that
chooses the best available default on the network.  *Any* static
default breaks this mechanism, and should only be used to workaround a
broken network configuration.

Though a router did a somewhat surprising thing (coming up with a
different link-local address), the network here is working perfectly
well.

> > We took a look at the router, and found that, before reboot, it had
> > been
> > using blahblah:dcc1 as the link-local, but after reboot it started
> > using
> > blahblah:dcc2.
> 
> Currently, NetworkManager doesn't cope well with changes like this and
> unfortunately this applies to the Git version of NM as well. I hope
> to improve this at some point of time but even the kernel is not very
> helpful here.

Note that IPv6 autoconf would've handled this absolutely gracefully, if
NM had not interfered - the box would've expired the default, and the
other RA would become active. The right thing to do here is to let the
protocol work as designed.

> > My main question: What should happen in this situation? Is this a bug
> > in NM?
> 
> NM is working around lack of information from kernel and it works only in
> basic situations. There are solutions to this.

NM only lacks information if you require that NM track the state of the
network stack.  This might be required for DHCP interfaces, since NM
needs to manage the DHCP agent.  But what is the use-case for autoconf?

If someone desires different behavior, then the right thing to do is
disable autoconf and use a different interface configuration method
(DHCP, static config, etc).

Ross

Attachment: signature.asc
Description: This is a digitally signed message part



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