
<div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><div><font face="arial, helvetica, sans-serif" style="line-height: 23.3240013122559px;">Hi, </font><font face="arial, helvetica, sans-serif"><span style="line-height: 23.3240013122559px;">Elena Ezhova, thanks for your work to this problem!</span></font></div><div><font face="arial, helvetica, sans-serif"><span style="line-height: 23.3240013122559px;">  I agree with your analysis, this why I commit this bug but don't submit patch for it.</span></font></div><div><font face="arial, helvetica, sans-serif"><div style="font-family: Helvetica, 'Microsoft Yahei', verdana; line-height: 23.3240013122559px;"><font face="Helvetica, Microsoft Yahei, verdana" style="line-height: 1.7;"><span style="line-height: 23.3240013122559px;">  I have  want to use </span></font><span style="font-family: arial, helvetica, sans-serif; line-height: 23.7999992370605px;">conntrack to solve this bug, but I also thought the problem you have said:</span></div><div style="font-family: Helvetica, 'Microsoft Yahei', verdana; line-height: 23.3240013122559px;"><span style="font-family: arial, helvetica, sans-serif; line-height: 23.7999992370605px;">            </span><span style="font-family: arial, helvetica, sans-serif; line-height: 23.7999992370605px;">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: </span></div></font><div style="line-height: 23.7999992370605px;"><font face="arial, helvetica, sans-serif"><div>             $ sudo conntrack -L  | grep "10.0.0.5"</div><div>             tcp      6 431954 ESTABLISHED src=10.0.0.3 dst=10.0.0.5 sport=60723 dport=22 src=10.0.0.5 dst=10.0.0.3 sport=22 dport=60723 [ASSURED] mark=0 use=1</div><div>             tcp      6 431976 ESTABLISHED src=10.0.0.3 dst=10.0.0.5 sport=60729 dport=22 src=10.0.0.5 dst=10.0.0.3 sport=22 dport=60729 [ASSURED] mark=0 use=1</div><div><br></div></font></div><div><font face="Helvetica, Microsoft Yahei, verdana" style="font-family: Helvetica, 'Microsoft Yahei', verdana; line-height: 1.7;"><span style="line-height: 23.3240013122559px;">1. I think </span></font><font face="Helvetica, Microsoft Yahei, verdana" style="font-family: Helvetica, 'Microsoft Yahei', verdana; line-height: 1.7;"><span style="line-height: 23.3240013122559px;">this problem is due to that in compute node, all tenants  </span></font><span style="font-family: Helvetica, 'Microsoft Yahei', verdana; line-height: 23.3240013122559px;">instances</span><span style="font-family: Helvetica, 'Microsoft Yahei', verdana; line-height: 23.3240013122559px;"> (if use ovs agent, it use vlan to </span><span style="font-family: arial, helvetica, sans-serif; line-height: 23.3240013122559px;">isolate different tenant instance</span><span style="font-family: Helvetica, 'Microsoft Yahei', verdana; line-height: 23.3240013122559px;">)</span><span style="font-family: Helvetica, 'Microsoft Yahei', verdana; line-height: 23.3240013122559px;"> are </span><span style="font-family: Helvetica, 'Microsoft Yahei', verdana; line-height: 23.3240013122559px;">in same namespace, so it can't </span><font face="Helvetica, Microsoft Yahei, verdana"><span style="line-height: 23.3240013122559px;">distinguish the </span></font><span style="font-family: arial, helvetica, sans-serif; line-height: 23.7999992370605px;">connection</span><span style="font-family: arial, helvetica, sans-serif; line-height: 23.7999992370605px;"> as above use case.</span></div></div><div><span style="font-family: arial, helvetica, sans-serif; line-height: 23.7999992370605px;">2. the </span><font face="arial, helvetica, sans-serif">ip_conntrack works above L3, so it can't </font><span style="font-family: arial, helvetica, sans-serif; line-height: 23.7999992370605px;"> </span><span style="font-family: arial, helvetica, sans-serif; line-height: 23.7999992370605px;">search for a connection by destination MAC</span></div><div><br></div><div>I am not clear as ajo said:</div><div>      <span style="font-family: arial; line-height: 23.3240013122559px; white-space: pre-wrap;">I'm not sure if removing all the conntrack rules that match the </span><span style="font-family: arial; line-height: 23.3240013122559px; white-space: pre-wrap;">certain filter would be OK enough, as it may only lead to full reevaluation </span><span style="font-family: arial; line-height: 23.3240013122559px; white-space: pre-wrap;">of rules for the next packet of the cleared connections (may be I'm missing  </span><span style="font-family: arial; line-height: 23.3240013122559px; white-space: pre-wrap;">some corner detail, which could be).</span></div><div><span style="font-family: arial, helvetica, sans-serif; line-height: 23.7999992370605px;"><br></span></div><br><br><br><br><div></div><div id="divNeteaseMailCard"></div><br>在 2014-10-23 18:22:46，"Elena Ezhova" <eezhova@mirantis.com> 写道：<br> <blockquote id="isReplyContent" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><div dir="ltr"><font face="arial, helvetica, sans-serif">Hi!</font><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">I am working on a bug "</font><span style="font-family:arial,helvetica,sans-serif;color:rgb(51,51,51);line-height:34px">ping still working once connected even after related security group rule is deleted" </span><span style="font-family:arial,helvetica,sans-serif">(</span><span style="font-family:arial,helvetica,sans-serif"><a href="https://bugs.launchpad.net/neutron/+bug/1335375">https://bugs.launchpad.net/neutron/+bug/1335375</a></span><span style="font-family:arial,helvetica,sans-serif">). The gist of the problem is the following: when we delete a security group rule the corresponding rule in iptables is also deleted, but the connection, that was allowed by that rule, is not being destroyed.</span></div><div><span style="font-family:arial,helvetica,sans-serif">The reason for such behavior is that in iptables we have the following structure of a chain that filters input packets for an interface of an istance:</span></div><div><span style="font-family:arial,helvetica,sans-serif"><br></span></div><div><div style=""><div>Chain neutron-openvswi-i830fa99f-3 (1 references)</div><div> pkts bytes target     prot opt in     out     source               destination         </div><div>    0     0 DROP       all  --  *      *       <a href="http://0.0.0.0/0">0.0.0.0/0</a>            <a href="http://0.0.0.0/0">0.0.0.0/0</a>            state INVALID /* Drop packets that are not associated with a state. */</div><div>    0     0 RETURN     all  --  *      *       <a href="http://0.0.0.0/0">0.0.0.0/0</a>            <a href="http://0.0.0.0/0">0.0.0.0/0</a>            state RELATED,ESTABLISHED /* Direct packets associated with a known session to the RETURN chain. */</div><div>    0     0 RETURN     udp  --  *      *       10.0.0.3             <a href="http://0.0.0.0/0">0.0.0.0/0</a>            udp spt:67 dpt:68</div><div>    0     0 RETURN     all  --  *      *       <a href="http://0.0.0.0/0">0.0.0.0/0</a>            <a href="http://0.0.0.0/0">0.0.0.0/0</a>            match-set IPv43a0d3610-8b38-43f2-8 src</div><div>    0     0 RETURN     tcp  --  *      *       <a href="http://0.0.0.0/0">0.0.0.0/0</a>            <a href="http://0.0.0.0/0">0.0.0.0/0</a>            tcp dpt:22      <---- rule that allows ssh on port 22                    </div><div>    1    84 RETURN     icmp --  *      *       <a href="http://0.0.0.0/0">0.0.0.0/0</a>            <a href="http://0.0.0.0/0">0.0.0.0/0</a>           </div><div>    0     0 neutron-openvswi-sg-fallback  all  --  *      *       <a href="http://0.0.0.0/0">0.0.0.0/0</a>            <a href="http://0.0.0.0/0">0.0.0.0/0</a>            /* Send unmatched traffic to the fallback chain. */</div><div><br></div></div></div><h1 id="edit-title" class="" style="margin:0px;padding:0px;font-weight:normal;clear:none;line-height:34px;color:rgb(51,51,51);background-image:none;background-repeat:initial"><font>So, if we delete rule </font><span style="font-size:small;line-height:normal;color:rgb(34,34,34)">that allows tcp on port 22, then all connections that are already established won't be closed, because all packets would satisfy the rule: </span></h1><div>0     0 RETURN     all  --  *      *       <a href="http://0.0.0.0/0">0.0.0.0/0</a>            <a href="http://0.0.0.0/0">0.0.0.0/0</a>            state RELATED,ESTABLISHED /* Direct packets associated with a known session to the RETURN chain. */<span style="font-size:small;line-height:normal;color:rgb(34,34,34)"><br></span></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">I seek advice on the way how to deal with the problem. There are a couple of ideas how to do it (more or less realistic):</font></div><div><ul><li><font face="arial, helvetica, sans-serif">Kill the connection using conntrack</font></li></ul><font face="arial, helvetica, sans-serif">          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: </font></div><div><font face="arial, helvetica, sans-serif"><div>         $ sudo conntrack -L  | grep "10.0.0.5"</div><div>         tcp      6 431954 ESTABLISHED src=10.0.0.3 dst=10.0.0.5 sport=60723 dport=22 src=10.0.0.5 dst=10.0.0.3 sport=22 dport=60723 [ASSURED] mark=0 use=1</div><div>         tcp      6 431976 ESTABLISHED src=10.0.0.3 dst=10.0.0.5 sport=60729 dport=22 src=10.0.0.5 dst=10.0.0.3 sport=22 dport=60729 [ASSURED] mark=0 use=1</div><div><br></div></font></div><div><font face="arial, helvetica, sans-serif">I wonder whether there is any way to search for a connection by destination MAC?</font></div><div><ul><li><font face="arial, helvetica, sans-serif">Delete iptables rule that directs </font>packets associated with a known session to the RETURN chain</li></ul>           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.</div><div><br></div><div>Please share your thoughts on how it would be better to handle it.</div><div><br></div><div>Thanks in advance,</div><div>Elena</div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><br></div></div>

</blockquote></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>