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
Forgot my footnote:
[1] https://patchwork.ozlabs.org/patch/1257045/
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
