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/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/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 (#12178): https://lists.fd.io/g/vpp-dev/message/12178
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]
-=-=-=-=-=-=-=-=-=-=-=-
