<div dir="ltr"><div><br></div><div>Adding some more info here, Thanks Numan! for pointing to this.</div><div><br></div><div>The issue I am facing looks similar to the one described in [1] and [2]. But it seems the issue is not yet fixed. Is there a plan to fix this soon? In Opendaylight security groups is implemented using ovs-conntrack. So the flow based router ping responder and floating IP translations hits this issue.</div><div><br></div><div>[1]<a href="https://mail.openvswitch.org/pipermail/ovs-dev/2017-March/329542.html">https://mail.openvswitch.org/pipermail/ovs-dev/2017-March/329542.html</a></div><div>[2]<a href="https://patchwork.ozlabs.org/patch/739796/">https://patchwork.ozlabs.org/patch/739796/</a></div><div><br></div><div>Thanks</div><div>Aswin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 2, 2017 at 5:41 PM, Aswin S <span dir="ltr"><<a href="mailto:aswinsuryan@gmail.com" target="_blank">aswinsuryan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Joe,<div><br></div><div>Thanks for the quick response, I apologize for being cryptic. Yes FIP is floating IP and SG is access control list. The issue can be reproduced with two namespace using the steps in [1] in ovs 2.7. </div><div><br></div><div>With [1]</div><div><br></div><div>From 10.100.5.8 if I try to ping/ssh 10.100.5.9 it works, but not when I try ping/ssh to 192.168.56.32 from 10.100.5.8.</div><div><br></div><div>But it seems to work if I track them in two different ct zones as below(in 40,41,251,252) </div><div><br></div><div><div>"table=40,priority=61010,ip,<wbr>dl_src=fa:16:3e:1d:3d:01,nw_<wbr>src=10.100.5.8,actions=ct(<wbr>table=41,zone=5001)"</div><div>"table=40,priority=61010,ip,<wbr>dl_src=fa:16:3e:13:85:be,nw_<wbr>src=10.100.5.9,actions=ct(<wbr>table=41,zone=5002)"</div></div><div><br></div><div><div>"table=41,priority=1000,ct_<wbr>state=+new+trk,ip,dl_src=fa:<wbr>16:3e:1d:3d:01,nw_src=10.100.<wbr>5.8,actions=ct(commit,zone=<wbr>5001),resubmit(,21)"</div><div>"table=41,priority=1000,ct_<wbr>state=+new+trk,ip,dl_src=fa:<wbr>16:3e:13:85:be,nw_src=10.100.<wbr>5.9,actions=ct(commit,zone=<wbr>5002),resubmit(,21)"</div></div><div><br></div><div>[1]<a href="https://gist.github.com/aswinsuryan/c22919576ae19e14ed489bf1f6c668cb" target="_blank">https://gist.github.com/<wbr>aswinsuryan/<wbr>c22919576ae19e14ed489bf1f6c668<wbr>cb</a></div><div><br></div><div>Aswin<br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Fri, Jun 2, 2017 at 5:22 AM, Joe Stringer <span dir="ltr"><<a href="mailto:joe@ovn.org" target="_blank">joe@ovn.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-82411458035576242gmail-">On 1 June 2017 at 05:23, Aswin S <<a href="mailto:aswinsuryan@gmail.com" target="_blank">aswinsuryan@gmail.com</a>> wrote:<br>
> Hi,<br>
> When SG is implemented using conntrack rules , TCP connection via FIP<br>
> between vms in the same compute is failing<br>
<br>
</span>What is SG?<br>
<br>
Is FIP "floating IP"?<br>
<div><div class="m_-82411458035576242gmail-h5"><br>
> In my topology I have two vm on the same compute both having floating ip<br>
> associated with it and the fip translation is done using openflow rules.<br>
><br>
> When using vm internal network ip it is working fine and I can ssh to the<br>
> other vm.<br>
><br>
> The conntrack event logs are as follows (Src ip 10.100.5.5 Dest Ip<br>
> 10.100.5.12<br>
> [NEW] tcp 6 120 SYN_SENT src=10.100.5.5 dst=10.100.5.12 sport=43724<br>
> dport=22 [UNREPLIED] src=10.100.5.12 dst=10.100.5.5 sport=22 dport=43724<br>
> zone=5001<br>
> [UPDATE] tcp 6 60 SYN_RECV src=10.100.5.5 dst=10.100.5.12 sport=43724<br>
> dport=22 src=10.100.5.12 dst=10.100.5.5 sport=22 dport=43724 zone=5001<br>
> [UPDATE] tcp 6 432000 ESTABLISHED src=10.100.5.5 dst=10.100.5.12<br>
> sport=43724 dport=22 src=10.100.5.12 dst=10.100.5.5 sport=22 dport=43724<br>
> [ASSURED] zone=5001<br>
><br>
><br>
> But when I use FIP(the TCP packets are marked as Invalid and dropped.<br>
> The SYN reaches the second vm which sends back the SYN ack and the status of<br>
> conntrack entry is updated at the destination. Though the SYN-ACK reaches<br>
> vm1 the conntrack state still remain UNREPLIED and the ack packet send to<br>
> vm2 is marked as invalid and dropped. In the pipeline the packet is<br>
> submitted to the conntrack both at egress and ingress side. The packet is<br>
> submitted to conntrack after the fip modification.<br>
><br>
> The conntrack event logs (Vm1 10.100.5.5, 192.168.56.29, Vm2 10.100.5.12,<br>
> 192.168.56.23)<br>
><br>
> [NEW] tcp 6 120 SYN_SENT src=10.100.5.12 dst=192.168.56.29<br>
> sport=58218 dport=22 [UNREPLIED] src=192.168.56.29 dst=10.100.5.12 sport=22<br>
> dport=58218 zone=5001<br>
> [NEW] tcp 6 120 SYN_SENT src=192.168.56.23 dst=10.100.5.5<br>
> sport=58218 dport=22 [UNREPLIED] src=10.100.5.5 dst=192.168.56.23 sport=22<br>
> dport=58218 zone=5001<br>
> [UPDATE] tcp 6 60 SYN_RECV src=192.168.56.23 dst=10.100.5.5<br>
> sport=58218 dport=22 src=10.100.5.5 dst=192.168.56.23 sport=22 dport=58218<br>
> zone=5001<br>
<br>
</div></div>It looks like you're modifying the destination address on traffic from<br>
VM1->VM2 before submitting to conntrack and modifying the source<br>
address on traffic from VM2->VM1 before submitting to conntrack, which<br>
means that conntrack is not seeing bidirection traffic between two<br>
physical IPs, nor is it seeing bidirectional traffic between floating<br>
IPs.. rather, it is seeing two unidirectional connections between<br>
either VM1's physical IP and VM2's FIP, or VM1's FIP and VM2's<br>
physical IP. The Linux connection tracker, when it sees unidirectional<br>
SYNACK, will classify it as invalid, leading to your drop.<br>
<span class="m_-82411458035576242gmail-"><br></span></blockquote></div></div><div>The flows I have mentioned in [1] works if it is two zones, so I think it should not be an issue of netfilter not seeing bidirectional packets.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-82411458035576242gmail-">
> The issue is not limited to TCP, if try with ICMP with FIP, the ping packet<br>
> from vm1 to vm2 will be always new state in the connection tracker. This<br>
> works(both TCP and ICMP) fine if the vm are two compute nodes. So is this an<br>
> issue when a modified packet in the pipeline is submitted to connection<br>
> tracker? Does netfilter/ovs conntrack check for any other field than src ip/<br>
> port dest ip/port for marking a packet as reply pakcet?<br>
<br>
</span>It deals with the actual packet contents when you execute the ct() action.<br>
<span class="m_-82411458035576242gmail-"><br>
> I am using ovs 2.7.0. I have reported an issue a while ago[1] which still<br>
> exsits and this seems to be related<br>
><br>
> [1]<a href="https://mail.openvswitch.org/pipermail/ovs-discuss/2016-December/043228.html" rel="noreferrer" target="_blank">https://mail.openvswitch.or<wbr>g/pipermail/ovs-discuss/2016-<wbr>December/043228.html</a><br>
<br>
</span>It looks like you're seeing events corresponding to modified packets<br>
according to your output above, so I don't see the relation to this<br>
other thread.<br></blockquote></span><div>Yes that makes sense, here it showing modified packets, but I just thought the root cause may not be related to modified packets. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Cheers,<br>
Joe<br>
</blockquote></div><br></div></div>
</blockquote></div><br></div>