[ovs-dev] Conntrack with SCTP: +est is never reached.
trozet at redhat.com
Thu Mar 19 18:30:14 UTC 2020
In addition I can see in my setup that conntrack and ovs-dpctl all the
states are established:
At this point the connection is open and only heartbeats and HB Acks are
being sent. However, if I poll ovs-dpctl dump-flows, the only flow I see
with sctp get hit every few seconds with 1 packet is:
packets:1, bytes:98, used:3.885s, actions:hash(l4(0)),recirc(0xfd)
Notice the match contains "+new" but there is no new session here. I'm
Red Hat CTO Networking Team
On Thu, Mar 19, 2020 at 10:39 AM Mark Michelson <mmichels at redhat.com> wrote:
> 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. In a recent test run by Tim Rozet, he ran into an issue with my
> > patch.
> > 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,
> > (2) cookie=0xd84870e, duration=1724.090s, table=14, n_packets=6,
> > n_bytes=636, idle_age=257,
> > 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
>  https://patchwork.ozlabs.org/patch/1257045/
>  https://bugzilla.redhat.com/show_bug.cgi?id=1718372
More information about the dev