On 5/21/21 11:27 AM, Paolo Valerio wrote: > Aaron Conole <[email protected]> writes: > >> Dumitru Ceara <[email protected]> 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 <[email protected]> >>>> --- >>>> 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"? >> >> 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 > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
