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 16:08:09 -0800	[thread overview]
Message-ID: <4939C269.4010609@candelatech.com> (raw)
In-Reply-To: <20081206092448.0c83d606.ipng@69706e6720323030352d30312d31340a.nosense.org>

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.

Thanks,
Ben

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


  reply	other threads:[~2008-12-06  0:08 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
2008-12-05 22:54     ` Mark Smith
2008-12-06  0:08       ` Ben Greear [this message]
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=4939C269.4010609@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.