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 8215D21F1D4 for ; Sun, 25 Jan 2015 19:32:31 -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 t0Q3WRak010921; Sun, 25 Jan 2015 19:32:27 -0800 Date: Sun, 25 Jan 2015 19:32:27 -0800 (PST) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: dpreed@reed.com In-Reply-To: <1422242279.46066942@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> <1422242279.46066942@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: Mon, 26 Jan 2015 03:32:59 -0000 On Sun, 25 Jan 2015, dpreed@reed.com wrote: > Looking up an address in a routing table is o(1) if the routing table is a > hash table. That's much more efficient than a TCAM. My simple example just > requires a delete/insert at each node's route lookup table. > > My point was about collections of WLAN's bridged together. Look at what > happens (at the packet/radio layer) when a new node joins a bridged set of > WLANs using STP. It is not exactly simple to rebuild the Ethernet layer's > bridge routing tables in a complex network. How would it be any easier to rebuild the routing table? (even ignoring the question of what the devices use as their gateway) > And the limit of 4096 entries in many inexpensive switches is not a trivial > limit. Getting similar number of ports that all can be routed is significantly more expensive. Yes, the mid-range switches can run layer 3 routing, but they are far less efficient at doing so than they are at switching. > Routers used to be memory-starved (a small number of KB of RAM was the norm). > Perhaps the thinking then (back before 2000) has not been revised, even though > the hardware is a lot more capacious. well, you do have to remember that most of the routing protocols were designed in the days of those limits. > Remember, the Ethernet layer in WLANs is implemented by microcontrollers, > typically not very capable ones, plus TCAMs which are pretty limited in their > flexibility. > > While it is tempting to use the "pre-packaged, proprietary" Ethernet switch > functionality, routing gets you out of the binary blobs, and let's you be a > lot smarter and more scalable. how do I run my own software on a HP switch to eliminate the binary blobs? How do I get similar performance on something with a dozen or more ports? From a theoretical point of view, you are absolutly correct, but there isn't an open equivalent available. This is even before you start talking about what's coded into the ASICs on the higher end switches, which while they are limited in what they can do, within those limits they will massivly outperform the other options. > Given that it does NOT cost more to do routing > at the IP layer, building complex Ethernet bridging is not obviously a win. Ok, if it's not more expensive to do this. Exactly how would I set this up? remember that I have no ability to make any changes to the clients (iphones, android, Linux, Windows, Macs) I can't have them all running a routing protocol to have them figure out what gateway to use as they move from AP to AP. not using 'cheap' commodity switches would make it more expensive (in my case we invested in buying a bunch of HP switches a couple years ago) David Lang