From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp161.iad.emailsrvr.com (smtp161.iad.emailsrvr.com [207.97.245.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 334A2200AEE for ; Sat, 7 Jul 2012 08:53:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp56.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 99DFA3D911A; Sat, 7 Jul 2012 11:53:05 -0400 (EDT) X-Virus-Scanned: OK Received: from legacy7.wa-web.iad1a (legacy7.wa-web.iad1a.rsapps.net [192.168.2.216]) by smtp56.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 62DC83D910A; Sat, 7 Jul 2012 11:53:05 -0400 (EDT) Received: from reed.com (localhost [127.0.0.1]) by legacy7.wa-web.iad1a (Postfix) with ESMTP id 4EE5B3200B0; Sat, 7 Jul 2012 11:53:05 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Sat, 7 Jul 2012 11:53:05 -0400 (EDT) Date: Sat, 7 Jul 2012 11:53:05 -0400 (EDT) From: dpreed@reed.com To: "David Lamparter" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20120707115305000000_30998" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <20120706165935.GB2916974@jupiter.n2.diac24.net> References: <7isjdcpm1q.fsf@lanthane.pps.jussieu.fr> <40851341093226@web25d.yandex.ru> <7ik3yoz7p2.fsf@lanthane.pps.jussieu.fr> <1521341229978@web13h.yandex.ru> <206861341262491@web23d.yandex.ru> <458481341303008@web7d.yandex.ru> <751571341318910@web30g.yandex.ru> <20120706165935.GB2916974@jupiter.n2.diac24.net> Message-ID: <1341676385.321916162@apps.rackspace.com> X-Mailer: webmail7.0 Cc: cerowrt-devel , babel-users Subject: Re: [Cerowrt-devel] [Babel-users] switching cerowrt to quagga-babeld issues X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jul 2012 15:53:07 -0000 ------=_20120707115305000000_30998 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AHere's the architectural issue at the root of this issue (I think):=0A = =0A"P.S.: Also, NetworkManager and Quagga should never run on the same host= .=0ANetworkManager does Host processing, Quagga does Router processing, and= =0Athose two are mutually exclusive."=0A =0AIt should be the case that a ho= st 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 ach= ieve (maybe impossible without careful isolation of all the parts). If so,= it is a Linux stack issue that arises from mingling host and router datagr= ams in a way that does not fully separate them.=0A =0ASo, it could be viewe= d as a bug in Linux (including NetworkManager and Quagga) that that separat= ion is not achievable(achieved). NetworkManager spans the layers and mana= ges Ethernet mostly, but sometimes views it through the IP lens, making som= e assumptions that are not always valid architectural invariants. NetworkM= anager assumes that there is only one primary host IP interface, for exampl= e, as I recall, even though IPv6 especially supports many IPv6 addresses in= the same box for Hosts and for routers.=0A =0ASo the interfaces and IP add= resses for the router must be managed separately from those in the host, ev= en if on the same box.=0A =0AThe 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/o= r 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 straightfor= ward with no gotchas). This would separate the host interfaces from the ro= uter ones unambiguously.=0A =0AThen let NetworkManager see only the host-co= ntrolled interface, but let the other interfaces be out of NetworkManager's= control.=0A =0A =0A =0A =0A-----Original Message-----=0AFrom: "David Lampa= rter" =0ASent: Friday, July 6, 2012 12:59pm=0ATo: "Dave= Taht" =0ACc: "babel-users" , "cerowrt-devel" =0ASubjec= t: Re: [Cerowrt-devel] [Babel-users] switching cerowrt to quagga-babeld iss= ues=0A=0A=0A=0AOn Tue, Jul 03, 2012 at 09:18:43AM -0400, Dave Taht wrote:= =0A> On Tue, Jul 3, 2012 at 8:35 AM, Denis Ovsienko wrote:=0A> >> Does anybody know where this difference comes from?=0A> >= =0A> > The difference comes from NetworkManager. Its efforts in reproducing= =0A> > high-metric RTPROT_KERNEL routes with low-metric RTPROT_STATIC ones= =0A> > are effectively hiding the kernel issue outside of CeroWrt runtime.= =0A> > Would it be better to add a watchdog shell script, which does the=0A= > > same, or patch the kernel?=0A> =0A> I would *much rather* patch the ker= nel than have a watchdog. However I=0A> don't quite understand=0A> the redi= stribution issue vs a vs ipv6 here. If I have a "redistribute=0A> kernel" o= n for ipv4, it does propagate the default route.=0A=0AI'm not sure I unders= tood your problem here, but if it boils down to=0A"zebra doesn't redistribu= te an IPv6 RA default route", then that's by=0Adesign and shouldn't be touc= hed.=0A=0AIPv6 RA is a router to host protocol. Routers should never accep= t=0Ainformation from it, it is neither secure nor able to convey enough=0Ad= etails to prevent loops or dead-end routes.=0A=0AThis is also why enabling = IPv6 forwarding disables reception of route=0Aadvertisements in-kernel.=0A= =0AIf I understand correctly, your use-case is a mesh router that acts as a= =0Ahost on a "parent" network. If so, this case should be handled by a=0As= eparate daemon that receives and processes IPv6 RAs, hopefully applies=0Aso= me filtering. Also, this absolutely cannot be default behaviour.=0A=0AIf I= misunderstood the issues, please ignore my mail.=0A=0ACheers,=0A=0A=0A-Dav= id=0A=0A=0AP.S.: Also, NetworkManager and Quagga should never run on the sa= me host.=0ANetworkManager does Host processing, Quagga does Router processi= ng, and=0Athose two are mutually exclusive.=0A_____________________________= __________________=0ACerowrt-devel mailing list=0ACerowrt-devel@lists.buffe= rbloat.net=0Ahttps://lists.bufferbloat.net/listinfo/cerowrt-devel ------=_20120707115305000000_30998 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Here's the= architectural issue at the root of this issue (I think):

=0A

 

=0A

"P.S.: = Also, NetworkManager and Quagga should never run on the same host.
Net= workManager does Host processing, Quagga does Router processing, and
t= hose two are mutually exclusive."

=0A

&n= bsp;

=0A

It should be the case that a ho= st 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 h= ard to achieve (maybe impossible without careful isolation of all the parts= ).  If so, it is a Linux stack issue that arises from mingling host an= d router datagrams in a way that does not fully separate them.

=0A

 

=0A

So= , it could be viewed as a bug in Linux (including NetworkManager and Quagga= ) that that separation is not achievable(achieved).   NetworkMana= ger spans the layers and manages Ethernet mostly, but sometimes views it th= rough the IP lens, making some assumptions that are not always valid archit= ectural invariants.  NetworkManager assumes that there is only one pri= mary host IP interface, for example, as I recall, even though IPv6 especial= ly supports many IPv6 addresses in the same box for Hosts and for routers.<= /p>=0A

 

=0A

So the interfaces and IP addresses for the router must be managed= separately from those in the host, even if on the same box.

=0A

 

=0A

The = easiest way to do a very clean separation in Linux when sharing the physica= l NICs as link-endpoints among router and host functions is perhaps using v= irtualization of the NICs with VLANs and/or the TAP interface providing a v= irtual link between the router and host on the same box.  (I haven't s= tudied this in detail, but it seems straightforward with no gotchas). = This would separate the host interfaces from the router ones unambiguously= .

=0A

 

=0A

Then let NetworkManager see only the host-controlled interface,= but let the other interfaces be out of NetworkManager's control.

=0A

 

=0A

 

=0A

 

=0A

 

=0A

-----Origin= al Message-----
From: "David Lamparter" <equinox@diac24.net>
Sent: Friday, July 6, 2012 12:59pm
To: "Dave Taht" <dave.taht@gma= il.com>
Cc: "babel-users" <babel-users@lists.alioth.debian.org&g= t;, "cerowrt-devel" <cerowrt-devel@lists.bufferbloat.net>
Subjec= t: Re: [Cerowrt-devel] [Babel-users] switching cerowrt to quagga-babeld iss= ues

=0A
=0A

On Tue, Jul 03, 2012 at 09:18:43AM -0400, Dave Taht wrote:<= br />> On Tue, Jul 3, 2012 at 8:35 AM, Denis Ovsienko <infrastation@y= andex.ru> wrote:
> >> Does anybody know where this differe= nce comes from?
> >
> > The difference comes from Net= workManager. Its efforts in reproducing
> > high-metric RTPROT_K= ERNEL routes with low-metric RTPROT_STATIC ones
> > are effectiv= ely hiding the kernel issue outside of CeroWrt runtime.
> > Woul= d it be better to add a watchdog shell script, which does the
> >= ; same, or patch the kernel?
>
> I would *much rather* pat= ch the kernel than have a watchdog. However I
> don't quite underst= and
> the redistribution issue vs a vs ipv6 here. If I have a "redi= stribute
> kernel" on for ipv4, it does propagate the default route= .

I'm not sure I understood your problem here, but if it boils d= own to
"zebra doesn't redistribute an IPv6 RA default route", then tha= t's by
design and shouldn't be touched.

IPv6 RA is a router= to host protocol. Routers should never accept
information from it, i= t is neither secure nor able to convey enough
details to prevent loops= or dead-end routes.

This is also why enabling IPv6 forwarding d= isables reception of route
advertisements in-kernel.

If I u= nderstand correctly, your use-case is a mesh router that acts as a
hos= t on a "parent" network. If so, this case should be handled by a
sepa= rate daemon that receives and processes IPv6 RAs, hopefully applies
so= me filtering. Also, this absolutely cannot be default behaviour.

If I misunderstood the issues, please ignore my mail.

Cheers,<= br />

-David


P.S.: Also, NetworkManager and Qua= gga should never run on the same host.
NetworkManager does Host proces= sing, Quagga does Router processing, and
those two are mutually exclus= ive.
_______________________________________________
Cerowrt-deve= l mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.= bufferbloat.net/listinfo/cerowrt-devel

=0A
 ------=_20120707115305000000_30998--