[Edited Message Follows] Hi all,
I'm currently porting a plugin from v18.01 to v19.08 and having an issue with
VPP pcap functionality in the newer version. The plugin has added the following
node (ip4-mac-output) to the ip4-output feature arc and when it's enabled I see
duplicate packets when taking a tx pcap via vppctl (so two identical SYNs,
SYN/ACKs, etc.):
VNET_FEATURE_INIT (ip4_mac_output, static) =
{
.arc_name = "ip4-output",
.node_name = "ip4-mac-output",
.runs_before = 0,
};
VLIB_REGISTER_NODE (ip4_mac_output_node) =
{
.function = ip4_mac_output,
.name = "ip4-mac-output",
.vector_size = sizeof (u32),
.type = VLIB_NODE_TYPE_INTERNAL,
.n_errors = ARRAY_LEN(mac_error_strings),
.error_strings = mac_error_strings,
.n_next_nodes = MAC_OUTPUT_N_NEXT,
.next_nodes = {
[MAC_OUTPUT_NEXT_INTERFACE_OUTPUT] = "interface-output",
[MAC_OUTPUT_NEXT_DROP] = "error-drop",
},
};
The node receives a packet and always directs it to 'interface-output' unless
in error case. I have tested this with all business logic removed from the
node, so the issue doesn't appear related to what the node does, rather the
position of the node in the packet processing graph. When I disable this node,
the tx pcaps do not show the duplicate packets.
I added some breakpoints to see when the interface-output node was getting
called and packets getting added to pcap file. With the plugin node
(ip4-mac-output) disabled I see *vnet_interface_pcap_tx_trace* called once, but
with ip4-mac-output enabled I see it called twice.
*TRACE 1*
Breakpoint 2, vnet_interface_pcap_tx_trace (sw_if_index_from_buffer=1,
frame=<optimized out>, node=<optimized out>, vm=0x2b5b3994c580)
at
/bfs-build/build-area.42/builds/LinuxNBngp_mainline_RH7/2020-07-02-0858/third-party/vpp/vpp_1908/src/vnet/interface_output.c:844
844 pcap_add_buffer_to_mul_file
(&vlib_global_main.owm_pcap[OWM_VLIB_TX].pcap_main, vm, bi0,
vlib_global_main.pktfilter.snaplen,
&vlib_global_main.owm_pcap[OWM_VLIB_TX].pcap_enable);
(gdb) bt
#0 *vnet_interface_pcap_tx_trace* (sw_if_index_from_buffer=1, frame=<optimized
out>, node=<optimized out>, vm=0x2b5b3994c580)
at
/bfs-build/build-area.42/builds/LinuxNBngp_mainline_RH7/2020-07-02-0858/third-party/vpp/vpp_1908/src/vnet/interface_output.c:844
#1 vnet_per_buffer_interface_output_node_fn_avx2 (vm=0x2b5b3994c580,
node=<optimized out>, frame=<optimized out>)
at
/bfs-build/build-area.42/builds/LinuxNBngp_mainline_RH7/2020-07-02-0858/third-party/vpp/vpp_1908/src/vnet/interface_output.c:940
#2 0x00002b5b31858eeb in dispatch_node (last_time_stamp=<optimized out>,
frame=0x2b5bbccd9680, dispatch_state=VLIB_NODE_STATE_POLLING,
type=VLIB_NODE_TYPE_INTERNAL, node=0x2b5bbcbf2180, vm=0x2b5b3994c580)
at
/bfs-build/build-area.42/builds/LinuxNBngp_mainline_RH7/2020-07-02-0858/third-party/vpp/vpp_1908/src/vlib/main.c:1302
#3 dispatch_pending_node (vm=vm@entry=0x2b5b3994c580,
pending_frame_index=pending_frame_index@entry=4, last_time_stamp=<optimized
out>)
*TRACE 2*
Breakpoint 2, vnet_interface_pcap_tx_trace (sw_if_index_from_buffer=0,
frame=<optimized out>, node=<optimized out>, vm=<optimized out>)
at
/bfs-build/build-area.42/builds/LinuxNBngp_mainline_RH7/2020-07-02-0858/third-party/vpp/vpp_1908/src/vnet/interface_output.c:844
844 pcap_add_buffer_to_mul_file
(&vlib_global_main.owm_pcap[OWM_VLIB_TX].pcap_main, vm, bi0,
vlib_global_main.pktfilter.snaplen,
&vlib_global_main.owm_pcap[OWM_VLIB_TX].pcap_enable);
(gdb) bt
#0 *vnet_interface_pcap_tx_trace* (sw_if_index_from_buffer=0, frame=<optimized
out>, node=<optimized out>, vm=<optimized out>)
at
/bfs-build/build-area.42/builds/LinuxNBngp_mainline_RH7/2020-07-02-0858/third-party/vpp/vpp_1908/src/vnet/interface_output.c:844
#1 vnet_interface_output_node (vm=<optimized out>, node=<optimized out>,
frame=<optimized out>)
at
/bfs-build/build-area.42/builds/LinuxNBngp_mainline_RH7/2020-07-02-0858/third-party/vpp/vpp_1908/src/vnet/interface_output.c:918
#2 0x00002b5b31858eeb in dispatch_node (last_time_stamp=<optimized out>,
frame=0x2b5bbcbda340, dispatch_state=VLIB_NODE_STATE_POLLING,
type=VLIB_NODE_TYPE_INTERNAL, node=0x2b5bbcbf2800, vm=0x2b5b3994c580)
at
/bfs-build/build-area.42/builds/LinuxNBngp_mainline_RH7/2020-07-02-0858/third-party/vpp/vpp_1908/src/vlib/main.c:1302
#3 dispatch_pending_node (vm=vm@entry=0x2b5b3994c580,
pending_frame_index=pending_frame_index@entry=5, last_time_stamp=<optimized
out>)
at
/bfs-build/build-area.42/builds/LinuxNBngp_mainline_RH7/2020-07-02-0858/third-party/vpp/vpp_1908/src/vlib/main.c:1481
When ip4-mac-output is disabled, I don't see TRACE 1 , I only see TRACE 2. When
ip4-mac-output is enabled, both of these stacks are invoked so packets get
added to the pcap file twice.
I have attached an https pcap with (enabled.pcap) and without (disabled.pcap)
ip4-mac-output node so you can see the duplicate packets. I should add that the
duplicate packets are not seen elsewhere on the network - the client and server
pcaps do not have any duplicate packets so the issue seems confined the the
vppctl pcap utility.
Can anyone suggest why I might be seeing this extra call (and thus duplicate
behaviour in pcap) when the ip4-mac-output node is added to the ip4-output
feature arc? We did not see this behaviour in VPP 18.01.
Any thoughts welcome.
Many thanks,
Gerard
disabled.pcap
Description: Binary data
enabled.pcap
Description: Binary data
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16984): https://lists.fd.io/g/vpp-dev/message/16984 Mute This Topic: https://lists.fd.io/mt/75543730/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
