As I found out there already is a change made by Xurong Yang that assigns
conntrack zones to ports https://review.openstack.org/#/c/118274/6
If merged, it will make connection tracking easier and will allow to add
functionality for closing connections after updating or deleting security
group
Hi, Elena Ezhova, thanks for your work to this problem!
I agree with your analysis, this why I commit this bug but don't submit patch
for it.
I have want to use conntrack to solve this bug, but I also thought the
problem you have said:
The problem here is that it is sometimes
I think the root cause of the problem here is that we are losing
segregation between tenants at the conntrack level. The compute side plugs
everything into the same namespace and we have no guarantees about
uniqueness of any other fields kept by conntrack.
Because of this loss of uniqueness, I
Just like Kevin I was considering using conntrack zones to segregate
connections.
However, I don't know whether this would be feasible as I've never used
iptables CT target in real applications.
Segregation should probably happen at the security group level - or even at
the rule level - rather
Nice!, It sounds like a good mechanism to handle this.
Defining a good mechanism here is crucial, we must be aware of the
2^16 zones limit [1], and that ipset rules will coalesce connections
to lots of different IPs over the same rule.
May be a good option is to tag connections per rule (we
While a zone per rule would be nice because we can easily delete connection
state by only referencing a zone, that's probably overkill. We only need
enough to disambiguate between overlapping IPs so we can then delete
connection state by matching standard L3/4 headers again, right?
I think a
Kevin, I agree, with you, 1 zone per port should be reasonable.
The 2^16 rule limit will force us into keeping state (to tie
ports to zones across reboots), may be this state can be just
recovered by reading the iptables rules at boot, and reconstructing
the current openvswitch-agent local
sorry: when I said boot, I mean openvswitch agent restart.
- Original Message -
Kevin, I agree, with you, 1 zone per port should be reasonable.
The 2^16 rule limit will force us into keeping state (to tie
ports to zones across reboots), may be this state can be just
recovered by
Assigning a distinct ct zone to each port sounds more scalable. This should
keep the number of zones per host contained.
What should the workflow when rules are updated or deleted be?
1) From the rule security group find ports on host where it's applied
2) kill all matching connections for those
Hi Elena,
On Thu, Oct 23, 2014 at 4:22 AM, Elena Ezhova eezh...@mirantis.com wrote:
Kill the connection using conntrack
The problem here is that it is sometimes impossible to tell which
connection should be killed. For example there may be two instances running
in different
Miguel Ángel,
On Thu, Oct 23, 2014 at 5:56 AM, Miguel Angel Ajo Pelayo
mangel...@redhat.com wrote:
Temporarily removing this entry doesn't seem like a good solution
to me as we can't really know how long do we need to remove this rule to
induce the connection to close at both ends (it will
On 10/23/2014 08:57 PM, Brian Haley wrote:
On 10/23/14 6:22 AM, Elena Ezhova wrote:
Hi!
I am working on a bug ping still working once connected even after
related security group rule is
deleted (https://bugs.launchpad.net/neutron/+bug/1335375). The gist of
the problem is the following: when we
On Fri, Oct 24, 2014 at 6:17 AM, Salvatore Orlando sorla...@nicira.com 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
Hi!
This is an interesting topic, I don't know if there's any way to
target connection tracker rules by MAC, but that'd be the ideal solution.
I also understand the RETURN for RELATED,ESTABLISHED is there for
performance reasons, and removing it would lead to longer table evaluation,
and
If you exec conntrack inside the namespace with ip netns exec does it still
show both connections?
Vish
On Oct 23, 2014, at 3:22 AM, Elena Ezhova eezh...@mirantis.com wrote:
Hi!
I am working on a bug ping still working once connected even after related
security group rule is deleted
On 10/23/14 6:22 AM, Elena Ezhova wrote:
Hi!
I am working on a bug ping still working once connected even after
related security group rule is
deleted (https://bugs.launchpad.net/neutron/+bug/1335375). The gist of
the problem is the following: when we delete a security group rule the
16 matches
Mail list logo
