]> git.itanic.dy.fi Git - linux-stable/commit
vxlan: Add support for nexthop ID metadata
authorIdo Schimmel <idosch@nvidia.com>
Mon, 17 Jul 2023 08:12:27 +0000 (11:12 +0300)
committerDavid S. Miller <davem@davemloft.net>
Wed, 19 Jul 2023 09:53:48 +0000 (10:53 +0100)
commitd977e1c8e3a143bceb63a0042890f4a0268a9990
treee416bae5172e6655e0e0f400b67307a197e9229b
parent8bb5e82589f0141a990d3fd21d5b79a73a8c6c7b
vxlan: Add support for nexthop ID metadata

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@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
drivers/net/vxlan/vxlan_core.c