Ok. As requested, pcap trace & test script attached. Actually I made some
simplification to indicate the problem – using native IPSEC instead of DPDK.
You can see in the buffer trace that ip-lookup is referred by ip-input in the
beginning then by esp-encrypt later. It means the ownership of ip-l
Please write up the issue and share the config and pg input script as I asked.
You might find that the issue disappears pretty rapidly, with no further action
on your part... (😉)...
The basic graph engine is not a place to start hacking based on “I think I get
it...”
Thanks... Dave
From: vpp-
thanks. I think I get it. By maintaining the ownership, vPP is able to enqueue
all buffers destinated to the same target node into the owner's next frame at
one time. This avoids dispatching the node function multiple times.
The bug is still there. I will create a patch later for further discuss
Hi,
You should go from nat44-out2in to ip4-policer-classify only if it is
configured on given interface (check if sw_if_index0 in nat44-out2in has
configured/enabled policer), I think this may be reason of ASSERT.
Matus
-Original Message-
From: vpp-dev@lists.fd.io On Behalf Of Raj
Se
Hi Matus,
Thanks for the code fragment it helped me get a better understanding
of what I have to do, and have modified the code. But occasionally VPP
hits an ASSERT at:
DBGvpp# 0: /vpp/src/vlib/node_funcs.h:296
(vlib_node_runtime_get_next_frame) assertion `next_index <
n->n_next_nodes' fails
Abor
As you've probably noticed, the buffer manager has been under active
development. That may or may not have anything to do with the issue.
Please follow the bug reporting process:
https://wiki.fd.io/view/VPP/BugReports. In this case, using master/latest,
please create a Jira ticket including t
Hi all,
just a kind reminder the RC2 is today 18:00 UTC.
--a
On 1/21/19, Andrew 👽 Yourtchenko wrote:
> Hi all,
>
> A gentle reminder that VPP 19.01 RC2 is this Wednesday January 23rd, 18:00
> UTC.
>
> Note: After Wednesday's RC2 Milestone, only critical bug fixes will be
> merged into stable/1
On 22 Jan 2019, at 23:47, Ed Kern (ejk) mailto:e...@cisco.com>>
wrote:
As discussed in the vpp call this morning I have moved this from from running
on xenial to bionic.
Ran cleanly on the sandbox…but please let me know if anyone sees issues in
production.
Thanks!
--
Damjan
-=-=-=-=-=-=-=
