Hi, Neale.
I have tested the fix, the crash can not be reproduced any more.
BR/Lollita Liu
From: Neale Ranns (nranns) <nra...@cisco.com>
Sent: Friday, March 8, 2019 8:22 PM
To: Lollita Liu <lollita....@ericsson.com>; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP crash when deleting route related with GTPU tunnel
endpoint
Hi Lolita,
I have reproduced this issue and this is the resulting fix:
https://gerrit.fd.io/r/#/c/18138/
could you please also verify it fixes all your test cases.
Thanks,
Neale
De : Lollita Liu <lollita....@ericsson.com<mailto:lollita....@ericsson.com>>
Date : jeudi 7 mars 2019 à 03:52
À : "Neale Ranns (nranns)" <nra...@cisco.com<mailto:nra...@cisco.com>>,
"vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>"
<vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>
Objet : RE: [vpp-dev] VPP crash when deleting route related with GTPU tunnel
endpoint
Hi，Neale.
Sorry that I have do the test on my own branch yesterday.
I have retry the test on main with “* master f940f8a
[origin/master] session: use transport custom tx for app transports”
And try the test on vxlan and gtp, it is reproduced. Please check the backtrace.
DBGvpp# ip route del 0.0.0.0/0 via 18.1.0.1
Thread 1 "lollita_main" received signal SIGSEGV, Segmentation fault.
0x00007ffff75a4e1e in fib_entry_src_covered_inherit_add
(fib_entry=0x7ffdf5cd352c, source=FIB_SOURCE_RR)
at /home/vppshare/lollita/vpp-gerrit/vpp/src/vnet/fib/fib_entry_src.c:951
/home/vppshare/lollita/vpp-gerrit/vpp/src/vnet/fib/fib_entry_src.c:951:27449:beg:0x7ffff75a4e1e
(gdb) bt
#0 0x00007ffff75a4e1e in fib_entry_src_covered_inherit_add
(fib_entry=0x7ffdf5cd352c, source=FIB_SOURCE_RR)
at /home/vppshare/lollita/vpp-gerrit/vpp/src/vnet/fib/fib_entry_src.c:951
#1 0x00007ffff75a56b0 in fib_entry_src_action_reactivate
(fib_entry=0x7ffdf5cd352c, source=FIB_SOURCE_RR)
at /home/vppshare/lollita/vpp-gerrit/vpp/src/vnet/fib/fib_entry_src.c:1168
#2 0x00007ffff759befd in fib_entry_cover_updated (fib_entry_index=16) at
/home/vppshare/lollita/vpp-gerrit/vpp/src/vnet/fib/fib_entry.c:1375
#3 0x00007ffff75ac121 in fib_entry_cover_update_one (cover=0x7ffdf5cd30ac,
covered=16, args=0x0)
at /home/vppshare/lollita/vpp-gerrit/vpp/src/vnet/fib/fib_entry_cover.c:168
#4 0x00007ffff75abf53 in fib_entry_cover_walk_node_ptr (depend=0x7ffdf5949e9c,
args=0x7ffdf5c007c0)
at /home/vppshare/lollita/vpp-gerrit/vpp/src/vnet/fib/fib_entry_cover.c:80
#5 0x00007ffff7597782 in fib_node_list_walk (list=28, fn=0x7ffff75abf09
<fib_entry_cover_walk_node_ptr>, args=0x7ffdf5c007c0)
at /home/vppshare/lollita/vpp-gerrit/vpp/src/vnet/fib/fib_node_list.c:375
#6 0x00007ffff75abfde in fib_entry_cover_walk (cover=0x7ffdf5cd30ac,
walk=0x7ffff75ac0f5 <fib_entry_cover_update_one>, args=0x0)
at /home/vppshare/lollita/vpp-gerrit/vpp/src/vnet/fib/fib_entry_cover.c:104
#7 0x00007ffff75ac16f in fib_entry_cover_update_notify
(fib_entry=0x7ffdf5cd30ac)
at /home/vppshare/lollita/vpp-gerrit/vpp/src/vnet/fib/fib_entry_cover.c:177
#8 0x00007ffff759ac7b in fib_entry_post_update_actions
(fib_entry=0x7ffdf5cd30ac, source=FIB_SOURCE_DEFAULT_ROUTE,
old_flags=FIB_ENTRY_FLAG_NONE)
at /home/vppshare/lollita/vpp-gerrit/vpp/src/vnet/fib/fib_entry.c:798
#9 0x00007ffff759b46b in fib_entry_source_removed (fib_entry=0x7ffdf5cd30ac,
old_flags=FIB_ENTRY_FLAG_NONE)
at /home/vppshare/lollita/vpp-gerrit/vpp/src/vnet/fib/fib_entry.c:989
#10 0x00007ffff759b6c0 in fib_entry_path_remove (fib_entry_index=0,
source=FIB_SOURCE_CLI, rpath=0x7ffdf6c1a7bc)
at /home/vppshare/lollita/vpp-gerrit/vpp/src/vnet/fib/fib_entry.c:1072
#11 0x00007ffff7585246 in fib_table_entry_path_remove2 (fib_index=0,
prefix=0x7ffdf5c00ab0, source=FIB_SOURCE_CLI, rpath=0x7ffdf6c1a7bc)
at /home/vppshare/lollita/vpp-gerrit/vpp/src/vnet/fib/fib_table.c:652
#12 0x00007ffff6f59f8e in vnet_ip_route_cmd (vm=0x7ffff6801240
<vlib_global_main>, main_input=0x7ffdf5c00ee0, cmd=0x7ffdf5bafc7c)
at /home/vppshare/lollita/vpp-gerrit/vpp/src/vnet/ip/lookup.c:463
#13 0x00007ffff6533abf in vlib_cli_dispatch_sub_commands (vm=0x7ffff6801240
<vlib_global_main>, cm=0x7ffff6801440 <vlib_global_main+512>,
input=0x7ffdf5c00ee0, parent_command_index=45) at
/home/vppshare/lollita/vpp-gerrit/vpp/src/vlib/cli.c:607
#14 0x00007ffff653396a in vlib_cli_dispatch_sub_commands (vm=0x7ffff6801240
<vlib_global_main>, cm=0x7ffff6801440 <vlib_global_main+512>,
input=0x7ffdf5c00ee0, parent_command_index=0) at
/home/vppshare/lollita/vpp-gerrit/vpp/src/vlib/cli.c:568
#15 0x00007ffff6533eec in vlib_cli_input (vm=0x7ffff6801240 <vlib_global_main>,
input=0x7ffdf5c00ee0, function=0x7ffff65c22fc <unix_vlib_cli_output>,
function_arg=0) at /home/vppshare/lollita/vpp-gerrit/vpp/src/vlib/cli.c:707
#16 0x00007ffff65c7e7f in unix_cli_process_input (cm=0x7ffff6801ac0
<unix_cli_main>, cli_file_index=0)
at /home/vppshare/lollita/vpp-gerrit/vpp/src/vlib/unix/cli.c:2420
#17 0x00007ffff65c8a40 in unix_cli_process (vm=0x7ffff6801240
<vlib_global_main>, rt=0x7ffdf5bf0000, f=0x0)
at /home/vppshare/lollita/vpp-gerrit/vpp/src/vlib/unix/cli.c:2536
#18 0x00007ffff6572a9d in vlib_process_bootstrap (_a=140728715966800) at
/home/vppshare/lollita/vpp-gerrit/vpp/src/vlib/main.c:1463
#19 0x00007ffff60277dc in clib_calljmp () from
/home/vppshare/lollita/vpp-gerrit/vpp/build-root/install-vpp_debug-native/vpp/lib/libvppinfra.so.19.04
#20 0x00007ffdf51ff920 in ?? ()
#21 0x00007ffff6572bc8 in vlib_process_startup (vm=0x8, p=0x7ffdf51ff960,
f=0x7ffff65c02aa <vlib_process_signal_event_data+506>)
---Type <return> to continue, or q <return> to quit---
at /home/vppshare/lollita/vpp-gerrit/vpp/src/vlib/main.c:1485
Also attach configuration here for your favor.
1 set interface state eth0 up
2 set interface mtu 1500 eth0
3
4 create sub-interfaces eth0 181
5 set interface state eth0.181 up
6 set interface ip address eth0.181 18.1.0.31/24
7
8 create sub-interfaces eth0 182
9 set interface state eth0.182 up
10 set interface ip address eth0.182 18.2.0.31/24
11
12 ip route 0.0.0.0/0 via 18.1.0.1
Create gtp tunnel via
create gtpu tunnel src 1.1.1.1 dst 1.1.1.4 teid 1
Create vxlan tunnel via
create vxlan tunnel src 1.1.1.1 dst 1.1.14 vni 1
BR/Lollita Liu
From: Neale Ranns (nranns) <nra...@cisco.com<mailto:nra...@cisco.com>>
Sent: Wednesday, March 6, 2019 9:02 PM
To: Lollita Liu <lollita....@ericsson.com<mailto:lollita....@ericsson.com>>;
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] VPP crash when deleting route related with GTPU tunnel
endpoint
Hi lolita,
What GTPU code are you running. Your test case does not work for me on master:
DBGvpp# create gtpu tunnel src 1.1.1.1 dst 1.1.1.4 teid-in 3 teid-out 4
create gtpu tunnel: parse error: 'teid-in 3 teid-out 4'
to answer your questions:
1) You should be able to delete the default route even though it is used to
reach the tunnel destination. You don’t provide a backtrace, but I suspect the
GTPU code does not restack the tunnel correctly.
2) It established the child dependency (i.e. build edges in a graph). In
this case the tunnel depends on the route it uses to reach the destintion.
/neale
De : <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> au nom de lollita
<lollita....@ericsson.com<mailto:lollita....@ericsson.com>>
Date : mercredi 6 mars 2019 à 11:50
À : "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>"
<vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>
Objet : [vpp-dev] VPP crash when deleting route related with GTPU tunnel
endpoint
Hi,
I’m checking the implementation of GTPU performance enhancement with
bypass ip-lookup after gtpu_encap.
I started up a VPP with hardware interface configuration only, and do following
configuration:
ip route add 0.0.0.0/0 via 18.1.0.1
create gtpu tunnel src 1.1.1.1 dst 1.1.1.4 teid-in 3 teid-out 4
ip route add 1.2.3.4/32 via gtpu_tunnel0
A host route created:
17@1.1.1.4/32<mailto:17@1.1.1.4/32>
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:18 buckets:1 uRPF:20 to:[2:72]]
[0] [@12]: dpo-load-balance: [proto:ip4 index:16 buckets:1 uRPF:8 to:[0:0]
via:[270:17056]]
[0] [@5]: ipv4 via 18.1.0.1 eth0.181: mtu:9000
0004969829b40209c0d2bbc3810000b50800
And the packet to 1.2.3.4 will be encapsulated via GTP and send to
ip4-load-balance directly.
Then I do another test,
ip route add 0.0.0.0/0 via 18.1.0.1
create gtpu tunnel src 1.1.1.1 dst 1.1.1.4 teid-in 3 teid-out 4
ip route del 0.0.0.0/0 via 18.1.0.1
VPP crashed when deleting the default route, both on debug and release version.
I think it is a bug.
I did same test on VXLAN, and it also crashed.
I assume the relation between default route and route to 1.1.1.4 is established
via below code in vnet_gtpu_add_del_tunnel.
t->sibling_index = fib_entry_child_add
(t->fib_entry_index, gtm->fib_node_type, t - gtm->tunnels);
I uncommented the two lines, but vpp still crashed.
In summary, my question is :
1、 Is it a bug of the crash when deleting default route in that scenario?
2、 What is the usage of fib_entry_child_add related code?
BR/Lollita Liu
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12478): https://lists.fd.io/g/vpp-dev/message/12478
Mute This Topic: https://lists.fd.io/mt/30283902/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
