From: Jamal Hadi Salim <jhs@mojatatu•com>
To: vyasevic@redhat•com, "netdev@vger•kernel.org" <netdev@vger•kernel.org>
Cc: Stephen Hemminger <stephen@networkplumber•org>,
Scott Feldman <sfeldma@cumulusnetworks•com>,
John Fastabend <john.r.fastabend@intel•com>
Subject: Re: RFC: bridge get fdb by bridge device
Date: Tue, 11 Feb 2014 16:08:55 -0500 [thread overview]
Message-ID: <52FA9167.2040305@mojatatu.com> (raw)
In-Reply-To: <52FA8F8B.3080500@redhat.com>
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?
>> 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
next prev parent reply other threads:[~2014-02-11 21:08 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <52F21F72.2090405@mojatatu.com>
[not found] ` <52F29747.7040008@redhat.com>
[not found] ` <52F3CF76.9090404@mojatatu.com>
[not found] ` <52F3E357.4040006@redhat.com>
2014-02-09 15:06 ` RFC: bridge get fdb by bridge device Jamal Hadi Salim
2014-02-09 19:33 ` John Fastabend
2014-02-11 17:03 ` Jamal Hadi Salim
2014-02-10 16:31 ` Vlad Yasevich
2014-02-11 17:07 ` Jamal Hadi Salim
2014-02-11 18:21 ` Vlad Yasevich
2014-02-11 20:15 ` Jamal Hadi Salim
2014-02-11 20:21 ` John Fastabend
2014-02-11 20:30 ` John Fastabend
2014-02-11 21:04 ` Jamal Hadi Salim
2014-02-12 18:50 ` John Fastabend
2014-02-13 12:50 ` Jamal Hadi Salim
2014-02-13 15:37 ` Jamal Hadi Salim
2014-02-13 16:03 ` John Fastabend
2014-02-11 21:00 ` Vlad Yasevich
2014-02-11 21:08 ` Jamal Hadi Salim [this message]
2014-02-11 21:12 ` Jamal Hadi Salim
2014-02-12 19:02 ` Vlad Yasevich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52FA9167.2040305@mojatatu.com \
--to=jhs@mojatatu$(echo .)com \
--cc=john.r.fastabend@intel$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=sfeldma@cumulusnetworks$(echo .)com \
--cc=stephen@networkplumber$(echo .)org \
--cc=vyasevic@redhat$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox