[ovs-git] [ovn-org/ovn] 56e2cd: ovn-controller: Detect OVS datapath capabilities.

Dumitru Ceara noreply at github.com
Fri Jun 18 22:28:26 UTC 2021


  Branch: refs/heads/master
  Home:   https://github.com/ovn-org/ovn
  Commit: 56e2cd3a2f06b79b7d57cc8637fc0d258652aff5
      https://github.com/ovn-org/ovn/commit/56e2cd3a2f06b79b7d57cc8637fc0d258652aff5
  Author: Dumitru Ceara <dceara at redhat.com>
  Date:   2021-06-18 (Fri, 18 Jun 2021)

  Changed paths:
    M controller/ovn-controller.c
    M include/ovn/features.h
    M lib/automake.mk
    A lib/features.c
    A lib/test-ovn-features.c
    M tests/automake.mk
    M tests/ovn-controller.at
    A tests/ovn-features.at
    M tests/testsuite.at

  Log Message:
  -----------
  ovn-controller: Detect OVS datapath capabilities.

Automatically create an OVS Datapath record if none exists for the
current br-int datapath type.

Add a 'features' module to track which OVS features are available in
the datapath currently being used.  For now, only ct_zero_snat is
tracked, all other features are assumed to be on-par between all
datapaths.

A future commit will make use of the 'features' module to conditionally
program openflows based on available datapath features.

Acked-by: Mark D. Gray <mark.d.gray at redhat.com>
Signed-off-by: Dumitru Ceara <dceara at redhat.com>
Signed-off-by: Numan Siddique <numans at ovn.org>


  Commit: 58683a4271e6a885f2f2aea27f3df88e69a5c388
      https://github.com/ovn-org/ovn/commit/58683a4271e6a885f2f2aea27f3df88e69a5c388
  Author: Dumitru Ceara <dceara at redhat.com>
  Date:   2021-06-18 (Fri, 18 Jun 2021)

  Changed paths:
    M include/ovn/actions.h
    M lib/actions.c
    M tests/ovn.at
    M tests/system-common-macros.at
    M tests/system-ovn.at

  Log Message:
  -----------
  ovn-controller: Handle DNAT/no-NAT conntrack tuple collisions.

Assuming a load balancer, LB1, with:
- VIP: 42.42.42.42:4242
- backend: 42.42.42.1:2121

A client might connect to the backend either directly or through the
VIP.  If the first connection is via the VIP and the second connection
is direct but happens to use the same source L4 port, OVN should make
sure that the second connection is SNATed (source port translation) in
order to avoid a tuple collision at commit time.

For example:
1. Session via the VIP:
   - original packet: src=42.42.42.2:2000, dst=42.42.42.42:4242
   - after DNAT:      src=42.42.42.2:2000, dst=42.42.42.1:2121
2. Session directly connected to the backend:
   - original packet: src=42.42.42.2:2000, dst=42.42.42.1:2121
   - in acl stage committing this connection would fail.

In order to avoid this we now use the all-zero-ip NAT OVS feature when
committing connections in the ACL stage.  This translates to a no-op
SNAT when there's no tuple collision, and performs source port
translation when a tuple collision would happen.

We program flows to perform all-zero-ip NAT conditionally, only if the
datapath being used supports it.

Reported-at: https://bugzilla.redhat.com/1939676
Signed-off-by: Dumitru Ceara <dceara at redhat.com>
Acked-by: Mark D. Gray <mark.d.gray at redhat.com>
Signed-off-by: Numan Siddique <numans at ovn.org>


Compare: https://github.com/ovn-org/ovn/compare/f6bd743cb9a7...58683a4271e6


More information about the git mailing list