lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 07 Mar 2009 08:30:49 -0800
From:	Ben Greear <greearb@...delatech.com>
To:	Mark Smith 
	<nanog@...5b20a518b8f6864949bd940457dc124746ddc.nosense.org>
CC:	Patrick McHardy <kaber@...sh.net>,
	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.
>   
At least for my use, having them all blindly TX is fine.  For thousands
of interfaces, if you did this right and also delivered all broadcast 
packets locally
(ie, ARP), you will cause a lot of overhead, and unless you are running 
a patched
kernel (or namespaces perhaps), you can't really communicate with 
yourself over the
network anyway using IP.

For the behaviour you want, try adding pairs of VETH interfaces and add 
one end
of the veth's to the bridge.  Add a physical port to the bridge for 
egress.  Since this
can be done, I don't really see any reason to change mac-vlan 
significantly...

If the veth/bridge thing doesn't work, then let us know, as I think that 
would be
a bug.  I use a similar-to-veth virtual-device pair in this way and it 
works fine.

Thanks,
Ben

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


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

Powered by Openwall GNU/*/Linux Powered by OpenVZ