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 0F6BD21F200 for ; Sun, 25 Jan 2015 18:43:06 -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 t0Q2h38a010789; Sun, 25 Jan 2015 18:43:03 -0800 Date: Sun, 25 Jan 2015 18:43:03 -0800 (PST) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Dave Taht In-Reply-To: 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> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alexander Duyck , "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 02:43:35 -0000 On Sun, 25 Jan 2015, Dave Taht wrote: > To your roaming point, yes this is certainly one place where migrating > bridged vms across machines breaks down, and yet more and more vm > layers are doing it. I would certainly prefer routing in this case. What's the difference between "roaming" and moving a VM from one place in the network to another? As far as layer 2 vs layer 3 goes. If you try to operate at layer 3, you are going to have quite a bit of smarts in the endpoint. Even if it's only connected vi a single link. If you think about it, even if your network routing tables list every machine in our environment individually, you still have a problem of what gateway the endpoint uses. It would have to change every time it moved. Since DHCP doesn't update frequently enough to be transparent, you would need to have each endpoint running a routing protocol. This can work for individual hobbiests, but not when you need to support random devices (how would you configure an iPhone to support this?) Letting the layer 2 equipment deal with the traffic within the building and invoking layer 3 to go outside the building (or to a different security domain) makes a lot of sense. Even if that means that layer 2 within a building looks very similar to what layer 3 used to look like around a city. back to the topic of wifi, I'm not aware of any APs that participate in the switch protocols at this level. I also don't know of any reasonably priced switches that can do anything smarter than plain spanning tree when connected through multiple paths (I'd love to learn otherwise) David Lang