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