[ovs-dev] Conntrack with SCTP: +est is never reached.

Aaron Conole aconole at redhat.com
Fri Mar 20 18:38:56 UTC 2020


Aaron Conole <aconole at redhat.com> writes:

> Tim Rozet <trozet at 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):

# 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 \
  '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 at 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?

>> Tim Rozet
>> Red Hat CTO Networking Team
>>
>> On Thu, Mar 19, 2020 at 3:11 PM Ben Pfaff <blp at 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?



More information about the dev mailing list