Copying in Piotr, Fan and some other folks for awareness/any input.
Best,
Zach
On 28/09/2022 09:07, Zachary Leaf via lists.fd.io wrote:
> Hi Guangming,
>
> Thanks for the report. I think you may have uncovered some of the bugs
> in the general inbound matching logic.
>
> I
Hi Guangming,
Thanks for the report. I think you may have uncovered some of the bugs
in the general inbound matching logic.
I think there are 2 problems with the logic for the standard linear
search (not flow cache, but impacts flow cache):
1. Only matches source/dest ip, and doesn't match source
Hi,
Re: VPP community call/meeting on 8th March
If possible please can we spend some brief time discussing some outstanding
IPSec patches:
* ipsec: perf improvement of ipsec4_input_node using flow cache (
https://gerrit.fd.io/r/c/vpp/+/32903 )
* Outbound side was merged back in October last y
Hi Andrew,
The tests updated as part of this patch[1] are related to the IPSec outbound
side "flow cache" i.e. test/test_ipsec_spd_flow_cache.py (see commit[2]). This
is really testing the behaviour of the flow cache, rather than this drop by
default behaviour described here. These tests just h
Hi Neale,
Please see https://gerrit.fd.io/r/c/vpp/+/34252 for the patch for this. Would
appreciate a review when you get the chance so Juraj can start adding the CSIT
tests required for the inbound side IPSec flow cache (
https://gerrit.fd.io/r/c/vpp/+/32903 ).
Best,
Zach
-=-=-=-=-=-=-=-=-=-
Hi Neale/all,
I've noticed an inconsistency between the default behaviour for non-matching
packets in the ipsec-input and ipsec-output nodes. I'm not sure if this
intended or not.
The summary is:
- For ipsec-output, any non-matching packets are dropped by default with the
same mechanism as per
