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> > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#8490): https://lists.fd.io/g/vpp-dev/message/8490 View All Messages In Topic (2): https://lists.fd.io/g/vpp-dev/topic/14475974 Mute This Topic: https://lists.fd.io/mt/14475974/21656 New Topic: https://lists.fd.io/g/vpp-dev/post Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656 Group Home: https://lists.fd.io/g/vpp-dev Contact Group Owner: vpp-dev+ow...@lists.fd.io Terms of Service: https://lists.fd.io/static/tos Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub -=-=-=-=-=-=-=-=-=-=-=-
