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.)
--Justin
-=-=-=-=-=-=-=-=-=-
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.
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)
There is also a flag distinguishing between the initiating and reply direction.
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];
};
The controller may choose not to set the NXACF_RESUBMIT flag if firewall
enforcement just needs to be done in one direction. For example, a VIF may be
allowed to send out any traffic, but can only receive traffic from the PIF on
source port 80 that it had initiated. In this case, traffic coming from the
PIF needs to have the flag state matched, but not from the VIF. Resubmitting
the flow requires two trips through the datapath, so if it’s not necessary, it
is better to avoid matching the connection state.
When this connection tracking action is called with the NXACF_RESUBMIT flag,
the connection tracking state matches will be populated:
/* Connection tracking state.
*
* The connection tracking state is populated by the NXAST_CONNTRACK
* action. The following flags are defined:
*
* - CONN_STATE_TRACKED (0x80): Connection tracking has occurred.
* - CONN_STATE_REPLY (0x40): This flow did not initiate the connection.
*
* The following values describe the state of the connection:
*
* - New (0x01): This is the beginning of a new connection.
* - Established (0x02): This is part of an already existing connection.
* - Related (0x04): This is a new connection that is "expected".
*
* Prereqs: None.
*
* Format: 8-bit fully maskable
*
* Masking: Fully maskable. */
#define NXM_NX_CONN_STATE NXM_HEADER (0x0001, 35, 1)
#define NXM_NX_CONN_STATE_W NXM_HEADER_W(0x0001, 35, 1)
OVS is responsible for reestablishing all metadata when NXACF_RESUBMIT is used,
so that it appears in the flow table as if the lookup never left the
classifier.
Packets can be redirected using standard OpenFlow mechanisms. For example,
based on the connection state and packet headers, traffic can be sent through
GRE tunnels to another system for logging or further processing by a
third-party partner.
Linux Details
-------------
Connection tracking is handled by the kernel conntrack module. As such, the
standard userspace conntrack utilities, such as conntrackd (state
synchronization between hypervisors) and connection tracking helpers are
available. When the OVS kernel module processes a flow with the “conntrack”
action, it hands it to the appropriate conntrack functions for processing. The
conntrack module processes the packet and marks the SKB with the state of the
connection (new, established, direction, etc).
The OpenFlow “conntrack” action and datapath action behave slightly
differently. As described earlier, the two arguments for the OpenFlow version
are the zone and flag indicating whether further processing should be done.
The datapath version’s argument is only the zone. If further processing should
be done, the “conntrack” datapath action is paired with a “recirculate” action.
If the recirculation happens, this time through, the SKB’s conntrack field is
populated, so the flow match includes the connection state. If a kernel flow
entry is not found, it is sent back to userspace for further processing.
Normally, the packet that is sent back to ovs-vswitchd would start a new
evaluation, which means the existing metadata state would be lost. However,
when the controller indicates that a packet should continue processing after
connection tracking, the metadata is stored in userspace and a 32-bit reference
id is allocated from the recirculation id pool. If the flow misses in the
kernel table, the recirculation id is sent to userspace with the rest of the
flow. On reception, the userspace looks up the stored metadata with the
recirculation id and repopulates the appropriate fields in the flow entry
before doing normal OpenFlow table lookups.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
