Re: [ovs-dev] [PATCHv4 00/11] Add support for connection tracking.
> On Oct 13, 2015, at 3:39 PM, Joe Stringer wrote: > > Thanks all, I made some minor fixups (mostly documentation) and pushed > this series to master. > > Next step: Datapath backport! This is great!! Thanks Joe! Jarno ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCHv4 00/11] Add support for connection tracking.
On 2 October 2015 at 14:16, Joe Stringer 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
Re: [ovs-dev] [PATCHv4 00/11] Add support for connection tracking.
On 5 October 2015 at 15:32, Ben Pfaff wrote: > On Fri, Oct 02, 2015 at 02:16:07PM -0700, Joe Stringer 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). > > I think I've acked every patch except 11 (I'll defer to Daniele on that > one). Thanks for the review. I already got review from Daniele on the last round for patch 11. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCHv4 00/11] Add support for connection tracking.
On Fri, Oct 02, 2015 at 02:16:07PM -0700, Joe Stringer 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). I think I've acked every patch except 11 (I'll defer to Daniele on that one). ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCHv4 00/11] Add support for connection tracking.
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. --- This series is also available here with WIP datapath support: https://github.com/justinpettit/ovs conntrack --- v4: Reduce duplicate code for parsing ct_labels Simplify reg_load for 128-bit fields More testing of commandline formatting for fields ct_label byte ordering is now consistent with conntrack-tools Update for latest proposed interface changes Minor bugfixes Add several acks v3: Change label OpenFlow wire format to be128. Extend ct_state to 32 bits on the wire (remains 16 bits in flow). Expand on ovs-ofctl documentation for ct fields and action. Add several new OpenFlow wire-format and formatting tests. Handle nested actions parsing with the correct OpenFlow version. Tighten corner case error handling. Add some new system tests passing packets via the local stack. v2: Applied patches 1-2. Expand NXM_NX_CT_STATE to 16 bits (datapath remains 8 bits). Extend interface documentation, particularly in meta-flow and ofp-actions. Addressed feedback from v1. v1: First non-