[ovs-dev] [PATCH v3] conntrack: document all-zero IP SNAT behavior and add a test case

Eelco Chaudron echaudro at redhat.com
Thu May 27 08:09:43 UTC 2021



On 27 May 2021, at 10:01, Dumitru Ceara wrote:

> On 5/27/21 9:26 AM, Eelco Chaudron wrote:
>>
>>
>> On 25 May 2021, at 15:20, Aaron Conole wrote:
>>
>>> Dumitru Ceara <dceara at redhat.com> writes:
>>>
>>>> On 5/21/21 11:27 AM, Paolo Valerio wrote:
>>>>> Aaron Conole <aconole at redhat.com> writes:
>>>>>
>>>>>> Dumitru Ceara <dceara at redhat.com> writes:
>>>>>>
>>>>>>> On 4/26/21 2:19 PM, Eelco Chaudron wrote:
>>>>>>>> Currently, conntrack in the kernel has an undocumented feature referred
>>>>>>>> to as all-zero IP address NULL SNAT. Basically, when a source port
>>>>>>>> collision is detected during the commit, the source port will be
>>>>>>>> translated to an ephemeral port. If there is no collision, no SNAT is
>>>>>>>> performed.
>>>>>>>>
>>>>>>>> This patchset documents this behavior and adds a self-test to verify
>>>>>>>> it's not changing.
>>>>>>>>
>>>>>>>> Signed-off-by: Eelco Chaudron <echaudro at redhat.com>
>>>>>>>> ---
>>>>>>>> v3: Renamed NULL SNAT to all-zero IP SNAT.
>>>>>>>> v2: Fixed NULL SNAT to only work in the -rpl state to be inline with
>>>>>>>>     OpenShift-SDN's behavior.
>>>>>>>
>>>>>>> Hi Eelco,
>>>>>>>
>>>>>>> Would it be possible to add this capability to the list of kernel
>>>>>>> Datapath.capabilities ovsdb column? [0]
>>>>>>>
>>>>>>> Given that the patch to add userspace datapath support for all-zero IP
>>>>>>> SNAT is not accepted yet [1], and even if it does it will likely not be
>>>>>>> backported to LTS because it's a feature, this would make it easier for
>>>>>>> OVN (for example ovn-controller) to determine at runtime if it should
>>>>>>> use all-zero IP SNAT or not.
>>>>>>
>>>>>> I think it would be rather difficult to add this to the userspace patch
>>>>>> being proposed.
>>>>>>
>>>>>> Actually, if we want something where datapath can detect whether such
>>>>>> feature is supported, there isn't a good test.  For instance, normally
>>>>>> we would attempt to insert a flow that has the characteristics we desire
>>>>>> and look for a failure to insert.  In the case of all-zero SNAT,
>>>>>> both datapaths can "accept" it, so it becomes difficult.
>>>>>>
>>>>>
>>>>> I was wondering the same, a successful insertion doesn't ensure the
>>>>> correctness and so the support of this feature.
>>>>>
>>>>>> Also, the netlink datapath under linux has had this support since it was
>>>>>> introduced, so we're really just documenting it here.  It can still be
>>>>>> used in older releases.  OTOH, userspace doesn't have such support.
>>>>>> Both datapaths will accept flows with SNAT set to 0, as far as I can
>>>>>> tell.  This means there's not an easy way to distinguish them.
>>>>>>
>>>>>> Maybe we need a change to this patchset to reject such flows from the
>>>>>> netdev datapath, and then we can modify [1] to remove such limitation.
>>>>
>>>> That would work, I guess.
>>>>
>>>>>> Then it can be detected by the datapath capabilities that already exist.
>>>>
>>>> Sounds good to me but which already existing datapath capability would
>>>> you use?  As far as I see the existing ones are:
>>>>
>>>> https://github.com/openvswitch/ovs/blob/13c0eaa7b4fc2694a8c6cc8e6487ec6538c607e4/ofproto/ofproto-dpif.c#L5567
>>>>
>>>> Shouldn't we add a new one, e.g., "ct_zero_nat"?
>>>
>>> Yes, sorry - I think it was meant to use the mechanism that already
>>> existed, rather than reuse an existing bit.
>>>
>>
>> I’ll ping Paolo to see if he started the effort, if not I can do it today.
>>
>> Dumitru, so from OVN you will check to see if ct_zero_nat support field is in the database, if not you will support SNAT only on the kernel dpath. If it is present, you use it depending not the value set? (Which will be true for both kernel and userspace). Or do I miss something?
>>
>
> OVN cannot differentiate between datapath types unless we hardcode
> datapath-type names which doesn't seem OK to me.

Can’t it use the datapath_type from the bridge table?

> The plan is for OVN to use all-zero IP SNAT only if the ct_zero_nat
> field is in the database.
>
> So, in order to use it with the kernel datapath, the field needs to be
> set to 'true' when the kernel datapath is used.

Is Paolo’s patch good enough? Meaning if we add the ct_zero_nat to his patch will that be enough?

> Thanks,
> Dumitru
>
>>>>>>
>>>>>> Maybe I missed something, or misunderstood something.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>
>>>>> Considering that linux supports all-zero snat since day one, the
>>>>> assumption seems solid enough to me for it.
>>>>>
>>>>> I have no details about it, but what about Windows dp?
>>>>>
>>>>>>> [0]
>>>>>>> https://github.com/openvswitch/ovs/commit/27501802d09f782b8133031c1eae3394ae5ce147
>>>>>>>
>>>>>>> [1] https://patchwork.ozlabs.org/project/openvswitch/list/?series=241223
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Dumitru
>>>>>
>>



More information about the dev mailing list