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

Tim Rozet 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:
sctp,orig=(src=169.254.33.1,dst=169.254.33.2,sport=38982,dport=31769),reply=(src=10.244.0.5,dst=169.254.33.1,sport=62324,dport=38982),zone=9,protoinfo=(state=ESTABLISHED,vtag_orig=3615038536,vtag_reply=554870550)
sctp,orig=(src=169.254.33.1,dst=169.254.33.2,sport=38982,dport=31769),reply=(src=169.254.33.2,dst=169.254.33.1,sport=31769,dport=38982),protoinfo=(state=ESTABLISHED,vtag_orig=3615038536,vtag_reply=554870550)
sctp,orig=(src=169.254.33.1,dst=10.244.0.5,sport=38982,dport=62324),reply=(src=10.244.0.5,dst=100.64.0.1,sport=62324,dport=38982),zone=8,protoinfo=(state=ESTABLISHED,vtag_orig=3615038536,vtag_reply=554870550)
sctp,orig=(src=100.64.0.1,dst=10.244.0.5,sport=38982,dport=62324),reply=(src=10.244.0.5,dst=100.64.0.1,sport=62324,dport=38982),zone=15,protoinfo=(state=ESTABLISHED,vtag_orig=3615038536,vtag_reply=554870550)

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:
recirc_id(0x1c),in_port(3),ct_state(+new-est-rel-rpl-inv+trk),ct_label(0/0x1),eth(),eth_type(0x0800),ipv4(dst=169.254.33.2,proto=132,frag=no),sctp(dst=31769),
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
using openvswitch-2.12.0-1.fc31.x86_64.

Thanks,

Tim Rozet
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[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