Re: [Cerowrt-devel] [Babel-users] switching cerowrt to quagga-babeld issues

[dpreed@reed.com]

[-- Attachment #1: Type: text/plain, Size: 4183 bytes --]


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" <equinox@diac24.net>
Sent: Friday, July 6, 2012 12:59pm
To: "Dave Taht" <dave.taht@gmail.com>
Cc: "babel-users" <babel-users@lists.alioth.debian.org>, "cerowrt-devel" <cerowrt-devel@lists.bufferbloat.net>
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 <infrastation@yandex.ru> 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
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[-- Attachment #2: Type: text/html, Size: 5319 bytes --]