Date:	Mon, 09 Mar 2009 14:31:46 +0100
From:	Patrick McHardy <kaber@...sh.net>
To:	Mark Smith 
	<nanog@...5b20a518b8f6864949bd940457dc124746ddc.nosense.org>
CC:	greearb@...delatech.com, David Miller <davem@...emloft.net>,
	netdev@...r.kernel.org,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	shemminger@...ux-foundation.org
Subject: Re: MACVLANs really best solution? How about a bridge with multiple
 bridge virtual interfaces? (was Re: [PATCH] macvlan: Support creating macvlans
 from macvlans)

Mark Smith wrote:
> Hi,
> 
> Ben said,
>> I wouldn't deny sending with wrong source mac..ethernet interfaces can 
>> do this,
>> and mac-vlan should look as much like ethernet is possible.
> 
> I agree, however there's further things that mac-vlans aren't
> currently doing as virtual ethernet interfaces that real ones do.
> Unicast ethernet traffic sent out one mac-vlan interface with a
> destination address of another mac-vlan interface on the same host
> isn't delivered. mac-vlan interfaces, even though they're conceptually
> located on the same ethernet segment, are currently isolated from each
> other for unicast traffic.
> 
> Thinking about the few scenarios where I've been using mac-vlans, it
> seems to me that the fundamental goal of mac-vlans is to be
> functionaly equivalent to having multiple physical ethernet network
> cards attached to the same LAN segment, with those physical
> interfaces attached together via a switch or a hub.
> 
> Virtualising that scenario using mac-vlans and a single physical
> interface means that the outbound mac-vlan code on a host needs to
> replicate the functionality of a switch or a hub. Outbound unicast
> traffic from one mac-vlan interface needs to be either seen by the
> destination address matching code of all other mac-vlan interfaces (i.e.
> replicating hub functionality), or selectively forwarded to the
> intended mac-vlan interface (replicating switch functionality). If the
> unicast destination doesn't match one of the other mac-vlan interfaces,
> then it should be forwarded out the mac-vlan interfaces' parent physical
> interface, as the destination is likely to be on the physical ethernet.
> Blindly forwarding the outbound mac-vlan origin traffic out the physical
> interface doesn't solve the problem - switches (and I'm pretty sure at
> least functionaly, hubs) don't forward traffic back out the interface
> they receive it on. So the hub/switch forwarding functionality between
> mac-vlan interfaces and their parent physical interface needs to happen
> within the kernel.
> 
> I've been thinking of having a go at adding this functionality. But
> then I realised that that would just be more duplication of the
> functionality of the code that is aleady in the kernel - the bridging
> code. It does all those things already.
> 
> It seems to me that the only reason the bridging code can't be used
> today for "mac-vlan" functionality is that it only allows creation of a
> single bridge virtual interface. If the bridging code and associated
> utilities were extended to support multiple virtual interfaces
> (possibly with the first interface being the "handle" interface for the
> bridge instance), then the mac-vlan code would be redundant.
> Conceptually, it'd also be more consistent with some of the other
> mechanisms that can be added to a bridge, such as adding tap, dummy or
> other virtual interfaces to a bridge in conjunction with multiple bridge
> virtual interfaces - a scenario I tried to do a while back and asked
> about in December in a post titled, "Is it valid to add a macvlan
> virtual interface to a bridge? If so, there seems to be a bug with it."
> 
> Using the bridge method wouldn't allow the real physical
> interface to be used as a normal e.g. IP interface, as is allowed when
> using mac-vlans. But I don't think is much of an issue - another bridge
> virtual interface could be created to be used instead.

I agree on most points. There is one fundamental operational difference
however. With macvlan, all MAC addresses are known are therefore can be
programmed as secondary unicast addresses, while a bridge always uses
promiscous mode and for unknown addresses needs to flood forward them.

This could be changed in the bridging code of course for bridges
consisting purely of local devices. Most of the bridging stuff isn't
needed for macvlans though, so its probably easier to simply perform
a lookup for local devices in macvlan on transmit, similar to what
is done on reception.


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists