I have some idea that is not good
1, spi should be one key in inbound policy serach
typedef union
{
struct
{
ip4_address_t ip4_src_addr;
ip4_address_t ip4_dest_addr;
U32 spi;
ipsec_spd_policy_type_t policy_type;
}; // 16 bytes total
ipsec4_hash_kv_16_8_t kv_16_8;
} ipsec4_inbound_spd_tuple_t;
2, Maybe we do not need a write a unified method to be fit to both inbound
and outbound.
3, We should use another method (Eg: remove on entry) , not reset cache
entry, when add or del one spd.
In roadwarrior scenario , for server , many client attach and detach is
usaual beviour.
Thanks
Guangming
zhangguangm...@baicells.com
From: Benoit Ganne (bganne) via lists.fd.io
Date: 2022-09-28 16:22
To: vpp-dev@lists.fd.io
CC: Zhang, Roy Fan; Bronowski, PiotrX; Lijian Zhang; Honnappa Nagarahalli
Subject: Re: [vpp-dev] There is bug in patch
Looks like it would be a good time to unify slow-path/fastpath and
inbound/outbound policy matching code
Best
ben
> -----Original Message-----
> From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Zachary Leaf
> Sent: Wednesday, September 28, 2022 10:10
> To: vpp-dev@lists.fd.io
> Cc: Zhang, Roy Fan <roy.fan.zh...@intel.com>; Bronowski, PiotrX
> <piotrx.bronow...@intel.com>; Lijian Zhang <lijian.zh...@arm.com>;
> Honnappa Nagarahalli <honnappa.nagaraha...@arm.com>
> Subject: Re: [vpp-dev] There is bug in patch
>
> 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 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/dest ports
> > or protocol
> > 2. First looks for a match in a vector of all PROTECT policies, then in
> > BYPASS, then finally in DISCARD if nothing matched above
> >
> > In contrast the way I think the matching logic should work is matching a
> > full 5-tuple of {sip/dip, sp/dp, proto} as per outbound side, with all
> > policies searched in one vector so priorities are respected [1].
> >
> > From what you've said I think what may cause your issue is a
> > combination of the 2 above problems, flow cache activation and the
> > particular policy you included:
> >
> > - First packet enters, does not match any PROTECT rules, so searches and
> > matches BYPASS rule for catch all 0.0.0.0-255.255.255.255 /0 range
> > (inbound logic does not check port ranges or protocol)
> > - Now flow cache has an entry for 0.0.0.0-255.255.255.255 that will
> > match every packet in future
> >
> > Obviously the inbound logic is pretty broken, I think it really needs a
> > full re-write to align with outbound side. In hindsight it would have
> > been better to fix all this before adding flow cache but these issues
> > weren't really clear before.
> >
> > As far as fixing your problem, disabling flow cache would work to match
> > the PROTECT policy because of the ordering of the linear search (see 2
> > above), but doesn't fix any of the other possible issues.
> >
> > Otherwise really any 0.0.0.0-255.255.255.255 range is going to mess up
> > and match everything in flow cache if the first packet that enters
> > matches one of these rules.
> >
> > You can try using the new fast path functionality, but from a quick look
> > this also might only be matching sip/dip and not a full 5-tuple so
> > possibly will have the same issue.
> >
> > Best,
> >
> > Zach
> >
> > 1: https://gerrit.fd.io/r/c/vpp/+/34252/3#message-
> 958bacb4654a030e835502af5e486f614c5a1433
> >
> >
> >
> >
> >
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21941): https://lists.fd.io/g/vpp-dev/message/21941
Mute This Topic: https://lists.fd.io/mt/93942743/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
