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

Aaron Conole aconole at redhat.com
Fri Mar 20 19:22:10 UTC 2020


Aaron Conole <aconole at redhat.com> writes:

> 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):

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 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