Hi Stan, If I recall correctly, we update an adjacency only when adding a neighbor. So, I a few clarifying questions to better understand the problem: - From your description am I right to understand that you manage to forward some traffic and only after some time hit the issue? - Could you paste the fib entry that’s being updated (sh ip fib <ip-pref>)? - Are you using VPP’s TCP stack?
Thanks, Florin > On Sep 18, 2017, at 8:19 AM, Ratliff, Stanley <sratl...@idirect.net> wrote: > > Hi, > > I’m getting a SIGSEGV in VPP trying to send a lot of traffic in one direction > via a TCP connection. I’ve enabled the VLIB_BUFFER_TRAJECTORY_TRACE, and I’m > getting this: > > Context trace for bi 28664834 b 0x7fff5cd8bf00, visited 3 > ip4-lookup (238) > ip4-rewrite (230) > ip4-lookup (238) > > Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault. > vlib_increment_combined_counter (byte_increment=1448, packet_increment=1, > index=4294967295, cpu_index=<optimized out>, cm=0x7fffb5bec40c) > at /home/sratliff/vpp/build-data/../src/vlib/counter.h:258 > 258 new_bytes = old_bytes + byte_increment; > (gdb) bt > #0 vlib_increment_combined_counter (byte_increment=1448, packet_increment=1, > index=4294967295, cpu_index=<optimized out>, > cm=0x7fffb5bec40c) at > /home/sratliff/vpp/build-data/../src/vlib/counter.h:258 > #1 vnet_interface_output_node (vm=<optimized out>, node=<optimized out>, > frame=<optimized out>) > at /home/sratliff/vpp/build-data/../src/vnet/interface_output.c:624 > #2 0x00007ffff77567d2 in dispatch_node (vm=0x7ffff79a9240 > <vlib_global_main>, node=0x7fffb591d240, type=<optimized out>, > dispatch_state=VLIB_NODE_STATE_POLLING, frame=<optimized out>, > last_time_stamp=21044750699247852) > at /home/sratliff/vpp/build-data/../src/vlib/main.c:998 > #3 0x00007ffff7756b85 in dispatch_pending_node (vm=vm@entry=0x7ffff79a9240 > <vlib_global_main>, p=0x7fffb6c5a244, > last_time_stamp=<optimized out>) at > /home/sratliff/vpp/build-data/../src/vlib/main.c:1136 > #4 0x00007ffff775732b in vlib_main_loop (vm=0x7ffff79a9240 > <vlib_global_main>) at /home/sratliff/vpp/build-data/../src/vlib/main.c:1545 > #5 vlib_main (vm=vm@entry=0x7ffff79a9240 <vlib_global_main>, > input=input@entry=0x7fffb5e9efa0) > at /home/sratliff/vpp/build-data/../src/vlib/main.c:1681 > #6 0x00007ffff7790373 in thread0 (arg=140737347490368) at > /home/sratliff/vpp/build-data/../src/vlib/unix/main.c:507 > #7 0x00007ffff6a07c40 in clib_calljmp () at > /home/sratliff/vpp/build-data/../src/vppinfra/longjmp.S:110 > #8 0x00007fffffffd4d0 in ?? () > #9 0x00007ffff7790d02 in vlib_unix_main (argc=<optimized out>, > argv=<optimized out>) > at /home/sratliff/vpp/build-data/../src/vlib/unix/main.c:575 > #10 0x0000000000000000 in ?? () > (gdb) > > > I’ve seen a couple of paths on the back-trace – this one, and one in mtrie.h. > It appears that the ip4-lookup sends the packet off to re-write, and the > Ethernet header *is* applied. Then, ip4_rewrite decides to send the packet > back to lookup, and of course, the current_data is pointing at the Ethernet > header, not the IP header. My surmise is that this has something to do with > the adjacency processing. Is there any way to lengthen the amount of time > that an adjacency is seen to be “good”? It looks like traffic is caught in > the timeframe where VPP is ARPing, looking to refresh the adjacency, and this > traffic is misdirected. Or, I could be way out in left field… > > Any pointers would be appreciated. > > Regards, > Stan > This electronic message and any files transmitted with it contains > information from iDirect, which may be privileged, proprietary > and/or confidential. It is intended solely for the use of the individual > or entity to whom they are addressed. If you are not the original > recipient or the person responsible for delivering the email to the > intended recipient, be advised that you have received this email > in error, and that any use, dissemination, forwarding, printing, or > copying of this email is strictly prohibited. If you received this email > in error, please delete it and immediately notify the sender. > _______________________________________________ > vpp-dev mailing list > vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > https://lists.fd.io/mailman/listinfo/vpp-dev > <https://lists.fd.io/mailman/listinfo/vpp-dev>
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
