Mark Michelson <mmich...@redhat.com> writes:
> On 3/20/20 3:22 PM, Aaron Conole wrote:
>> Aaron Conole <acon...@redhat.com> writes:
>>
>>> Aaron Conole <acon...@redhat.com> writes:
>>>
>>>> Tim Rozet <tro...@redhat.com> writes:
>>>>
>>>>> I filed https://bugzilla.redhat.com/show_bug.cgi?id=1815217 to track this
>>>>> issue.
>>>>
>>>> Thanks!
>>>
>>> I tested with the following setup (no modifications to kernel or ovs):
>>
>> Final update below
>>
>>> # using kernel 5.6.0-rc6+, ovs master built using make rpm-fedora and
>>> installed
>>>
>>> ip netns add left
>>> ip netns add right
>>> ip link add center-left type veth peer name left0
>>> ip link add center-right type veth peer name right0
>>> ip link set center-left up
>>> ip link set center-right up
>>> ip link set left0 netns left
>>> ip link set right0 netns right
>>> ip netns exec left ip addr add 172.31.110.1/30 dev left0
>>> ip netns exec right ip addr add 172.31.110.2/30 dev right0
>>> ip netns exec left ip link set left0 up
>>> ip netns exec right ip link set right0 up
>>>
>>> # just to ignore any possible selinux issues...
>>> setenforce Permissive
>>> systemctl start openvswitch
>>>
>>> systemctl start openvswitch
>>> ovs-vsctl add-br br0 -- set Bridge br0 fail-mode=secure
>>> ovs-vsctl add-port br0 center-left
>>> ovs-vsctl add-port br0 center-right
>>> ovs-ofctl add-flow br0 table=0,arp,action=NORMAL
>>>
>>> ovs-ofctl add-flow br0 'table=0,sctp,actions=ct(table=1)'
>>> ovs-ofctl add-flow br0 \
>>>
>>> 'table=1,sctp,in_port=center-left,ct_state=+trk+new,actions=ct(commit),center-right'
>>
>>
>>> ovs-ofctl add-flow br0 \
>>> 'table=1,sctp,in_port=center-right,ct_state=+rpl+trk,actions=center-left'
>>> ovs-ofctl add-flow br0 \
>>
>> ^^ This flow isn't actually needed.
>>
>> Additionally, I tested with the rhel8 kernel, and FDP from rhel8
>> (openvswitch2.12-2.12.0-22), and still was able to get an SCTP
>> connection.
>>
>>> 'table=1,sctp,in_port=center-left,ct_state=+trk+est,actions=center-right'
>>> ovs-ofctl add-flow br0 \
>>> 'table=1,sctp,in_port=center-right,ct_state=+trk+est,actions=center-left'
>>>
>>> # ensure arp is following action normal
>>> ip netns exec left arping 172.31.110.2 -I left0
>>>
>>> # in one terminal
>>> ip netns exec right ncat --listen --sctp -vv
>>>
>>> # in another terminal
>>> ip netns exec left ncat --sctp 172.31.110.2 31337
>>>
>>> Result:
>>>
>>> [root@wsfd-netdev92 ~]# ip netns exec right ncat --listen --sctp -vv
>>> Ncat: Version 7.70 ( https://nmap.org/ncat )
>>> Ncat: Listening on :::31337
>>> Ncat: Listening on 0.0.0.0:31337
>>> Ncat: Connection from 172.31.110.1.
>>> Ncat: Connection from 172.31.110.1:34461.
>>> asdf
>>> fdsa
>>> fasdfsadf
>>> asdfasdfasdfda
>>>
>>>
>>> Seems I have bidirectional communications... It looks like you need the
>>> +rpl flow to match replies (which is what I would expect).
>>>
>>> Looking at the dpctl flows, I see the following display (periodically):
>>> recirc_id(0x2b),in_port(3),ct_state(-new+rpl+trk),eth(),eth_type(0x0800),ipv4(proto=132,frag=no),
>>> packets:1, bytes:98, used:4.310s, actions:2
>>> recirc_id(0x2c),in_port(2),ct_state(-new+est-rpl+trk),eth(),eth_type(0x0800),ipv4(proto=132,frag=no),
>>> packets:1, bytes:98, used:4.314s, actions:3
>>>
>>> And from dump-conntrack:
>>> sctp,orig=(src=172.31.110.1,dst=172.31.110.2,sport=34461,dport=31337),reply=(src=172.31.110.2,dst=172.31.110.1,sport=31337,dport=34461),protoinfo=(state=ESTABLISHED,vtag_orig=2708668805,vtag_reply=1149194430)
>>>
>>> Does it help?
>
> Thanks for the test Aaron. This gives us some good discussion points.
>
> First, as Ben suggested, we should ensure that kernel and OVS versions
> are the same between you and Tim. Since you tested with rhel8 and FDP,
> this seems unlikely to be an issue, but we should still double-check.
>
> Second, we should compare the packets exchanged in the tests you and
> Tim ran. I know that in the OVN case, there was a load balancer
> (i.e. an OpenFlow group action + undnat on the reply path) involved,
> and I wonder if that might have in some way caused a problem that the
> simpler test didn't trigger.
Yes, I am wondering if the packets are going through actual hardware.
In Tim's test he has packets hitting the +inv+trk rule, and I wonder if
there is some kind of crc32 offload that is getting hit.
> Third, we should determine when in your test that the conntrack state
> reached "est". If it's after the INIT and INIT_ACK, then that's
> fantastic. If it's later, then we need to determine when, and we'll
> need to determine how to address this in OVN.
It should be after the COOKIE exchanges, but I didn't check that. I was
really trying to get a tight reproducer.
>>>
>>>>> Tim Rozet
>>>>> Red Hat CTO Networking Team
>>>>>
>>>>> On Thu, Mar 19, 2020 at 3:11 PM Ben Pfaff <b...@ovn.org> wrote:
>>>>>
>>>>> On Thu, Mar 19, 2020 at 10:27:52AM -0400, Mark Michelson wrote:
>>>>> > I've recently been working on adding support for SCTP load balancers
>>>>> in
>>>>> > OVN[1]. In a recent test run by Tim Rozet, he ran into an issue with
>>>>> my
>>>>> > patch[2].
>>>>>
>>>>> Do we have any idea whether OVS conntrack works for SCTP in general?
>>>>>
>>>>> Aaron, you're the only person I can quickly find who has committed
>>>>> anything related to sctp and conntrack, with commit 93346d889271
>>>>> ("conntrack: add display support for sctp"). Did you test conntrack
>>>>> with sctp or did you have any reports of success or failure with it?
>>
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
