<font face="tahoma" size="2"><p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;">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.</p>
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;">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.  And the limit of 4096 entries in many inexpensive switches is not a trivial limit.</p>
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;">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.</p>
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;">Remember, the Ethernet layer in WLANs is implemented by microcontrollers, typically not very capable ones, plus TCAMs which are pretty limited in their flexibility.</p>
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;">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.  Given that it does NOT cost more to do routing at the IP layer, building complex Ethernet bridging is not obviously a win.</p>
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;">BTW, TCAMs are used in IP layer switching, too, and also are used in packet filtering.  Maybe not in cheap consumer switches, but lots of Gigabit switches implement IP layer switching and filtering.  At HP, their switches routinely did all their IP layer switching entirely in TCAMs.</p>
<!--WM_COMPOSE_SIGNATURE_START--><!--WM_COMPOSE_SIGNATURE_END-->
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;"><br /><br />On Sunday, January 25, 2015 9:58pm, "Dave Taht" <dave.taht@gmail.com> said:<br /><br /></p>
<div id="SafeStyles1422241573">
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;">> On Sun, Jan 25, 2015 at 6:43 PM, David Lang <david@lang.hm> wrote:<br />> > On Sun, 25 Jan 2015, Dave Taht wrote:<br />> ><br />> >> To your roaming point, yes this is certainly one place where migrating<br />> >> bridged vms across machines breaks down, and yet more and more vm<br />> >> layers are doing it. I would certainly prefer routing in this case.<br />> ><br />> ><br />> > What's the difference between "roaming" and moving a VM from one place in<br />> > the network to another?<br />> <br />> I think most people think of "roaming" as moving fairly rapidly from one<br />> piece of edge connectivity to another, and moving a vm is a great deal more<br />> permanent operation.<br />> <br />> > As far as layer 2 vs layer 3 goes. If you try to operate at layer 3, you are<br />> > going to have quite a bit of smarts in the endpoint. Even if it's only<br />> > connected vi a single link. If you think about it, even if your network<br />> > routing tables list every machine in our environment individually, you still<br />> > have a problem of what gateway the endpoint uses. It would have to change<br />> > every time it moved. Since DHCP doesn't update frequently enough to be<br />> > transparent, you would need to have each endpoint running a routing<br />> > protocol.<br />> <br />> Hmm? I don't ever use a dhcp-supplied default gateway, I depend on the routing<br />> protocol to supply that. In terms of each vm running a routing protocol,<br />> well, no, I would rely on the underlying bare metal OS to be doing<br />> that, supplying<br />> the FIB tables to the overlying vms, if they need it, but otherwise the vms<br />> just see a "default" route and don't bother with it. They do need to inform the<br />> bare metal OS (better term for this please? hypervisor?) of what IPs they own.<br />> <br />> static default gateways are evil. and easily disabled. in linux you<br />> merely comment<br />> out the "routers" in /etc/dhcp/dhclient.conf, in openwrt, set<br />> "defaultroute 0" for the<br />> interface fetching dhcp.<br />> <br />> When a box migrates, it tells the hypervisor it's addresses, and then that box<br />> propagates out the route change to elsewhere.<br />> <br />> ><br />> > This can work for individual hobbiests, but not when you need to support<br />> > random devices (how would you configure an iPhone to support this?)<br />> <br />> Carefully. :)<br />> <br />> I do note that this stuff does (or at least did) work on some of the open<br />> source variants of android. I would rather like it if android added ipv6<br />> tethering soon, and made it possible to mesh together multiple phones.<br />> <br />> ><br />> ><br />> > Letting the layer 2 equipment deal with the traffic within the building and<br />> > invoking layer 3 to go outside the building (or to a different security<br />> > domain) makes a lot of sense. Even if that means that layer 2 within a<br />> > building looks very similar to what layer 3 used to look like around a city.<br />> <br />> Be careful what you wish for.<br />> <br />> ><br />> ><br />> > back to the topic of wifi, I'm not aware of any APs that participate in the<br />> > switch protocols at this level. I also don't know of any reasonably priced<br />> > switches that can do anything smarter than plain spanning tree when<br />> > connected through multiple paths (I'd love to learn otherwise)<br />> ><br />> > David Lang<br />> <br />> <br />> <br />> --<br />> Dave Täht<br />> <br />> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks<br />> </p>
</div></font>