Re: [vpp-dev] vpp in a non-previleged mode

[Damjan Marion via lists.fd.io]

Why do you need dpdk?

— 
Damjan

> On 18.06.2021., at 06:47, Venumadhav Josyula  wrote:
> 
> 
> Hi Christian,
> 
> Can you please share the exact steps please ?
> 
> Thanks,
> Regards,
> Venu
> 
>> On Thu, 17 Jun 2021 at 21:25, Christian Hopps  wrote:
>> 
>> "Venumadhav Josyula"  writes:
>> 
>> > Hi All,
>> >
>> > Can you run vpp + dpdk in non-privileged mode ? This vpp running
>> > inside pod as a cnf
>> 
>> I did this at one point, IIRC I had to disable something small bit of code 
>> in the dpdk_early_init that required root, but as this code was only 
>> required to do something directly with the HW later, it wasn't needed in the 
>> container/virtual case.
>> 
>> Thanks,
>> Chris.
>> 
>> >
>> > Thanks,
>> > Regards,
>> > Venu
>> >
>> >
>> >
>> > 
>> 
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19605): https://lists.fd.io/g/vpp-dev/message/19605
Mute This Topic: https://lists.fd.io/mt/83551481/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] vpp in a non-previleged mode

[Venumadhav Josyula]

Hi Christian,

Can you please share the exact steps please ?

Thanks,
Regards,
Venu

On Thu, 17 Jun 2021 at 21:25, Christian Hopps  wrote:

>
> "Venumadhav Josyula"  writes:
>
> > Hi All,
> >
> > Can you run vpp + dpdk in non-privileged mode ? This vpp running
> > inside pod as a cnf
>
> I did this at one point, IIRC I had to disable something small bit of code
> in the dpdk_early_init that required root, but as this code was only
> required to do something directly with the HW later, it wasn't needed in
> the container/virtual case.
>
> Thanks,
> Chris.
>
> >
> > Thanks,
> > Regards,
> > Venu
> >
> >
> >
> > 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19604): https://lists.fd.io/g/vpp-dev/message/19604
Mute This Topic: https://lists.fd.io/mt/83551481/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] VPP and IS-IS

[Mike Beattie]

On Wed, Jun 16, 2021 at 09:14:13AM -0700, tim.boh...@gmx.ch wrote:
> Hi, I have found VPP as I was looking for an SRv6 testbed with a
> distributed control plane via IS-IS. Now the initial intent and how I came
> to VPP was a combination of FRR and VPP, which is discontinued as it
> seems. After some unfruitful research my question is if there is any
> existing possibility I may have overlooked to combine VPP with IS-IS?
> Sorry if this was answered before, my search only brought up old answers
> and I am unsure if this has changed.

Tim,

The current way to do this will be with the linux-cp and linux-nl plugins.

linux-cp has been merged to master, but linux-nl is still in development.
The Changeset for that is here: https://gerrit.fd.io/r/c/vpp/+/31122

Your rough order of actions is:
* clone master:
  - git clone https://gerrit.fd.io/r/vpp
* fetch the linux-nl changeset to your local repository:
  - git fetch origin refs/changes/22/31122/8
  - git checkout -b linux-nl b4ed743
* rebase or cherry-pick that changeset onto master:
  - git checkout linux-nl
  - git rebase master
  - [fix conflicts - there's a couple now]
* build.

* Configure in /etc/vpp/startup.conf :
  - disable ping and enable cp/nl:
o Add to plugins {} :
plugin ping_plugin.so { disable }
plugin linux_cp_plugin.so { enable }
plugin linux_nl_plugin.so { enable }

  - Enable linux-cp:
o Add this section:
  linux-cp {
  default netns dataplane
  interface-auto-create  # Optional
  }

* With latest FRR, start watchfrr with --netns. On Debian, in
  /etc/frr/daemons:
watchfrr_options="--netns=dataplane"

I've been slowly building a new router infrastructure with this using OSPF
and BGP, so far so good.

Mike.
-- 
Mike Beattie 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19603): https://lists.fd.io/g/vpp-dev/message/19603
Mute This Topic: https://lists.fd.io/mt/83584229/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] vpp in a non-previleged mode

[Christian Hopps]

"Venumadhav Josyula"  writes:


Hi All,

Can you run vpp + dpdk in non-privileged mode ? This vpp running
inside pod as a cnf


I did this at one point, IIRC I had to disable something small bit of code in 
the dpdk_early_init that required root, but as this code was only required to 
do something directly with the HW later, it wasn't needed in the 
container/virtual case.

Thanks,
Chris.



Thanks,
Regards,
Venu








signature.asc
Description: PGP signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19602): https://lists.fd.io/g/vpp-dev/message/19602
Mute This Topic: https://lists.fd.io/mt/83551481/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] clib_mask_compare_u16_x64 has asan issue

[James Tervit]

Hi Benoit,

Thank you I will have another go tomorrow.


On 17/06/2021, 15:28, "Benoit Ganne (bganne) via lists.fd.io" 
 wrote:

Here it is: https://gerrit.fd.io/r/c/vpp/+/32765
Note you also need https://gerrit.fd.io/r/c/vpp/+/32764/ to avoid false 
positives.

Best
ben

> -Original Message-
> From: Benoit Ganne (bganne)
> Sent: jeudi 17 juin 2021 11:40
> To: dmar...@me.com; jiangxiaom...@outlook.com
> Cc: vpp-dev@lists.fd.io
> Subject: RE: [vpp-dev] clib_mask_compare_u16_x64 has asan issue
> 
> I have a fix in progress for this one (I mean tell ASan to accept overflow
> there), I'll try to push it today.
> 
> Best
> ben
> 
> > -Original Message-
> > From: vpp-dev@lists.fd.io  On Behalf Of Damjan
> Marion
> > via lists.fd.io
> > Sent: jeudi 17 juin 2021 11:33
> > To: jiangxiaom...@outlook.com
> > Cc: vpp-dev@lists.fd.io
> > Subject: Re: [vpp-dev] clib_mask_compare_u16_x64 has asan issue
> >
> >
> > yes, for performance reason it is written as it is, you can ask asan to
> > ignore it
> >
> >
> > —
> > Damjan
> >
> >
> > On 17.06.2021., at 11:28, jiangxiaom...@outlook.com wrote:
> >
> >
> >
> > Hi Damjan Marion,
> >
> >  vector function: clib_mask_compare_u16_x64 has ASAN Issue,
> >
> >
> >
> > clib_mask_compare_u16_x64 (u16 v, u16 *a, u32 n_elts)
> > {
> >   ...
> >   u16x32u *av = (u16x32u *) a;
> >   ...
> >
> >   x = i8x32_pack (v16 == av[0], v16 == av[1]); <-  
av[0]
> > will read 64 bytes, but a[0] only have 2 bytes
> >
> >
> >
> > This function will lead to session node crash if ASAS enabled
> >
> >
> >
> >
> > 
=
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 0x7ff96f54d700 (LWP 113687)]
> > 0x773de5c1 in
> > __asan::FakeStack::AddrIsInFakeStack(unsigned long, unsigned long*,
> > unsigned long*) () from /home/dev/code/net-
> > base/dist/script/test/../../lib/libasan.so.5
> > Missing separate debuginfos, use: debuginfo-install 
libgcc-
> > 4.8.5-44.el7.x86_64 libstdc++-4.8.5-44.el7.x86_64 libuuid-2.23.2-
> > 65.el7_9.1.x86_64 mbedtls-2.7.17-1.el7.x86_64 pkcs11-helper-1.11-
> > 3.el7.x86_64
> > (gdb) bt
> > #0  0x773de5c1 in
> > __asan::FakeStack::AddrIsInFakeStack(unsigned long, unsigned long*,
> > unsigned long*) () from /home/dev/code/net-
> > base/dist/script/test/../../lib/libasan.so.5
> > #1  0x774c5a11 in
> > __asan::ThreadStackContainsAddress(__sanitizer::ThreadContextBase*,
> void*)
> > () from /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> > #2  0x774dfdc2 in
> > __sanitizer::ThreadRegistry::FindThreadContextLocked(bool
> > (*)(__sanitizer::ThreadContextBase*, void*), void*) () from
> > /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> > #3  0x774c6e5a in
> > __asan::FindThreadByStackAddress(unsigned long) () from
> > /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> > #4  0x773d8fb6 in
> > __asan::GetStackAddressInformation(unsigned long, unsigned long,
> > __asan::StackAddressDescription*) () from /home/dev/code/net-
> > base/dist/script/test/../../lib/libasan.so.5
> > #5  0x773da3f9 in
> > __asan::AddressDescription::AddressDescription(unsigned long, unsigned
> > long, bool) () from /home/dev/code/net-
> > base/dist/script/test/../../lib/libasan.so.5
> > #6  0x773dce51 in
> > __asan::ErrorGeneric::ErrorGeneric(unsigned int, unsigned long, unsigned
> > long, unsigned long, unsigned long, bool, unsigned long) () from
> > /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> > #7  0x774c0c2a in 
__asan::ReportGenericError(unsigned
> > long, unsigned long, unsigned long, unsigned long, bool, unsigned long,
> > unsigned int, bool) () from /home/dev/code/net-
> > base/dist/script/test/../../lib/libasan.so.5
> > #8  0x774c2194 in __asan_report_load_n () from
> > /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> > #9  0x741c34c5 in clib_mask_compare_u16_x64 
(v=2,
> > a=0x7fffd38cb980, n_elts=1) at /home/dev/code/net-base/.vpp-21.06-
> > rc2/src/vppinfra/vector_funcs.h:24
> > #10 0x

Re: [vpp-dev] Infinite loop in fib_walk_sync

[Sudhir CR via lists.fd.io]

Hi All,
I further modified the configuration and observed that issue is seen when
mpls route is present in the configuration.
Please find the simplified configuration to reproduce the issue.
Here MPLS route is used to pop the label do ipv4 forwarding

*Device configuration*
*Node 1:*
set interface ip address memif32321/32321 23.0.0.2/24

*mpls local-label add 2003 non-eos via 23.0.0.3 memif32321/32321
 out-labels 3*
bfd udp session add interface memif32321/32321 local-addr 23.0.0.2
peer-addr 23.0.0.3 desired-min-tx 40 required-min-rx 40 detect-mult
3
*Node 2:*
set interface ip address memif32321/32321 23.0.0.3/24

*mpls local-label add 2002 non-eos via 23.0.0.2 memif32321/32321
 out-labels 3*
bfd udp session add interface memif32321/32321 local-addr 23.0.0.3
peer-addr 23.0.0.2 desired-min-tx 40 required-min-rx 40 detect-mult
3

Thanks and Regards,
Sudhir

On Thu, Jun 17, 2021 at 2:32 PM Benoit Ganne (bganne) 
wrote:

> Hi Sudhir,
>
> It went through and this is the 3rd time now, but AFAICS you still did not
> address Neale's point:
> https://lists.fd.io/g/vpp-dev/message/19554?p=,,,20,0,0,0::Created,,infinite+loop,20,2,0,83418156
>
> Best
> ben
>
> > -Original Message-
> > From: vpp-dev@lists.fd.io  On Behalf Of Sudhir CR
> via
> > lists.fd.io
> > Sent: jeudi 17 juin 2021 10:59
> > To: vpp-dev@lists.fd.io
> > Subject: Re: [vpp-dev] Infinite loop in fib_walk_sync
> >
> > Hi All,
> >
> > I am resending the same again as i am not sure the former one had reached
> > the forum.
> >
> > Regards,
> > Sudhir.
> >
> > On Thu, Jun 17, 2021 at 1:15 PM Sudhir CR via lists.fd.io
> >    >  > wrote:
> >
> >
> >   Hi All,
> >   We have been using vpp with our stack for the 6PE solution for some
> > time.
> >   But when we recently enabled BFD in vpp we are observing an
> infinite
> > loop with the below call stack.
> >
> >   Any help in resolving this issue would be appreciated  .
> >
> >   (gdb) thread apply all bt
> >
> >   Thread 3 (Thread 0x7f6d27bfe700 (LWP 449)):
> >   #0  0x7f6dc79d4007 in vlib_worker_thread_barrier_check () at
> > /home/supervisor/libvpp/src/vlib/threads.h:438
> >   #1  0x7f6dc79ce52e in vlib_main_or_worker_loop
> > (vm=0x7f6da5f9b6c0, is_main=0) at
> > /home/supervisor/libvpp/src/vlib/main.c:1788
> >   #2  0x7f6dc79cdd47 in vlib_worker_loop (vm=0x7f6da5f9b6c0) at
> > /home/supervisor/libvpp/src/vlib/main.c:2008
> >   #3  0x7f6dc7a2592a in vlib_worker_thread_fn
> (arg=0x7f6da3593180)
> > at /home/supervisor/libvpp/src/vlib/threads.c:1862
> >   #4  0x7f6dc724bc34 in clib_calljmp () at
> > /home/supervisor/libvpp/src/vppinfra/longjmp.S:123
> >   #5  0x7f6d27bfdec0 in ?? ()
> >   #6  0x7f6dc7a1dad3 in vlib_worker_thread_bootstrap_fn
> > (arg=0x7f6da3593180) at /home/supervisor/libvpp/src/vlib/threads.c:585
> >   Backtrace stopped: previous frame inner to this frame (corrupt
> > stack?)
> >
> >   Thread 2 (Thread 0x7f6d283ff700 (LWP 448)):
> >   #0  0x7f6dc79d3ffe in vlib_worker_thread_barrier_check () at
> > /home/supervisor/libvpp/src/vlib/threads.h:438
> >   #1  0x7f6dc79ce52e in vlib_main_or_worker_loop
> > (vm=0x7f6da5f9a200, is_main=0) at
> > /home/supervisor/libvpp/src/vlib/main.c:1788
> >   #2  0x7f6dc79cdd47 in vlib_worker_loop (vm=0x7f6da5f9a200) at
> > /home/supervisor/libvpp/src/vlib/main.c:2008
> >   #3  0x7f6dc7a2592a in vlib_worker_thread_fn
> (arg=0x7f6da3593080)
> > at /home/supervisor/libvpp/src/vlib/threads.c:1862
> >   #4  0x7f6dc724bc34 in clib_calljmp () at
> > /home/supervisor/libvpp/src/vppinfra/longjmp.S:123
> >   #5  0x7f6d283feec0 in ?? ()
> >   #6  0x7f6dc7a1dad3 in vlib_worker_thread_bootstrap_fn
> > (arg=0x7f6da3593080) at /home/supervisor/libvpp/src/vlib/threads.c:585
> >   Backtrace stopped: previous frame inner to this frame (corrupt
> > stack?)
> >
> >   Thread 1 (Thread 0x7f6dd47c2240 (LWP 226)):
> >   #0  0x7f6dc723c2dc in hash_header (v=0x7f6da6870e18) at
> > /home/supervisor/libvpp/src/vppinfra/hash.h:113
> >   #1  0x7f6dc723d329 in get_pair (v=0x7f6da6870e18, i=55) at
> > /home/supervisor/libvpp/src/vppinfra/hash.c:58
> >   #2  0x7f6dc723c372 in lookup (v=0x7f6da6870e18,
> > key=140108524924744, op=GET, new_value=0x0, old_value=0x0)
> >   at /home/supervisor/libvpp/src/vppinfra/hash.c:557
> >   #3  0x7f6dc723c261 in _hash_get (v=0x7f6da6870e18,
> > key=140108524924744) at /home/supervisor/libvpp/src/vppinfra/hash.c:641
> >   #4  0x7f6dc8bbb5f4 in adj_nbr_find (nh_proto=FIB_PROTOCOL_IP4,
> > link_type=VNET_LINK_MPLS, nh_addr=0x7f6da6866c30, sw_if_index=8)
> >   at /home/supervisor/libvpp/src/vnet/adj/adj_nbr.c:124
> >   #5  0x7f6dc8bbb661 in adj_nbr_add_or_lock
> > (nh_proto=FIB_PROTOCOL_IP4, link_type=VNET_LINK_MPLS,
> > nh_addr=0x7f6da6866c30, sw_if_index=8)
> >   at 

Re: [vpp-dev] clib_mask_compare_u16_x64 has asan issue

[Benoit Ganne (bganne) via lists.fd.io]

Here it is: https://gerrit.fd.io/r/c/vpp/+/32765
Note you also need https://gerrit.fd.io/r/c/vpp/+/32764/ to avoid false 
positives.

Best
ben

> -Original Message-
> From: Benoit Ganne (bganne)
> Sent: jeudi 17 juin 2021 11:40
> To: dmar...@me.com; jiangxiaom...@outlook.com
> Cc: vpp-dev@lists.fd.io
> Subject: RE: [vpp-dev] clib_mask_compare_u16_x64 has asan issue
> 
> I have a fix in progress for this one (I mean tell ASan to accept overflow
> there), I'll try to push it today.
> 
> Best
> ben
> 
> > -Original Message-
> > From: vpp-dev@lists.fd.io  On Behalf Of Damjan
> Marion
> > via lists.fd.io
> > Sent: jeudi 17 juin 2021 11:33
> > To: jiangxiaom...@outlook.com
> > Cc: vpp-dev@lists.fd.io
> > Subject: Re: [vpp-dev] clib_mask_compare_u16_x64 has asan issue
> >
> >
> > yes, for performance reason it is written as it is, you can ask asan to
> > ignore it
> >
> >
> > —
> > Damjan
> >
> >
> > On 17.06.2021., at 11:28, jiangxiaom...@outlook.com wrote:
> >
> >
> >
> > Hi Damjan Marion,
> >
> >  vector function: clib_mask_compare_u16_x64 has ASAN Issue,
> >
> >
> >
> > clib_mask_compare_u16_x64 (u16 v, u16 *a, u32 n_elts)
> > {
> >   ...
> >   u16x32u *av = (u16x32u *) a;
> >   ...
> >
> >   x = i8x32_pack (v16 == av[0], v16 == av[1]); <-  av[0]
> > will read 64 bytes, but a[0] only have 2 bytes
> >
> >
> >
> > This function will lead to session node crash if ASAS enabled
> >
> >
> >
> >
> > =
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 0x7ff96f54d700 (LWP 113687)]
> > 0x773de5c1 in
> > __asan::FakeStack::AddrIsInFakeStack(unsigned long, unsigned long*,
> > unsigned long*) () from /home/dev/code/net-
> > base/dist/script/test/../../lib/libasan.so.5
> > Missing separate debuginfos, use: debuginfo-install libgcc-
> > 4.8.5-44.el7.x86_64 libstdc++-4.8.5-44.el7.x86_64 libuuid-2.23.2-
> > 65.el7_9.1.x86_64 mbedtls-2.7.17-1.el7.x86_64 pkcs11-helper-1.11-
> > 3.el7.x86_64
> > (gdb) bt
> > #0  0x773de5c1 in
> > __asan::FakeStack::AddrIsInFakeStack(unsigned long, unsigned long*,
> > unsigned long*) () from /home/dev/code/net-
> > base/dist/script/test/../../lib/libasan.so.5
> > #1  0x774c5a11 in
> > __asan::ThreadStackContainsAddress(__sanitizer::ThreadContextBase*,
> void*)
> > () from /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> > #2  0x774dfdc2 in
> > __sanitizer::ThreadRegistry::FindThreadContextLocked(bool
> > (*)(__sanitizer::ThreadContextBase*, void*), void*) () from
> > /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> > #3  0x774c6e5a in
> > __asan::FindThreadByStackAddress(unsigned long) () from
> > /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> > #4  0x773d8fb6 in
> > __asan::GetStackAddressInformation(unsigned long, unsigned long,
> > __asan::StackAddressDescription*) () from /home/dev/code/net-
> > base/dist/script/test/../../lib/libasan.so.5
> > #5  0x773da3f9 in
> > __asan::AddressDescription::AddressDescription(unsigned long, unsigned
> > long, bool) () from /home/dev/code/net-
> > base/dist/script/test/../../lib/libasan.so.5
> > #6  0x773dce51 in
> > __asan::ErrorGeneric::ErrorGeneric(unsigned int, unsigned long, unsigned
> > long, unsigned long, unsigned long, bool, unsigned long) () from
> > /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> > #7  0x774c0c2a in __asan::ReportGenericError(unsigned
> > long, unsigned long, unsigned long, unsigned long, bool, unsigned long,
> > unsigned int, bool) () from /home/dev/code/net-
> > base/dist/script/test/../../lib/libasan.so.5
> > #8  0x774c2194 in __asan_report_load_n () from
> > /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> > #9  0x741c34c5 in clib_mask_compare_u16_x64 (v=2,
> > a=0x7fffd38cb980, n_elts=1) at /home/dev/code/net-base/.vpp-21.06-
> > rc2/src/vppinfra/vector_funcs.h:24
> > #10 0x741c374c in clib_mask_compare_u16 (v=2,
> > a=0x7fffd38cb980, mask=0x7ff96ecf5310, n_elts=1) at /home/dev/code/net-
> > base/.vpp-21.06-rc2/src/vppinfra/vector_funcs.h:79
> > #11 0x741c3b7b in enqueue_one (vm=0x7fffd1c73080,
> > node=0x7fffd2d21040, used_elt_bmp=0x7ff96ecf5440, next_index=2,
> > buffers=0x7fffd1d3b2d0, nexts=0x7fffd38cb980, n_buffers=1, n_left=1,
> > tmp=0x7ff96ecf5480) at /home/dev/code/net-base/.vpp-21.06-
> > rc2/src/vlib/buffer_funcs.c:30
> > #12 0x741fe451 in vlib_buffer_enqueue_to_next_fn_hsw
> > (vm=0x7fffd1c73080, node=0x7fffd2d21040, buffers=0x7fffd1d3b2d0,
> > nexts=0x7fffd38cb980, count=1) at /home/dev/code/

Re: [vpp-dev] Regarding DPO object

[Neale Ranns]

Hi Vijay,

The CLI, whether for ABF or IP routes, cannot parse arbitrary DPOs, especially 
your custom one. If you must use the CLI, which is strongly discouraged, you’ll 
have to extend it to support parsing your own DPO and to construct the 
fib_route_path accordingly.

/neale


From: Vijay Kumar 
Date: Thursday, 17 June 2021 at 13:08
To: Neale Ranns 
Cc: vpp-dev 
Subject: Re: [vpp-dev] Regarding DPO object

Hi Neale,

I saw the code of abf_plicy_cmd() function. I was hoping to see something 
related to DPO in the function unformat_fib_route_path() which parses the ABF 
CLI. But I did not find anything.

All I could find within the function was the below code related to source 
address matching.
else if (unformat (input, "src-lookup"))
{
rpath->frp_flags |= FIB_ROUTE_PATH_SOURCE_LOOKUP;
}

Could you help to share the exact syntax to attach DPO in the ABFpolicy command?


abf policy add id  acl  via 192.168.1.1 GigE0/0


Regards.

On Wed, Jun 16, 2021 at 8:07 PM Neale Ranns 
mailto:ne...@graphiant.com>> wrote:

It does use ACLs for matching, that’s what allows you to specify src and dst IP 
ranges. Once matched the packet is forwarded on the path the specified by the 
policy. You can set this path to use your DPO. Use the EXCLUSIVE flag to do 
this.

/neale


From: Vijay Kumar mailto:vjkumar2...@gmail.com>>
Date: Wednesday, 16 June 2021 at 16:28
To: Neale Ranns mailto:ne...@graphiant.com>>
Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] Regarding DPO object
Hi Neale,

The ABF is ACL based matching and forwarding plugin right. This would allow one 
to match a packet with ACL and forward it on a configured outbound interface.

My case is different, I don't want to match ACL and forward packets out on an 
interface. I want the packet matching a certain SRC IP range to be sent to my 
new plugin (in this case XYZ ) which would do further processing specific to 
our product.

For example, if IPSec traffic is originating from UE, we see the packets flow 
through these nodes. After ESP and GRE, the inner packet src IP is that of the 
UE. Is it possible for graph node XYZ to request for an IP packet matching 
certain SRC IP?

UE --> 
[ESP4_decryptIPGRE_Input-IPXYZ-IP-Interface]-> 
internet host



Regards.






On Wed, Jun 16, 2021 at 7:07 PM Neale Ranns 
mailto:ne...@graphiant.com>> wrote:
Hi Vijay,

The FIB will only match against a destination prefix. If you want to use DPOs 
with more complex matching, try the ABF plugin.

/neale


From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> on behalf of Vijay Kumar via 
lists.fd.io 
mailto:gmail@lists.fd.io>>
Date: Wednesday, 16 June 2021 at 15:04
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] Regarding DPO object
Hi experts,

I am creating a DPO object (for protocol IP4) and am tying an UE prefix for 
this DPO and adding the corresponding entry to the FIB table.

I have a graph node to which I need to post all IP packets matching a range of 
source IPs.

Does the DPO work only for packets destined to a certain prefix or range of IP 
prefixes or can we use DPO for requesting packets based on source IP range also?


Regards,
Vijay N
Regards,
Vijay N

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19598): https://lists.fd.io/g/vpp-dev/message/19598
Mute This Topic: https://lists.fd.io/mt/83579849/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Regarding DPO object

[Vijay Kumar]

Hi Neale,

I saw the code of abf_plicy_cmd() function. I was hoping to see something
related to DPO in the function *unformat_fib_route_path*() which parses the
ABF CLI. But I did not find anything.

All I could find within the function was the below code related to source
address matching.
else if (unformat (input, "src-lookup"))
{
rpath->frp_flags |= FIB_ROUTE_PATH_SOURCE_LOOKUP;
}

Could you help to share the exact syntax to attach DPO in the ABFpolicy
command?

abf policy add id  acl  via 192.168.1.1 GigE0/0



Regards.

On Wed, Jun 16, 2021 at 8:07 PM Neale Ranns  wrote:

>
>
> It does use ACLs for matching, that’s what allows you to specify src and
> dst IP ranges. Once matched the packet is forwarded on the path the
> specified by the policy. You can set this path to use your DPO. Use the
> EXCLUSIVE flag to do this.
>
>
>
> /neale
>
>
>
>
>
> *From: *Vijay Kumar 
> *Date: *Wednesday, 16 June 2021 at 16:28
> *To: *Neale Ranns 
> *Cc: *vpp-dev 
> *Subject: *Re: [vpp-dev] Regarding DPO object
>
> Hi Neale,
>
>
>
> The ABF is ACL based matching and forwarding plugin right. This would
> allow one to match a packet with ACL and forward it on a configured
> outbound interface.
>
>
>
> My case is different, I don't want to match ACL and forward packets out on
> an interface. I want the packet matching a certain SRC IP range to be sent
> to my new plugin (in this case *XYZ *) which would do further processing
> specific to our product.
>
>
>
> For example, if IPSec traffic is originating from UE, we see the packets
> flow through these nodes. After ESP and GRE, the inner packet src IP is
> that of the UE. Is it possible for graph node *XYZ *to request for an IP
> packet matching certain SRC IP?
>
>
>
> UE --> 
> [ESP4_decryptIPGRE_Input-IP*XYZ*-IP-Interface]->
> internet host
>
>
>
>
>
>
>
> Regards.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Jun 16, 2021 at 7:07 PM Neale Ranns  wrote:
>
> Hi Vijay,
>
>
>
> The FIB will only match against a destination prefix. If you want to use
> DPOs with more complex matching, try the ABF plugin.
>
>
>
> /neale
>
>
>
>
>
> *From: *vpp-dev@lists.fd.io  on behalf of Vijay
> Kumar via lists.fd.io 
> *Date: *Wednesday, 16 June 2021 at 15:04
> *To: *vpp-dev 
> *Subject: *[vpp-dev] Regarding DPO object
>
> Hi experts,
>
>
>
> I am creating a DPO object (for protocol IP4) and am tying an UE prefix
> for this DPO and adding the corresponding entry to the FIB table.
>
>
>
> I have a graph node to which I need to post all IP packets matching a
> range of source IPs.
>
>
>
> Does the DPO work only for packets destined to a certain prefix or range
> of IP prefixes or can we use DPO for requesting packets based on source IP
> range also?
>
>
>
>
>
> Regards,
>
> Vijay N
>
> Regards,
>
> Vijay N
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19597): https://lists.fd.io/g/vpp-dev/message/19597
Mute This Topic: https://lists.fd.io/mt/83579849/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] clib_mask_compare_u16_x64 has asan issue

[jiangxiaoming]

Is there any way  setting asan only avoiding error in this function ?

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19596): https://lists.fd.io/g/vpp-dev/message/19596
Mute This Topic: https://lists.fd.io/mt/83600497/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] clib_mask_compare_u16_x64 has asan issue

[Benoit Ganne (bganne) via lists.fd.io]

I have a fix in progress for this one (I mean tell ASan to accept overflow 
there), I'll try to push it today.

Best
ben

> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Damjan Marion
> via lists.fd.io
> Sent: jeudi 17 juin 2021 11:33
> To: jiangxiaom...@outlook.com
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] clib_mask_compare_u16_x64 has asan issue
> 
> 
> yes, for performance reason it is written as it is, you can ask asan to
> ignore it
> 
> 
> —
> Damjan
> 
> 
>   On 17.06.2021., at 11:28, jiangxiaom...@outlook.com wrote:
> 
> 
> 
>   Hi Damjan Marion,
> 
>vector function: clib_mask_compare_u16_x64 has ASAN Issue,
> 
> 
> 
>   clib_mask_compare_u16_x64 (u16 v, u16 *a, u32 n_elts)
>   {
> ...
> u16x32u *av = (u16x32u *) a;
> ...
> 
> x = i8x32_pack (v16 == av[0], v16 == av[1]); <-  av[0]
> will read 64 bytes, but a[0] only have 2 bytes
> 
> 
> 
>   This function will lead to session node crash if ASAS enabled
> 
> 
> 
> 
>   =
> 
>   Program received signal SIGSEGV, Segmentation fault.
>   [Switching to Thread 0x7ff96f54d700 (LWP 113687)]
>   0x773de5c1 in
> __asan::FakeStack::AddrIsInFakeStack(unsigned long, unsigned long*,
> unsigned long*) () from /home/dev/code/net-
> base/dist/script/test/../../lib/libasan.so.5
>   Missing separate debuginfos, use: debuginfo-install libgcc-
> 4.8.5-44.el7.x86_64 libstdc++-4.8.5-44.el7.x86_64 libuuid-2.23.2-
> 65.el7_9.1.x86_64 mbedtls-2.7.17-1.el7.x86_64 pkcs11-helper-1.11-
> 3.el7.x86_64
>   (gdb) bt
>   #0  0x773de5c1 in
> __asan::FakeStack::AddrIsInFakeStack(unsigned long, unsigned long*,
> unsigned long*) () from /home/dev/code/net-
> base/dist/script/test/../../lib/libasan.so.5
>   #1  0x774c5a11 in
> __asan::ThreadStackContainsAddress(__sanitizer::ThreadContextBase*, void*)
> () from /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
>   #2  0x774dfdc2 in
> __sanitizer::ThreadRegistry::FindThreadContextLocked(bool
> (*)(__sanitizer::ThreadContextBase*, void*), void*) () from
> /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
>   #3  0x774c6e5a in
> __asan::FindThreadByStackAddress(unsigned long) () from
> /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
>   #4  0x773d8fb6 in
> __asan::GetStackAddressInformation(unsigned long, unsigned long,
> __asan::StackAddressDescription*) () from /home/dev/code/net-
> base/dist/script/test/../../lib/libasan.so.5
>   #5  0x773da3f9 in
> __asan::AddressDescription::AddressDescription(unsigned long, unsigned
> long, bool) () from /home/dev/code/net-
> base/dist/script/test/../../lib/libasan.so.5
>   #6  0x773dce51 in
> __asan::ErrorGeneric::ErrorGeneric(unsigned int, unsigned long, unsigned
> long, unsigned long, unsigned long, bool, unsigned long) () from
> /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
>   #7  0x774c0c2a in __asan::ReportGenericError(unsigned
> long, unsigned long, unsigned long, unsigned long, bool, unsigned long,
> unsigned int, bool) () from /home/dev/code/net-
> base/dist/script/test/../../lib/libasan.so.5
>   #8  0x774c2194 in __asan_report_load_n () from
> /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
>   #9  0x741c34c5 in clib_mask_compare_u16_x64 (v=2,
> a=0x7fffd38cb980, n_elts=1) at /home/dev/code/net-base/.vpp-21.06-
> rc2/src/vppinfra/vector_funcs.h:24
>   #10 0x741c374c in clib_mask_compare_u16 (v=2,
> a=0x7fffd38cb980, mask=0x7ff96ecf5310, n_elts=1) at /home/dev/code/net-
> base/.vpp-21.06-rc2/src/vppinfra/vector_funcs.h:79
>   #11 0x741c3b7b in enqueue_one (vm=0x7fffd1c73080,
> node=0x7fffd2d21040, used_elt_bmp=0x7ff96ecf5440, next_index=2,
> buffers=0x7fffd1d3b2d0, nexts=0x7fffd38cb980, n_buffers=1, n_left=1,
> tmp=0x7ff96ecf5480) at /home/dev/code/net-base/.vpp-21.06-
> rc2/src/vlib/buffer_funcs.c:30
>   #12 0x741fe451 in vlib_buffer_enqueue_to_next_fn_hsw
> (vm=0x7fffd1c73080, node=0x7fffd2d21040, buffers=0x7fffd1d3b2d0,
> nexts=0x7fffd38cb980, count=1) at /home/dev/code/net-base/.vpp-21.06-
> rc2/src/vlib/buffer_funcs.c:110
>   #13 0x75aff172 in vlib_buffer_enqueue_to_next
> (vm=0x7fffd1c73080, node=0x7fffd2d21040, buffers=0x7fffd1d3b2d0,
> nexts=0x7fffd38cb980, count=1) at /home/dev/code/net-base/.vpp-21.06-
> rc2/src/vlib/buffer_node.h:344
>   #14 0x75b16b0a in session_flush_pending_tx_buffers
> (wrk=0x7fffd4d1ad40, node=0x7fffd2d21040) at /home/dev/code/net-base/.vpp-
> 21.06-rc2/src/vnet/session/session_node.c:1626
>   #15 

Re: [vpp-dev] clib_mask_compare_u16_x64 has asan issue

[Damjan Marion via lists.fd.io]

yes, for performance reason it is written as it is, you can ask asan to ignore 
it

— 
Damjan

> On 17.06.2021., at 11:28, jiangxiaom...@outlook.com wrote:
> 
> Hi Damjan Marion,
> 
>  vector function: clib_mask_compare_u16_x64 has ASAN Issue,
> 
> clib_mask_compare_u16_x64 (u16 v, u16 *a, u32 n_elts)
> {
>   ...
>   u16x32u *av = (u16x32u *) a;
>   ...
>
>   x = i8x32_pack (v16 == av[0], v16 == av[1]); <-  av[0] will read 64 
> bytes, but a[0] only have 2 bytes
> 
> This function will lead to session node crash if ASAS enabled
> 
> =
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7ff96f54d700 (LWP 113687)]
> 0x773de5c1 in __asan::FakeStack::AddrIsInFakeStack(unsigned long, 
> unsigned long*, unsigned long*) () from 
> /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> Missing separate debuginfos, use: debuginfo-install 
> libgcc-4.8.5-44.el7.x86_64 libstdc++-4.8.5-44.el7.x86_64 
> libuuid-2.23.2-65.el7_9.1.x86_64 mbedtls-2.7.17-1.el7.x86_64 
> pkcs11-helper-1.11-3.el7.x86_64
> (gdb) bt
> #0  0x773de5c1 in __asan::FakeStack::AddrIsInFakeStack(unsigned long, 
> unsigned long*, unsigned long*) () from 
> /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> #1  0x774c5a11 in 
> __asan::ThreadStackContainsAddress(__sanitizer::ThreadContextBase*, void*) () 
> from /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> #2  0x774dfdc2 in 
> __sanitizer::ThreadRegistry::FindThreadContextLocked(bool 
> (*)(__sanitizer::ThreadContextBase*, void*), void*) () from 
> /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> #3  0x774c6e5a in __asan::FindThreadByStackAddress(unsigned long) () 
> from /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> #4  0x773d8fb6 in __asan::GetStackAddressInformation(unsigned long, 
> unsigned long, __asan::StackAddressDescription*) () from 
> /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> #5  0x773da3f9 in 
> __asan::AddressDescription::AddressDescription(unsigned long, unsigned long, 
> bool) () from /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> #6  0x773dce51 in __asan::ErrorGeneric::ErrorGeneric(unsigned int, 
> unsigned long, unsigned long, unsigned long, unsigned long, bool, unsigned 
> long) () from /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> #7  0x774c0c2a in __asan::ReportGenericError(unsigned long, unsigned 
> long, unsigned long, unsigned long, bool, unsigned long, unsigned int, bool) 
> () from /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> #8  0x774c2194 in __asan_report_load_n () from 
> /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> #9  0x741c34c5 in clib_mask_compare_u16_x64 (v=2, a=0x7fffd38cb980, 
> n_elts=1) at 
> /home/dev/code/net-base/.vpp-21.06-rc2/src/vppinfra/vector_funcs.h:24
> #10 0x741c374c in clib_mask_compare_u16 (v=2, a=0x7fffd38cb980, 
> mask=0x7ff96ecf5310, n_elts=1) at 
> /home/dev/code/net-base/.vpp-21.06-rc2/src/vppinfra/vector_funcs.h:79
> #11 0x741c3b7b in enqueue_one (vm=0x7fffd1c73080, 
> node=0x7fffd2d21040, used_elt_bmp=0x7ff96ecf5440, next_index=2, 
> buffers=0x7fffd1d3b2d0, nexts=0x7fffd38cb980, n_buffers=1, n_left=1, 
> tmp=0x7ff96ecf5480) at 
> /home/dev/code/net-base/.vpp-21.06-rc2/src/vlib/buffer_funcs.c:30
> #12 0x741fe451 in vlib_buffer_enqueue_to_next_fn_hsw 
> (vm=0x7fffd1c73080, node=0x7fffd2d21040, buffers=0x7fffd1d3b2d0, 
> nexts=0x7fffd38cb980, count=1) at 
> /home/dev/code/net-base/.vpp-21.06-rc2/src/vlib/buffer_funcs.c:110
> #13 0x75aff172 in vlib_buffer_enqueue_to_next (vm=0x7fffd1c73080, 
> node=0x7fffd2d21040, buffers=0x7fffd1d3b2d0, nexts=0x7fffd38cb980, count=1) 
> at /home/dev/code/net-base/.vpp-21.06-rc2/src/vlib/buffer_node.h:344
> #14 0x75b16b0a in session_flush_pending_tx_buffers 
> (wrk=0x7fffd4d1ad40, node=0x7fffd2d21040) at 
> /home/dev/code/net-base/.vpp-21.06-rc2/src/vnet/session/session_node.c:1626
> #15 0x75b1a3db in session_queue_node_fn (vm=0x7fffd1c73080, 
> node=0x7fffd2d21040, frame=0x0) at 
> /home/dev/code/net-base/.vpp-21.06-rc2/src/vnet/session/session_node.c:1793
> #16 0x740a1bfb in dispatch_node (vm=0x7fffd1c73080, 
> node=0x7fffd2d21040, type=VLIB_NODE_TYPE_INPUT, 
> dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x0, 
> last_time_stamp=101201619637438) at 
> /home/dev/code/net-base/.vpp-21.06-rc2/src/vlib/main.c:1024
> #17 0x740a6aef in vlib_main_or_worker_loop (vm=0x7fffd1c73080, 
> is_main=0) at /home/dev/code/net-base/.vpp-21.06-rc2/src/vlib/main.c:1618
> #18 0x740a8713 in vlib_worker_loop (vm=0x7fffd1c73080) at 
> /home/dev/code/net-base/.vpp-21.06-rc2/src/vlib/main.c:1783
> #19 0x7413f573 in vlib_worker_thread_fn (arg=0x7fffd685c500) at 
> /home/dev/code/net-base/

[vpp-dev] clib_mask_compare_u16_x64 has asan issue

[jiangxiaoming]

Hi Damjan Marion,

vector function: clib_mask_compare_u16_x64 has ASAN Issue,

> 
> clib_mask_compare_u16_x64 (u16 v, u16 *a, u32 n_elts)
> {
> ...
> u16x32u *av = (u16x32u *) a;
> ...
> 
> x = i8x32_pack (v16 == av[0], v16 == av[1]); <- *av[0] will read 64
> bytes, but a[0] only have 2 bytes
> *
> 

This function will lead to session node crash if ASAS enabled

> 
> =
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7ff96f54d700 (LWP 113687)]
> 0x773de5c1 in __asan::FakeStack::AddrIsInFakeStack(unsigned long,
> unsigned long*, unsigned long*) () from
> /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> Missing separate debuginfos, use: debuginfo-install
> libgcc-4.8.5-44.el7.x86_64 libstdc++-4.8.5-44.el7.x86_64
> libuuid-2.23.2-65.el7_9.1.x86_64 mbedtls-2.7.17-1.el7.x86_64
> pkcs11-helper-1.11-3.el7.x86_64
> (gdb) bt
> #0  0x773de5c1 in __asan::FakeStack::AddrIsInFakeStack(unsigned
> long, unsigned long*, unsigned long*) () from
> /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> #1  0x774c5a11 in
> __asan::ThreadStackContainsAddress(__sanitizer::ThreadContextBase*, void*)
> () from /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> #2  0x774dfdc2 in
> __sanitizer::ThreadRegistry::FindThreadContextLocked(bool
> (*)(__sanitizer::ThreadContextBase*, void*), void*) () from
> /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> #3  0x774c6e5a in __asan::FindThreadByStackAddress(unsigned long)
> () from /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> #4  0x773d8fb6 in __asan::GetStackAddressInformation(unsigned
> long, unsigned long, __asan::StackAddressDescription*) () from
> /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> #5  0x773da3f9 in
> __asan::AddressDescription::AddressDescription(unsigned long, unsigned
> long, bool) () from
> /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> #6  0x773dce51 in __asan::ErrorGeneric::ErrorGeneric(unsigned int,
> unsigned long, unsigned long, unsigned long, unsigned long, bool, unsigned
> long) () from
> /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> #7  0x774c0c2a in __asan::ReportGenericError(unsigned long,
> unsigned long, unsigned long, unsigned long, bool, unsigned long, unsigned
> int, bool) () from
> /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> #8  0x774c2194 in __asan_report_load_n () from
> /home/dev/code/net-base/dist/script/test/../../lib/libasan.so.5
> #9  0x741c34c5 in clib_mask_compare_u16_x64 (v=2,
> a=0x7fffd38cb980, n_elts=1) at
> /home/dev/code/net-base/.vpp-21.06-rc2/src/vppinfra/vector_funcs.h:24
> #10 0x741c374c in clib_mask_compare_u16 (v=2, a=0x7fffd38cb980,
> mask=0x7ff96ecf5310, n_elts=1) at
> /home/dev/code/net-base/.vpp-21.06-rc2/src/vppinfra/vector_funcs.h:79
> #11 0x741c3b7b in enqueue_one (vm=0x7fffd1c73080,
> node=0x7fffd2d21040, used_elt_bmp=0x7ff96ecf5440, next_index=2,
> buffers=0x7fffd1d3b2d0, nexts=0x7fffd38cb980, n_buffers=1, n_left=1,
> tmp=0x7ff96ecf5480) at
> /home/dev/code/net-base/.vpp-21.06-rc2/src/vlib/buffer_funcs.c:30
> #12 0x741fe451 in vlib_buffer_enqueue_to_next_fn_hsw
> (vm=0x7fffd1c73080, node=0x7fffd2d21040, buffers=0x7fffd1d3b2d0,
> nexts=0x7fffd38cb980, count=1) at
> /home/dev/code/net-base/.vpp-21.06-rc2/src/vlib/buffer_funcs.c:110
> #13 0x75aff172 in vlib_buffer_enqueue_to_next (vm=0x7fffd1c73080,
> node=0x7fffd2d21040, buffers=0x7fffd1d3b2d0, nexts=0x7fffd38cb980,
> count=1) at
> /home/dev/code/net-base/.vpp-21.06-rc2/src/vlib/buffer_node.h:344
> #14 0x75b16b0a in session_flush_pending_tx_buffers
> (wrk=0x7fffd4d1ad40, node=0x7fffd2d21040) at
> /home/dev/code/net-base/.vpp-21.06-rc2/src/vnet/session/session_node.c:1626
> 
> #15 0x75b1a3db in session_queue_node_fn (vm=0x7fffd1c73080,
> node=0x7fffd2d21040, frame=0x0) at
> /home/dev/code/net-base/.vpp-21.06-rc2/src/vnet/session/session_node.c:1793
> 
> #16 0x740a1bfb in dispatch_node (vm=0x7fffd1c73080,
> node=0x7fffd2d21040, type=VLIB_NODE_TYPE_INPUT,
> dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x0,
> last_time_stamp=101201619637438) at
> /home/dev/code/net-base/.vpp-21.06-rc2/src/vlib/main.c:1024
> #17 0x740a6aef in vlib_main_or_worker_loop (vm=0x7fffd1c73080,
> is_main=0) at /home/dev/code/net-base/.vpp-21.06-rc2/src/vlib/main.c:1618
> #18 0x740a8713 in vlib_worker_loop (vm=0x7fffd1c73080) at
> /home/dev/code/net-base/.vpp-21.06-rc2/src/vlib/main.c:1783
> #19 0x7413f573 in vlib_worker_thread_fn (arg=0x7fffd685c500) at
> /home/dev/code/net-base/.vpp-21.06-rc2/src/vlib/threads.c:1562
> #20 0x7377b504 in clib_calljmp () at
> /home/dev/code/net-base/.vpp-21.06-rc2/src/vppinfra/longjmp.S:123
> #21 0x7ff96f54cc30 in ?? ()
> #22 0x74

Re: [vpp-dev] vpp hangs with bfd configuration

[Sudhir CR via lists.fd.io]

Hi neale,
Sorry for the late reply,
After your comment i made a slight change in the configuration, still issue
is seen.
Since it looks like a fib issue, I started a new issue with a different
subject.
Please find full details in below url
https://lists.fd.io/g/vpp-dev/message/19589

Thanks and Regards,
Sudhir


On Thu, Jun 10, 2021 at 9:07 PM Neale Ranns  wrote:

>
>
>
>
> *From: *vpp-dev@lists.fd.io  on behalf of Sudhir CR
> via lists.fd.io 
> *Date: *Thursday, 10 June 2021 at 08:50
> *To: *vpp-dev@lists.fd.io 
> *Subject: *[vpp-dev] vpp hangs with bfd configuration
>
> Hi All,
>
> when we are trying to establish a BFD session between two containers while
> processing "adj_bfd_notify '' * VPP went into an infinite loop and hung *in
> one of the containers, and this issue is reproducible every time with below
> topology and configuration.
>
>
>
> Any help in fixing the issue would be appreciated.
>
>
>
> *Topology:*
>
>
>
>   Container1 (memif32321/32321)  -
> (memif32321/32321)Container2
>
>
>
> *Configuration:*
>
> Container1
>
> 
>
> set interface ip address memif32321/32321 4.4.4.4/24
> ip table add 100
> ip route add 4.4.4.0/24 table 100 via 4.4.4.5 memif32321/32321 out-labels
> 
> ip route add 4.4.4.5/32 table 100 via 4.4.4.5 memif32321/32321 out-labels
> 
>
> set interface mpls memif32321/32321 enable
> mpls local-label add  eos via 4.4.4.5 memif32321/32321
> ip4-lookup-in-table 100
>
>
>
> what’s the intent here? Do you want to forward via the memif or do a
> lookup, you can’t do both.
>
> Fix that and see if it helps.
>
>
>
> /neale
>
>
>
> bfd udp session add interface memif32321/32321 local-addr 4.4.4.4
> peer-addr 4.4.4.5 desired-min-tx 40 required-min-rx 40 detect-mult 3
>
>
>
> Container2
>
> 
>
> set interface ip address memif32321/32321 4.4.4.5/24
> ip table add 100
> ip route add 4.4.4.0/24 table 100 via 4.4.4.4 memif32321/32321 out-labels
> 
> ip route add 4.4.4.4/32 table 100 via 4.4.4.4 memif32321/32321 out-labels
> 
> set interface mpls memif32321/32321 enable
> mpls local-label add   eos via 4.4.4.4 memif32321/32321
> ip4-lookup-in-table 100
> bfd udp session add interface memif32321/32321 local-addr 4.4.4.5
> peer-addr 4.4.4.4 desired-min-tx 40 required-min-rx 40 detect-mult 3
>
>
>
> *VPP version: *20.09
>
>
>
> (gdb) thread apply all bt
>
> Thread 3 (Thread 0x7f7ac6ffe700 (LWP 422)):
> #0  0x7f7b67036ffe in vlib_worker_thread_barrier_check () at
> /home/supervisor/development/libvpp/src/vlib/threads.h:438
> #1  0x7f7b6703152e in vlib_main_or_worker_loop (vm=0x7f7b46cf3240,
> is_main=0) at /home/supervisor/development/libvpp/src/vlib/main.c:1788
> #2  0x7f7b67030d47 in vlib_worker_loop (vm=0x7f7b46cf3240) at
> /home/supervisor/development/libvpp/src/vlib/main.c:2008
> #3  0x7f7b6708892a in vlib_worker_thread_fn (arg=0x7f7b41f14540) at
> /home/supervisor/development/libvpp/src/vlib/threads.c:1862
> #4  0x7f7b668adc44 in clib_calljmp () at
> /home/supervisor/development/libvpp/src/vppinfra/longjmp.S:123
> #5  0x7f7ac6ffdec0 in ?? ()
> #6  0x7f7b67080ad3 in vlib_worker_thread_bootstrap_fn
> (arg=0x7f7b41f14540) at
> /home/supervisor/development/libvpp/src/vlib/threads.c:585
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>
> Thread 2 (Thread 0x7f7ac77ff700 (LWP 421)):
> #0  0x7f7b67036fef in vlib_worker_thread_barrier_check () at
> /home/supervisor/development/libvpp/src/vlib/threads.h:437
> #1  0x7f7b6703152e in vlib_main_or_worker_loop (vm=0x7f7b45fe8b80,
> is_main=0) at /home/supervisor/development/libvpp/src/vlib/main.c:1788
> #2  0x7f7b67030d47 in vlib_worker_loop (vm=0x7f7b45fe8b80) at
> /home/supervisor/development/libvpp/src/vlib/main.c:2008
> #3  0x7f7b6708892a in vlib_worker_thread_fn (arg=0x7f7b41f14440) at
> /home/supervisor/development/libvpp/src/vlib/threads.c:1862
> #4  0x7f7b668adc44 in clib_calljmp () at
> /home/supervisor/development/libvpp/src/vppinfra/longjmp.S:123
> #5  0x7f7ac77feec0 in ?? ()
> #6  0x7f7b67080ad3 in vlib_worker_thread_bootstrap_fn
> (arg=0x7f7b41f14440) at
> /home/supervisor/development/libvpp/src/vlib/threads.c:585
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>
> Thread 1 (Thread 0x7f7b739b7740 (LWP 226)):
> #0  0x7f7b681c952b in fib_node_list_remove (list=54, sibling=63) at
> /home/supervisor/development/libvpp/src/vnet/fib/fib_node_list.c:246
> #1  0x7f7b681c7695 in fib_node_child_remove
> (parent_type=FIB_NODE_TYPE_ADJ, parent_index=1, sibling_index=63)
> at /home/supervisor/development/libvpp/src/vnet/fib/fib_node.c:131
> #2  0x7f7b681b2395 in fib_walk_destroy (fwi=2) at
> /home/supervisor/development/libvpp/src/vnet/fib/fib_walk.c:262
> #3  0x7f7b681b2f13 in fib_walk_sync (parent_type=FIB_NODE_TYPE_ADJ,
> parent_index=1, ctx=0x7f7b2e08dc90)
> at /home/supervisor/development/libvpp/src/vnet/fib/fib_walk.c:818
> #4  0x7f7b6821ed4d in adj

Re: [vpp-dev] Infinite loop in fib_walk_sync

[Benoit Ganne (bganne) via lists.fd.io]

Hi Sudhir,

It went through and this is the 3rd time now, but AFAICS you still did not 
address Neale's point: 
https://lists.fd.io/g/vpp-dev/message/19554?p=,,,20,0,0,0::Created,,infinite+loop,20,2,0,83418156

Best
ben

> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Sudhir CR via
> lists.fd.io
> Sent: jeudi 17 juin 2021 10:59
> To: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] Infinite loop in fib_walk_sync
> 
> Hi All,
> 
> I am resending the same again as i am not sure the former one had reached
> the forum.
> 
> Regards,
> Sudhir.
> 
> On Thu, Jun 17, 2021 at 1:15 PM Sudhir CR via lists.fd.io
>     > wrote:
> 
> 
>   Hi All,
>   We have been using vpp with our stack for the 6PE solution for some
> time.
>   But when we recently enabled BFD in vpp we are observing an infinite
> loop with the below call stack.
> 
>   Any help in resolving this issue would be appreciated  .
> 
>   (gdb) thread apply all bt
> 
>   Thread 3 (Thread 0x7f6d27bfe700 (LWP 449)):
>   #0  0x7f6dc79d4007 in vlib_worker_thread_barrier_check () at
> /home/supervisor/libvpp/src/vlib/threads.h:438
>   #1  0x7f6dc79ce52e in vlib_main_or_worker_loop
> (vm=0x7f6da5f9b6c0, is_main=0) at
> /home/supervisor/libvpp/src/vlib/main.c:1788
>   #2  0x7f6dc79cdd47 in vlib_worker_loop (vm=0x7f6da5f9b6c0) at
> /home/supervisor/libvpp/src/vlib/main.c:2008
>   #3  0x7f6dc7a2592a in vlib_worker_thread_fn (arg=0x7f6da3593180)
> at /home/supervisor/libvpp/src/vlib/threads.c:1862
>   #4  0x7f6dc724bc34 in clib_calljmp () at
> /home/supervisor/libvpp/src/vppinfra/longjmp.S:123
>   #5  0x7f6d27bfdec0 in ?? ()
>   #6  0x7f6dc7a1dad3 in vlib_worker_thread_bootstrap_fn
> (arg=0x7f6da3593180) at /home/supervisor/libvpp/src/vlib/threads.c:585
>   Backtrace stopped: previous frame inner to this frame (corrupt
> stack?)
> 
>   Thread 2 (Thread 0x7f6d283ff700 (LWP 448)):
>   #0  0x7f6dc79d3ffe in vlib_worker_thread_barrier_check () at
> /home/supervisor/libvpp/src/vlib/threads.h:438
>   #1  0x7f6dc79ce52e in vlib_main_or_worker_loop
> (vm=0x7f6da5f9a200, is_main=0) at
> /home/supervisor/libvpp/src/vlib/main.c:1788
>   #2  0x7f6dc79cdd47 in vlib_worker_loop (vm=0x7f6da5f9a200) at
> /home/supervisor/libvpp/src/vlib/main.c:2008
>   #3  0x7f6dc7a2592a in vlib_worker_thread_fn (arg=0x7f6da3593080)
> at /home/supervisor/libvpp/src/vlib/threads.c:1862
>   #4  0x7f6dc724bc34 in clib_calljmp () at
> /home/supervisor/libvpp/src/vppinfra/longjmp.S:123
>   #5  0x7f6d283feec0 in ?? ()
>   #6  0x7f6dc7a1dad3 in vlib_worker_thread_bootstrap_fn
> (arg=0x7f6da3593080) at /home/supervisor/libvpp/src/vlib/threads.c:585
>   Backtrace stopped: previous frame inner to this frame (corrupt
> stack?)
> 
>   Thread 1 (Thread 0x7f6dd47c2240 (LWP 226)):
>   #0  0x7f6dc723c2dc in hash_header (v=0x7f6da6870e18) at
> /home/supervisor/libvpp/src/vppinfra/hash.h:113
>   #1  0x7f6dc723d329 in get_pair (v=0x7f6da6870e18, i=55) at
> /home/supervisor/libvpp/src/vppinfra/hash.c:58
>   #2  0x7f6dc723c372 in lookup (v=0x7f6da6870e18,
> key=140108524924744, op=GET, new_value=0x0, old_value=0x0)
>   at /home/supervisor/libvpp/src/vppinfra/hash.c:557
>   #3  0x7f6dc723c261 in _hash_get (v=0x7f6da6870e18,
> key=140108524924744) at /home/supervisor/libvpp/src/vppinfra/hash.c:641
>   #4  0x7f6dc8bbb5f4 in adj_nbr_find (nh_proto=FIB_PROTOCOL_IP4,
> link_type=VNET_LINK_MPLS, nh_addr=0x7f6da6866c30, sw_if_index=8)
>   at /home/supervisor/libvpp/src/vnet/adj/adj_nbr.c:124
>   #5  0x7f6dc8bbb661 in adj_nbr_add_or_lock
> (nh_proto=FIB_PROTOCOL_IP4, link_type=VNET_LINK_MPLS,
> nh_addr=0x7f6da6866c30, sw_if_index=8)
>   at /home/supervisor/libvpp/src/vnet/adj/adj_nbr.c:243
>   #6  0x7f6dc8b904db in fib_path_attached_next_hop_get_adj
> (path=0x7f6da6866c18, link=VNET_LINK_MPLS, dpo=0x7f6d8edbb168)
>   at /home/supervisor/libvpp/src/vnet/fib/fib_path.c:674
>   #7  0x7f6dc8b8ffb0 in fib_path_contribute_forwarding
> (path_index=58, fct=FIB_FORW_CHAIN_TYPE_MPLS_NON_EOS, dpo=0x7f6d8edbb168)
>   at /home/supervisor/libvpp/src/vnet/fib/fib_path.c:2475
>   ---Type  to continue, or q  to quit---
>   #8  0x7f6dc8b98399 in fib_path_ext_stack
> (path_ext=0x7f6da42ab220, child_fct=FIB_FORW_CHAIN_TYPE_MPLS_NON_EOS,
>   imp_null_fct=FIB_FORW_CHAIN_TYPE_MPLS_NON_EOS,
> nhs=0x7f6da8718a80) at
> /home/supervisor/libvpp/src/vnet/fib/fib_path_ext.c:241
>   #9  0x7f6dc8b6e293 in fib_entry_src_collect_forwarding
> (pl_index=50, path_index=58, arg=0x7f6d8edbb380)
>   at /home/supervisor/libvpp/src/vnet/fib/fib_entry_src.c:476
>   #10 0x7f6dc8b8926d in fib_path_list_walk (path_list_index=50,
> func=0x7f6dc8b6e100 ,
> ctx=0x7f6d8edbb380)
>   at /home/supervisor/libvpp

Re: [vpp-dev] Infinite loop in fib_walk_sync

[Sudhir CR via lists.fd.io]

Hi All,
I am resending the same again as i am not sure the former one had reached
the forum.

Regards,
Sudhir.

On Thu, Jun 17, 2021 at 1:15 PM Sudhir CR via lists.fd.io  wrote:

> Hi All,
> We have been using vpp with our stack for the 6PE solution for some time.
> But when we recently enabled BFD in vpp we are observing an infinite loop
> with the below call stack.
>
> Any help in resolving this issue would be appreciated  .
>
> (gdb) thread apply all bt
>
> Thread 3 (Thread 0x7f6d27bfe700 (LWP 449)):
> #0  0x7f6dc79d4007 in vlib_worker_thread_barrier_check () at
> /home/supervisor/libvpp/src/vlib/threads.h:438
> #1  0x7f6dc79ce52e in vlib_main_or_worker_loop (vm=0x7f6da5f9b6c0,
> is_main=0) at /home/supervisor/libvpp/src/vlib/main.c:1788
> #2  0x7f6dc79cdd47 in vlib_worker_loop (vm=0x7f6da5f9b6c0) at
> /home/supervisor/libvpp/src/vlib/main.c:2008
> #3  0x7f6dc7a2592a in vlib_worker_thread_fn (arg=0x7f6da3593180) at
> /home/supervisor/libvpp/src/vlib/threads.c:1862
> #4  0x7f6dc724bc34 in clib_calljmp () at
> /home/supervisor/libvpp/src/vppinfra/longjmp.S:123
> #5  0x7f6d27bfdec0 in ?? ()
> #6  0x7f6dc7a1dad3 in vlib_worker_thread_bootstrap_fn
> (arg=0x7f6da3593180) at /home/supervisor/libvpp/src/vlib/threads.c:585
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>
> Thread 2 (Thread 0x7f6d283ff700 (LWP 448)):
> #0  0x7f6dc79d3ffe in vlib_worker_thread_barrier_check () at
> /home/supervisor/libvpp/src/vlib/threads.h:438
> #1  0x7f6dc79ce52e in vlib_main_or_worker_loop (vm=0x7f6da5f9a200,
> is_main=0) at /home/supervisor/libvpp/src/vlib/main.c:1788
> #2  0x7f6dc79cdd47 in vlib_worker_loop (vm=0x7f6da5f9a200) at
> /home/supervisor/libvpp/src/vlib/main.c:2008
> #3  0x7f6dc7a2592a in vlib_worker_thread_fn (arg=0x7f6da3593080) at
> /home/supervisor/libvpp/src/vlib/threads.c:1862
> #4  0x7f6dc724bc34 in clib_calljmp () at
> /home/supervisor/libvpp/src/vppinfra/longjmp.S:123
> #5  0x7f6d283feec0 in ?? ()
> #6  0x7f6dc7a1dad3 in vlib_worker_thread_bootstrap_fn
> (arg=0x7f6da3593080) at /home/supervisor/libvpp/src/vlib/threads.c:585
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>
> Thread 1 (Thread 0x7f6dd47c2240 (LWP 226)):
> #0  0x7f6dc723c2dc in hash_header (v=0x7f6da6870e18) at
> /home/supervisor/libvpp/src/vppinfra/hash.h:113
> #1  0x7f6dc723d329 in get_pair (v=0x7f6da6870e18, i=55) at
> /home/supervisor/libvpp/src/vppinfra/hash.c:58
> #2  0x7f6dc723c372 in lookup (v=0x7f6da6870e18, key=140108524924744,
> op=GET, new_value=0x0, old_value=0x0)
> at /home/supervisor/libvpp/src/vppinfra/hash.c:557
> #3  0x7f6dc723c261 in _hash_get (v=0x7f6da6870e18,
> key=140108524924744) at /home/supervisor/libvpp/src/vppinfra/hash.c:641
> #4  0x7f6dc8bbb5f4 in adj_nbr_find (nh_proto=FIB_PROTOCOL_IP4,
> link_type=VNET_LINK_MPLS, nh_addr=0x7f6da6866c30, sw_if_index=8)
> at /home/supervisor/libvpp/src/vnet/adj/adj_nbr.c:124
> #5  0x7f6dc8bbb661 in adj_nbr_add_or_lock (nh_proto=FIB_PROTOCOL_IP4,
> link_type=VNET_LINK_MPLS, nh_addr=0x7f6da6866c30, sw_if_index=8)
> at /home/supervisor/libvpp/src/vnet/adj/adj_nbr.c:243
> #6  0x7f6dc8b904db in fib_path_attached_next_hop_get_adj
> (path=0x7f6da6866c18, link=VNET_LINK_MPLS, dpo=0x7f6d8edbb168)
> at /home/supervisor/libvpp/src/vnet/fib/fib_path.c:674
> #7  0x7f6dc8b8ffb0 in fib_path_contribute_forwarding (path_index=58,
> fct=FIB_FORW_CHAIN_TYPE_MPLS_NON_EOS, dpo=0x7f6d8edbb168)
> at /home/supervisor/libvpp/src/vnet/fib/fib_path.c:2475
> ---Type  to continue, or q  to quit---
> #8  0x7f6dc8b98399 in fib_path_ext_stack (path_ext=0x7f6da42ab220,
> child_fct=FIB_FORW_CHAIN_TYPE_MPLS_NON_EOS,
> imp_null_fct=FIB_FORW_CHAIN_TYPE_MPLS_NON_EOS, nhs=0x7f6da8718a80) at
> /home/supervisor/libvpp/src/vnet/fib/fib_path_ext.c:241
> #9  0x7f6dc8b6e293 in fib_entry_src_collect_forwarding (pl_index=50,
> path_index=58, arg=0x7f6d8edbb380)
> at /home/supervisor/libvpp/src/vnet/fib/fib_entry_src.c:476
> #10 0x7f6dc8b8926d in fib_path_list_walk (path_list_index=50,
> func=0x7f6dc8b6e100 , ctx=0x7f6d8edbb380)
> at /home/supervisor/libvpp/src/vnet/fib/fib_path_list.c:1408
> #11 0x7f6dc8b6da44 in fib_entry_src_mk_lb (fib_entry=0x7f6da6868730,
> esrc=0x7f6da75b11c0, fct=FIB_FORW_CHAIN_TYPE_MPLS_NON_EOS,
> dpo_lb=0x7f6da6868758) at
> /home/supervisor/libvpp/src/vnet/fib/fib_entry_src.c:576
> #12 0x7f6dc8b6e6d3 in fib_entry_src_action_install
> (fib_entry=0x7f6da6868730, source=FIB_SOURCE_CLI)
> at /home/supervisor/libvpp/src/vnet/fib/fib_entry_src.c:706
> #13 0x7f6dc8b6f5ff in fib_entry_src_action_reactivate
> (fib_entry=0x7f6da6868730, source=FIB_SOURCE_CLI)
> at /home/supervisor/libvpp/src/vnet/fib/fib_entry_src.c:1222
> #14 0x7f6dc8b6c5c2 in fib_entry_back_walk_notify (node=0x7f6da6868730,
> ctx=0x7f6d8edbb668)
> at /home/supervisor/libvpp/src/vnet/fib/fib_entry.c:316
> #15 0x7f6dc8b648c2 in f

[vpp-dev] Infinite loop in fib_walk_sync

[Sudhir CR via lists.fd.io]

Hi All,
We have been using vpp with our stack for the 6PE solution for some time.
But when we recently enabled BFD in vpp we are observing an infinite loop
with the below call stack.

Any help in resolving this issue would be appreciated  .

(gdb) thread apply all bt

Thread 3 (Thread 0x7f6d27bfe700 (LWP 449)):
#0  0x7f6dc79d4007 in vlib_worker_thread_barrier_check () at
/home/supervisor/libvpp/src/vlib/threads.h:438
#1  0x7f6dc79ce52e in vlib_main_or_worker_loop (vm=0x7f6da5f9b6c0,
is_main=0) at /home/supervisor/libvpp/src/vlib/main.c:1788
#2  0x7f6dc79cdd47 in vlib_worker_loop (vm=0x7f6da5f9b6c0) at
/home/supervisor/libvpp/src/vlib/main.c:2008
#3  0x7f6dc7a2592a in vlib_worker_thread_fn (arg=0x7f6da3593180) at
/home/supervisor/libvpp/src/vlib/threads.c:1862
#4  0x7f6dc724bc34 in clib_calljmp () at
/home/supervisor/libvpp/src/vppinfra/longjmp.S:123
#5  0x7f6d27bfdec0 in ?? ()
#6  0x7f6dc7a1dad3 in vlib_worker_thread_bootstrap_fn
(arg=0x7f6da3593180) at /home/supervisor/libvpp/src/vlib/threads.c:585
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 2 (Thread 0x7f6d283ff700 (LWP 448)):
#0  0x7f6dc79d3ffe in vlib_worker_thread_barrier_check () at
/home/supervisor/libvpp/src/vlib/threads.h:438
#1  0x7f6dc79ce52e in vlib_main_or_worker_loop (vm=0x7f6da5f9a200,
is_main=0) at /home/supervisor/libvpp/src/vlib/main.c:1788
#2  0x7f6dc79cdd47 in vlib_worker_loop (vm=0x7f6da5f9a200) at
/home/supervisor/libvpp/src/vlib/main.c:2008
#3  0x7f6dc7a2592a in vlib_worker_thread_fn (arg=0x7f6da3593080) at
/home/supervisor/libvpp/src/vlib/threads.c:1862
#4  0x7f6dc724bc34 in clib_calljmp () at
/home/supervisor/libvpp/src/vppinfra/longjmp.S:123
#5  0x7f6d283feec0 in ?? ()
#6  0x7f6dc7a1dad3 in vlib_worker_thread_bootstrap_fn
(arg=0x7f6da3593080) at /home/supervisor/libvpp/src/vlib/threads.c:585
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 1 (Thread 0x7f6dd47c2240 (LWP 226)):
#0  0x7f6dc723c2dc in hash_header (v=0x7f6da6870e18) at
/home/supervisor/libvpp/src/vppinfra/hash.h:113
#1  0x7f6dc723d329 in get_pair (v=0x7f6da6870e18, i=55) at
/home/supervisor/libvpp/src/vppinfra/hash.c:58
#2  0x7f6dc723c372 in lookup (v=0x7f6da6870e18, key=140108524924744,
op=GET, new_value=0x0, old_value=0x0)
at /home/supervisor/libvpp/src/vppinfra/hash.c:557
#3  0x7f6dc723c261 in _hash_get (v=0x7f6da6870e18, key=140108524924744)
at /home/supervisor/libvpp/src/vppinfra/hash.c:641
#4  0x7f6dc8bbb5f4 in adj_nbr_find (nh_proto=FIB_PROTOCOL_IP4,
link_type=VNET_LINK_MPLS, nh_addr=0x7f6da6866c30, sw_if_index=8)
at /home/supervisor/libvpp/src/vnet/adj/adj_nbr.c:124
#5  0x7f6dc8bbb661 in adj_nbr_add_or_lock (nh_proto=FIB_PROTOCOL_IP4,
link_type=VNET_LINK_MPLS, nh_addr=0x7f6da6866c30, sw_if_index=8)
at /home/supervisor/libvpp/src/vnet/adj/adj_nbr.c:243
#6  0x7f6dc8b904db in fib_path_attached_next_hop_get_adj
(path=0x7f6da6866c18, link=VNET_LINK_MPLS, dpo=0x7f6d8edbb168)
at /home/supervisor/libvpp/src/vnet/fib/fib_path.c:674
#7  0x7f6dc8b8ffb0 in fib_path_contribute_forwarding (path_index=58,
fct=FIB_FORW_CHAIN_TYPE_MPLS_NON_EOS, dpo=0x7f6d8edbb168)
at /home/supervisor/libvpp/src/vnet/fib/fib_path.c:2475
---Type  to continue, or q  to quit---
#8  0x7f6dc8b98399 in fib_path_ext_stack (path_ext=0x7f6da42ab220,
child_fct=FIB_FORW_CHAIN_TYPE_MPLS_NON_EOS,
imp_null_fct=FIB_FORW_CHAIN_TYPE_MPLS_NON_EOS, nhs=0x7f6da8718a80) at
/home/supervisor/libvpp/src/vnet/fib/fib_path_ext.c:241
#9  0x7f6dc8b6e293 in fib_entry_src_collect_forwarding (pl_index=50,
path_index=58, arg=0x7f6d8edbb380)
at /home/supervisor/libvpp/src/vnet/fib/fib_entry_src.c:476
#10 0x7f6dc8b8926d in fib_path_list_walk (path_list_index=50,
func=0x7f6dc8b6e100 , ctx=0x7f6d8edbb380)
at /home/supervisor/libvpp/src/vnet/fib/fib_path_list.c:1408
#11 0x7f6dc8b6da44 in fib_entry_src_mk_lb (fib_entry=0x7f6da6868730,
esrc=0x7f6da75b11c0, fct=FIB_FORW_CHAIN_TYPE_MPLS_NON_EOS,
dpo_lb=0x7f6da6868758) at
/home/supervisor/libvpp/src/vnet/fib/fib_entry_src.c:576
#12 0x7f6dc8b6e6d3 in fib_entry_src_action_install
(fib_entry=0x7f6da6868730, source=FIB_SOURCE_CLI)
at /home/supervisor/libvpp/src/vnet/fib/fib_entry_src.c:706
#13 0x7f6dc8b6f5ff in fib_entry_src_action_reactivate
(fib_entry=0x7f6da6868730, source=FIB_SOURCE_CLI)
at /home/supervisor/libvpp/src/vnet/fib/fib_entry_src.c:1222
#14 0x7f6dc8b6c5c2 in fib_entry_back_walk_notify (node=0x7f6da6868730,
ctx=0x7f6d8edbb668)
at /home/supervisor/libvpp/src/vnet/fib/fib_entry.c:316
#15 0x7f6dc8b648c2 in fib_node_back_walk_one (ptr=0x7f6d8edbb688,
ctx=0x7f6d8edbb668)
at /home/supervisor/libvpp/src/vnet/fib/fib_node.c:161
#16 0x7f6dc8b4f36a in fib_walk_advance (fwi=1) at
/home/supervisor/libvpp/src/vnet/fib/fib_walk.c:368
#17 0x7f6dc8b4ff00 in* fib_walk_sync *(parent_type=FIB_NODE_TYPE_PATH_LIST,
parent_index=50, ctx=0x7f6d8edbb828)
a

Re: [vpp-dev] ERROR while "make install-ext-deps" in vagrant #vpp

[Benoit Ganne (bganne) via lists.fd.io]

Hi Andy,

Are you using build-root/vagrant ? I do not know how much it is 
tested/maintained.
With that in mind, we'd need the whole output to figure out the issue: the 
output you gave starts after the initial error so we cannot diagnose anything.

Best
ben

> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of
> andy...@gmail.com
> Sent: jeudi 17 juin 2021 00:35
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] ERROR while "make install-ext-deps" in vagrant #vpp
> 
> Hi folks,
> 
> Can anyone help on this?
> 
> DEBUG ssh: stderr: make[3]: *** [packages/ipsec-mb.mk:48:
> /vpp/build-root/build-vpp-native/external/.ipsec-mb.build.ok] Error 2
> 
>  INFO interface: detail: make[3]: *** [packages/ipsec-
> mb.mk:48: /vpp/build-root/build-vpp-native/external/.ipsec-mb.build.ok]
> Error 2
>  INFO interface: detail: VPP: make[3]: ***
> [packages/ipsec-mb.mk:48: /vpp/build-root/build-vpp-
> native/external/.ipsec-mb.build.ok] Error 2
> VPP: make[3]: *** [packages/ipsec-mb.mk:48:
> /vpp/build-root/build-vpp-native/external/.ipsec-mb.build.ok] Error 2
>  INFO interface: detail: make[3]: Leaving directory
> '/vpp/build/external'
>  INFO interface: detail: VPP: make[3]: Leaving
> directory '/vpp/build/external'
> VPP: make[3]: Leaving directory '/vpp/build/external'
> DEBUG ssh: stderr: make[2]: *** [Makefile:160: ebuild-
> build] Error 2
> 
>  INFO interface: detail: make[2]: *** [Makefile:160:
> ebuild-build] Error 2
>  INFO interface: detail: VPP: make[2]: ***
> [Makefile:160: ebuild-build] Error 2
> VPP: make[2]: *** [Makefile:160: ebuild-build] Error 2
>  INFO interface: detail: make[2]: Leaving directory
> '/vpp/build/external'
>  INFO interface: detail: VPP: make[2]: Leaving
> directory '/vpp/build/external'
> VPP: make[2]: Leaving directory '/vpp/build/external'
> DEBUG ssh: stderr: make[1]: *** [Makefile:732: external-
> install] Error 2
> 
>  INFO interface: detail: make[1]: *** [Makefile:732:
> external-install] Error 2
>  INFO interface: detail: VPP: make[1]: ***
> [Makefile:732: external-install] Error 2
> VPP: make[1]: *** [Makefile:732: external-install]
> Error 2
>  INFO interface: detail: make[1]: Leaving directory
> '/vpp/build-root'
>  INFO interface: detail: VPP: make[1]: Leaving
> directory '/vpp/build-root'
> VPP: make[1]: Leaving directory '/vpp/build-root'
> DEBUG ssh: stderr: make: *** [Makefile:566: pkg-deb] Error
> 2
> 
>  INFO interface: detail: make: *** [Makefile:566: pkg-deb]
> Error 2
>  INFO interface: detail: VPP: make: *** [Makefile:566:
> pkg-deb] Error 2
> VPP: make: *** [Makefile:566: pkg-deb] Error 2
> DEBUG ssh: Exit status: 2
> ERROR warden: Error occurred: The SSH command responded
> with a non-zero exit status. Vagrant
> assumes that this means the command failed. The output for
> this command
> should be in the log above. Please read the output to
> determine what
> went wrong.
>  INFO warden: Beginning recovery process...
>  INFO warden: Recovery complete.
> ERROR warden: Error occurred: The SSH command responded
> with a non-zero exit status. Vagrant
> assumes that this means the command failed. The output for
> this command
> should be in the log above. Please read the output to
> determine what
> went wrong.
> 
> Best,
> --Andy
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19588): https://lists.fd.io/g/vpp-dev/message/19588
Mute This Topic: https://lists.fd.io/mt/83592549/21656
Mute #vpp:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-