On 8/12/24 14:05, Ilya Maximets wrote: > On 8/12/24 13:55, Ilya Maximets wrote: >> On 8/12/24 06:16, [email protected] wrote: >>> From: Numan Siddique <[email protected]> >>> >>> IPv6 Neigh Solicitation (NS) responder logical flows match on ip6.dst >>> field. These flows when translated to datapath flows also match on >>> ip6.dst, which means a separate datapath flow per destination IP >>> address. This may cause significant performance issues in some >>> setups (particularly ovs-dpdk telco deployments). >>> >>> This patch addresses this issue by matching on eth.mcast6 so that >>> datapath flows for normal IPv6 traffic doesn't have to match on >>> ip6.dst. IPv6 NS packets are generally multicast. A new logical >>> match "nd_ns_mcast" for this purpose. >>> >>> After this patch, We no longer respond to IPv6 NS unicast packets. >>> This behavior now matches the IPv4 ARP responder flows. Note >>> that after the commit [1] which was recently added we now only >>> respond to IPv4 ARP broadcast packets. >> >> But we still need to reply to unicast NS requests for router ports, right? >> Unlike ARP, > > Actually, ARP has a similar mechanism - Unicast Poll, for the same purpose > of validating cache entries without fully removing them. See: > https://datatracker.ietf.org/doc/html/rfc1122#section-2 > > So, we should be responding for unicast ARPs for router ports as well. >
Both for ARP request and NS we only proxy in the switch pipeline. It's perfectly fine to not reply in the OVN pipeline and let packets reach the VIFs. The VIFs will reply to the unicast requests. This is transparent for the requester. I didn't review Numan's patch in detail but the idea behind it is correct. Regards, Dumitru >> IPv6 will use unicast NS requests for Reachability Confirmation: >> >> 7.3.1. Reachability Confirmation >> >> ... >> >> In some cases (e.g., UDP-based protocols and routers forwarding >> packets to hosts), such reachability information may not be readily >> available from upper-layer protocols. When no hints are available >> and a node is sending packets to a neighbor, the node actively probes >> the neighbor using unicast Neighbor Solicitation messages to verify >> that the forward path is still working. >> >> https://datatracker.ietf.org/doc/html/rfc4861#section-7.3.1 >> >> Or do we reply to those somewhere else? >> >>> >>> A recent patch [2] from Ilya partially addressed the same datapath >>> flow explosion issue by matching on eth.mcast6 for MLD packets. >>> With this patch, we now completely address the datapath flow >>> explosion issue for IPv6 traffic provided all the logical ports >>> of a logical switch are not configured with port security. >>> >>> [1] - c48ed1736a58 ("Do not reply on unicast arps for IPv4 targets.") >>> [2] - 43c34f2e6676 ("logical-fields: Add missing multicast matches for MLD >>> and IGMP.") >>> >>> Reported-at: https://issues.redhat.com/browse/FDP-728 >>> Reported-by: Mike Pattrick <[email protected]> >>> Signed-off-by: Numan Siddique <[email protected]> >> >> Best regards, Ilya Maximets. > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
