netdev - Re: RFC: bridge get fdb by bridge device

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: <52FBC55B.9040505@redhat.com>
Date:	Wed, 12 Feb 2014 14:02:51 -0500
From:	Vlad Yasevich <vyasevic@...hat.com>
To:	Jamal Hadi Salim <jhs@...atatu.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:	Stephen Hemminger <stephen@...workplumber.org>,
	Scott Feldman <sfeldma@...ulusnetworks.com>,
	John Fastabend <john.r.fastabend@...el.com>
Subject: Re: RFC: bridge get fdb by bridge device

On 02/11/2014 04:08 PM, Jamal Hadi Salim wrote:
> On 02/11/14 16:00, Vlad Yasevich wrote:
>> On 02/11/2014 03:15 PM, Jamal Hadi Salim wrote:
> 
>>
>> Because it just a multi-function nic that isn't tagged with any
>> kine of bridge flag.  As John said, this might be useful, but not
>> done yet.
>>
> 
> Ok, fair enough. Someone should send a patch - John perhaps.
> 
>>
>> Not directly.  However, if you put a layered software device in between
>> (vlan, bond, macvlan), then you can add that device to another bridge.
>> In fact, people do that to get GVRP working with VMs.
>>
> 
> Do you recall the reasoning behind it?

Before my time. It's there since before 2.6.12 :)

-vlad

> 
> 
>>> It certainly has some equivalent semantics (looks at dst MAC then
>>> picks the port). Possible to add Vlans as well?
>>
>> I suppose.   You can do things like:
>> # ip link add link eth0 dev vlan100 protocol 8021Q id 100
>> # ip link add link vlan0 dev mac100 type macvlan
>>
>> Now, you have a macvlan (mac100) that will only receive vlan100 traffic.
>> Expressing this in terms of fdb would be a bit difficult since each
>> interface is separate and eth0 doesn't really know about the stack.
>> It would require quite a lot of code.
>>
> 
> nice.
> 
>>> Why dont we tag such a thing as a bridge then?
>>>
>>
>> Because they are not always a bridge.  It could be just a nic capable of
>> mac filtering.
>>
> 
> I think in one of the modes it is merely a filter.
> But you turn on this other feature it is a bridge.
> 
>>
>> Didn't realize it has different connotation for vxlan.  The you probably
>> don't want to include and support in the bridge fdb show command.
> 
> Thats what i thought you said earlier ;->
> 
> cheers,
> jamal

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