Re: [vpp-dev] NAT44 && vxlan tunnel conflict

2018-10-29 Thread wangchuan...@163.com
The attempt failed! Adding static mapping to bvi or tap-in-OS both does not work. Is there any cmd that can remove the NAT logic of udp-4789 from NAT44? Help please! wangchuan...@163.com From: Dave Barach (dbarach) Date: 2018-10-29 22:25 To: wangchuan...@163.com; vpp-dev@lists.fd.io

Re: [vpp-dev] VPP and RCU?

2018-10-29 Thread Florin Coras
> On Oct 29, 2018, at 1:42 PM, Stephen Hemminger > wrote: > > On Mon, 29 Oct 2018 13:20:27 -0700 > Florin Coras wrote: > >> Hi Stephen, >> >> No, we don’t support RCU. Wouldn’t rw-locks be enough to support your >> usecases? >> >> Florin >> >>> On Oct 29, 2018, at 12:40 PM, Stephen

Re: [vpp-dev] Snooping non-IP packets

2018-10-29 Thread Andrew Yourtchenko
If by chance you are in a bridge setup, then you can use the new l2 feature arc - there is an arc that sees exactly that - packets that are neither ipv4 nor IPv6 - you can see the https://gerrit.fd.io/r/#/c/15165/ where I switched the acl plugin over to it... --a > On 29 Oct 2018, at 19:01,

Re: [vpp-dev] VPP and RCU?

2018-10-29 Thread Florin Coras
Hi Stephen, No, we don’t support RCU. Wouldn’t rw-locks be enough to support your usecases? Florin > On Oct 29, 2018, at 12:40 PM, Stephen Hemminger > wrote: > > Is it possible to do Read Copy Update with VPP? Either using Userspace RCU > (https://librcu.org) > or manually. RCU is very

[vpp-dev] VPP and RCU?

2018-10-29 Thread Stephen Hemminger
Is it possible to do Read Copy Update with VPP? Either using Userspace RCU (https://librcu.org) or manually. RCU is very efficient way to handle read mostly tables and other dynamic cases such as plugins. The several things that are needed are non-preempt, atomic update of a pointer and a

Re: [vpp-dev] Snooping non-IP packets

2018-10-29 Thread Damjan Marion via Lists.Fd.Io
Yes, you can just use device-input feature arc instead. Please note that packets on that arc are not (optionally) assigned to sub-interfaces yet. So if you have vlan subinterface, packets will show up as main interface packets and with original l2 header. -- Damjan > On 29 Oct 2018, at

[vpp-dev] Snooping non-IP packets

2018-10-29 Thread Prashant Upadhyaya
Hi, I am using DPDK Plugin I want to write a node which will get to observe all the non-IP packets. By observe, I mean that I want my node to see the non-IP packets, but when I return from my node, the packets should traverse the original graph of VPP which they would have followed had my node

Re: [vpp-dev] Regarding clib_file_add API

2018-10-29 Thread Damjan Marion via Lists.Fd.Io
Right now it is main thread. there is a plan to make this per-thread. ETA unknown... — Damjan > On 29 Oct 2018, at 17:14, Prashant Upadhyaya wrote: > > Hi, > > I understand that when I do something like the following -- > clib_file_t template = {0}; > template.read_function = my_read_cb;

[vpp-dev] Regarding clib_file_add API

2018-10-29 Thread Prashant Upadhyaya
Hi, I understand that when I do something like the following -- clib_file_t template = {0}; template.read_function = my_read_cb; template.file_descriptor = my_fd; template.private_data = my_data; my_handle = clib_file_add (_main, ); Then my_read_cb will be called whenever the my_fd has data

Re: [vpp-dev] Regarding vlib_buffer_t construction for tx of a self-made packet

2018-10-29 Thread Dave Barach via Lists.Fd.Io
Cool, glad you found what you needed... -Original Message- From: Prashant Upadhyaya Sent: Monday, October 29, 2018 11:48 AM To: Dave Barach (dbarach) Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] Regarding vlib_buffer_t construction for tx of a self-made packet Thanks a bunch Dave

Re: [vpp-dev] Regarding vlib_buffer_t construction for tx of a self-made packet

2018-10-29 Thread Prashant Upadhyaya
Thanks a bunch Dave ! The vlib_buffer_add_data(...) does the trick for me ! All that I really had to do was to just set up the following fields in the vlib_buffer_t for the buffer index created by the function vnet_buffer (b)->sw_if_index[VLIB_RX] vnet_buffer (b)->sw_if_index[VLIB_TX] What a

Re: [vpp-dev] NAT44 && vxlan tunnel conflict

2018-10-29 Thread Dave Barach via Lists.Fd.Io
The NAT plugin is tossing vxlan out-to-in packets. You’ll get different results if you add a static mapping for (UDP, 4789) packets - maybe not the desired result, but at least a different result... D. From: vpp-dev@lists.fd.io On Behalf Of wangchuan...@163.com Sent: Monday, October 29, 2018

Re: [vpp-dev] non-initial fragment unexpected drop

2018-10-29 Thread Andrew Yourtchenko
Dear Emma, the behavior you are observing is expected. Since we do not do in-flight reassembly, in order to make the ACL work for the fragment we have to do first-match on a relaxed rule derived from L4 rule that would have matched that packet. I think just issuing "set acl-plugin

[vpp-dev] non-initial fragment unexpected drop

2018-10-29 Thread emma sdi
Hi Dear VPP When I was trying to test fragmentation feature in VPP, I encountered a problem. firstly, I added an acl as below: acl_add_replace deny proto 1 sport 2-2 dport 3-3, permit+reflect and then I saw that ICMP ping packets were passing through the VPP matching with second rule. At the

[vpp-dev] NAT44 && vxlan tunnel conflict

2018-10-29 Thread wangchuan...@163.com
Hi all, I want to login PC1 through SSH2 where vpp is running, and the VPP is used as the VXLAN translate center(only 1 ip). However, I found some error! Data from vxlan tunnel 1 were dropped, which should be decaped at one vxlan-tunnel-1 and transmited out from vxlan-tunnel-2. How can I