Hello VPP experts,
There seems to be a problem with "ip mroute add" causing assertion
failure. This happens for the current master branch and the stable/2005
branch, but not for stable/1908 and stable/2001.
Doing the following is enough to see the problem:
create int rdma host-if enp101s0f1 name Interface101
set int ip address Interface101 10.0.0.1/24
ip mroute add 224.0.0.1 via Interface101 Accept
The "ip mroute add" command there then causes an assertion failure.
Backtrace:
Thread 1 "vpp_main" received signal SIGABRT, Aborted.
__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 0x00007ffff4629801 in __GI_abort () at abort.c:79
#2 0x00000000004071a3 in os_panic () at vpp/src/vpp/vnet/main.c:371
#3 0x00007ffff55085b9 in debugger () at vpp/src/vppinfra/error.c:84
#4 0x00007ffff5508337 in _clib_error (how_to_die=2, function_name=0x0,
line_number=0, fmt=0x7ffff76b04b0 "%s:%d (%s) assertion `%s' fails")
at vpp/src/vppinfra/error.c:143
#5 0x00007ffff74d1ed8 in dpo_proto_to_fib (dpo_proto=255) at
vpp/src/vnet/fib/fib_types.c:353
#6 0x00007ffff7504111 in fib_path_attached_get_adj
(path=0x7fffb602cda0, link=255, dpo=0x7fffa6f3c2e8) at
vpp/src/vnet/fib/fib_path.c:721
#7 0x00007ffff75038fa in fib_path_resolve (path_index=15) at
vpp/src/vnet/fib/fib_path.c:1949
#8 0x00007ffff74f6a18 in fib_path_list_paths_add (path_list_index=13,
rpaths=0x7fffb6523b40) at vpp/src/vnet/fib/fib_path_list.c:902
#9 0x00007ffff75c795a in mfib_entry_src_paths_add
(msrc=0x7fffb6527c10, rpaths=0x7fffb6523b40) at
vpp/src/vnet/mfib/mfib_entry.c:754
#10 0x00007ffff75c764e in mfib_entry_path_update (mfib_entry_index=1,
source=MFIB_SOURCE_CLI, rpaths=0x7fffb6523b40) at
vpp/src/vnet/mfib/mfib_entry.c:1009
#11 0x00007ffff75ce98a in mfib_table_entry_paths_update_i (fib_index=0,
prefix=0x7fffa6f3c720, source=MFIB_SOURCE_CLI, rpaths=0x7fffb6523b40)
at vpp/src/vnet/mfib/mfib_table.c:318
#12 0x00007ffff75ce643 in mfib_table_entry_path_update (fib_index=0,
prefix=0x7fffa6f3c720, source=MFIB_SOURCE_CLI, rpath=0x7fffb5ffa330)
at vpp/src/vnet/mfib/mfib_table.c:335
#13 0x00007ffff6f18ce2 in vnet_ip_mroute_cmd (vm=0x7ffff63969c0
<vlib_global_main>, main_input=0x7fffa6f3cf18, cmd=0x7fffb5efced0) at
vpp/src/vnet/ip/lookup.c:819
#14 0x00007ffff6093139 in vlib_cli_dispatch_sub_commands
(vm=0x7ffff63969c0 <vlib_global_main>, cm=0x7ffff6396bf0
<vlib_global_main+560>, input=0x7fffa6f3cf18, parent_command_index=463)
at vpp/src/vlib/cli.c:568
#15 0x00007ffff6092fdd in vlib_cli_dispatch_sub_commands
(vm=0x7ffff63969c0 <vlib_global_main>, cm=0x7ffff6396bf0
<vlib_global_main+560>, input=0x7fffa6f3cf18, parent_command_index=0)
at vpp/src/vlib/cli.c:528
#16 0x00007ffff609218f in vlib_cli_input (vm=0x7ffff63969c0
<vlib_global_main>, input=0x7fffa6f3cf18, function=0x0, function_arg=0)
at vpp/src/vlib/cli.c:667
#17 0x00007ffff616180b in startup_config_process (vm=0x7ffff63969c0
<vlib_global_main>, rt=0x7fffb4a9c480, f=0x0) at
vpp/src/vlib/unix/main.c:366
#18 0x00007ffff60dd704 in vlib_process_bootstrap (_a=140736226945080)
at vpp/src/vlib/main.c:1502
#19 0x00007ffff552c744 in clib_calljmp () at
vpp/src/vppinfra/longjmp.S:123
#20 0x00007fffb4d06830 in ?? ()
#21 0x00007ffff60dd2a2 in vlib_process_startup (vm=0x28800000000,
p=0xcd5b1d5112dc20, f=0xb4d069a0) at vpp/src/vlib/main.c:1524
#22 0x00000030b6523520 in ?? ()
#23 0x000000000000002f in ?? ()
#24 0x00000035b4d429c0 in ?? ()
#25 0x0000000000000034 in ?? ()
#26 0x00007ffff7b775b4 in vlibapi_get_main () at
vpp/src/vlibapi/api_common.h:385
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)
The code at the assertion at fib_types.c:353 looks like this:
fib_protocol_t
dpo_proto_to_fib (dpo_proto_t dpo_proto)
{
switch (dpo_proto)
{
case DPO_PROTO_IP6:
return (FIB_PROTOCOL_IP6);
case DPO_PROTO_IP4:
return (FIB_PROTOCOL_IP4);
case DPO_PROTO_MPLS:
return (FIB_PROTOCOL_MPLS);
default:
break;
}
ASSERT(0); <--- this assertion is triggered
return (0);
}
so apparently dpo_proto does not have any of the allowed values.
Testing earlier commits in the git history pointed to the following
seemingly unrelated and harmless refactoring commit as the point when
this problem started:
30cca512c (build: remove valgrind leftovers, 2019-11-25)
What we are trying to do, which has worked for VPP 19.08, is to enable
receiving of multicast packets on a given interface using two commands
like this:
ip mroute add 224.0.0.1 via Interface101 Accept
ip mroute add 224.0.0.1 via local Forward
but now for the master branch the first of those "ip mroute add" lines
gives the assertion failure.
Has something changed regarding how the "ip mroute add" command is to
be used?
If not, could the assertion failure indicate a bug somewhere?
The problem seems easy to reproduce, at least for me the assertion
happens in the same way every time.
Best regards,
Elias
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#16634): https://lists.fd.io/g/vpp-dev/message/16634
Mute This Topic: https://lists.fd.io/mt/74649468/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
