Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic?

[David Lang <david@lang.hm>]

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