Here is the CSIT sequence that always leads to the problem (based on baseline IPv4 test case): 1. Construct VPP startup configuration: 1T1C with 2p 1nic based on actual topology, Intel x520-da2 2. Apply configuration by writing to /etc/vpp/startup.conf file 3. Restart the vpp service: service vpp stop, service vpp start 4. Configure IPv4: 'sw_interface_set_flags sw_if_index 2 admin-up' 'sw_interface_set_flags sw_if_index 1 admin-up' 'ip_neighbor_add_del sw_if_index 2 dst 10.10.10.2 mac 3c:fd:fe:9c:ee:a0' 'ip_neighbor_add_del sw_if_index 1 dst 1.1.1.2 mac 90:e2:ba:b5:05:e5' 'sw_interface_add_del_address sw_if_index 2 10.10.10.1/24' 'sw_interface_add_del_address sw_if_index 1 1.1.1.1/30' 'ip_add_del_route 20.20.20.0/24 via 1.1.1.2 sw_if_index 1 resolve-attempts 10 count 1' 'sw_interface_dump' 'sw_interface_dump' 'sw_interface_dump ' 5. Ask TRex to find NDR 6. Measure clock cycle per VPP node at NDR by sequence: a. start traffic at NDR rate b. 'clear run' vpp PID=642 crashes, see vpe.log vpp_api_test PID=1065 hangs c. 'show run' d. stop traffic 7. continue in test evaluation Steps 1-5 are OK. Step 6.b. seem to result in vpp crash that clears all the configuration. Attached file outputs, backtraces for vpp_api_test seem to be more verbose after your patch: 1) ps -ef 2) vpp_api_test PID - gdb data structures prints (PID=1065) 3) vpp_api_test PID - gdb data structures prints (PID=1142) 4) vpp PID - gdb data structures prints 5) $ cat /tmp/vpe.log 6) $ cat /tmp/vpp.log