Dear Rubina, When I was adding the multicore support, the handoff infra was just being written at the same time, so I conservatively did not use it, and currently the ACL plugin uses a bit of calculated juggling to avoid requeueing the packet to the single-authority worker that has created the session.
Having the ability to react on full TCP flags would require adding this requeue logic - because anything more sophisticated than the current estabished/transient dichotomy would be insane to handle without the handoff. Of course that would require tests how it affects all the functioning. I have it in my wishlist but no specific plans yet that I would commit to. Help always welcome, obviously :-) --a On 6/2/18, Rubina Bianchi <r_bian...@outlook.com> wrote: > As Regards to your question, the case that I'm testing is connection > tracking in stateful firewall which its functionality is the same as Linux > conntrack. Do you have any plan to provide VPP as an appropriate > infrastructure for firewall applications? > ________________________________ > From: Andrew 👽 Yourtchenko <ayour...@gmail.com> > Sent: Tuesday, May 29, 2018 1:10 PM > To: Rubina Bianchi > Cc: vpp-dev@lists.fd.io > Subject: Re: [vpp-dev] Support for TCP flag > > Hi Rubina, > > I designed the stateful mode to be just a bit more than the ACL, with > a "diode" state, rather than going for the fully fledged firewall > model - as a balance between the simplicity and the functionality. > > The full tracking of the TCP state machine was not in scope - getting > into that territory properly requires also TCP sequence number > tracking, etc. - and there the complexity would far outweigh the > usefulness for most practical cases. > > So I needed to primarily differentiate the session state from the > timeout perspective - when to remove it. > > For that purpose, there are two types of TCP sessions, decided by > taking by the combination of SYN,FIN,RST,ACK TCP flag bits seen from > each side: > > 1) Those that has seen SYN+ACK on both sides are fully open (this is > where the "tcp idle" timeout applies, which is usually rather long. > > 2) Those that had seen any other combination of the flags (this is > where the "tcp transient" timeout applies, which is default to 2 > minutes) > > As we receive the packets, we update the seen flags, and we may change > the current idle timeout based on the accumulated seen flags. > > Additionally, if we run out of sessions when creating the new ones, > then the sessions in the transient state will be cleaned up and reused > in the FIFO manner - so as to simulate a simple mechanism against the > resource starvation for the higher session rate. > > This is a deliberate design choice, and unless there is some > operational issues with it (i.e. where the resource clean-up does not > happen where it should, etc...), I did not have any plans to change > it. > > So, could you expand a bit more on what kind of use case you are > looking for, to discuss further ? > > --a > > On 5/29/18, Rubina Bianchi <r_bian...@outlook.com> wrote: >> Hi >> I have a question about vpp stateful mode. It seems that vpp stateful >> mode >> hasn't implemented completely. I mean there aren't any feature same as >> contrack in linux kernel. So, vpp doesn't have any mechanism to handle >> TCP >> sessions based on different flags. For example I sent TCP three way >> handshaking packets in different order (ack -> syn -> syn-ack), in this >> case >> an idle session is added to session table. Do you have any plan to >> develop >> it? >> > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9589): https://lists.fd.io/g/vpp-dev/message/9589 Mute This Topic: https://lists.fd.io/mt/20405228/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
