As I found out there already is a change made by Xurong Yang that assigns
conntrack zones to ports
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.
I believe that the change requires attention and discussion as there are
some concerns regarding it. Perhaps somebody could take a look it?

On Fri, Oct 24, 2014 at 9:28 PM, Carl Baldwin <> wrote:

> On Fri, Oct 24, 2014 at 6:17 AM, Salvatore Orlando <>
> wrote:
> > Assigning a distinct ct zone to each port sounds more scalable. This
> should
> > keep the number of zones per host
> Agree that zones could be a good solution to this problem.  +1 to zone
> / port for scalability.  Though it will take a bit more code and
> complexity to kill the right connections than it would with zone /
> rule.
> > Once we identify the ports, and therefore the ct zones, then we'd still
> need
> > to find the connections matching the rules which were removed. This does
> not
> > sound like being too difficult, but it can result in searches over long
> > lists - think about an instance hosting a DB or web server.
> Are you thinking of listing all connections and then iterating over
> the list with some code to match it to a security group rule being
> removed/updated?  Or, map the security group rule to conntrack filter
> arguments to send to a call to conntrack -D?
> This could be problematic.  What if security group rules were
> redundant and an update or removal of a rule should not really affect
> any existing connections?  If all connections were compared instead
> against the set of *remaining* security group rules then this wouldn't
> be a problem.  This sounds non-trivial to me.  I'm probably thinking
> too hard about this.  ;)
> > The above two considerations made me suggest the idea of associating ct
> > zones with rules, but it is probably true that this can cause us to go
> > beyond the 2^16 limit.
> I agree we'd hit this limit.
> Carl
> _______________________________________________
> OpenStack-dev mailing list
OpenStack-dev mailing list

Reply via email to