Hi, You need to update next_nodes in VLIB_REGISTER_NODE (snat_out2in_node) too
Matus -----Original Message----- From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Raj Sent: Tuesday, February 5, 2019 4:02 PM To: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] Configuring NAT and Policing together Hello all, I spent some more time trying to figure out what is going on here. Issue here is in the 'vlib_node_runtime_get_next_frame(), ASSERT (next_index < n->n_next_nodes) fails. Here next_index and n->n_next_nodes are both same with value 4. I had updated snat_out2in_next_t with an additional entry SNAT_OUT2IN_NEXT_POLICER_CLASSIFY as follows: typedef struct { u32 sw_if_index; @@ -103,6 +105,7 @@ typedef enum SNAT_OUT2IN_NEXT_LOOKUP, SNAT_OUT2IN_NEXT_ICMP_ERROR, SNAT_OUT2IN_NEXT_REASS, + SNAT_OUT2IN_NEXT_POLICER_CLASSIFY, SNAT_OUT2IN_N_NEXT, } snat_out2in_next_t; But apparently that is not enough. Any pointers to figure out the reason why runtime next_nodes(vlib_node_runtime_t->n_next_nodes) is not updated? Thanks and Regards, Raj On Fri, Jan 25, 2019 at 3:12 PM Raj via Lists.Fd.Io <rajlistuser=gmail....@lists.fd.io> wrote: > > 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/libvppinfr > a.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/157026 > Group Owner: vpp-dev+ow...@lists.fd.io > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub > [rajlistu...@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12182): https://lists.fd.io/g/vpp-dev/message/12182 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] -=-=-=-=-=-=-=-=-=-=-=-