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 namespaces that have the same ip addresses. As a compute > doesn't know anything about namespaces, it cannot distinguish between the > two seemingly identical connections:
If it really were different namespaces -- Linux network namespaces -- then it wouldn't matter. The conntrack context is isolated between namespaces. A similar fix for floating IPs takes advantage of this fact [1]. However, I don't think you meant "Linux network namespaces" when you said "different namespaces" above. I think you probably just meant to use "different namespaces" as a more generic term for different network traffic domains that are isolated from each other. So, moving on... In the case of security groups on compute nodes isolation is accomplished using VLANs, linux bridges, etc. So, yes, the conntrack context is shared. I can't think of a way to use conntrack to solve this problem. I'm not advocating the following approach at the moment, just brainstorming here... I wonder if we could just ignore the potential IP address overlap and kill the connections anyway. What would happen? Some connections that were supposed to survive will actually recover if nf_conntrack_tcp_loose is enabled. But, some may not recover. So, maybe this isn't a brilliant idea. > I wonder whether there is any way to search for a connection by destination > MAC? Well, for one thing, the mac is not guaranteed unique either. For another, I don't even know if conntrack is aware of or cares about any L2 details about the connection since it is kind of an L3/L4 sort of thing. > Delete iptables rule that directs packets associated with a known session to > the RETURN chain > > It will force all packets to go through the full chain each time > and this will definitely make the connection close. But this will strongly > affect the performance. Probably there may be created a timeout after which > this rule will be restored, but it is uncertain how long should it be. I don't think this is just about performance, this will cause other connections to stop working. If I'm not mistaken, removing these rules makes it behave more like a stateless firewall. In stateless firewalls, rules must be spelled out independently for ingress and egress packets whereas in a stateful firewall, one typically thinks of the whole connection as ingress or egress (after adding those RELATED/ESTABLISHED rules to allow the other direction through based on conntrack state). Here's another brainstorming idea... I wonder if something could be done with the NOTRACK target in the raw table. Could such a rule be added to squash active connections by hiding them from conntrack? Rules could be added with a timeout so that they don't stay in the table forever. The rule would have to be written to match security group rules that were just deleted. This could be tricky. But, once added, they could be removed on the next iptables update after a given period of time or on agent restart. Carl [1] https://review.openstack.org/#/c/103475/ _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev