On Wed, Feb 6, 2019 at 11:05 AM Matus Fabian -X (matfabia - PANTHEON
TECHNOLOGIES at Cisco) <matfa...@cisco.com> 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 = 0x7ffff66dcf88 <null_node_fn>, 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 = 0x7ffff6ccb857 <ip4_policer_classify>, 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]
-=-=-=-=-=-=-=-=-=-=-=-
