[ovs-dev] RFC: conntrack Initial Design

Thomas Graf tgraf at suug.ch
Fri Jun 6 15:00:00 UTC 2014


On 05/22/14 at 01:39pm, Justin Pettit wrote:
> Below, is a first cut of the design document I wrote for integrating with the connection tracker.  As I mentioned at my OpenStack presentation, I have a prototype that (largely) implements this, but it's not ready to be shared yet.  The goal is to have it in a released version of OVS by the end of the year.  If there are any conntrack experts, please let me know if you think I've missed anything.  (And, since this is very early, it is all subject to change.)

Apologies for taking this long to provide feedback to this.

> High-level Design
> -----------------
> To make use of the connection tracker, the controller writer uses the new
> "conntrack" action.  The action’s arguments are a zone and whether the flow
> should be sent back to the flow table for further processing (similar to a
> "resubmit" action).  The zone argument for the “conntrack” action is a
> connection context, which allows overlapping addresses in different contexts.

I think you design makes a lot of sense. Especially reusing the existing
Linux connection tracking code.

> The controller is responsible for choosing the zone identifier, but it only
> needs to be local to the hypervisor.  If the flow is sent back for further
> processing, the new "conn_state" match fields will be populated.  The represent
> the state of the connection:
> 
>     * New: This is the beginning of a new connection.
>     * Established: This is part of an already existing connection.
>     * Related: This is a new connection that is "expected" (e.g., the data
>       channel of an established FTP connection)

How about extending this with the following additional state:
 
  * Invalid: Maps to the kernel INVALID state. Refers to packets associated
    with no known connection. This could be an ICMP message not related to
    any known connection or a packet for which conntrack could not be
    performed for some reason.

  * Untracked: Assuming a "CT --notrack" equivalent is provided such
    flows would need its own state. See suggestion below.

> There is also a flag distinguishing between the initiating and reply direction.

The flag to indicate whether a reply has been seen or not has been found
useful as well. (Refer to kernel SEEN_REPLY)

> Connection Tracking
> -------------------
> The new connection tracking action is defined as follows:
> 
>     /* Action structure for NXAST_CONNTRACK.
>      *
>      * Pass traffic to the connection tracker.  If 'flags' is NXACF_RESUBMIT,
>      * traffic is resubmitted back to the flow table with the NXM_NX_CONN_STATE
>      * and NXM_NX_CONN_STATE_W matches set.  A standard "resubmit" action
>      * is not sufficient, since connection tracking occurs outside of the
>      * classifier.  The 'zone' argument specifies a context within which the
>      * tracking is done. */
>     struct nx_action_conntrack {
>         ovs_be16 type;              /* OFPAT_VENDOR. */
>         ovs_be16 len;               /* 16. */
>         ovs_be32 vendor;            /* NX_VENDOR_ID. */
>         ovs_be16 subtype;           /* NXAST_CONNTRACK. */
>         ovs_be16 flags;             /* Either 0 or NXACF_RESUBMIT. */
>         ovs_be16 zone;              /* Connection tracking context. */
>         uint8_t  pad[2];
>     };

Should we also allow to optionally specify the expire time for the created
connection tracking entries? The Linux connection tracking code allows to
define multiple profiles so each conntrack action could have its own profile
without interfering with other conntrack uses of the kernel.

Did you also consider adding a "noconntrack" action that maps to
"CT --notrack" extension to mark flows with a dont-track flag? It can
severely simplify conntrack setups by f.e. excluding conntrack for UDP
port 53. 



More information about the dev mailing list