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

Mark Michelson mmichels at redhat.com
Thu Mar 19 14:39:24 UTC 2020


On 3/19/20 10:27 AM, Mark Michelson wrote:
> Hi,
> 
> 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].
> 
> In short, during a typical SCTP association, it appears that conntrack 
> never reaches the "+est" state.
> 
> OVN installs the following two OF flows for load balancers:
> 
> (1) cookie=0x3bfb3d5b, duration=1724.090s, table=14, n_packets=0, 
> n_bytes=0, idle_age=1724, 
> priority=120,ct_state=+est+trk,sctp,metadata=0x3,nw_dst=169.254.33.2,tp_dst=31769 
> actions=set_field:0x8/0x8->reg10,ct(table=15,zone=NXM_NX_REG11[0..15],nat)
> (2) cookie=0xd84870e, duration=1724.090s, table=14, n_packets=6, 
> n_bytes=636, idle_age=257, 
> priority=120,ct_state=+new+trk,sctp,metadata=0x3,nw_dst=169.254.33.2,tp_dst=31769 
> actions=set_field:0x8/0x8->reg10,group:2
> 
> The idea is that when dealing with a new connection, we should load 
> balance to a group (flow 2). Once the connection is established, we 
> should dnat to assure that the traffic goes to the destination stored in 
> conntrack (flow 1).
> 
> With SCTP, we were seeing an issue where the INIT sent by the client 
> would hit flow 2 as expected. The INIT_ACK from the server would then 
> reach the client. The client would send a COOKIE_ECHO, and this would 
> hit neither flow 1 nor flow 2. Conntrack apparently reached a state 
> where it was neither "new" nor "est".
> 
> Looking at the netfilter code for SCTP, this makes some amount of sense. 
> After the INIT and INIT_ACK are exchanged, there are the COOKIE_ECHOED 
> and COOKIE_WAIT states that can be entered prior to being ESTABLISHED.
> 
> So Tim added a new flow for sctp that would perform the same actions as 
> flow 1 above, but would match for "-new-est+trk". In other words, SCTP 
> traffic that is tracked but is not new and also not established. This 
> had the intended effect of matching on the COOKIE_ECHO from the client.
> 
> However, Tim then noticed that even after the COOKIE_ECHO and 
> COOKIE_ACK, additional DATA traffic from the client over the SCTP 
> association never matched flow 1. In other words, the conntrack state 
> apparently never actually reached "+est" according to OVS.
> 
> My worry is if there might be a bug somewhere in OVS that makes it so 
> that SCTP associations never reach an established conntrack state. Or 
> perhaps this is by design? If so, then what should OVN do for SCTP 
> associations when we normally want to match the +est state?
> 
> Thanks,
> Mark Michelson

[1] https://patchwork.ozlabs.org/patch/1257045/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1718372



More information about the dev mailing list