Here's the architectural issue at the root of this issue (I think):
"P.S.: Also, NetworkManager and Quagga should never run on the same host.
NetworkManager does Host processing, Quagga does Router processing, and
those two are mutually exclusive."
It should be the case that a host and a router can exist and run in the same
physical box, this is part of the IP architecture. But Linux's network stack
may make this hard to achieve (maybe impossible without careful isolation of
all the parts). If so, it is a Linux stack issue that arises from mingling
host and router datagrams in a way that does not fully separate them.
So, it could be viewed as a bug in Linux (including NetworkManager and Quagga)
that that separation is not achievable(achieved). NetworkManager spans the
layers and manages Ethernet mostly, but sometimes views it through the IP lens,
making some assumptions that are not always valid architectural invariants.
NetworkManager assumes that there is only one primary host IP interface, for
example, as I recall, even though IPv6 especially supports many IPv6 addresses
in the same box for Hosts and for routers.
So the interfaces and IP addresses for the router must be managed separately
from those in the host, even if on the same box.
The easiest way to do a very clean separation in Linux when sharing the
physical NICs as link-endpoints among router and host functions is perhaps
using virtualization of the NICs with VLANs and/or the TAP interface providing
a virtual link between the router and host on the same box. (I haven't studied
this in detail, but it seems straightforward with no gotchas). This would
separate the host interfaces from the router ones unambiguously.
Then let NetworkManager see only the host-controlled interface, but let the
other interfaces be out of NetworkManager's control.
-----Original Message-----
From: "David Lamparter" <[email protected]>
Sent: Friday, July 6, 2012 12:59pm
To: "Dave Taht" <[email protected]>
Cc: "babel-users" <[email protected]>, "cerowrt-devel"
<[email protected]>
Subject: Re: [Cerowrt-devel] [Babel-users] switching cerowrt to quagga-babeld
issues
On Tue, Jul 03, 2012 at 09:18:43AM -0400, Dave Taht wrote:
> On Tue, Jul 3, 2012 at 8:35 AM, Denis Ovsienko <[email protected]> wrote:
> >> Does anybody know where this difference comes from?
> >
> > The difference comes from NetworkManager. Its efforts in reproducing
> > high-metric RTPROT_KERNEL routes with low-metric RTPROT_STATIC ones
> > are effectively hiding the kernel issue outside of CeroWrt runtime.
> > Would it be better to add a watchdog shell script, which does the
> > same, or patch the kernel?
>
> I would *much rather* patch the kernel than have a watchdog. However I
> don't quite understand
> the redistribution issue vs a vs ipv6 here. If I have a "redistribute
> kernel" on for ipv4, it does propagate the default route.
I'm not sure I understood your problem here, but if it boils down to
"zebra doesn't redistribute an IPv6 RA default route", then that's by
design and shouldn't be touched.
IPv6 RA is a router to host protocol. Routers should never accept
information from it, it is neither secure nor able to convey enough
details to prevent loops or dead-end routes.
This is also why enabling IPv6 forwarding disables reception of route
advertisements in-kernel.
If I understand correctly, your use-case is a mesh router that acts as a
host on a "parent" network. If so, this case should be handled by a
separate daemon that receives and processes IPv6 RAs, hopefully applies
some filtering. Also, this absolutely cannot be default behaviour.
If I misunderstood the issues, please ignore my mail.
Cheers,
-David
P.S.: Also, NetworkManager and Quagga should never run on the same host.
NetworkManager does Host processing, Quagga does Router processing, and
those two are mutually exclusive.
_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel
