netdev - Re: [PATCH 5/6] e1000: Secondary unicast address support

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0711140210590.15397@bizon.gios.gov.pl>
Date:	Wed, 14 Nov 2007 02:17:40 +0100 (CET)
From:	Krzysztof Oledzki <olel@....pl>
To:	Ben Greear <greearb@...delatech.com>
cc:	Auke Kok <auke-jan.h.kok@...el.com>, davem@...emloft.net,
	jeff@...zik.org, netdev@...r.kernel.org, jesse.brandeburg@...el.com
Subject: Re: [PATCH 5/6] e1000: Secondary unicast address support



On Tue, 13 Nov 2007, Ben Greear wrote:

> Krzysztof Oledzki wrote:
>
>> I'm afraid mac-vlans is not a solution here. Having 2x more interfaces (ex. 
>> 2000 instead of 1000) makes everything (especially routing, firewalling and 
>> QoS) much more complicated. It would be nice to have something like "ip 
>> addr add a.b.c.d/24 dev vlan32 hwaddress aa:bb:cc:dd:ee:ff".
>
> I'll take your word for it, though I have had good luck using mac-vlans
> in my own app.  They are nice because the are full-fledged interfaces,
> so you can treat them basically as .1q vlans or ethernet devices, including
> all the routing and firewalling tricks.

OK. But in my situation it is going to be:

vlan1 (.1q) - real MAC
vlan1a (mac-vlan) - VRRP MAC
(...)
vlan999 (.1q) - real MAC
vlan999 (mac-vlan) - VRRP MAC

... with packets for the same destination coming in and out over both 
interfaces depending on a src ip address.

>> BTW: is it possible to stack mac-vlans ontop of .1Q vlans?
>
> I believe it will work fine.  You could probably also stack .1q
> VLANs on top of mac-vlans so long as you use the same MAC for the VLANs as 
> for
> the mac-vlan dev.

So, this is something exactly I don't want to do as I need two different 
MAC addresses. ;)

Best regards,

 				Krzysztof Olędzki