Hi, I am checking whether policing feature is enabled or not in NAT with the following approach --- Did an extern declaration for policer_classify_main_t in nat/out2in.c
if (pcm->classify_table_index_by_sw_if_index[0][sw_if_index0] != ~0) { /* feature is enabled */ next0 = SNAT_OUT2IN_NEXT_POLICER_CLASSIFY; vlib_node_add_next (vm, ip4_policer_classify_node->index, next0); } --- I have a feeling that this is not the best/proper way, but I could not figure out any thing better. Please suggest is there any other optimized/proper way to check an interface feature is enabled or not? But when the packets starts flowing, VPP is getting aborted !! DBGvpp# Aborted Makefile:473: recipe for target 'run' failed make: *** [run] Error 134 =====> following is the gdb trace for the same <============== __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007f7b08a7542a in __GI_abort () at abort.c:89 #2 0x000055d570fd6f5e in os_exit (code=1) at /home/<xxx>/vpp/src/vpp/vnet/main.c:349 #3 0x00007f7b0a1e7cac in unix_signal_handler (signum=11, si=0x7f7ac8fff670, uc=0x7f7ac8fff540) at /home/<xxx>/vpp/src/vlib/unix/main.c:157 #4 <signal handler called> #5 0x00007f7ac3f2606d in svs_input_inline (vm=0x7f7b0a413240 <vlib_global_main>, node=0x7f7ac95a3080, frame=0x7f7aca271d00, fproto=FIB_PROTOCOL_IP4) at /home/<xxx>/vpp/src/plugins/svs/svs.c:294 #6 0x00007f7ac3f262af in svs_input_ip4 (vm=0x7f7b0a413240 <vlib_global_main>, node=0x7f7ac95a3080, frame=0x7f7aca271d00) at /home/<xxx>/vpp/src/plugins/svs/svs.c:339 #7 0x00007f7b0a18eae4 in dispatch_node (vm=0x7f7b0a413240 <vlib_global_main>, node=0x7f7ac95a3080, type=VLIB_NODE_TYPE_INTERNAL, dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7f7aca271d00, last_time_stamp=12587373585573984) at /home/<xxx>/vpp/src/vlib/main.c:989 #8 0x00007f7b0a18f09d in dispatch_pending_node (vm=0x7f7b0a413240 <vlib_global_main>, pending_frame_index=3, last_time_stamp=12587373585573984) at /home/<xxx>/vpp/src/vlib/main.c:1139 #9 0x00007f7b0a190c9c in vlib_main_or_worker_loop (vm=0x7f7b0a413240 <vlib_global_main>, is_main=1) at /home/<xxx>/vpp/src/vlib/main.c:1555 #10 0x00007f7b0a191478 in vlib_main_loop (vm=0x7f7b0a413240 <vlib_global_main>) at /home/<xxx>/vpp/src/vlib/main.c:1629 #11 0x00007f7b0a19204b in vlib_main (vm=0x7f7b0a413240 <vlib_global_main>, input=0x7f7ac8ffffb0) at /home/<xxx>/vpp/src/vlib/main.c:1820 #12 0x00007f7b0a1e94ba in thread0 (arg=140166429749824) at /home/<xxx>/vpp/src/vlib/unix/main.c:607 #13 0x00007f7b098128a4 in clib_calljmp () from /home/<xxx>/vpp/build-root/install-vpp_debug-native/vpp/lib/libvppinfra.so.18.10 #14 0x00007ffcc1a6b2d0 in ?? () #15 0x00007f7b0a1e996e in vlib_unix_main (argc=2, argv=0x7ffcc1a6c5c8) at /home/<xxx>/vpp/src/vlib/unix/main.c:676 #16 0x000055d570fd6927 in main (argc=2, argv=0x7ffcc1a6c5c8) at /home/<xxx>/vpp/src/vpp/vnet/main.c:264 Thanks and Regards, Raj On Wed, Jan 23, 2019 at 8:05 PM Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco) <matfa...@cisco.com> wrote: > > Hi, > > You should go from nat44-out2in to ip4-policer-classify only if it is > configured on given interface (check if sw_if_index0 in nat44-out2in has > configured/enabled policer), I think this may be reason of ASSERT. > > Matus > > > -----Original Message----- > From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Raj > Sent: Wednesday, January 23, 2019 3:05 PM > To: vpp-dev@lists.fd.io > Subject: Re: [vpp-dev] Configuring NAT and Policing together > > Hi Matus, > > Thanks for the code fragment it helped me get a better understanding of what > I have to do, and have modified the code. But occasionally VPP hits an ASSERT > at: > > DBGvpp# 0: /vpp/src/vlib/node_funcs.h:296 > (vlib_node_runtime_get_next_frame) assertion `next_index < > n->n_next_nodes' fails > Aborted > > The approach I had followed was to get the index of policer classify node and > setting that as the next node of 'nat44-out2in' > ,'nat44-out2in-reass' and 'nat44-out2in-fast'. > > This is the partial diff of how we got the index of ip4-policer-classify and > setting the next node. (full diff is attached). > > --- a/src/plugins/nat/out2in.c > +++ b/src/plugins/nat/out2in.c > @@ -1110,6 +1113,15 @@ snat_out2in_node_fn (vlib_main_t * vm, > > proto0 = ip_proto_to_snat_proto (ip0->protocol); > > + ip4_policer_classify_node = > + vlib_get_node_by_name (vm, (u8 *) "ip4-policer-classify"); > + if (ip4_policer_classify_node) > + { > + next0 = SNAT_OUT2IN_NEXT_POLICER_CLASSIFY; > + vlib_node_add_next (vm, ip4_policer_classify_node->index, > + next0); > + } > + > if (PREDICT_FALSE (proto0 == ~0)) > { > if (nat_out2in_sm_unknown_proto (sm, b0, ip0, rx_fib_index0)) > > I hope the approach followed is the correct one, but I could not figure out > why the ASSERT is happening. > > Thanks and Regards, > > Raj > > > On Tue, Jan 22, 2019 at 8:10 PM Matus Fabian -X (matfabia - PANTHEON > TECHNOLOGIES at Cisco) <matfa...@cisco.com> wrote: > > > > nat44-out2in node: > > u32 next0 = SNAT_OUT2IN_NEXT_LOOKUP; > > <...> > > vlib_validate_buffer_enqueue_x1 (vm, node, next_index, to_next, > > n_left_to_next, bi0, next0); > > > > whatever you specify in VNET_FEATURE_INIT runs_before is ignored for > > nat44-out2in, normally when you want continue to nex node in feature arc > > you use vnet_feature_next(), but this is not possible in NAT (nat44-out2in > > is not always configured as interface feature, e.g. worker handoff in case > > of multithreading or combined in-out NAT interface). > > > > Matus > > > > -----Original Message----- > > From: Raj <rajlistu...@gmail.com> > > Sent: Tuesday, January 22, 2019 3:22 PM > > To: Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco) > > <matfa...@cisco.com> > > Cc: vpp-dev@lists.fd.io > > Subject: Re: [vpp-dev] Configuring NAT and Policing together > > > > On Tue, Jan 22, 2019 at 7:44 PM Matus Fabian -X (matfabia - PANTHEON > > TECHNOLOGIES at Cisco) <matfa...@cisco.com> wrote: > > > I don't think it is working way you wanted since nat44-out2in goes > > > directly to ip4-lookup instead of continue in feature arc to > > > ip4-policer-classify. > > > > Yes, you were right. My conclusion was premature. I still do not quite > > understand VNET_FEATURE_INIT to route the traffic the way I want. A sample > > code fragment would be very helpful. > > > > Thanks and Regards, > > > > Raj
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12002): https://lists.fd.io/g/vpp-dev/message/12002 Mute This Topic: https://lists.fd.io/mt/29379239/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-