[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <001001ca1a93$b6e50ee0$24af2ca0$@edu>
Date: Tue, 11 Aug 2009 07:55:04 -0700
From: "Paul Congdon \(UC Davis\)" <ptcongdon@...avis.edu>
To: "'Fischer, Anna'" <anna.fischer@...com>,
"'Arnd Bergmann'" <arnd@...db.de>
Cc: "'Stephen Hemminger'" <shemminger@...ux-foundation.org>,
<bridge@...ts.linux-foundation.org>,
<linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>,
<virtualization@...ts.linux-foundation.org>, <evb@...oogroups.com>,
<davem@...emloft.net>, <kaber@...sh.net>, <adobriyan@...il.com>,
"'Eric Biederman'" <ebiederm@...ssion.com>
Subject: RE: [PATCH][RFC] net/bridge: add basic VEPA support
> >
> > The patch from Eric Biederman to allow macvlan to bridge between
> > its slave ports is at
> >
> > http://kerneltrap.org/mailarchive/linux-netdev/2009/3/9/5125774
>
> Looking through the discussions here, it does not seem as if a decision
> was made to integrate those patches, because they would make the
> macvlan
> interface behave too much like a bridge. Also, it seems as if there was
> still a problem with doing multicast/broadcast delivery when enabling
> local VM-to-VM communication. Is that solved by now?
>
Also, is there a solution, or plans for a solution, to address macvtap
interfaces that are set to 'promiscuous' mode? It would seem fairly easy to
support this for interfaces that are simply trying to listen to the port
(e.g. Wireshark). If the port was being used by something like a firewall
then the VEPA filtering doesn't work too well.
Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists