From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.etorok.net (mail.etorok.net [IPv6:2a01:4f8:160:1223::beef:2]) by huchra.bufferbloat.net (Postfix) with ESMTP id EBD2821F0A2 for ; Fri, 17 Aug 2012 12:05:48 -0700 (PDT) Received: from [IPv6:2a02:2f02:1022:727d:1e6f:65ff:fe23:db0d] (unknown [IPv6:2a02:2f02:1022:727d:1e6f:65ff:fe23:db0d]) by mail.etorok.net (Postfix) with ESMTPSA id 5A36F46A8; Fri, 17 Aug 2012 21:05:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=etorok.net; s=MAILOUT; t=1345230347; bh=vPjY3LWvGppPBJ4rGBWDrd/lnXaX1FA9U9FPisg72pI=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=O3Fqg49/4uNisR+bE7MnGmwKCYfqPnBjc9tBiEk2HhHaHasPkm7VQApVU9icLSVk9 ZBKRiWUCUmS/RV7m1j65sRWTOUmavkbYPr5TfkQQ6bPW0ppkD77moDmG9NTOQ34H4p X6SqOoWWP3kwZU1nPxGh3ugEUPYHKH2L/jAL6NVw= Message-ID: <502E9609.5040800@etorok.net> Date: Fri, 17 Aug 2012 22:05:45 +0300 From: =?ISO-8859-1?Q?T=F6r=F6k_Edwin?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6 MIME-Version: 1.0 To: Dave Taht References: <502E064C.50305@etorok.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.5 at mail X-Virus-Status: Clean Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] cerowrt 3.3.8-17: nice latency improvements, some issues with bind 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: Fri, 17 Aug 2012 19:05:49 -0000 On 08/17/2012 09:05 PM, Dave Taht wrote: > I'm widening the distribution of this email a little bit in light of > the benchmark results (somewhat too far) below, and some of the other > issues raised. [ok, will write a separate reply for the benchmark numbers] > > On Fri, Aug 17, 2012 at 1:52 AM, Török Edwin > wrote: >> However I've encountered some issues with bind. After powering on the router this morning DNS wasn't working, >> and logread showed a lot of errors from bind about a broken trust chain on every domain name. >> Any idea what could've caused this behaviour? > > This is http://www.bufferbloat.net/issues/113 (relevant bugs have also > been filed in the dnssec and ntp databases) > > a long standing circular problem between getting accurate time via ntp > and dns, so that dnssec can be enabled. I was using unbound on openwrt for dnssec before and I haven't noticed this problem. However I had some .ro time servers configured, and apparently they use quite a wide range for their RRSIG, so maybe I was just lucky not to hit a situation where both .ro and .org would fail to validate. RRSIG NS 5 2 7200 20120819122953 20120720122953.... RRSIG NSEC 8 1 86400 20120824000000 20120816230000 ... While the .org RRSIG has quite a recent timestamp: org. 900 IN RRSIG SOA 7 1 900 20120907184119 20120817174119 Added the .ro timeservers to cerowrt now, and will see if the problem occurs again. >> Another minor issue is that p910nd and luci-app-p910nd were not available via opkg install, but I found them on openwrt.org, so that works now. > > I don't know what they are but I can enable them in the next build. Thanks, they are a simple way to share your USB printer across the network without running CUPS on the router itself. > >> DHCPv6-PD had to be configured manually of course, same as with openwrt, the difference is that I only get IPv6 on wired interfaces now, >> and not on wireless. >> That seems to be by design because the interfaces are not bridged anymore and I get only a /64 from my ISP (slan_len 0), so can't really create >> more sub-networks from it. > > As multiple providers seem to think that a single /64 "is all you > need", despite the prevalence of guest and other sorts of secondary > networks on ipv4. This is a HUGE problem on the current native ipv6 > deployments. > > Note that it's not exactly fair to blame the providers, most of the > home CPE gear they are dealing with can barely handle ipv6 in the > first place, being based on ancient kernels and specifications. That > gear is improving, all too slowly, with things like openwrt/cerowrt in > the lead.... (apple seems to be doing fairly well, too) > > Having only a single /64 delegated makes ipv6 unusable IMHO. Still usable on my main machine, a pain to make it work with VMs though. (only way I could make it work was to bridge them to host's ethernet). > > I (or rather juliusz) solved the single /64-only problem years ago by > switching to using babel and ahcp, which pushes out ipv6 /128 ips. > This method has the added benefit of making switching between multiple > wired and wireless APs utterly transparent, even for long held TCP > connections. Thanks, will have to try that out. > > I run my own networks this way whenever possible, as it's *really > nice* to be able to unplug and not lose 20 ssh connections, and plug > back in, to get bandwidth, and have babel figure out the right way to > go automagically. > > However fixing both the APs and the hosts (via adding ahcp and babel) > is kind of fixing a global infrastructure issue that is hard to get > the rest of the world to agree to, and things like network manager > don't think this way, either... But I'm glad to see progress being > made in homenet towards having a flooding prefix distribution protocol > based on something like ahcp, this will cut down on NAT usage in ipv4 > and lead to a more flexible network in the future. - and I'm sure more > and more native deployments will delegate /60s or better in the > future. > > Using dhcpv6 it is also possible to do allocations of /80s but this > breaks the 95% of all devices that only can do SLAAC. > > It is best to get at least a /60 delegation from the ISP. They probably won't listen. For the amount I pay them I'm happy I get IPv6 at all :) > > My way of coping with the half-arsed single /64 delegation ipv6 native > deployments I've dealt with thus far has been 6to4 and 6in4, which do > /48s. I get slightly higher throughput in IPv6 though (75 Mbps vs 45 Mbps). Apparenly ISP forgot to shape my IPv6 traffic the same way it does with my IPv4. Although... if I have QoS enabled in cerowrt and I set download speed limit to 47000 kbit/s I'm still able to do 62000kbit/s with wget. If I set the limit to 27000 then wget -4 speed drops to 24000 kbit/s, but -6 speed stays the same. Doesn't QoS apply to IPv6 as well? > IF you'd like to have more bandwidth back, you can jiggle the qlen_* > variables in the debloat script up, but remember that tcp's reaction > time is quadratic as to the amount of buffering. I'd be interested in > you repeating your benchmark after doing that? The difference between > 3 buffers and 8 is pretty dramatic... Will do, and report back (to both ML). Thanks for the detailed reply. --Edwin