Re: RFC: bridge get fdb by bridge device

[Vlad Yasevich <vyasevic@redhat.com>]

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