<div dir="ltr">As I found out there already is a change made by Xurong Yang that assigns conntrack zones to ports <a href="https://review.openstack.org/#/c/118274/6">https://review.openstack.org/#/c/118274/6</a> <div>If merged, it will make connection tracking easier and will allow to add functionality for closing connections after updating or deleting security group rules. I will try to add this functionality basing on the existing patch and see if it works.<br><div>I believe that the change requires attention and discussion as there are some concerns regarding it. Perhaps somebody could take a look it?</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 24, 2014 at 9:28 PM, Carl Baldwin <span dir="ltr"><<a href="mailto:carl@ecbaldwin.net" target="_blank">carl@ecbaldwin.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Fri, Oct 24, 2014 at 6:17 AM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>> wrote:<br>
> Assigning a distinct ct zone to each port sounds more scalable. This should<br>
> keep the number of zones per host<br>
<br>
</span>Agree that zones could be a good solution to this problem.  +1 to zone<br>
/ port for scalability.  Though it will take a bit more code and<br>
complexity to kill the right connections than it would with zone /<br>
rule.<br>
<span class=""><br>
> Once we identify the ports, and therefore the ct zones, then we'd still need<br>
> to find the connections matching the rules which were removed. This does not<br>
> sound like being too difficult, but it can result in searches over long<br>
> lists - think about an instance hosting a DB or web server.<br>
<br>
</span>Are you thinking of listing all connections and then iterating over<br>
the list with some code to match it to a security group rule being<br>
removed/updated?  Or, map the security group rule to conntrack filter<br>
arguments to send to a call to conntrack -D?<br>
<br>
This could be problematic.  What if security group rules were<br>
redundant and an update or removal of a rule should not really affect<br>
any existing connections?  If all connections were compared instead<br>
against the set of *remaining* security group rules then this wouldn't<br>
be a problem.  This sounds non-trivial to me.  I'm probably thinking<br>
too hard about this.  ;)<br>
<span class=""><br>
> The above two considerations made me suggest the idea of associating ct<br>
> zones with rules, but it is probably true that this can cause us to go<br>
> beyond the 2^16 limit.<br>
<br>
</span>I agree we'd hit this limit.<br>
<span class=""><font color="#888888"><br>
Carl<br>
</font></span><div class=""><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div></div>