From: Dave Taht <dave.taht@gmail.com>
To: David Lang <david@lang.hm>
Cc: "cerowrt-devel@lists.bufferbloat.net"
<cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic?
Date: Sun, 25 Jan 2015 18:58:44 -0800 [thread overview]
Message-ID: <CAA93jw4wr+UeSdYK+y8U2S6K=KCiKN0Z7LUn__aAjBTw2qowrg@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1501251821500.19609@nftneq.ynat.uz>
On Sun, Jan 25, 2015 at 6:43 PM, David Lang <david@lang.hm> 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 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.
Hmm? I don't ever use a dhcp-supplied default gateway, I depend on the routing
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 own.
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 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.
Be careful what you wish for.
>
>
> 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
--
Dave Täht
thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
next prev parent reply other threads:[~2015-01-26 2:58 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-14 2:20 Richard Smith
2015-01-20 16:59 ` Rich Brown
2015-01-21 23:40 ` Richard Smith
2015-01-21 23:58 ` David Lang
2015-01-22 9:04 ` Richard Smith
2015-01-22 9:18 ` David Lang
2015-01-22 18:19 ` Richard Smith
2015-01-22 22:09 ` David Lang
2015-01-22 22:55 ` Roman Toledo Casabona
2015-01-24 14:59 ` dpreed
2015-01-24 15:30 ` Kelvin Edmison
2015-01-25 4:35 ` David Lang
2015-01-25 5:02 ` Dave Taht
2015-01-25 5:04 ` Dave Taht
2015-01-25 6:44 ` David Lang
2015-01-25 7:06 ` David Lang
[not found] ` <CAA93jw64KjW-JjLxB3i_ZK348NCyJYSQACFO34MaUsBBWyZ+pA@mail.gmail.com>
2015-01-25 7:59 ` Dave Taht
2015-01-25 9:39 ` David Lang
2015-01-25 15:03 ` Chuck Anderson
2015-01-25 20:17 ` dpreed
2015-01-25 23:21 ` Aaron Wood
2015-01-25 23:57 ` David Lang
2015-01-26 1:51 ` dpreed
2015-01-26 2:09 ` David Lang
2015-01-26 4:33 ` Valdis.Kletnieks
2015-01-26 4:44 ` David Lang
2015-01-27 0:14 ` dpreed
2015-01-27 0:23 ` David Lang
2015-01-26 2:19 ` Dave Taht
2015-01-26 2:43 ` David Lang
2015-01-26 2:58 ` Dave Taht [this message]
2015-01-26 3:17 ` dpreed
2015-01-26 3:32 ` David Lang
2015-01-26 3:45 ` Dave Taht
2015-01-27 0:12 ` dpreed
2015-01-27 0:31 ` David Lang
2015-01-27 0:36 ` Dave Taht
2015-01-26 3:19 ` David Lang
2015-01-26 4:25 ` Valdis.Kletnieks
2015-01-26 4:39 ` David Lang
2015-01-26 16:42 ` Valdis.Kletnieks
2015-01-25 8:07 ` Outback Dingo
2015-01-30 16:14 ` Richard Smith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAA93jw4wr+UeSdYK+y8U2S6K=KCiKN0Z7LUn__aAjBTw2qowrg@mail.gmail.com' \
--to=dave.taht@gmail.com \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=david@lang.hm \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox