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. > 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
