Re: [vpp-dev] Configuring NAT and Policing together
On Wed, Feb 6, 2019 at 11:05 AM Matus Fabian -X (matfabia - PANTHEON
TECHNOLOGIES at Cisco) wrote:
> You need to update next_nodes in VLIB_REGISTER_NODE (snat_out2in_node) too
This was already one. Did some debugging using GDB and figured out
that the issue could be in the node ip4_policer_classify node.
Earlier 'runs_before' was updated with 'nat44-in2out' in
'ip4-policer-classify' node. With this I was hitting ASSERT
(next_index < n->n_next_nodes) for the 'ip4-policer-classify' node.
(gdb) print *(nm->nodes_by_type[VLIB_NODE_TYPE_INTERNAL])
$12 = {cacheline0 = 0x7fffb533da40 "\210\317m\366\377\177",
function = 0x766dcf88 , errors = 0x7fffb51d7b2c,
clocks_since_last_overflow = 0, max_clock = 0, max_clock_n = 0,
calls_since_last_overflow = 0, vectors_since_last_overflow = 0,
next_frame_index = 6,
node_index = 0, input_main_loops_per_call = 0,
main_loop_count_last_dispatch = 0,
main_loop_vector_stats = {0, 0}, flags = 0, state = 0, n_next_nodes = 0,
cached_next_index = 0, thread_index = 0, runtime_data = 0x7fffb533da86 ""}
(gdb) print *n
$13 = {cacheline0 = 0x7fffb534c5c0 "W\270\314\366\377\177",
function = 0x76ccb857 , errors = 0x7fffb538159c,
clocks_since_last_overflow = 89712, max_clock = 22476, max_clock_n = 1,
calls_since_last_overflow = 11, vectors_since_last_overflow = 11,
next_frame_index = 1945, node_index = 539, input_main_loops_per_call = 0,
main_loop_count_last_dispatch = 335304799, main_loop_vector_stats =
{1, 0}, flags = 0,
state = 0, n_next_nodes = 4, cached_next_index = 2, thread_index = 0,
runtime_data = 0x7fffb534c606 ""}
But when I added the feature 'nat44-out2in' also in the .runs_before
of 'ip4-policer-classify', the issue was fixed. No Assertions and I
could see the functionality is working fine.
diff --git a/src/vnet/ip/ip4_forward.c b/src/vnet/ip/ip4_forward.c
index 9dac828a..e9a99006 100644
--- a/src/vnet/ip/ip4_forward.c
+++ b/src/vnet/ip/ip4_forward.c
@@ -753,7 +753,7 @@ VNET_FEATURE_INIT (ip4_policer_classify, static) =
{
.arc_name = "ip4-unicast",
.node_name = "ip4-policer-classify",
- .runs_before = VNET_FEATURES ("ipsec-input-ip4"),
+ .runs_before = VNET_FEATURES
("ipsec-input-ip4","nat44-in2out","nat44-out2in"),
};
What I would like to know is whether this is the correct fix for this
ASSERT failure, and if yes I am not sure how exactly it works.
Does adding the feature 'nat44-out2in' in the .runs_before of
'ip4-policer-classify' has a side effect of incrementing the value of
n_next_nodes? If not how adding the above patch resolve the Assert
failure?
With regards,
Raj
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12226): https://lists.fd.io/g/vpp-dev/message/12226
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]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Configuring NAT and Policing together
Hi,
You need to update next_nodes in VLIB_REGISTER_NODE (snat_out2in_node) too
Matus
-Original Message-
From: 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
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 0x7f7b08a7542a in __GI_abort () at abort.c:89
> #2 0x55d570fd6f5e in os_exit (code=1) at
> /home//vpp/src/vpp/vnet/main.c:349
> #3 0x7f7b0a1e7cac in unix_signal_handler (signum=11,
> si=0x7f7ac8fff670, uc=0x7f7ac8fff540)
> at /home//vpp/src/vlib/unix/main.c:157
> #4
> #5 0x7f7ac3f2606d in svs_input_inline (vm=0x7f7b0a413240
> , node=0x7f7ac95a3080,
> frame=0x7f7aca271d00, fproto=FIB_PROTOCOL_IP4) at
> /home//vpp/src/plugins/svs/svs.c:294
> #6 0x7f7ac3f262af in svs_input_ip4 (vm=0x7f7b0a413240
> , node=0x7f7ac95a3080,
> frame=0x7f7aca271d00) at /home//vpp/src/plugins/svs/svs.c:339
> #7 0x7f7b0a18eae4 in dispatch_node (vm=0x7f7b0a413240
> , node=0x7f7ac95a3080,
> type=VLIB_NODE_TYPE_INTERNAL,
> dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7f7aca271d00,
> last_time_stamp=12587373585573984) at
> /home//vpp/src/vlib/main.c:989
> #8 0x7f7b0a18f09d in dispatch_pending_node (vm=0x7f7b0a413240
> ,
> pending_frame_index=3, last_time_stamp=12587373585573984) at
> /home//vpp/src/vlib/main.c:1139
> #9 0x7f7b0a190c9c in vlib_main_or_worker_loop (vm=0x7f7b0a413240
> , is_main=1)
> at /home//vpp/src/vlib/main.c:1555
> #10 0x7f7b0a191478 in vlib_main_loop (vm=0x7f7b0a413240
> )
> at /home//vpp/src/vlib/main.c:1629
> #11 0x7f7b0a19204b in vlib_main (vm=0x7f7b0a413240
> , input=0x7f7ac8b0)
> at /home//vpp/src/vlib/main.c:1820
> #12 0x7f7b0a1e94ba in thread0 (arg=140166429749824) at
> /home//vpp/src/vlib/unix/main.c:607
> #13 0x7f7b098128a4 in clib_calljmp ()
>from
> /home//vpp/build-root/install-vpp_debug-native/vpp/lib/libvppinfr
> a.so.18.10
> #14 0x7ffcc1a6b2d0 in ?? ()
> #15 0x7f7b0a1e996e in vlib_unix_main (argc=2, argv=0x7ffcc1a6c5c8)
> at /home//vpp/src/vlib/unix/main.c:676
> #16 0x55d570fd6927 in main (argc=2, argv=0x7ffcc1a6c5c8) at
> /home//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) 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--
Re: [vpp-dev] Configuring NAT and Policing together
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 0x7f7b08a7542a in __GI_abort () at abort.c:89
#2 0x55d570fd6f5e in os_exit (code=1) at
/home//vpp/src/vpp/vnet/main.c:349
#3 0x7f7b0a1e7cac in unix_signal_handler (signum=11,
si=0x7f7ac8fff670, uc=0x7f7ac8fff540)
at /home//vpp/src/vlib/unix/main.c:157
#4
#5 0x7f7ac3f2606d in svs_input_inline (vm=0x7f7b0a413240
, node=0x7f7ac95a3080,
frame=0x7f7aca271d00, fproto=FIB_PROTOCOL_IP4) at
/home//vpp/src/plugins/svs/svs.c:294
#6 0x7f7ac3f262af in svs_input_ip4 (vm=0x7f7b0a413240
, node=0x7f7ac95a3080,
frame=0x7f7aca271d00) at /home//vpp/src/plugins/svs/svs.c:339
#7 0x7f7b0a18eae4 in dispatch_node (vm=0x7f7b0a413240
, node=0x7f7ac95a3080,
type=VLIB_NODE_TYPE_INTERNAL,
dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7f7aca271d00,
last_time_stamp=12587373585573984) at /home//vpp/src/vlib/main.c:989
#8 0x7f7b0a18f09d in dispatch_pending_node (vm=0x7f7b0a413240
,
pending_frame_index=3, last_time_stamp=12587373585573984) at
/home//vpp/src/vlib/main.c:1139
#9 0x7f7b0a190c9c in vlib_main_or_worker_loop (vm=0x7f7b0a413240
, is_main=1)
at /home//vpp/src/vlib/main.c:1555
#10 0x7f7b0a191478 in vlib_main_loop (vm=0x7f7b0a413240 )
at /home//vpp/src/vlib/main.c:1629
#11 0x7f7b0a19204b in vlib_main (vm=0x7f7b0a413240
, input=0x7f7ac8b0)
at /home//vpp/src/vlib/main.c:1820
#12 0x7f7b0a1e94ba in thread0 (arg=140166429749824) at
/home//vpp/src/vlib/unix/main.c:607
#13 0x7f7b098128a4 in clib_calljmp ()
from
/home//vpp/build-root/install-vpp_debug-native/vpp/lib/libvppinfra.so.18.10
#14 0x7ffcc1a6b2d0 in ?? ()
#15 0x7f7b0a1e996e in vlib_unix_main (argc=2, argv=0x7ffcc1a6c5c8)
at /home//vpp/src/vlib/unix/main.c:676
#16 0x55d570fd6927 in main (argc=2, argv=0x7ffcc1a6c5c8) at
/home//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) 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 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))
> {
>
Re: [vpp-dev] Configuring NAT and Policing together
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 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) 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
> Sent: Tuesday, January 22, 2019 3:22 PM
> To: Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco)
>
> 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) 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 (#11981): https://lists.fd.io/g/vpp-dev/message/11981
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]
-=-=-=-=-=-=-=-=-=-=-=-
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) 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
> Sent: Tuesday, January 22, 2019 3:22 PM
> To: Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco)
>
> 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) 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
diff --git a/src/plugins/nat/out2in.c b/src/plugins/nat/out2in.c
index 8c013d9b..401bcacc 100755
--- a/src/plugins/nat/out2in.c
+++ b/src/plugins/nat/out2in.c
@@ -34,6 +34,7 @@
#include
#include
+
typedef struct
{
u32 sw_if_index;
@@ -103,6 +104,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;
@@ -1086,6 +1088,7 @@ snat_out2in_node_fn (vlib_main_t * vm,
snat_session_t *s0 = 0;
clib_bihash_kv_8_8_t kv0, value0;
u8 identity_nat0;
+ vlib_node_t *ip4_policer_classify_node = NULL;
/* speculatively enqueue b0 to the current next frame */
bi0 = from[0];
@@ -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))
@@ -1295,6 +1307,7 @@ VLIB_REGISTER_NODE (snat_out2in_node) = {
[SNAT_OUT2IN_NEXT_LOOKUP] = "ip4-lookup",
[SNAT_OUT2IN_NEXT_ICMP_ERROR] = "ip4-icmp-error",
[SNAT_OUT2IN_NEXT_REASS] = "nat44-out2in-reass",
+[SNAT_OUT2IN_NEXT_POLICER_CLASSIFY] = "ip4-policer-classify",
},
};
/* *INDENT-ON* */
@@ -1343,6 +1356,8 @@ nat44_out2in_reass_node_fn (vlib_main_t * vm,
u16 old_port0, new_port0;
ip_csum_t sum0;
u8 identity_nat0;
+ vlib_node_t *ip4_policer_classify_node = NULL;
+
/* speculatively enqu
Re: [vpp-dev] Configuring NAT and Policing together
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 Sent: Tuesday, January 22, 2019 3:22 PM To: Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco) 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) 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 (#11972): https://lists.fd.io/g/vpp-dev/message/11972 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] -=-=-=-=-=-=-=-=-=-=-=-
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) 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 (#11971): https://lists.fd.io/g/vpp-dev/message/11971 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Configuring NAT and Policing together
Hi,
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.
Matus
-Original Message-
From: Raj
Sent: Tuesday, January 22, 2019 3:00 PM
To: Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco)
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Configuring NAT and Policing together
Hi Matus,
This is the patch I have made and looks like its working.
diff --git a/src/plugins/nat/nat.c b/src/plugins/nat/nat.c index
540d3bf8..ac735e9a 100755
--- a/src/plugins/nat/nat.c
+++ b/src/plugins/nat/nat.c
@@ -47,6 +47,7 @@ VNET_FEATURE_INIT (ip4_snat_in2out, static) = {
VNET_FEATURE_INIT (ip4_snat_out2in, static) = {
.arc_name = "ip4-unicast",
.node_name = "nat44-out2in",
+ .runs_before = VNET_FEATURES ("ip4-policer-classify"),
.runs_after = VNET_FEATURES ("acl-plugin-in-ip4-fa",
"ip4-dhcp-client-detect"), };
Its just first time hacking on VPP code, so do let me know if this is the right
way or there is a better way.
Thanks and Regards,
Raj
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11970): https://lists.fd.io/g/vpp-dev/message/11970
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]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Configuring NAT and Policing together
Hi Matus,
This is the patch I have made and looks like its working.
diff --git a/src/plugins/nat/nat.c b/src/plugins/nat/nat.c
index 540d3bf8..ac735e9a 100755
--- a/src/plugins/nat/nat.c
+++ b/src/plugins/nat/nat.c
@@ -47,6 +47,7 @@ VNET_FEATURE_INIT (ip4_snat_in2out, static) = {
VNET_FEATURE_INIT (ip4_snat_out2in, static) = {
.arc_name = "ip4-unicast",
.node_name = "nat44-out2in",
+ .runs_before = VNET_FEATURES ("ip4-policer-classify"),
.runs_after = VNET_FEATURES ("acl-plugin-in-ip4-fa",
"ip4-dhcp-client-detect"),
};
Its just first time hacking on VPP code, so do let me know if this is
the right way or there is a better way.
Thanks and Regards,
Raj
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11969): https://lists.fd.io/g/vpp-dev/message/11969
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]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Configuring NAT and Policing together
comments inline
Matus
-Original Message-
From: vpp-dev@lists.fd.io On Behalf Of Raj
Sent: Tuesday, January 22, 2019 1:06 PM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Configuring NAT and Policing together
Hi Matus,
We were looking to modify the flow so that the south->north path looks
like ip4-input-no-checksum-> ip4-policer-classify -> nat44-in2out ->
ip4-lookup and north->south path should be ip4-input-no-checksum ->
nat44-in2out -> ip4-policer-classify -> ip4-lookup
With your suggested modifications we were able to get the desired flow for
south->north path, but with a small change, by putting "nat44-out2in" in
.runs_after. The code looks like:
.runs_before = VNET_FEATURES ("ipsec-input-ip4","nat44-in2out"),
.runs_after = VNET_FEATURES ("nat44-out2in"),
But in north->south direction ip4-policer-classify node is being skipped.
[mf:] nat44-out2in doesn't continue in feature arc but always goes directly to
ip4-lookup, as I write before NAT can't continue in feature arc using
vnet_feature_next
Also I did not fully understand this statement: "It would be possible to add
additional static graph arc from nat node to ip4-policer-classify and decide on
per-packet basis where to send packet since you don't know at compile time
whether policer is configured on interface.".
[mf:] You can add some code to nat44-out2in node where you packet next node is
chosen, if policer is enabled on interface packet goes to ip4-policer-classify
otherwise as usual to ip4-lookup
Thanks and Regards,
Raj
On Mon, Jan 21, 2019 at 6:04 PM Matus Fabian -X (matfabia - PANTHEON
TECHNOLOGIES at Cisco) wrote:
>
> Hi,
>
> You can use ip4-policer-classify before NAT node. Add nat44-in2out or
> nat44-out2in to ip4_policer_classify runs_before list
> VNET_FEATURE_INIT (ip4_policer_classify, static) = {
> .arc_name = "ip4-unicast",
> .node_name = "ip4-policer-classify",
> .runs_before = VNET_FEATURES ("ipsec4-input-feature",
> "nat44-in2out", "nat44-out2in"), };
>
> NAT code can't continue in feature arc using vnet_feature_next in some cases.
> It would be possible to add additional static graph arc from nat node to
> ip4-policer-classify and decide on per-packet basis where to send packet
> since you don't know at compile time whether policer is configured on
> interface.
>
> Matus
>
>
> -Original Message-
> From: vpp-dev@lists.fd.io On Behalf Of Raj
> Sent: Monday, January 21, 2019 1:00 PM
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Configuring NAT and Policing together
>
> Hello all,
>
> I am trying to configure NAT and VPP run together, but its not working.
>
> My configuration is as follows:
>
> version: vpp v18.10-release built by root on 41f0552eeae3
>
> Interfaces:
>
> GigabitEthernet1/0/0 (up):
> L3 100.69.1.1/24
> L3 2001:xxx:xxx:600::1/56
> GigabitEthernet1/0/1 (up):
> L3 xxx.79.223.14/29
> L3 2001:xxx:xxx:10d::600/64
>
> Policer config with default route:
>
> configure policer name policy1 cir 500 eir 0 cb 5000 eb 15000 rate
> kbps round closest type 1r3c conform-action transmit exceed-action
> mark-and-transmit AF22 violate-action drop configure policer name
> policy2 cir 750 eir 0 cb 7500 eb 2 rate kbps round closest type
> 1r3c conform-action transmit exceed-action mark-and-transmit AF22
> violate-action drop classify table mask l3 ip4 src classify table mask
> l3 ip4 dst classify session policer-hit-next policy1 exceed-color
> table-index 0 match l3 ip4 src 100.69.1.4 classify session
> policer-hit-next policy2 exceed-color table-index 1 match l3 ip4 dst
> 100.69.1.4 set policer classify interface GigabitEthernet1/0/0
> ip4-table 0 set policer classify interface GigabitEthernet1/0/1
> ip4-table 1 ip route add 0.0.0.0/0 via xxx.79.223.9
> GigabitEthernet1/0/1 ip route add ::/0 via 2001:xxx::10d::1
> GigabitEthernet1/0/1
>
> At this point, if I do a wget at 100.69.1.4 to download from
> xxx.79.223.9, the speed is about 1mbps, but ranging from about 1.5mbps
> to 831kbps
>
> /dev/null 14%[===> ] 75.30M 1.18Mb/s
>
> The packet trace show:
>
> 100.69.1.4 -> xxx.79.223.9
>
> 01:10:21:269382: dpdk-input
> GigabitEthernet1/0/0 rx queue 0
> 01:10:21:269383: ip4-input-no-checksum
> 01:10:21:269384: ip4-policer-classify
> 01:10:21:269384: ip4-lookup
> 01:10:21:269384: ip4-rewrite
> 01:10:21:269384: GigabitEthernet1/0/1-output
> 01:10:21:269385: GigabitEthernet1/0/1-tx
>
>
> xxx.79.223.9 -> 100.69.1.4
>
> 01:10:21:268964: dpdk-input
> GigabitEthernet1/0/1 rx queue 0
> 01:10:21:268970: ip4-input-no-checksum
Re: [vpp-dev] Configuring NAT and Policing together
Hi Matus,
We were looking to modify the flow so that the south->north path looks
like ip4-input-no-checksum-> ip4-policer-classify -> nat44-in2out ->
ip4-lookup and north->south path should be ip4-input-no-checksum ->
nat44-in2out -> ip4-policer-classify -> ip4-lookup
With your suggested modifications we were able to get the desired flow
for south->north path, but with a small change, by putting
"nat44-out2in" in .runs_after. The code looks like:
.runs_before = VNET_FEATURES ("ipsec-input-ip4","nat44-in2out"),
.runs_after = VNET_FEATURES ("nat44-out2in"),
But in north->south direction ip4-policer-classify node is being skipped.
Also I did not fully understand this statement: "It would be possible
to add additional static graph arc from nat node to
ip4-policer-classify and decide on per-packet basis where to send
packet since you don't know at compile time whether policer is
configured on interface.".
Thanks and Regards,
Raj
On Mon, Jan 21, 2019 at 6:04 PM Matus Fabian -X (matfabia - PANTHEON
TECHNOLOGIES at Cisco) wrote:
>
> Hi,
>
> You can use ip4-policer-classify before NAT node. Add nat44-in2out or
> nat44-out2in to ip4_policer_classify runs_before list
> VNET_FEATURE_INIT (ip4_policer_classify, static) =
> {
> .arc_name = "ip4-unicast",
> .node_name = "ip4-policer-classify",
> .runs_before = VNET_FEATURES ("ipsec4-input-feature", "nat44-in2out",
> "nat44-out2in"),
> };
>
> NAT code can't continue in feature arc using vnet_feature_next in some cases.
> It would be possible to add additional static graph arc from nat node to
> ip4-policer-classify and decide on per-packet basis where to send packet
> since you don't know at compile time whether policer is configured on
> interface.
>
> Matus
>
>
> -Original Message-
> From: vpp-dev@lists.fd.io On Behalf Of Raj
> Sent: Monday, January 21, 2019 1:00 PM
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Configuring NAT and Policing together
>
> Hello all,
>
> I am trying to configure NAT and VPP run together, but its not working.
>
> My configuration is as follows:
>
> version: vpp v18.10-release built by root on 41f0552eeae3
>
> Interfaces:
>
> GigabitEthernet1/0/0 (up):
> L3 100.69.1.1/24
> L3 2001:xxx:xxx:600::1/56
> GigabitEthernet1/0/1 (up):
> L3 xxx.79.223.14/29
> L3 2001:xxx:xxx:10d::600/64
>
> Policer config with default route:
>
> configure policer name policy1 cir 500 eir 0 cb 5000 eb 15000 rate kbps round
> closest type 1r3c conform-action transmit exceed-action mark-and-transmit
> AF22 violate-action drop configure policer name policy2 cir 750 eir 0 cb 7500
> eb 2 rate kbps round closest type 1r3c conform-action transmit
> exceed-action mark-and-transmit AF22 violate-action drop classify table mask
> l3 ip4 src classify table mask l3 ip4 dst classify session policer-hit-next
> policy1 exceed-color table-index 0 match l3 ip4 src 100.69.1.4 classify
> session policer-hit-next policy2 exceed-color table-index 1 match l3 ip4 dst
> 100.69.1.4 set policer classify interface GigabitEthernet1/0/0 ip4-table 0
> set policer classify interface GigabitEthernet1/0/1 ip4-table 1 ip route add
> 0.0.0.0/0 via xxx.79.223.9 GigabitEthernet1/0/1 ip route add ::/0 via
> 2001:xxx::10d::1 GigabitEthernet1/0/1
>
> At this point, if I do a wget at 100.69.1.4 to download from xxx.79.223.9,
> the speed is about 1mbps, but ranging from about 1.5mbps to 831kbps
>
> /dev/null 14%[===> ] 75.30M 1.18Mb/s
>
> The packet trace show:
>
> 100.69.1.4 -> xxx.79.223.9
>
> 01:10:21:269382: dpdk-input
> GigabitEthernet1/0/0 rx queue 0
> 01:10:21:269383: ip4-input-no-checksum
> 01:10:21:269384: ip4-policer-classify
> 01:10:21:269384: ip4-lookup
> 01:10:21:269384: ip4-rewrite
> 01:10:21:269384: GigabitEthernet1/0/1-output
> 01:10:21:269385: GigabitEthernet1/0/1-tx
>
>
> xxx.79.223.9 -> 100.69.1.4
>
> 01:10:21:268964: dpdk-input
> GigabitEthernet1/0/1 rx queue 0
> 01:10:21:268970: ip4-input-no-checksum
> 01:10:21:268973: ip4-policer-classify
> 01:10:21:268974: ip4-lookup
> 01:10:21:268975: ip4-rewrite
> 01:10:21:268976: GigabitEthernet1/0/0-output
> 01:10:21:268976: GigabitEthernet1/0/0-tx
>
> Now adding NAT using the commands:
>
> nat44 add interface address GigabitEthernet1/0/1 set interface nat44 in
> GigabitEthernet1/0/0 out GigabitEthernet1/0/1
>
> Policer stops working at this point.
>
> traces show:
>
> 100.69.1.4 -> xxx.79.223.9
>
> 01:23:19:656284: dpdk-input
> GigabitEthernet1/0/0 rx queue 0
> 01:23:19:656285: ip4-input-no-checksum
> 01:23:19:656285: nat44-in2out
> 01:23:19:656285: ip4-lookup
> 01:23:19:656286: ip4-rewrite
> 01:23:19:656286: GigabitEthernet1/0/1-output
> 01:23:19:656286: GigabitEthernet1/0/1-tx
>
> xxx.79.223.9 -> xxx.79.223.14
>
> 01:23:19:656289: dpdk-input
> GigabitEthernet1/0/1 rx queue 0
> 01:23:19:656290: ip4-input-no-checksum
> 01:23:19:656290: nat44-out2in
> 01:23:19:656290: ip4-lookup
> 01:23:19:656290: ip4-rewrite
> 01:23:19:656290:
Re: [vpp-dev] Configuring NAT and Policing together
Hi,
You can use ip4-policer-classify before NAT node. Add nat44-in2out or
nat44-out2in to ip4_policer_classify runs_before list
VNET_FEATURE_INIT (ip4_policer_classify, static) =
{
.arc_name = "ip4-unicast",
.node_name = "ip4-policer-classify",
.runs_before = VNET_FEATURES ("ipsec4-input-feature", "nat44-in2out",
"nat44-out2in"),
};
NAT code can't continue in feature arc using vnet_feature_next in some cases.
It would be possible to add additional static graph arc from nat node to
ip4-policer-classify and decide on per-packet basis where to send packet since
you don't know at compile time whether policer is configured on interface.
Matus
-Original Message-
From: vpp-dev@lists.fd.io On Behalf Of Raj
Sent: Monday, January 21, 2019 1:00 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Configuring NAT and Policing together
Hello all,
I am trying to configure NAT and VPP run together, but its not working.
My configuration is as follows:
version: vpp v18.10-release built by root on 41f0552eeae3
Interfaces:
GigabitEthernet1/0/0 (up):
L3 100.69.1.1/24
L3 2001:xxx:xxx:600::1/56
GigabitEthernet1/0/1 (up):
L3 xxx.79.223.14/29
L3 2001:xxx:xxx:10d::600/64
Policer config with default route:
configure policer name policy1 cir 500 eir 0 cb 5000 eb 15000 rate kbps round
closest type 1r3c conform-action transmit exceed-action mark-and-transmit AF22
violate-action drop configure policer name policy2 cir 750 eir 0 cb 7500 eb
2 rate kbps round closest type 1r3c conform-action transmit exceed-action
mark-and-transmit AF22 violate-action drop classify table mask l3 ip4 src
classify table mask l3 ip4 dst classify session policer-hit-next policy1
exceed-color table-index 0 match l3 ip4 src 100.69.1.4 classify session
policer-hit-next policy2 exceed-color table-index 1 match l3 ip4 dst 100.69.1.4
set policer classify interface GigabitEthernet1/0/0 ip4-table 0 set policer
classify interface GigabitEthernet1/0/1 ip4-table 1 ip route add 0.0.0.0/0 via
xxx.79.223.9 GigabitEthernet1/0/1 ip route add ::/0 via 2001:xxx::10d::1
GigabitEthernet1/0/1
At this point, if I do a wget at 100.69.1.4 to download from xxx.79.223.9, the
speed is about 1mbps, but ranging from about 1.5mbps to 831kbps
/dev/null 14%[===> ] 75.30M 1.18Mb/s
The packet trace show:
100.69.1.4 -> xxx.79.223.9
01:10:21:269382: dpdk-input
GigabitEthernet1/0/0 rx queue 0
01:10:21:269383: ip4-input-no-checksum
01:10:21:269384: ip4-policer-classify
01:10:21:269384: ip4-lookup
01:10:21:269384: ip4-rewrite
01:10:21:269384: GigabitEthernet1/0/1-output
01:10:21:269385: GigabitEthernet1/0/1-tx
xxx.79.223.9 -> 100.69.1.4
01:10:21:268964: dpdk-input
GigabitEthernet1/0/1 rx queue 0
01:10:21:268970: ip4-input-no-checksum
01:10:21:268973: ip4-policer-classify
01:10:21:268974: ip4-lookup
01:10:21:268975: ip4-rewrite
01:10:21:268976: GigabitEthernet1/0/0-output
01:10:21:268976: GigabitEthernet1/0/0-tx
Now adding NAT using the commands:
nat44 add interface address GigabitEthernet1/0/1 set interface nat44 in
GigabitEthernet1/0/0 out GigabitEthernet1/0/1
Policer stops working at this point.
traces show:
100.69.1.4 -> xxx.79.223.9
01:23:19:656284: dpdk-input
GigabitEthernet1/0/0 rx queue 0
01:23:19:656285: ip4-input-no-checksum
01:23:19:656285: nat44-in2out
01:23:19:656285: ip4-lookup
01:23:19:656286: ip4-rewrite
01:23:19:656286: GigabitEthernet1/0/1-output
01:23:19:656286: GigabitEthernet1/0/1-tx
xxx.79.223.9 -> xxx.79.223.14
01:23:19:656289: dpdk-input
GigabitEthernet1/0/1 rx queue 0
01:23:19:656290: ip4-input-no-checksum
01:23:19:656290: nat44-out2in
01:23:19:656290: ip4-lookup
01:23:19:656290: ip4-rewrite
01:23:19:656290: GigabitEthernet1/0/0-output
01:23:19:656291: GigabitEthernet1/0/0-tx
The traces show that when NAT is enabled, policer nodes are not getting
traversed.
Ideally 100.69.1.4 -> xxx.79.223.9 should have ip4-input-no-checksum
-> ip4-policer-classify -> nat44-in2out -> ip4-lookup and xxx.79.223.9
-> 100.69.1.4 should have ip4-input-no-checksum -> nat44-in2out ->
ip4-policer-classify -> ip4-lookup
Is such a configuration possible? How can I configure VPP for it? Is there any
incompatibility between NAT and Policer?
Thanks and Regards,
Raj
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11964): https://lists.fd.io/g/vpp-dev/message/11964
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]
-=-=-=-=-=-=-=-=-=-=-=-
