From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id D080021F202 for ; Sun, 25 Jan 2015 18:58:45 -0800 (PST) Received: by mail-oi0-f49.google.com with SMTP id a3so5358034oib.8 for ; Sun, 25 Jan 2015 18:58:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=9R71xmXxajOzw1idIWW3yo0A0D0oHAbctPULdABArIA=; b=B+I2s3FJ4G5kmcVTJFYk+5ciJjUWGJTFaf45duEGrUSwYTKjbYjazljuuVziB2hE/Q gOouHhieULhGDRLZz8EQe46xV8nMIk2uYWFEGR/SZKRPfe8uyqUGMmYHTJhPMtZJ9VZb qxv8KptVNZmKNk0TTTusyqm6ViJvSxrDqkKuzqVSbFWEamRRAhF1D9SUMN+ySkteBdwE 4VY+osH7mc272WhiifNPq8ocT5pz8HoUE4Vt2fpDSElyrr3x/wTplqD1xadtDAfRSRxU ImVs5lP15IcqsVPMOER4UvoFItTk5AuePRgurEL0Wnu0LQ7oY5T9YWJQGsfgvLgL8+5H v1dA== MIME-Version: 1.0 X-Received: by 10.182.27.164 with SMTP id u4mr11609471obg.63.1422241124633; Sun, 25 Jan 2015 18:58:44 -0800 (PST) Received: by 10.202.51.66 with HTTP; Sun, 25 Jan 2015 18:58:44 -0800 (PST) In-Reply-To: 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> Date: Sun, 25 Jan 2015 18:58:44 -0800 Message-ID: From: Dave Taht To: David Lang Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 02:59:14 -0000 On Sun, Jan 25, 2015 at 6:43 PM, David Lang wrote: > 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? I think most people think of "roaming" as moving fairly rapidly from one piece of edge connectivity to another, and moving a vm is a great deal more permanent operation. > 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 st= ill > 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. Hmm? I don't ever use a dhcp-supplied default gateway, I depend on the rout= ing protocol to supply that. In terms of each vm running a routing protocol, well, no, I would rely on the underlying bare metal OS to be doing that, supplying the FIB tables to the overlying vms, if they need it, but otherwise the vms just see a "default" route and don't bother with it. They do need to inform= the bare metal OS (better term for this please? hypervisor?) of what IPs they o= wn. static default gateways are evil. and easily disabled. in linux you merely comment out the "routers" in /etc/dhcp/dhclient.conf, in openwrt, set "defaultroute 0" for the interface fetching dhcp. When a box migrates, it tells the hypervisor it's addresses, and then that = box propagates out the route change to elsewhere. > > This can work for individual hobbiests, but not when you need to support > random devices (how would you configure an iPhone to support this?) Carefully. :) I do note that this stuff does (or at least did) work on some of the open source variants of android. I would rather like it if android added ipv6 tethering soon, and made it possible to mesh together multiple phones. > > > Letting the layer 2 equipment deal with the traffic within the building a= nd > 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 ci= ty. Be careful what you wish for. > > > back to the topic of wifi, I'm not aware of any APs that participate in t= he > switch protocols at this level. I also don't know of any reasonably price= d > switches that can do anything smarter than plain spanning tree when > connected through multiple paths (I'd love to learn otherwise) > > David Lang --=20 Dave T=C3=A4ht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks