[ovs-dev] [PATCH ovn] northd: Fix defrag flows for duplicate vips

Mark Gray mark.d.gray at redhat.com
Thu Jul 15 17:04:07 UTC 2021


On 15/07/2021 15:29, Dumitru Ceara wrote:
> On 7/15/21 3:54 PM, Mark Gray wrote:
>> On 15/07/2021 14:16, Mark Michelson wrote:
>>> Hi Mark,
> 
> Hi Mark, Mark,
> 
>>>
>>> I'm a bit curious about this change. Does the removal of the protocol 
>>> from the match mean that traffic that is not of the protocol specified 
>>> in the load balancer will be ct_dnat()'ed? Does that constitute 
>>> unexpected behavior?
>>>
>>
>> Yes, this is the case. It's a tradeoff between number of flows and
>> reirculations but thinking about it again, it may be better to have more
>> flows. I will create a v2.
>>
> 
> Unless we match on proto *and* L4 port I don't think it's worth adding
> per proto flows.  Assuming a TCP load balancer, all TCP traffic with
> destination VIP will still be ct_dnat()'ed, even if the TCP destination
> port is not the one defined in the load balancer VIP.
> 
> On the other hand, using the same VIP for multiple ports is probably a
> common use case so if we add the L4 port to the match the number of
> logical flows might increase significantly.

I don't think we can match on L4 port AFAIK, this could cause misses
with fragmented packets (which is the whole point of the defrag table).

I guess it depends on the use case as that will determine the number of
vips (which will generate a certain number of flows) and the traffic
pattern (which will determine the average number of ct_dnat()s). In a
system with a handful of VIPs for TCP traffic but mostly hosting UDP
traffic, it may be better to do as Mark M. suggests.

The number of flows may not be that high as we only add one flow per
protocol rather than one per port. So I guess in the worst case, this
could be 4x the number of load balancer VIPs associated with the logical
router.

> 
> Regards,
> Dumitru
> 



More information about the dev mailing list