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

Russell Bryant russell at ovn.org
Fri Feb 19 14:53:23 UTC 2016


On 02/18/2016 07:37 PM, Joe Stringer wrote:
> 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.

Right now, I don't think we ever do ct(commit) for a packet with the
related state bit set.  In that case, if we set ct_mark/ct_label on the
parent connection, will we see that value set when we see another
related packet?  I think that will result in the behavior we're looking
for ...

-- 
Russell Bryant



More information about the dev mailing list