On 8/12/24 14:29, Dumitru Ceara wrote: > On 8/12/24 14:22, Ilya Maximets wrote: >> On 8/12/24 14:14, Dumitru Ceara wrote: >>> 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). >> >> Could you point me to the code? I'm a little confused, because of >> this code snippet: >> >> build_lswitch_arp_nd_responder_known_ips: >> >> /* >> * Add ARP/ND reply flows if either the >> * - port is up and it doesn't have 'unknown' address defined or it >> * doesn't have the option disable_arp_nd_rsp=true. >> * - port type is router or <--- THIS >> * - port type is localport >> */ >> if (check_lsp_is_up && >> !lsp_is_up(op->nbsp) && !lsp_is_router(op->nbsp) && >> strcmp(op->nbsp->type, "localport")) { >> return; >> } >> >> This suggests that we're replying to ARP/ND requests for router ports >> in the switch pipline right here where we're now not replying to unicast >> requests. >> > > We're proxy-ing for router port owned IPs too to avoid flooding (and > encapsulation) of ARP request/NS packets. But if they're unicast > there's no flooding, so we either: > > - let the VIF reply > - reply in the router pipeline for router owned IPs: all calls to > build_lrouter_arp_flow() and build_lrouter_nd_flow().
OK, I see. Thanks for the pointers! The comment I quoted is still misleading a bit, I think. > >> >>> >>>>> >>>>> 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
