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 rules
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 mor
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 w
Miguel Ángel,
On Thu, Oct 23, 2014 at 5:56 AM, Miguel Angel Ajo Pelayo
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 only close if any
> n
Hi Elena,
On Thu, Oct 23, 2014 at 4:22 AM, Elena Ezhova 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 namespaces that have th
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 p
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
> recover
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 port/z
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 connt
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 li
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 tha
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 thi
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 imp
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
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 wrote:
> Hi!
>
> I am working on a bug "ping still working once connected even after related
> security group rule is deleted"
> (https://bugs.la
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 deg
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 corresponding
rule in iptables is also deleted, but
17 matches
Mail list logo
