On Fri, 05 Dec 2008 16:08:09 -0800
Ben Greear <greearb@candelatech.com> wrote:
quoted text > 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.
>
Why bother, a macvlan is just a special case of a bridge, so why not
just bridge everything?
--
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
