Re: [PATCH net-next 0/4] Allow bridge to function in non-promisc mode

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Mar 13, 2013 at 01:04:51PM -0400, Vlad Yasevich wrote:
> On 03/13/2013 12:09 PM, Stephen Hemminger wrote:
> >On Wed, 13 Mar 2013 11:45:40 -0400
> >Vlad Yasevich <vyasevic@redhat.com> wrote:
> >
> >>On 03/13/2013 11:39 AM, Stephen Hemminger wrote:
> >>>On Wed, 13 Mar 2013 08:12:29 -0400
> >>>Vlad Yasevich <vyasevic@redhat.com> wrote:
> >>>
> >>>>On 03/13/2013 02:22 AM, "Oleg A. Arkhangelsky" wrote:
> >>>>>
> >>>>>
> >>>>>13.03.2013, 05:45, "Vlad Yasevich" <vyasevic@redhat.com>:
> >>>>>
> >>>>>>The series adds an ability for the bridge to function in non-promiscuous mode.
> >>>>>
> >>>>>What is the practical applications for such setup? In other words,
> >>>>>in which cases I would want to put bridge into non-promiscuous
> >>>>>mode and specify some uplink ports?
> >>>>>
> >>>>
> >>>>On of the applications would be when bridge is an edge device servicing
> >>>>a VM deployment.  Each of the VMs knows the mac address that the guest
> >>>>has and may program that mac onto the uplinks.
> >>>
> >>>Why wouldn't that environment just use macvlan?
> >>>Is it because changing libvirt is harder than changing the kernel?
> >>>
> >>
> >>No, because macvlan has a drawback that it doesn't easily let guests
> >>talk to the host.  Bridge is still most commonly used for just that reason.
> >>
> >>-vlad
> >
> >Maybe fixing that with a flag to macvlan would be easier?
> >
> 
> Not really.  macvlan to physical device could be made simple enough.
> However, physical to macvlan is non-trivial at all.
> 
> We get around this right now by crating a macvlan on the host and
> have macvlan to macvlan communication essentially turning it into
> bridge.  But that doesn't work in all scenarios either.
> 
> -vlad

Yea macvlan bridged mode is a strange beast.  It almost wants to be a
bridge, but does not dare, for example it punts on all the issues we
have fixed in the bridge like multicast snooping, and just floods
packets.

Another issue is that different VMs have different needs. You might want
to run VMs that simply use a single MAC, so no need for promisc mode,
then want to start another VM that does bridging so we need to enable
promisc mode dynamically. I guess we could switch from macvtap to
tap and back, but it's pretty nasty.

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