Dear Rubina, On 9/24/18, Rubina Bianchi <r_bian...@outlook.com> wrote: > Dear Andrew, > > It's hardcoded as it was simple and fast solution for our default scenario > implementation. > As you correctly mentioned in previous email one of the bug fixes was the > restriction. Also another one is preventing reply packets pass through even
ok. that's more a "featurette" - I deliberately did not attempt to implement the "strict checking" because I had difficult time finding the attack vector. (rather than maybe some kind of "compliance" checks for the reasons of compliance ?) > if those packets are matched with an acl rule. In another word these reply > packets are not belong to any echo request in reverse direction. hmm so you are sort-of making a "protocol inspection engine" there ? :-) Anyway, so far I haven't managed to recreate this condition - though if you were running the 18.07 rather than 18.07.1 code, then the bug related to hash acl manipulation on ACL changes might have caused that effect... I will experiment a bit more, though. Also, remember the other thread we discussed a while ago about the throughput getting lower over time.. I have made https://gerrit.fd.io/r/#/c/14821/ which should significantly reduce the amount of session list shuffling work in normal case scenarios. Before I commit it, could you give it a shot to see if it indeed behaves as I would expect it to behave ? Thanks a lot! --a > Thanks, > Sincerely > ________________________________ > From: Andrew π½ Yourtchenko <ayour...@gmail.com> > Sent: Tuesday, September 18, 2018 4:06 PM > To: Rubina Bianchi > Cc: vpp-dev@lists.fd.io > Subject: Re: [vpp-dev] Odd problem in adding new session on vpp when its > session table is full > > Dear Rubina, > > On 9/18/18, Rubina Bianchi <r_bian...@outlook.com> wrote: >> Dear Andrew, >> >> Our changes is provided to you by creating a patch which is attached to >> this >> email. >> I didn't commit it to gerrit due to our specific scenario (permit+reflect >> on >> all inputs, permit+reflect or deny on all outputs). > > Why do you hardcode it as opposed to making it part of configuration ? > permit+reflect in one direction and deny except established sessions > is a fairly standard config. > >> In addition to ICMP timeout handling, our code fixes some ICMP bugs. > > Do you mean the "strict" enforcement of the one-request-one-response > policy for ICMP that this code does ? > > --a > >> Although, I think code is clear for you, I can explain it in details if >> you >> ask. >> >> Thanks, >> Sincerely >> ________________________________ >> From: Andrew π½ Yourtchenko <ayour...@gmail.com> >> Sent: Tuesday, September 18, 2018 11:27 AM >> To: Rubina Bianchi >> Cc: vpp-dev@lists.fd.io >> Subject: Re: [vpp-dev] Odd problem in adding new session on vpp when its >> session table is full >> >> >> >> >> Hi Rubina, >> >> On 18 Sep 2018, at 11:14, Rubina Bianchi >> <r_bian...@outlook.com<mailto:r_bian...@outlook.com>> wrote: >> >> Hi Dear Andrew >> >> 1) I just attached my init.conf to this email. As you guessed session >> table >> size is 1000000. This problem is occurred on vpp stable/1807. >> >> Ah, cool, that helps, thanks! >> >> >> 2) Yes, there is 6 timeout list. We added a list for handling icmp >> timeouts. >> >> That is not the stable/1807, then βΊοΈ would you mind submitting the change >> to >> gerrit so we could take a look at it and ideally incorporate into the >> master >> ? >> >> βa >> >> >> ________________________________ >> From: Andrew π½ Yourtchenko >> <ayour...@gmail.com<mailto:ayour...@gmail.com>> >> Sent: Monday, September 17, 2018 8:03 PM >> To: Rubina Bianchi >> Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> >> Subject: Re: [vpp-dev] Odd problem in adding new session on vpp when its >> session table is full >> >> Dear Rubina, >> >> looking at the outputs, there are a few anomalies that hopefully you >> can clarify: >> >> 1) the max session count is 1000000. The latest master has the default >> limit of 500000, and I do not see any startup config parameters >> changing that. Which version are you testing with/building off ? >> >> 2) there are 6 fa_conn_list_head elements in each worker for your >> outputs. That number was initially 3, and in the early spring when I >> introduced the purgatory list and the reserved unused list this number >> has increased to 5. The vectors are initialized at a start with a >> constant, so I am wondering why your outputs have a different number. >> >> Would be able to comment on these observations ? >> >> Thank you! >> >> --a >> >> On 9/17/18, Rubina Bianchi >> <r_bian...@outlook.com<mailto:r_bian...@outlook.com>> wrote: >>> * Dear VPP >>> >>> I ran a test on VPP configured with permit+reflect ACl rules with t-rex. >>> In >>> this test, I put two interfaces on one bridge-domain and had an ACL on >>> all >>> of its input and output interfaces. The ACL had just one rule which was >>> allowing any traffic. I ran my test until VPP's session table was full. >>> I >>> run t-rex whith following command: >>> >>> "./t-rex-64 -f cap2/sfr.yaml -m 10 -d 10000" >>> >>> >>> After a couple of days, I took another test on VPP. I tried to >>> establish >>> a >>> ssh session between two clients via my VPP. But session could not be >>> established. When I checked VPP trace, All of my ssh packets where >>> dropped >>> due to following error: >>> >>> "acl-plugin-in-ip4-l2: too many sessions to add new" >>> >>> when I checked VPP's session table, I realized that it was full. No >>> session >>> where deleted since my previous test and no session where going to be >>> added >>> to session table.I also checked my /var/log/hawk.log file and saw >>> following >>> error: >>> >>> "acl_fa_node_fn:516: BUG: session LSB16(sw_if_index) and 5-tuple >>> collision!" >>> >>> I could not fix this problem so I restarted my VPP service. After that, >>> I could not reproduce this state again. Does anyone have any idea on >>> what my problem on VPP was? >>> >>> I attached my hawk.log, vpp trace, "vppctl sh acl-plugin sessions" >>> output >>> and startup.conf file to this email. >>> >>> >>> >>> >>> >> <init.conf> >> >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10629): https://lists.fd.io/g/vpp-dev/message/10629 Mute This Topic: https://lists.fd.io/mt/25722080/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
