date:20210914

[vpp-dev] Cloud native VNF agent

2021-09-14 Thread Venumadhav Josyula

Hi  All,



Does the govpp have a Cloud native VNF agent also ? I was looking at the
slides on govpp, those are back from 2017

Is the Cloud native VNF agent also open sourced ?



Please note we do not want to use VPP-Ligato agent for cloud-native
platforms for our CU work. We are responsible for the dataplane pod where
vpp will run.



Any inputs / suggestions / pointers in the right direction are welcome



Thanks,

Regards,

Venu

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20136): https://lists.fd.io/g/vpp-dev/message/20136
Mute This Topic: https://lists.fd.io/mt/85621548/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] fail_over_mac=1 (Active) Bonding

2021-09-14 Thread steven luong via lists.fd.io

Chetan,

I have a patch in gerrit a long time ago and I just rebased it to the latest 
master
https://gerrit.fd.io/r/c/vpp/+/30866
Please feel free to test it thoroughly and let me know if you encounter any 
problem or not.

Steven

From:  on behalf of chetan bhasin 

Date: Tuesday, September 14, 2021 at 10:16 PM
To: vpp-dev 
Subject: [vpp-dev] fail_over_mac=1 (Active) Bonding

Hi,

We have a feature to support Bonding fail_over_mac=1 (Active) in VPP . Are 
there any plans to implement this ?

If we want to implement this, can anybody please provide a direction.

Thanks,
Chetan



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

[vpp-dev] fail_over_mac=1 (Active) Bonding

2021-09-14 Thread chetan bhasin

Hi,

We have a feature to support Bonding fail_over_mac=1 (Active) in VPP . Are
there any plans to implement this ?

If we want to implement this, can anybody please provide a direction.

Thanks,
Chetan

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20134): https://lists.fd.io/g/vpp-dev/message/20134
Mute This Topic: https://lists.fd.io/mt/85620877/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] Centos 8 install problems

2021-09-14 Thread Felipe Arturo Polanco

Ok, thanks for the info. Switching to Ubuntu worked.

On Tue, Sep 14, 2021, 7:57 AM Benoit Ganne (bganne) 
wrote:

> This is not very surprising unfortunately: we do not have any active
> maintainer for CentOS anymore, and CentOS has been removed from our CI/CD
> pipeline because of that.
> You might want to use Debian or Ubuntu which are actively supported.
>
> Best
> ben
>
> > -Original Message-
> > From: vpp-dev@lists.fd.io  On Behalf Of Felipe
> Arturo
> > Polanco
> > Sent: mardi 14 septembre 2021 04:39
> > To: vpp-dev@lists.fd.io
> > Subject: [vpp-dev] Centos 8 install problems
> >
> > Hi,
> >
> > Is Centos 8 supported for VPP compile?
> >
> > We are trying both Rocky Linux and Centos 8 compile from source and we
> are
> > hitting the same error:
> >
> > ModuleNotFoundError: No module named 'ninja'
> >
> >
> > But ninja is already installed
> >
> > [root@SUT3_VPP vpp]# pip3 install ninja
> > WARNING: Running pip install with root privileges is generally not a good
> > idea. Try `pip3 install --user` instead.
> > Requirement already satisfied: ninja in /usr/local/lib64/python3.6/site-
> > packages
> >
> >
> >
> > This error shows up if we compile vpp after compiling dpdk, without dpdk
> > compilation we are not getting the vpp-plugin-dpdk RPM and the dpdk
> stanza
> > in startup.conf is being unrecognized.
> >
> > Any suggestions?
> >
> > Thanks,
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20133): https://lists.fd.io/g/vpp-dev/message/20133
Mute This Topic: https://lists.fd.io/mt/85593666/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] TLS app stuck after burst of traffic #vpp-hoststack

2021-09-14 Thread Florin Coras

Forgot to mention that if my hunch is accurate, probably you should try 
increasing tls’s fifo segment memory by adding a tls stanza to startup.conf, 
e.g.:

tls { first-segment-size 4g }

Where 4g can be larger if you have lots of sessions. 

Regards, 
Florin

> On Sep 14, 2021, at 8:45 AM, Florin Coras via lists.fd.io 
>  wrote:
> 
> Hi Olivia, 
> 
> Could you try this with latest code? We’ve had a number of fixes go in over 
> the past months, including the one that you’ve mentioned lower. Hard to say 
> if the issue has been fixed as tls might ignore the dequeue notifications 
> from tcp for some reason. If I were to guess, this [1] might help. 
> 
> Regards, 
> Florin
> 
> [1] https://gerrit.fd.io/r/c/vpp/+/32389 
> 
> 
>> On Sep 14, 2021, at 5:57 AM, Olivia Dunham > > wrote:
>> 
>> During sudden burst of traffic, the TCP fifo gets full. When this happens 
>> the openssl TLS app de-schedules the transport. But once the TCP data is 
>> sent out, the TLS is not resuming. VPP ends up in a state where TCP fifo is 
>> empty, but the TLS fifo is full and no more Tx happens on TLS fifo.
>> 
>> VPP version: 21.01
>> 
>> We came across this commit - session tls: deq notifications for custom tx 
>> 
>> Not sure what is the issue fixed by this commit, but It doesn't seem to fix 
>> the above mentioned issue. 
>> 
>> 
> 
> 
> 


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

Re: [vpp-dev] TLS app stuck after burst of traffic #vpp-hoststack

2021-09-14 Thread Florin Coras

Hi Olivia, 

Could you try this with latest code? We’ve had a number of fixes go in over the 
past months, including the one that you’ve mentioned lower. Hard to say if the 
issue has been fixed as tls might ignore the dequeue notifications from tcp for 
some reason. If I were to guess, this [1] might help. 

Regards, 
Florin

[1] https://gerrit.fd.io/r/c/vpp/+/32389

> On Sep 14, 2021, at 5:57 AM, Olivia Dunham  wrote:
> 
> During sudden burst of traffic, the TCP fifo gets full. When this happens the 
> openssl TLS app de-schedules the transport. But once the TCP data is sent 
> out, the TLS is not resuming. VPP ends up in a state where TCP fifo is empty, 
> but the TLS fifo is full and no more Tx happens on TLS fifo.
> 
> VPP version: 21.01
> 
> We came across this commit - session tls: deq notifications for custom tx 
> 
> Not sure what is the issue fixed by this commit, but It doesn't seem to fix 
> the above mentioned issue. 
> 
> 


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

Re: [vpp-dev]: Assert in vnet_mpls_tunnel_del()

2021-09-14 Thread Rajith PR via lists.fd.io

Hi Neale,

You are right, I think there is a possibility of a route getting resolved
through the tunnel, when the tunnel delete was called.
Though what is being resolved is not the mpls tunnel by itself nor the
rpath with the extension, but the plain nexthop.

Thanks a lot for the pointer. But how can this be fixed in our application?
I can check the ret_val of *vnet_mpls_tunnel_path_remove*() before calling
*vnet_mpls_tunnel_del*.
If paths are not removed, bail out and do the vnet_mpls_tunnel_del at a
later point of time.  Is there any better way to do it? Can you please
suggest.

Thanks,
Rajith




On Tue, Sep 14, 2021 at 5:27 PM Neale Ranns  wrote:

>
>
> Hi Rajiyh,
>
>
>
> Maybe there’s something that still resolves through the tunnel when it’s
> deleted?
>
>
>
> /neale
>
>
>
> *From: *vpp-dev@lists.fd.io  on behalf of Rajith PR
> via lists.fd.io 
> *Date: *Tuesday, 14 September 2021 at 13:17
> *To: *vpp-dev 
> *Subject: *[vpp-dev]: Assert in vnet_mpls_tunnel_del()
>
> Hi All,
>
>
>
> We recently started using the VPP's mpls tunnel constructs for our L2
> cross connect application. In certain test scenarios we are seeing a crash
> in the delete path of the mpls tunnel.
>
> Any pointers to fix the issue would be really helpful.
>
>
>
> Version: *20.09*
>
> Call Stack:
>
>
>
> Thread 1 (Thread 0x7f854cdd3400 (LWP 14261)):
>
> #0  0x7f854c41b492 in __GI___waitpid (pid=21116, 
> stat_loc=stat_loc@entry=0x7f84f79abc28, options=options@entry=0) at 
> ../sysdeps/unix/sysv/linux/waitpid.c:30
>
> #1  0x7f854c386177 in do_system (line=) at 
> ../sysdeps/posix/system.c:149
>
> #2  0x7f854c96918d in bd_signal_handler_cb () from 
> /usr/local/lib/libbd-infra.so
>
> #3  0x7f853db8953f in rtb_bd_signal_handler () from 
> /usr/local/lib/libvlib.so.1.0.1
>
> #4  0x7f853db899a2 in unix_signal_handler () from 
> /usr/local/lib/libvlib.so.1.0.1
>
> #5  
>
> #6  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
>
> #7  0x7f854c377921 in __GI_abort () at abort.c:79
>
> #8  0x7f853f58a9e3 in os_panic () from /usr/local/lib/librtbvpp.so
>
> #9  0x7f853d35aaa9 in ?? () from /usr/local/lib/libvppinfra.so.1.0.1
>
> #10 0x7f853d35a827 in _clib_error () from 
> /usr/local/lib/libvppinfra.so.1.0.1
>
> #11 0x7f853ecb2d75 in ?? () from /usr/local/lib/libvnet.so.1.0.1
>
> #12 0x7f853ecb302d in fib_path_list_get_n_paths () from 
> /usr/local/lib/libvnet.so.1.0.1
>
> #13 0x7f853e8f0b5c in ?? () from /usr/local/lib/libvnet.so.1.0.1
>
> #14 0x7f853e8ef942 in ?? () from /usr/local/lib/libvnet.so.1.0.1
>
> #15 0x7f853e8ed51a in ?? () from /usr/local/lib/libvnet.so.1.0.1
>
> #16 0x7f853e2e9e1a in ?? () from /usr/local/lib/libvnet.so.1.0.1
>
> #17 0x7f853e2ea0e8 in vnet_sw_interface_set_flags () from 
> /usr/local/lib/libvnet.so.1.0.1
>
> #18 0x7f853e2eb6e4 in vnet_delete_sw_interface () from 
> /usr/local/lib/libvnet.so.1.0.1
>
> #19 0x7f853e2eede9 in vnet_delete_hw_interface () from 
> /usr/local/lib/libvnet.so.1.0.1
>
> #20 0x7f853e8ee368 in vnet_mpls_tunnel_del () from 
> /usr/local/lib/libvnet.so.1.0.1
>
> #21 0x7f853f74535a in rtb_vpp_l2_xconnect_route_del_handle () from 
> /usr/local/lib/librtbvpp.so
>
> #22 0x7f853f7453fa in rtb_vpp_l2_xconnect_route_handle () from 
> /usr/local/lib/librtbvpp.so
>
> #23 0x7f853f69551b in rtb_vpp_route_mapping_process () from 
> /usr/local/lib/librtbvpp.so
>
> #24 0x7f853f696a67 in rtb_vpp_route_adjacency_handle () from 
> /usr/local/lib/librtbvpp.so
>
> #25 0x7f853f696d22 in rtb_vpp_route_api_out_process () from 
> /usr/local/lib/librtbvpp.so
>
> #26 0x7f85406b3975 in fib_route_api_out_del () from 
> /usr/local/lib/libfibd.so
>
> #27 0x7f85406b3a83 in fib_route_api_out_tbl_vpp_wlk () from 
> /usr/local/lib/libfibd.so
>
> #28 0x7f85406a550b in fib_job_tmr_cb () from /usr/local/lib/libfibd.so
>
> #29 0x7f854b27e6c2 in bds_qrunner_dispatch () from 
> /usr/local/lib/libbds.so
>
> #30 0x7f854b27f77c in bds_qrunner_dispatch_type () from 
> /usr/local/lib/libbds.so
>
> #31 0x7f854b27f9aa in bds_qrunner_dispatch_prepare () from 
> /usr/local/lib/libbds.so
>
> #32 0x7f854b27faa8 in bds_qrunner_expire () from /usr/local/lib/libbds.so
>
> #33 0x7f854a67f616 in ?? () from /usr/local/lib/libqb.so
>
> #34 0x7f854a67cfa7 in ?? () from /usr/local/lib/libqb.so
>
> #35 0x7f854a67d797 in qb_loop_run_vpp_wrapper () from 
> /usr/local/lib/libqb.so
>
> #36 0x7f854a6890e8 in lib_qb_service_start_event_wrapper_loop () from 
> /usr/local/lib/libqb.so
>
> #37 0x7f854c96b262 in bd_event_loop_run_once () from 
> /usr/local/lib/libbd-infra.so
>
> #38 0x7f85060444f8 in ?? () from 
> /usr/local/lib/vpp_plugins/rtbrick_plugin.so
>
> #39 0x7f853db058dd in ?? () from /usr/local/lib/libvlib.so.1.0.1
>
> #40 0x7f853d37ec34 in clib_calljmp () from 
> /usr/local/lib/libvppinfra.so.1.0.1
>
> #41 0x7f85255f7a10 in ?? ()
>
> #42 0x7f853db0531f in ?? () from /us

[vpp-dev] VPP healthy or not, or VAPI connection is healthy or not #vapi #vpp #shm

2021-09-14 Thread RaviKiran Veldanda

Hi Experts,
We are using several applications to communicate the VPP by using the VAPI.
We are using Vapi_connect, Vapi_send, Vapi_recv calls,
Sometimes I see one of the application can not able to communicate with VPP and 
it will give errors.
At the same time other applications are running fine with VPP and VPP also 
running fine.
So I have two questions,
1> How to determine the VAPI Connection is stable and its working? to take 
decision application reconnect/restart.
2> How to determine the VPP is in good state and its working? to take decision 
of vpp restart.

Any pointer will be big help..
//Ravi

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20129): https://lists.fd.io/g/vpp-dev/message/20129
Mute This Topic: https://lists.fd.io/mt/85602420/21656
Mute #shm:https://lists.fd.io/g/vpp-dev/mutehashtag/shm
Mute #vapi:https://lists.fd.io/g/vpp-dev/mutehashtag/vapi
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]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] TLS app stuck after burst of traffic #vpp-hoststack

2021-09-14 Thread Olivia Dunham

During sudden burst of traffic, the TCP fifo gets full. When this happens the 
openssl TLS app de-schedules the transport. But once the TCP data is sent out, 
the TLS is not resuming. VPP ends up in a state where TCP fifo is empty, but 
the TLS fifo is full and no more Tx happens on TLS fifo.

VPP version: 21.01

We came across this commit - session tls: deq notifications for custom tx ( 
https://github.com/FDio/vpp/commit/1e6a0f64653c8142fa7032aba127ab4894bafc3c )
Not sure what is the issue fixed by this commit, but It doesn't seem to fix the 
above mentioned issue.

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

Re: [vpp-dev]: Assert in vnet_mpls_tunnel_del()

2021-09-14 Thread Neale Ranns


Hi Rajiyh,

Maybe there’s something that still resolves through the tunnel when it’s 
deleted?

/neale

From: vpp-dev@lists.fd.io  on behalf of Rajith PR via 
lists.fd.io 
Date: Tuesday, 14 September 2021 at 13:17
To: vpp-dev 
Subject: [vpp-dev]: Assert in vnet_mpls_tunnel_del()
Hi All,

We recently started using the VPP's mpls tunnel constructs for our L2 cross 
connect application. In certain test scenarios we are seeing a crash in the 
delete path of the mpls tunnel.
Any pointers to fix the issue would be really helpful.

Version: 20.09
Call Stack:

Thread 1 (Thread 0x7f854cdd3400 (LWP 14261)):

#0  0x7f854c41b492 in __GI___waitpid (pid=21116, 
stat_loc=stat_loc@entry=0x7f84f79abc28, options=options@entry=0) at 
../sysdeps/unix/sysv/linux/waitpid.c:30

#1  0x7f854c386177 in do_system (line=) at 
../sysdeps/posix/system.c:149

#2  0x7f854c96918d in bd_signal_handler_cb () from 
/usr/local/lib/libbd-infra.so

#3  0x7f853db8953f in rtb_bd_signal_handler () from 
/usr/local/lib/libvlib.so.1.0.1

#4  0x7f853db899a2 in unix_signal_handler () from 
/usr/local/lib/libvlib.so.1.0.1

#5  

#6  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51

#7  0x7f854c377921 in __GI_abort () at abort.c:79

#8  0x7f853f58a9e3 in os_panic () from /usr/local/lib/librtbvpp.so

#9  0x7f853d35aaa9 in ?? () from /usr/local/lib/libvppinfra.so.1.0.1

#10 0x7f853d35a827 in _clib_error () from 
/usr/local/lib/libvppinfra.so.1.0.1

#11 0x7f853ecb2d75 in ?? () from /usr/local/lib/libvnet.so.1.0.1

#12 0x7f853ecb302d in fib_path_list_get_n_paths () from 
/usr/local/lib/libvnet.so.1.0.1

#13 0x7f853e8f0b5c in ?? () from /usr/local/lib/libvnet.so.1.0.1

#14 0x7f853e8ef942 in ?? () from /usr/local/lib/libvnet.so.1.0.1

#15 0x7f853e8ed51a in ?? () from /usr/local/lib/libvnet.so.1.0.1

#16 0x7f853e2e9e1a in ?? () from /usr/local/lib/libvnet.so.1.0.1

#17 0x7f853e2ea0e8 in vnet_sw_interface_set_flags () from 
/usr/local/lib/libvnet.so.1.0.1

#18 0x7f853e2eb6e4 in vnet_delete_sw_interface () from 
/usr/local/lib/libvnet.so.1.0.1

#19 0x7f853e2eede9 in vnet_delete_hw_interface () from 
/usr/local/lib/libvnet.so.1.0.1

#20 0x7f853e8ee368 in vnet_mpls_tunnel_del () from 
/usr/local/lib/libvnet.so.1.0.1

#21 0x7f853f74535a in rtb_vpp_l2_xconnect_route_del_handle () from 
/usr/local/lib/librtbvpp.so

#22 0x7f853f7453fa in rtb_vpp_l2_xconnect_route_handle () from 
/usr/local/lib/librtbvpp.so

#23 0x7f853f69551b in rtb_vpp_route_mapping_process () from 
/usr/local/lib/librtbvpp.so

#24 0x7f853f696a67 in rtb_vpp_route_adjacency_handle () from 
/usr/local/lib/librtbvpp.so

#25 0x7f853f696d22 in rtb_vpp_route_api_out_process () from 
/usr/local/lib/librtbvpp.so

#26 0x7f85406b3975 in fib_route_api_out_del () from 
/usr/local/lib/libfibd.so

#27 0x7f85406b3a83 in fib_route_api_out_tbl_vpp_wlk () from 
/usr/local/lib/libfibd.so

#28 0x7f85406a550b in fib_job_tmr_cb () from /usr/local/lib/libfibd.so

#29 0x7f854b27e6c2 in bds_qrunner_dispatch () from /usr/local/lib/libbds.so

#30 0x7f854b27f77c in bds_qrunner_dispatch_type () from 
/usr/local/lib/libbds.so

#31 0x7f854b27f9aa in bds_qrunner_dispatch_prepare () from 
/usr/local/lib/libbds.so

#32 0x7f854b27faa8 in bds_qrunner_expire () from /usr/local/lib/libbds.so

#33 0x7f854a67f616 in ?? () from /usr/local/lib/libqb.so

#34 0x7f854a67cfa7 in ?? () from /usr/local/lib/libqb.so

#35 0x7f854a67d797 in qb_loop_run_vpp_wrapper () from 
/usr/local/lib/libqb.so

#36 0x7f854a6890e8 in lib_qb_service_start_event_wrapper_loop () from 
/usr/local/lib/libqb.so

#37 0x7f854c96b262 in bd_event_loop_run_once () from 
/usr/local/lib/libbd-infra.so

#38 0x7f85060444f8 in ?? () from 
/usr/local/lib/vpp_plugins/rtbrick_plugin.so

#39 0x7f853db058dd in ?? () from /usr/local/lib/libvlib.so.1.0.1

#40 0x7f853d37ec34 in clib_calljmp () from 
/usr/local/lib/libvppinfra.so.1.0.1

#41 0x7f85255f7a10 in ?? ()

#42 0x7f853db0531f in ?? () from /usr/local/lib/libvlib.so.1.0.1
Code Snippet for Creating Tunnel (rpath has the out-labels and  nexthop):

  vec_add1(rpaths, rpath);
  tunnel_sw_if_index = vnet_mpls_tunnel_create(1, 0, NULL);
  vnet_mpls_tunnel_path_add(tunnel_sw_if_index, rpaths);
  vnet_sw_interface_admin_up(vnm, tunnel_sw_if_index);

Code Snippet for Deleting Tunnel.


 vec_add1(rpaths, rpath);
 vnet_mpls_tunnel_path_remove(sw_if_index, rpaths);
 vec_free(rpaths);
 vnet_mpls_tunnel_del(sw_if_index);

Thanks,
Rajith


NOTICE TO RECIPIENT This e-mail message and any attachments are confidential 
and may be privileged. If you received this e-mail in error, any review, use, 
dissemination, distribution, or copying of this e-mail is strictly prohibited. 
Please notify us immediately of the error by return e-mail and please delete 
this message from your system. For more information ab

Re: [vpp-dev] Centos 8 install problems

2021-09-14 Thread Benoit Ganne (bganne) via lists.fd.io

This is not very surprising unfortunately: we do not have any active maintainer 
for CentOS anymore, and CentOS has been removed from our CI/CD pipeline because 
of that.
You might want to use Debian or Ubuntu which are actively supported.

Best
ben

> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Felipe Arturo
> Polanco
> Sent: mardi 14 septembre 2021 04:39
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Centos 8 install problems
> 
> Hi,
> 
> Is Centos 8 supported for VPP compile?
> 
> We are trying both Rocky Linux and Centos 8 compile from source and we are
> hitting the same error:
> 
> ModuleNotFoundError: No module named 'ninja'
> 
> 
> But ninja is already installed
> 
> [root@SUT3_VPP vpp]# pip3 install ninja
> WARNING: Running pip install with root privileges is generally not a good
> idea. Try `pip3 install --user` instead.
> Requirement already satisfied: ninja in /usr/local/lib64/python3.6/site-
> packages
> 
> 
> 
> This error shows up if we compile vpp after compiling dpdk, without dpdk
> compilation we are not getting the vpp-plugin-dpdk RPM and the dpdk stanza
> in startup.conf is being unrecognized.
> 
> Any suggestions?
> 
> Thanks,

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

[vpp-dev]: Assert in vnet_mpls_tunnel_del()

2021-09-14 Thread Rajith PR via lists.fd.io

Hi All,

We recently started using the VPP's mpls tunnel constructs for our L2 cross
connect application. In certain test scenarios we are seeing a crash in the
delete path of the mpls tunnel.
Any pointers to fix the issue would be really helpful.

Version: *20.09*
Call Stack:

Thread 1 (Thread 0x7f854cdd3400 (LWP 14261)):

#0  0x7f854c41b492 in __GI___waitpid (pid=21116,
stat_loc=stat_loc@entry=0x7f84f79abc28, options=options@entry=0) at
../sysdeps/unix/sysv/linux/waitpid.c:30
#1  0x7f854c386177 in do_system (line=) at
../sysdeps/posix/system.c:149
#2  0x7f854c96918d in bd_signal_handler_cb () from
/usr/local/lib/libbd-infra.so
#3  0x7f853db8953f in rtb_bd_signal_handler () from
/usr/local/lib/libvlib.so.1.0.1
#4  0x7f853db899a2 in unix_signal_handler () from
/usr/local/lib/libvlib.so.1.0.1
#5  
#6  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#7  0x7f854c377921 in __GI_abort () at abort.c:79
#8  0x7f853f58a9e3 in os_panic () from /usr/local/lib/librtbvpp.so
#9  0x7f853d35aaa9 in ?? () from /usr/local/lib/libvppinfra.so.1.0.1
#10 0x7f853d35a827 in _clib_error () from
/usr/local/lib/libvppinfra.so.1.0.1
#11 0x7f853ecb2d75 in ?? () from /usr/local/lib/libvnet.so.1.0.1
#12 0x7f853ecb302d in fib_path_list_get_n_paths () from
/usr/local/lib/libvnet.so.1.0.1
#13 0x7f853e8f0b5c in ?? () from /usr/local/lib/libvnet.so.1.0.1
#14 0x7f853e8ef942 in ?? () from /usr/local/lib/libvnet.so.1.0.1
#15 0x7f853e8ed51a in ?? () from /usr/local/lib/libvnet.so.1.0.1
#16 0x7f853e2e9e1a in ?? () from /usr/local/lib/libvnet.so.1.0.1
#17 0x7f853e2ea0e8 in vnet_sw_interface_set_flags () from
/usr/local/lib/libvnet.so.1.0.1
#18 0x7f853e2eb6e4 in vnet_delete_sw_interface () from
/usr/local/lib/libvnet.so.1.0.1
#19 0x7f853e2eede9 in vnet_delete_hw_interface () from
/usr/local/lib/libvnet.so.1.0.1
#20 0x7f853e8ee368 in vnet_mpls_tunnel_del () from
/usr/local/lib/libvnet.so.1.0.1
#21 0x7f853f74535a in rtb_vpp_l2_xconnect_route_del_handle () from
/usr/local/lib/librtbvpp.so
#22 0x7f853f7453fa in rtb_vpp_l2_xconnect_route_handle () from
/usr/local/lib/librtbvpp.so
#23 0x7f853f69551b in rtb_vpp_route_mapping_process () from
/usr/local/lib/librtbvpp.so
#24 0x7f853f696a67 in rtb_vpp_route_adjacency_handle () from
/usr/local/lib/librtbvpp.so
#25 0x7f853f696d22 in rtb_vpp_route_api_out_process () from
/usr/local/lib/librtbvpp.so
#26 0x7f85406b3975 in fib_route_api_out_del () from
/usr/local/lib/libfibd.so
#27 0x7f85406b3a83 in fib_route_api_out_tbl_vpp_wlk () from
/usr/local/lib/libfibd.so
#28 0x7f85406a550b in fib_job_tmr_cb () from /usr/local/lib/libfibd.so
#29 0x7f854b27e6c2 in bds_qrunner_dispatch () from /usr/local/lib/libbds.so
#30 0x7f854b27f77c in bds_qrunner_dispatch_type () from
/usr/local/lib/libbds.so
#31 0x7f854b27f9aa in bds_qrunner_dispatch_prepare () from
/usr/local/lib/libbds.so
#32 0x7f854b27faa8 in bds_qrunner_expire () from /usr/local/lib/libbds.so
#33 0x7f854a67f616 in ?? () from /usr/local/lib/libqb.so
#34 0x7f854a67cfa7 in ?? () from /usr/local/lib/libqb.so
#35 0x7f854a67d797 in qb_loop_run_vpp_wrapper () from
/usr/local/lib/libqb.so
#36 0x7f854a6890e8 in lib_qb_service_start_event_wrapper_loop ()
from /usr/local/lib/libqb.so
#37 0x7f854c96b262 in bd_event_loop_run_once () from
/usr/local/lib/libbd-infra.so
#38 0x7f85060444f8 in ?? () from
/usr/local/lib/vpp_plugins/rtbrick_plugin.so
#39 0x7f853db058dd in ?? () from /usr/local/lib/libvlib.so.1.0.1
#40 0x7f853d37ec34 in clib_calljmp () from
/usr/local/lib/libvppinfra.so.1.0.1
#41 0x7f85255f7a10 in ?? ()
#42 0x7f853db0531f in ?? () from /usr/local/lib/libvlib.so.1.0.1

Code Snippet for Creating Tunnel (rpath has the out-labels and  nexthop):


  vec_add1(rpaths, rpath);
  tunnel_sw_if_index = vnet_mpls_tunnel_create(1, 0, NULL);
  vnet_mpls_tunnel_path_add(tunnel_sw_if_index, rpaths);
  vnet_sw_interface_admin_up(vnm, tunnel_sw_if_index);


Code Snippet for Deleting Tunnel.

 vec_add1(rpaths, rpath);
 vnet_mpls_tunnel_path_remove(sw_if_index, rpaths);
 vec_free(rpaths);
 vnet_mpls_tunnel_del(sw_if_index);


Thanks,
Rajith

-- 
NOTICE TO
RECIPIENT This e-mail message and any attachments are 
confidential and may be
privileged. If you received this e-mail in error, 
any review, use,
dissemination, distribution, or copying of this e-mail is 
strictly
prohibited. Please notify us immediately of the error by return 
e-mail and
please delete this message from your system. For more 
information about Rtbrick, please visit us at www.rtbrick.com 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20125): https://lists.fd.io/g/vpp-dev/message/20125
Mute This Topic: https://lists.fd.io/mt/85599060/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://list

[vpp-dev] Cloud native VNF agent

Re: [vpp-dev] fail_over_mac=1 (Active) Bonding

[vpp-dev] fail_over_mac=1 (Active) Bonding

Re: [vpp-dev] Centos 8 install problems

Re: [vpp-dev] TLS app stuck after burst of traffic #vpp-hoststack

Re: [vpp-dev] TLS app stuck after burst of traffic #vpp-hoststack

Re: [vpp-dev]: Assert in vnet_mpls_tunnel_del()

[vpp-dev] VPP healthy or not, or VAPI connection is healthy or not #vapi #vpp #shm

[vpp-dev] TLS app stuck after burst of traffic #vpp-hoststack

Re: [vpp-dev]: Assert in vnet_mpls_tunnel_del()

Re: [vpp-dev] Centos 8 install problems

[vpp-dev]: Assert in vnet_mpls_tunnel_del()

12 matches

Site Navigation

Mail list logo

Footer information