Hi Dear Andrew I repeated once again my scenarios with short timeouts and upload all configs and outputs for your consideration. I am clear about that session cleaner process doesn't work properly and my Trex throughput stuck at 0. Please repeat this scenario to verify this (Unfortunately vpp is just stable for 200 second and after that vpp will be down).
Thanks, Sincerely Sent from Outlook<http://aka.ms/weboutlook> ________________________________ From: Andrew 👽 Yourtchenko <ayour...@gmail.com> Sent: Sunday, March 11, 2018 3:48 PM To: Rubina Bianchi Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] Freezing Session Deletion Operation Hi Rubina, I am assuming you are observing this both in single core and multicore scenario ? Based on the outputs, this is what I think might be going on: I am seeing the total# of sessions is 1000000, and no TCP transient sessions - thus the packets that require a a session are dropped. What is a bit peculiar, is that the session delete# per-worker are non-zero, yet the the delete counters are zero. To me this indicates there was a fair bit of transient sessions, which also then got recycled by the TCP sessions properly established, before the idle timeout has expired. And at the moment of taking the show command output the connection cleaner activity has not yet kicked in - I do not see either any session deleted by idle timeout nor its timer restarted. Which makes me think that the time interval in which you are testing must be relatively short... So, assuming the time between the start of the traffic and the time you have 1m sessions is quite short, this is simply using up all of the connection pool, a classic inherent resource management issue with any stateful scenario. You can verify that the sessions delete and start building again if you issue "clear acl-plugin sessions". Also, changing the session timeouts to more aggressive values (say, 10 seconds), should kick off the aggressive connection cleaning, thus should unlock this condition. Of course, shorter idle time means potentially useful connections removed. (the commands are "set acl-plugin session timeout <udp|tcp> idle <X>"). *if* neither of the above does not adequately describe what you are seeing, the cleaner node may for whatever reason ceases to kick in every half a second. To see the dynamics of conn cleaner node, you can use the debug command "set acl-plugin session event-trace 1" before the start of the test. This will produce the event trace, which you can view by "show event-logger all" - this should give a reasonable idea about what the cleaner node is up to. Please let me know. --a On 3/11/18, Rubina Bianchi <r_bian...@outlook.com> wrote: > Hi, > > I am testing vpp_18.01.1-124~g302ef0b5 (commit: > 696e0da1cde7e2bcda5a781f9ad286672de8dcbf) and vpp_18.04-rc0~322-g30787378 > (commit: 30787378f49714319e75437b347b7027a949700d) using Trex with sfr > scenario in one core and multicore state. > After a while I saw session deletion rate decreases and vpp throughput > becomes 0 bps. > All configuration files and outputs are attached. > > Thanks, > Sincerely > > Sent from Outlook<http://aka.ms/weboutlook> >
acls
Description: acls
init.conf
Description: init.conf
show sessions
Description: show sessions
startup.conf
Description: startup.conf
trex
Description: trex
