[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4939C269.4010609@candelatech.com>
Date: Fri, 05 Dec 2008 16:08:09 -0800
From: Ben Greear <greearb@...delatech.com>
To: Mark Smith <ipng@...06e6720323030352d30312d31340a.nosense.org>
CC: Patrick McHardy <kaber@...sh.net>, netdev@...r.kernel.org
Subject: Re: Is it valid to add a macvlan virtual interface to a bridge? If
so, there seems to be a bug with it.
Mark Smith wrote:
> Hi,
> Would handling of frames for promiscuous macvlan interfaces be quite
> similar to handling of incoming broadcast and multicast frames e.g.
> for an incoming frame, walk through the list of macvlan interfaces (or
> a separate list of promiscuous macvlan interfaces) that are currently in
> promiscuous mode, and hand them a copy of the incoming frame?
That could probably work.
>> You might try using a pair of VETH interfaces to bridge between
>> your host and virtual host.
>>
>
> What I was fundamentally trying to achieve was to avoid using any more
> than one physical interface on the box (excepting a separate
> management interface) to do this testing. While I happened to have
> another unused interface I could bridge this virtual host onto, in some
> cases you might not. Conceptually when using them, it is very easy to
> think of the macvlan interfaces as nothing very different to having
> multiple physical interfaces sitting on the same LAN segment. In my
> scenario, bridging only one of them for this specific case of a
> virtual guest host seemed like quite a logical thing to do.
>
> Would veth interfaces facilitate the sharing of a single physical
> interface between bridged and non-bridged processes on the host?
A Veth pair is like two ports linked back to each other..what is tx'd on one
is rx'd on the other.
You could probably add eth0, veth1a, veth2a to a bridge,
then add macvlans on veth1b and have your virtual guest
talk to veth2b.
I do similar things with my redirdev devices, which are almost identical
to veths, so I think it will work.
Thanks,
Ben
--
Ben Greear <greearb@...delatech.com>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists