[ovs-dev] [PATCHv4 00/11] Add support for connection tracking.
joestringer at nicira.com
Tue Oct 13 22:39:33 UTC 2015
On 2 October 2015 at 14:16, Joe Stringer <joestringer at nicira.com> wrote:
> This series adds support for sending packets through a connection tracker,
> which allows OVS to perform stateful firewalling functions. The functionality
> added in this series works in conjunction with the interface proposed in the
> in the current upstream Linux kernel development release, expected to become
> Linux-4.3. The linux datapath backport is not included in the series at this
> time, but a work in progress version is made available in a branch (see below).
> The functionality is manipulated through a new action "CT" and several new NXM
> fields: ct_state, ct_zone, ct_mark, ct_label. The CT action allows these fields
> to be populated, and for connections that match the flow to be tracked. Later
> patches in the series also allow metadata to be attached to these connections.
> When a flow is sent through the connection tracker, there are two common
> functions to perform. Firstly, match packets from port 1 and do a lookup:
> ovs-ofctl add-flow br0 "in_port=1,actions=ct(table=1)"
> When the table is specified, the ct action forks pipeline processing in two.
> The original instance of the packet will continue processing the current
> actions list as an untracked packet. An additional instance of the packet will
> be sent to the connection tracker, which will be re-injected into the OpenFlow
> pipeline to resume processing in the specified table, with the ct_state and
> other ct match fields set.
> The connection state, as represented in the ct_state field, consists of a
> collection of flags, including:
> - Tracked (trk): Connection tracking has occurred.
> - Reply (rpl): The flow is in the reply direction.
> - Invalid (inv): The connection tracker couldn't identify the connection.
> - New (new): This is the beginning of a new connection.
> - Established (est): This is part of an already existing connection.
> - Related (rel): This connection is related to an existing connection.
> When the first packets for a new connection are sent through the connection
> tracker, the ct_state will have the "+trk+new" flags set. The OpenFlow
> controller may specify a policy to match new connections and allow or deny
> The second function of the ct action is to "commit" the connections. This
> signals to the connection tracker that this connection should be tracked on an
> ongoing basis, so that subsequent packets may be identified as belonging to
> this connection. For instance, to allow new connections from port 1->2:
> ovs-ofctl add-flow br0 \
> Later packets in the connection will have the "+est" flag set, so existing
> connections may be allowed as so:
> ovs-ofctl add-flow br0 "in_port=1,ip,ct_state=+trk+est,action=2"
> In addition to the above, several other parameters may be provided to the ct
> - zone: A 16-bit value or NXM field to retrieve the zone from. Each zone is an
> independent connection tracking context. Connections which are committed to
> zone A will not be remembered in zone B, unless the connection is also
> explicitly committed to zone B.
> eg: actions=ct(zone=1),ct(zone=NXM_NX_REG0[0..15])
> - exec: Execute a nested set of actions. This allows additional functions to be
> performed as part of the connection tracking execution. In this series, the
> set_field, reg_move and reg_load actions are supported with two connection
> tracking metadata fields: ct_mark and ct_label. No other actions are
> eg: actions=ct(commit,exec(set_field:1->ct_mark))
> - alg: Specify an ALG to assist connection tracking. Some protocols consist of
> multiple traffic streams that are impossible to associate without additional
> context. This parameter provides that context to the connection tracker to
> make it possible to track, for instance, FTP data connections.
> eg: actions=ct(commit,alg=ftp)
> Further examples are available in the commit messages for each patch, the
> ovs-ofctl(8) man pages, and the traffic testsuite in tests/system-traffic.at.
Thanks all, I made some minor fixups (mostly documentation) and pushed
this series to master.
Next step: Datapath backport!
More information about the dev