On Tue, 2012-07-24 at 10:21 -0400, Pavel Simerda wrote: > > From: "Ross Vandegrift" <ross kallisti us> > > Why does NM do this? Iv6 autoconf is a dynamic routing protocol that > > chooses the best available default on the network. > > I guess it's because NetworkManager devels (and users) generally don't agree > that kernel's dynamic preference is useful enough. I don't think that > VPNs and such stuff could work leaving several default routes with the same > metric. It isn't the kernel's preference, but the *network's*. The kernel is just reporting the costs of the various routes it has heard about. If these costs aren't useful enough, then the network is misconfigured, and the user should expect degraded performance until it is fixed. This is a good use case for a static workaround. If the VPN isn't tied to at tunnel interface, then a static default makes sense. But this is a case where the user has explicitly configured static behavior, and expects traffic to be statically routed according to that configuration. > > *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. > > > > Software has bugs. Do you mean NM here, or the software announcing routes? In the first case, fair enough. But if you mean the second, then you're saying that NM is breaking IPv6 autoconf for all users just because some other software might have bugs. > > 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. > > Unfortunately NetworkManager is there to handle many more cases than > only the simple ones. But this wasn't a simple case - there were multiple gateways injecting defaults. NM didn't handle it because it broke the routing protocol, which is designed to handle more complex cases. Now, a user should surely be able to statically override a dynamic route. But NM shouldn't break things for everyone just because some network might have a misbehaving router announcing defaults it can't service. > > > 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? > > You can't use DHCP without router advertisements, se below. Fair enough, but this doesn't answer my question - what situation is NM trying to handle by overriding working routing protocol decisions with automatic static configuration that breaks things? What about such a situation justifies breaking the protocol for everyone? It's not like this complexity is free - the bugs in it prohibit me from enabling any IPv6 support in NM, and I'm in the simplest possible IPv6 situation - one /64 and one default. (Though to be fair, I haven't had the chance to test the fresh RC - hopefully I'll have time tonight.) Ross
Attachment:
signature.asc
Description: This is a digitally signed message part