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