On 11/25/22 12:08, Dumitru Ceara wrote:
> On 11/22/22 10:29, Ales Musil wrote:
>> Add action called ct_commit_nat, that performs
>> NAT while committing the connection. This is
>> useful for related traffic on which we need
>> to perform NAT, mainly ICMP. We need to
>> commit due to design decision of OvS[0]:
>>
>> "Connections identified as rel are separate from
>> the originating connection and must be committed separately."
>>
>> [0] http://www.openvswitch.org/support/dist-docs/ovs-fields.7.txt
>>
>> Reported-at: https://bugzilla.redhat.com/2126083
>> Acked-by: Mark Michelson <[email protected]>
>> Signed-off-by: Ales Musil <[email protected]>
>> ---
>> v3: Rebase on current main.
>> ---
[...]
>> @@ -1143,6 +1170,17 @@ encode_CT_SNAT_IN_CZONE(const struct ovnact_ct_nat
>> *cn,
>> encode_ct_nat(cn, ep, true, ep->common_nat_ct_zone, ofpacts);
>> }
>>
>> +static void
>> +encode_CT_COMMIT_NAT(const struct ovnact_ct_nat *cn,
>> + const struct ovnact_encode_params *ep,
>> + struct ofpbuf *ofpacts)
>> +{
>> + enum mf_field_id zone = ep->is_switch
>> + ? MFF_LOG_CT_ZONE
>> + : MFF_LOG_DNAT_ZONE;
>> + encode_ct_nat(cn, ep, false, zone, ofpacts);
>
> We only deal with DNAT (third argument is 'false'). I'm pretty sure
> there can also be a case when we need to allow and commit related SNATed
> traffic. Or am I missing something?
>
Ales pointed out privately that we only use the value of the third
argument of echode_ct_nat() if the address family is unspecified.
That's not the case. So we will be committing both SNATed and DNATed
traffic. It should be fine as is.
Regards,
Dumitru
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
