Hi,
On Fri, 05 Dec 2008 09:43:25 -0800

Ben Greear  wrote:
> Patrick McHardy wrote:

quoted text
>

> >> Should what I'm doing be working or possible? If not, could something

> >> be added to the kernel to prevent macvlan interfaces being added to

> >> bridge instances, to stop other people spending time trying to do what

> >> I've tried to do?

> >

> > Unfortunately one of both combinations will not work, no matter

> > what we do. The bridge code could issue a warning when adding

> > a bridge on top of a macvlan device, but there's no clean indication

> > that something is a macvlan device besides dev->rtnl_link_ops->kind

> > being "macvlan".

>

> A mac-vlan can't really be PROMISC either since it only receives

> BCAST frames and packets destined for it's own MAC, so I can't see

> how it could work in a bridge....

> 

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?
> user-space brctl could check for the driver string returned by

quoted text
> ethtool API to check if no one wants any additional cruft in

> the kernel...

>

>

> 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?
Regards,

Mark.

--

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