On 8/12/24 14:07, Dumitru Ceara wrote: > 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 ask about VIFs, my question is about router port IPs, that are only known to OVN., i.e. there is no other entity that would reply. > > 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
