netdev - Re: Is it valid to add a macvlan virtual interface to a bridge? If so, there seems to be a bug with it.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 5 Dec 2008 16:26:08 -0800
From:	Stephen Hemminger <shemminger@...tta.com>
To:	Ben Greear <greearb@...delatech.com>
Cc:	Mark Smith <ipng@...06e6720323030352d30312d31340a.nosense.org>,
	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.

On Fri, 05 Dec 2008 16:08:09 -0800
Ben Greear <greearb@...delatech.com> wrote:

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