From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id DB3A0200830 for ; Sun, 18 Mar 2012 14:27:33 -0700 (PDT) Received: by qcsp15 with SMTP id p15so1374570qcs.16 for ; Sun, 18 Mar 2012 14:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XHONDKw/pmhvwVWtVSaI3ntJ8QeRsZa5seZlwssLe9w=; b=ODLAkMrycSqHIwvANpt8YpUY+yIBsA2cXpBaLQiEZ26y2HsnwoLb/VkjX0vJW2SYUT OuN/Hxm8xyty0wwd4o5TH7kOWY2qZ6nw93tBggdnSl/+qFsyXVpT0e8pG7Qoi9oQCkSX yW4B9scAwvqvIRznKjrHFULSYM4c+yw8w6lhmuA+G/IVOQUwqBopmQhBdSU280PbGH7Y /4coRr5G8HJ28KiJlwqV5hnbxxbv8pRlcutbv9B15hfqYjWq7NSLgZpYMbzhOvILARs9 ir3UG6uuQmTvw5DoxilI5AoEqAtNFqV7T2oGCjLGJjPI62G3odrtbN2ptAP1CcXh1vGq eu8g== Received: by 10.224.220.211 with SMTP id hz19mr12560402qab.33.1332106052845; Sun, 18 Mar 2012 14:27:32 -0700 (PDT) Received: from [172.30.48.80] (c-50-138-169-248.hsd1.ma.comcast.net. [50.138.169.248]) by mx.google.com with ESMTPS id 1sm861202qac.3.2012.03.18.14.27.31 (version=SSLv3 cipher=OTHER); Sun, 18 Mar 2012 14:27:31 -0700 (PDT) Sender: Jim Gettys Message-ID: <4F665342.2080103@freedesktop.org> Date: Sun, 18 Mar 2012 17:27:30 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Dave Taht References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] mdns reflector issues on ipv6/babel routing through nat. 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: Sun, 18 Mar 2012 21:27:34 -0000 Oh, cool. Broadcast storms are soooo much fun... - Jim On 03/18/2012 05:24 PM, Dave Taht wrote: > On Sun, Mar 18, 2012 at 2:22 PM, Dave Taht wrote: >> Once you get to a few routers, a few deep, (3 in series in this case, >> 9 overall), the avahi mdns proxy starts to malfunction over ipv6, and >> I ended up with a rather nasty broadcast storm. >> >> So I had to disable the ipv6 multicast of mdns in order to get my >> network back in this (excessively) complex network. >> >> use-ipv6=no in the /etc/avahi/avahi-daemon file >> >> Seems to work fine, two deep. Curiously, I did not observe a similar >> storm for ipv4... >> >> Now this is across like 5 different versions of cerowrt, but it would >> not surprise me that this is a generic problem with avahi on ipv6, >> and/or a symptom of the brain-damaged-ness of mdns in the first place. >> >> use-ipv6=no >> >> I note that when you connect cero boxes together in a babel mesh >> configuration, site-local multicast is not a problem, because it >> doesn't work in the first place (by design). This can be construed as >> an advantage (no broadcast storm), or disadvantage (mdns and >> site-local multicast doesn't work across meshed links) > Actually I was wrong. I'm STILL observing a broadcast storm, AND it > is taking place across the meshed links too.... aggggh..... > >> Incidentally, I don't know if anyone would purposely inflict a network >> this complex on themselves: >> >> http://pastebin.com/LzeeiCXg >> >> but it does illustrate that a complex, automagically routed, fault >> tolerant ipv4 and ipv6 network IS feasible, so long as all internal >> addresses are unique. >> >> The biggest problem I run into is that 'failover-capable, >> fault-tolerant routing' introduces major headaches with firewall >> rules. >> >> Another thing the above paste illustrates that you can mix and match >> ipv4 nat with ipv6 fully meshed routing. >> >> The box I took that trace off has babel enabled on all interfaces, and >> has the following rule at the top of it's babeld.conf file >> >> out if ge00 ip 0.0.0.0/0 deny >> >> (as do multiple other boxes in the lab on the external network) >> >> this prohibits announcing ipv4 routes across the natted ge00 >> interface, but allows ipv6. In the caseof that paste, this particular >> router has NO internal wired connections at all, it just meshes >> internally for ipv4, and because ge00 is a higher quality (ethernet) >> interface, babel chooses it for the default for ipv6 for most routes. >> >> >> >> -- >> Dave Täht >> SKYPE: davetaht >> US Tel: 1-239-829-5608 >> http://www.bufferbloat.net > >