From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (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 32DA821F2E6 for ; Mon, 26 Jan 2015 16:23:18 -0800 (PST) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t0R0NHED016380; Mon, 26 Jan 2015 16:23:17 -0800 Date: Mon, 26 Jan 2015 16:23:17 -0800 (PST) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: dpreed@reed.com In-Reply-To: <1422317644.389812775@apps.rackspace.com> Message-ID: References: <54B5D28A.3010906@gmail.com> <7B1EA8F0-FCB6-4A37-950F-2558FC751DE8@gmail.com> <54C038D0.1000305@gmail.com> <54C0BD22.3000608@gmail.com> <54C13F47.1010203@gmail.com> <1422111577.328132080@apps.rackspace.com> <1422217048.025611275@apps.rackspace.com> <1422237076.005718796@apps.rackspace.com> <11462.1422246794@turing-police.cc.vt.edu> <1422317644.389812775@apps.rackspace.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic? 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: Tue, 27 Jan 2015 00:23:47 -0000 it doesn't get mixed in with tracking Internet routes as well. On Mon, 26 Jan 2015, dpreed@reed.com wrote: > And having every /48 MAC address in your entterprise tracked is cheaper? > > > On Sunday, January 25, 2015 11:44pm, "David Lang" said: > > > >> On Sun, 25 Jan 2015, Valdis.Kletnieks@vt.edu wrote: >> >> > On Sun, 25 Jan 2015 18:09:59 -0800, David Lang said: >> >> The difference is that the switches and their protocols have been >> designed from >> >> the beginning for this scale of operation, IP routing protocols are >> designed for >> >> much fewer endpoints to track. >> > >> > Anybody who's carrying a full routing table was swallowing on the order >> > of 528,833 routes (as of Friday's "weekly routing table report" posted >> > to NANOG). Pretty much everybody and their pet llama accepts full tables >> > thesedays. >> > >> > You know anybody who's doing that many entries in an L2 Ethernet broadcast >> > domain? >> >> The full IP routing tables are something that you normally only have to deal >> with in a few devices at the perimeter of your network. >> >> What is being talked about here is routing each /32 IP address individually >> throughout your network so that any IP address can be connected anywhere and >> have it 'just work' as far as the client on that IP is concerned. >> >> David Lang >>