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: <1bd20ab6-4792-7689-932a-a7b9ccf72402@blackwall.org>
Date: Thu, 13 Jul 2023 12:30:07 +0300
From: Nikolay Aleksandrov <razor@...ckwall.org>
To: Ido Schimmel <idosch@...dia.com>, netdev@...r.kernel.org,
 bridge@...ts.linux-foundation.org
Cc: davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com,
 edumazet@...gle.com, roopa@...dia.com, dsahern@...il.com, petrm@...dia.com,
 taspelund@...dia.com
Subject: Re: [RFC PATCH net-next 2/4] vxlan: Add support for nexthop ID
 metadata

On 13/07/2023 10:09, Ido Schimmel wrote:
> VXLAN FDB entries can point to FDB nexthop objects. Each such object
> includes the IP address(es) of remote VTEP(s) via which the target host
> is accessible. Example:
> 
>   # ip nexthop add id 1 via 192.0.2.1 fdb
>   # ip nexthop add id 2 via 192.0.2.17 fdb
>   # ip nexthop add id 1000 group 1/2 fdb
>   # bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 1000 src_vni 10020
> 
> This is useful for EVPN multihoming where a single host can be connected
> to multiple VTEPs. The source VTEP will calculate the flow hash of the
> skb and forward it towards the IP address of one of the VTEPs member in
> the nexthop group.
> 
> There are cases where an external entity (e.g., the bridge driver) can
> provide not only the tunnel ID (i.e., VNI) of the skb, but also the ID
> of the nexthop object via which the skb should be forwarded.
> 
> Therefore, in order to support such cases, when the VXLAN device is in
> external / collect metadata mode and the tunnel info attached to the skb
> is of bridge type, extract the nexthop ID from the tunnel info. If the
> ID is valid (i.e., non-zero), forward the skb via the nexthop object
> associated with the ID, as if the skb hit an FDB entry associated with
> this ID.
> 
> Signed-off-by: Ido Schimmel <idosch@...dia.com>
> ---
>   drivers/net/vxlan/vxlan_core.c | 44 ++++++++++++++++++++++++++++++++++
>   1 file changed, 44 insertions(+)
> 

LGTM
Acked-by: Nikolay Aleksandrov <razor@...ckwall.org>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ