On 8/12/24 14:10, Ilya Maximets wrote: > 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. >
This patch doesn't touch any of the router port related flows. Router ports still reply to all neighbor solicitations (regardless if they're unicast or multicast). >> >> 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
