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

Mark Michelson mmichels at redhat.com
Sat Mar 21 13:43:33 UTC 2020


On 3/20/20 3:22 PM, Aaron Conole wrote:
> 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?

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.

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.

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