All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
Cc: Patrick McHardy <kaber@trash.net>, netdev@vger.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.
Date: Fri, 05 Dec 2008 09:43:25 -0800	[thread overview]
Message-ID: <4939683D.40406@candelatech.com> (raw)
In-Reply-To: <4937D494.8080202@trash.net>

Patrick McHardy wrote:

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

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

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


  reply	other threads:[~2008-12-05 17:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-04 10:03 Is it valid to add a macvlan virtual interface to a bridge? If so, there seems to be a bug with it Mark Smith
2008-12-04 13:01 ` Patrick McHardy
2008-12-05 17:43   ` Ben Greear [this message]
2008-12-05 22:54     ` Mark Smith
2008-12-06  0:08       ` Ben Greear
2008-12-06  0:26         ` Stephen Hemminger
2008-12-06  0:43           ` Ben Greear
2008-12-18  3:44   ` Herbert Xu
2009-01-12  4:55     ` Patrick McHardy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4939683D.40406@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=ipng@69706e6720323030352d30312d31340a.nosense.org \
    --cc=kaber@trash.net \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.