netdev - Re: [PATCH net-next v2 0/5] bridge: per vlan dst

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]

Date:   Wed, 01 Feb 2017 21:58:25 -0800
From:   Roopa Prabhu <roopa@...ulusnetworks.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
CC:     netdev@...r.kernel.org, davem@...emloft.net,
        stephen@...workplumber.org, nikolay@...ulusnetworks.com,
        tgraf@...g.ch, hannes@...essinduktion.org, jbenc@...hat.com,
        pshelar@....org, dsa@...ulusnetworks.com, hadi@...atatu.com
Subject: Re: [PATCH net-next v2 0/5] bridge: per vlan dst_metadata support

On 2/1/17, 5:23 PM, Alexei Starovoitov wrote:
> On Tue, Jan 31, 2017 at 10:59:50PM -0800, Roopa Prabhu wrote:
>

[snip]

>> Solution in this patch series:
>> The Goal is to use a single vxlan device to carry all vnis similar
>> to the vxlan collect metadata mode but additionally allowing the bridge
>> and vxlan driver to carry all the forwarding information and also learn.
>> This implementation uses the existing dst_metadata infrastructure to map
>> vlan to a tunnel id.
> ovs and/or bpf can do the same already, but sounds like the main reason is
> to keep it integrated with bridge fdb to leverage your offload of bridge
> fdb into hw asic, right?

correct. We already use the bridge driver for vlan filtering and offloading. Having vlan to tunnel map
elsewhere is not feasible. It is also more than the hw offload asic case, we have routing protocols like bgp looking at bridge driver
l2 forwarding database for ethernet vpns (https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-07)
and they need a single place to look at bridge fdb table, vxlan fdb table, vlan and tunnel info. Also, Bgp might not be the only
protocol needing this info...we support other controllers too. Hence this info cannot be in a bpf or
live outside the bridge driver.

We today have the vlan info, bridge fdb table, vxlan remote dst fdb table. the missing peice is the vlan to vxlan-id mapping
which this series provides (Well, to be correct, this series helps with scaling this mapping.
Today we use a vxlan netdev per vlan which does not scale well). And this is a very common configuration in
data center switches that provide vxlan bridging gateway function.
[Google for 'vlan to vxlan mapping' should give a couple hits. I did not want to paste a link
to any specific vendor guide here...but found a generic blog --> http://www.definethecloud.net/vxlan-deep-dive/]

> If so, I guess, the extra complexity can be justified.
> The question is how do you program hw ? Is there really 1 to 1 mapping
> in the asics too? Or is it more flexible ?
yes, it is 1-1 mapping in asics too (might be variations on different chips but
this kind of function is supported by most asics).

> I think most swith asics can do other tunnels too,
> so can this vlan->vxlan 1 to 1 be generalized to cover different
> types of tunnels that can be configured on the switch?

yes, it can be. Hence i have kept the tunnel info netlink attribute generic. similar to how LWT provides
various encaps at the L3 routing layer, this can provide such function at the L2 bridge layer. But, to keep it relatively lite I use the
already existing dst_metadata infra to bridge vlan to vxlan (Which is already done in the case of vxlan collect metadata mode.
I simply extend it to cover the bridge case).

thanks,