[ovs-dev] [OVN] Applying ACL changes to existing connections

[Joe Stringer]

On 17 February 2016 at 18:12, Justin Pettit <jpettit at ovn.org> wrote:
>
>> On Feb 5, 2016, at 1:30 PM, Russell Bryant <russell at ovn.org> wrote:
>>
>>
>> Thank you for the write-up!  This approach sounds great to me.  Some
>> small questions...
>>
>> 1) If we're only using 1 bit for now, is there any reason to use
>> ct_label over ct_mark?  The docs in ovs-ofctl(8) seem to suggest they're
>> identical other than being 32-bit vs 128-bit.  Would using the 32-bit
>> ct_mark be beneficial in any way instead?
>
> I think ct_label is intended more for this bit-level twiddling, whereas ct_mark is usually treated as a single 32-bit number.  Clearly, this doesn't really matter in practice, since OVS interfaces with them the same.  Also, I figure that we're going to need to identify the ACL rule at some point, and I've been thinking ct_mark is what we'd use for that.
>
>> 2) One thing not explicitly addressed in this write-up is traffic marked
>> as related.  I think the proposal means just adding a match on
>> ct_label=0x1 where we match ct_state=+rel today and we just rely on a
>> packet in the request direction of the main connection to set ct_label.
>> That seems fine, but I wanted to clarify that point.
>
> That's a good point.  Do you know if the existing OpenStack integration handles related flows?
>
> Jarno or Joe, do you know how the connection tracker handles children of deleted flows?  There's the following comment in nl_ct_flush() in lib/netlink-conntrack.c:
>
>     /* Expectations are flushed automatically, because they do not
>      * have a master connection anymore */
>
> If we delete a specific entry, will its children get removed, too?  If that's true, this problem shouldn't be that difficult--although it is a little ugly.  I think we just need to have ovn-controller periodically sweep through the connection tracking entries looking for that bit, and blowing them away.

No. The parent connection holds a list of expected connections, and
when it is cleaned up, those expectations are cleaned up as well.
However, once an expectation has been fulfilled by packets matching
the expectation, if you commit that connection then it has a life of
its own. I don't see any link from parent to child connections in the
conntrack structures, so it seems unlikely that this is possible with
current APIs.

I think the way to do this currently is to uniquely identify
connection families with a ct_mark, and delete connections based on
this identifier.