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

Mark Michelson mmichels at redhat.com
Thu Mar 19 14:27:52 UTC 2020


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



More information about the dev mailing list