Re: [vpp-dev] veth alternative in VPP
Thanks Benoit and Neale. I used loopback interfaces, but since they are in different VRFs I couldn't establish a L3 connection between them. I will try pipe interfaces. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22419): https://lists.fd.io/g/vpp-dev/message/22419 Mute This Topic: https://lists.fd.io/mt/96048462/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] veth alternative in VPP
Hi, I am looking for veth pair alternative in VPP. I want to pass traffics between two VRFs and I want them to be processed as input packets to an interface( to use NAT or other ip features), so route leakage is not gonna help. Also, since I'm using one instance of VPP with multiple VRFs, using memifs are not viable. Are there any methods in VPP to achieve the same goal? Regards. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22412): https://lists.fd.io/g/vpp-dev/message/22412 Mute This Topic: https://lists.fd.io/mt/96048462/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] memory growth in charon using vpp_sswan
Thank you. Enabling DPD is not necessary to reproduce the issue. You can use `swanctl --list-sas` command to query SAs and see the problem. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22342): https://lists.fd.io/g/vpp-dev/message/22342 Mute This Topic: https://lists.fd.io/mt/95641379/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] memory growth in charon using vpp_sswan
Hi Kai, Thanks for your response. Yes your understanding is correct and `stat_segment_connect` is called only when querying SAs. This query does not occur unless: 1) you ask for SA status and 2) before sending DPD messages. I'm afraid using 5.9.6 version did not change anything. May I ask if in your end, you use DPD?( It is disabled by default, to enable `dpd_delay` value should be set in `swanctl.conf`) If the dead peer detection is disabled and I don't query my SAs too often, the situation does not arise. Regards Mahdi -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22326): https://lists.fd.io/g/vpp-dev/message/22326 Mute This Topic: https://lists.fd.io/mt/95641379/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] memory growth in charon using vpp_sswan
Hi, I used the plugin resided in `extras/vpp_sswan` on both 5.9.8 and 5.8.2 Strongswan versions. All functionalities are working great but after Child SAs are established, there's a constant memory growth in charon process( Reaching from 20MB RSS to 46MB RSS in 4 days, but this growth is visible from the beginning of establishment of SAs and is constant. Also I haven't tested it this issue exists with IKE SAs only with no Child SA). There are also no complaints From ASAN. Interestingly, If `stat_segment_disconnect` is not called( and `stat_segment_connect` is called once) in `query_sa` function, The problem is solved and there is no memory growth. I tried protecting the process of querying SAs with mutex but it was no good. I would like to know if there is any specific reason behind this connecting/fetching stats/disconnecting pattern? Couldn't connect once then keep the connection? I've also checked and tested the `stat_client.c` code. It seems fine and there are no memory issues there. So any advice regarding where to lookup or which tools should be used to catch the root cause of this problem? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22323): https://lists.fd.io/g/vpp-dev/message/22323 Mute This Topic: https://lists.fd.io/mt/95641379/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] Policer classify as an output feature
Hi VPP folks, Less than 2 years ago, a new feature named `input policing` was added to VPP and 7 months ago the output counterpart was added which enables a policer on all the incoming/outgoing traffic on an interface. Here is a similar patch to add class-based policing as an output feature: https://gerrit.fd.io/r/c/vpp/+/37566 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22115): https://lists.fd.io/g/vpp-dev/message/22115 Mute This Topic: https://lists.fd.io/mt/94752054/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] IGMP over an IPSec protected tunnel
Thanks Benoit. This patch solved the problem. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20846): https://lists.fd.io/g/vpp-dev/message/20846 Mute This Topic: https://lists.fd.io/mt/88966349/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] IGMP over an IPSec protected tunnel
Hi Benoit, Because of VPP's crash, I'm afraid i can't capture the pcap. But I'll share with you a packet trace of a normal interface with an IGMP packet. Normally yes, the packet goes through `ip4-lookup`, but here the path is: `ip4_input_inline`-> `ip4_input_check_x2`->`check_ver_opt_csum`. and since it has a Router Alert option, it goes to `ip4-options` then from there it goes to `ip4-local`. In this attached pcap, `sootap-tx` is my plugin node that is registered to get IGMP packets. igmp.pcap Description: application/vnd.tcpdump.pcap -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20837): https://lists.fd.io/g/vpp-dev/message/20837 Mute This Topic: https://lists.fd.io/mt/88966349/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] IGMP over an IPSec protected tunnel
Hi VPP folks, Recently I ran into a problem: receiving IGMP packets over a GRE tunnel protected by IPSec in transport mode, sometimes causes a VPP crash. The crash happens in `ip4-local` node. Using debug image, i realized the problem was caused by an invalid fib index passed to `fib_get()` function. Digging down the code, I found the root cause of this problem: buffer's opaque. IGMP packets have a Router Alert option in IP header. This causes the packets to directly goes from `ip4-input` node to `ip4-local` node and this is all right. But IGMP packets that are encrypted, first have to be decrypted. During this process, their buffer's opaque changes and `ipsec.sad_index` is set. Then the packet is passed to `ip4-input` then `ip4-local` and there, `ip.fib_index` from buffer's opaque is used; But the `ipsec.sad_index` and `ip.fib_index` are the same in opaque struct. This is the reason of invalid fib index. What is the best way to prevent the crashes and fix the behavior of IPSec decryption? which part of the code should be changed? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20834): https://lists.fd.io/g/vpp-dev/message/20834 Mute This Topic: https://lists.fd.io/mt/88966349/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] [wg]: Assigning threads to wireguard peers
Hello folks, Looking at `wg_peer_assign_thread` function One can see the logic behind peer thread assigning which is: " Use the same thread that the packet has come from, unless its main thread. In main thread case, randomly choose a worker thread to handoff". I understand assigning all peers uniformly to threads, can ( potentially) cause overall performance penalty. But in case of having lots of peers, all coming from the same interface, having more threads to handle them can become handy. So is there any other reason, other than performance impacts, behind limiting thread assigning to the above logic? Best regards, Mahdi -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20375): https://lists.fd.io/g/vpp-dev/message/20375 Mute This Topic: https://lists.fd.io/mt/86570818/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] ACL panics in `hash_acl_set_heap`
Hi Andrew, Thanks for you response. That makes sense. I will monitor my box memory usage. Unfortunately I'm using VPP 20.05. So I will try to forwardport( we have it? :D) this patch to it. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17433): https://lists.fd.io/g/vpp-dev/message/17433 Mute This Topic: https://lists.fd.io/mt/76882936/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] ACL panics in `hash_acl_set_heap`
Hi VPP folks, Setting ACL from VAPI, we have a panic `ACL plugin failed to allocate lookup heap of %U bytes` in `hash_acl_set_heap` function. It doesn't happen always. Time to time and randomly this problem occurs. My system has 8G of RAM. VPP is running with the default `startup.conf`. I've set 1024 hugepages, size 2M. So any idea where should i look for the error? If it's necessary to change any setting, I'd be glad to hear out. If any more information is needed, Inform me. Regards, Mahdi. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17419): https://lists.fd.io/g/vpp-dev/message/17419 Mute This Topic: https://lists.fd.io/mt/76882936/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] questions on IKEv2
Hi Filip, Thanks for your answer. I'm glad to hear them. I understand the difficulties with ikev2_initiate_sa_init return value. And i don't think there is a feasible solution for it because of dependencies on an outside VPP source. Maybe events are the best choice. Regards, Mahdi -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16605): https://lists.fd.io/g/vpp-dev/message/16605 Mute This Topic: https://lists.fd.io/mt/74577612/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] questions on IKEv2
Hello VPP folks! I'm using VPP 20.01 stable release. Regarding IKEv2 plugin, I've got some questions about its design and applications( in present and in future). The first thing i've noticed, is the API. There are no dumps nor status of profiles/ SAs. I issue a ikev2_initiate_sa_init, and it always returns success. But if the responder is not available in that time, the tunnel is not established. The second thing, is in fact the ikev2_initiate_sa_init itself( it's somehow the first question). I believed on failure, it will retransmit the packets on regular basis until the tunnel is established. After looking the code, I realized it's a one-shot thing. I've seen a routine-checking approach is used for SA rekeying( and in the recent version, for DPD). Is there a chance that the same thing can happen for ikev2_initiate_sa_init? Or it's a design choice? I'll be really glad to hear the IKEv2 plugin's design and goals so i can make my plannings. There are some minor problems i've encountered which, based on changes in 20.05 release, seems will get fixed in the future releases( like the one that Initiator always requests and Responder always respond. which make SA removing from responder a problem). IKEv2 is a great plugin and it's improving each day passing. So i just want a little clarification about its roadmap. And of course its API. Because current API in 20.01( and as i've looked in 20.05) is not very usable for clients. I'd be glad if I could make contributions to improve functionality of this plugin. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16584): https://lists.fd.io/g/vpp-dev/message/16584 Mute This Topic: https://lists.fd.io/mt/74577612/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] vapi_dispatch_one blocking mode #vpp #vapi
Hello, I noticed once, that vapi_recv function, called from vapi_dispatch_one, is called like this: vapi_recv (ctx, , , SVM_Q_WAIT, 0 ); and one time, it happened just once and i couldn't regenerate it, the code was freezed in pthread_cond_wait called from svm_queue_wait_inline. and when i traced it back, it was all started from vapi_recv. isn't it a better practice to call vapi_recv in vapi_dispatch_one with SVM_Q_TIMEDWAIT ? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13034): https://lists.fd.io/g/vpp-dev/message/13034 Mute This Topic: https://lists.fd.io/mt/31627670/21656 Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452 Mute #vapi: https://lists.fd.io/mk?hashtag=vapi=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
