Are there any updates on this topic? We are playing around with IPSEC/IKEV2
sitting behind NAT and up through v19.04.1 we are not seeing an option to
configure IKEv2 over UDP. I do see CLI support was added for
configuring/enabling IPSEC tunnel to use UDP via "ipsec sa add", but "show
trace" sh
Satya,
So, what are the reasons preventing you from doing the same ?
--a
> On 7 Jun 2019, at 13:09, Satya Murthy wrote:
>
> Hi Andrew,
>
> One difference I see between our plugin vs Gbp plugin is:
>
> In Gbp plugin, register_module is getting called as part of an API handler,
> which is usu
The instantaneous vector size - in the stats segment, per-thread - is the best
measure of how hard vpp is working.
It's not a linear function of the offered load, but for any given offered load
/ feature set you can model it with three segments:
* Dead asleep: vector size < 3, offered l
Hi Andrew,
One difference I see between our plugin vs Gbp plugin is:
In Gbp plugin, register_module is getting called as part of an API handler,
which is usually after the system comes to a stable state.
Whereas in our case, we are calling register_module as part of our plugin init
function, w
Satya,
Gbp plugin uses acl plugin in the way I suggested.
Another use is in abf plugin...
what are you doing different compared to those two ?
I wonder if the reason you can’t call init function is the same as the
registration issue - could be that acl plugin is not loaded ?
Please publish a
Hi Dave,
I tried using the perfmon plugin for cpu-cycles event on continuous ping over a
memif channel.
But, I am seeing that the command always return saying "Data Collection in
progress".
DBGvpp# set pmc cpu-cycles
Start collection for 1 events, wait 1.00 seconds
DEADMAN: collection still run
Hi,
I understand that VPP workers poll so they are always at 100 % CPU.
However, I want to get an estimate of what is the effective CPU
utilization i.e. the amount which was spent in doing the work for
packet processing.
In the native applications, the crude way I used to employ was to take
a tim
> And you might not want to enable reassembly in the input feature arc, unless
> you want every fragment arriving on that interface to be reassembled.
> Independently of packet being to your feature plugin or not.
>
> Hi Ole, yes we are checking for ip fragmented packet in our plugin and if
>
On Thu, Jun 6, 2019 at 09:06 AM, Ole Troan wrote:
>
> And you might not want to enable reassembly in the input feature arc,
> unless you want every fragment arriving on that interface to be
> reassembled. Independently of packet being to your feature plugin or not.
>
>
Hi Ole, yes we are check
