Mark Smith wrote:
quoted text
> Hi,

quoted text
> 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.

quoted text
>> 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@candelatech.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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html