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]
-=-=-=-=-=-=-=-=-=-=-=-
