Re: [PATCH net-next 0/3] net: nexthop: per-nexthop UDP dst port for fdb (VXLAN) nexthops

On Thu, Jul 16, 2026 at 02:33:21PM +0300, Ido Schimmel wrote:

OK, I understand. Each tenant has its own VNI, but it can have multiple
HA sets on the same node and you want to distinguish between them using
the UDP destination port.

Yes, that is exactly it.

I don't particularly like NHA_FDB_PORT because it's an FDB-specific
encapsulation attribute and these attributes naturally belong under
NHA_ENCAP. That being said, I fail to see a better alternative given
that FDB nexthops don't use NHA_ENCAP / LWT infra and probably
shouldn't. [...]
If you are going to post v2, please provide a more detailed motivation
in the cover letter.

Understood, and I agree with the tension. I would not move FDB nexthops
onto NHA_ENCAP / LWT either, so I will keep the FDB-specific surface as
small as I can (see the VNI answer below). v2 will carry a fuller
motivation in the cover letter.

In an earlier reply you wrote "shared inner MAC/IP". The "MAC" part was
intentional because you need to load balance pure L2 traffic? IOW, if
your traffic is only L3, can we do the load balancing using multipath
routes in the overlay instead of using FDB nexthop groups?

Yes, the MAC was intentional, but not because the payload is pure L2,
it can be IP. The reason is that the whole HA set is addressed as one
anycast identity, a single overlay IP and MAC. That is deliberate. One
stable address keeps failover transparent, we just drop a dead replica
from the group with no client re-resolution. The address is also
consumed one layer up as a single stable endpoint, so giving each
replica its own IP would push multi-address handling and health
checking into that consumer, which is not available to us today.

Related: What is the use case for NHA_FDB_VNI? In my experience, the VNI
is only translated when routing traffic between tenants. Why do you need
this in an FDB nexthop?

No strong use case, and your read matches mine. I will drop the
NHA_FDB_VNI mention from v2 rather than carry a speculative attribute
with no user.

Thanks again for the careful review.

Jack