On 2 October 2015 at 14:16, Joe Stringer <joestrin...@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 > them. > > 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 \ > "in_port=1,ip,ct_state=+trk+new,action=ct(commit),2" > > 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 > action: > - 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 > supported. > > 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! _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
