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 <[email protected]> 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 > > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
