Hi Ben:
This is my tcpdump result and the userspace datapath cache flow:
Note: the icmp reply got by ovs bridge should have 4 bytes CRC
09:42:40.883012 fa:16:3e:6c:07:83 > 00:00:0c:9f:f3:ae, ethertype IPv4 (0x0800),
length 98: (tos 0x0, ttl 63, id 7119, offset 0, flags [DF], proto ICMP (1),
length 84)
192.168.1.7 > 10.142.174.254: ICMP echo request, id 2604, seq 116, length 64
0x0000: 0000 0c9f f3ae fa16 3e6c 0783 0800 4500
0x0010: 0054 1bcf 4000 3f01 a49e c0a8 0107 0a8e
0x0020: aefe 0800 40d1 0a2c 0074 0fde 9f5d 0000
0x0030: 0000 3c80 0200 0000 0000 1011 1213 1415
0x0040: 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425
0x0050: 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435
0x0060: 3637
09:42:40.883683 fa:16:3e:0e:d1:15 > fa:16:3e:53:dd:68, ethertype IPv4 (0x0800),
length 102: (tos 0x0, ttl 254, id 7119, offset 0, flags [DF], proto ICMP (1),
length 84)
10.142.174.254 > 192.168.1.7: ICMP echo reply, id 2604, seq 116, length 64
0x0000: fa16 3e53 dd68 fa16 3e0e d115 0800 4500
0x0010: 0054 1bcf 4000 fe01 e59d 0a8e aefe c0a8
0x0020: 0107 0000 48d1 0a2c 0074 0fde 9f5d 0000
0x0030: 0000 3c80 0200 0000 0000 1011 1213 1415
0x0040: 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425
0x0050: 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435
0x0060: 3637 01a0 af78
tunnel(tun_id=0x5,src=10.142.18.11,dst=10.142.18.12,geneve({class=0x102,type=0x80,len=4,0xd30003/0x7fffffff}),flags(-df+csum+key)),rec
irc_id(0),in_port(15),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=1,frag=no),icmp(type=0),
packets:41, bytes:4182, used:0.380s,
actions:ct(zone=4),recirc(0x37)
tunnel(tun_id=0x5,src=10.142.18.11,dst=10.142.18.12,geneve({}),flags(-df+csum+key)),ct_state(+inv+trk),recirc_id(0x37),in_port(15),pac
ket_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no), packets:211, bytes:21522,
used:0.342s, actions:drop
Re: Re：[ovs-discuss] [HELP] Question about icmp pkt marked Invalid by userspace
conntrack
On October 10, 2019 5:57:58 PM PDT, txfh2007 <[email protected]> wrote:Hi Ben:
I just found the GCC_UNALIGNED_ACCESSORS error during gdb trace and not
sure this is a misaligned error or others. What I can confirm is during
"extract_l4" of this icmp reply packet, when we do "check_l4_icmp", the
unaligned error emits and the "extract_l4" returned false. So this packet be
marked as ct_state=invalid.
Thank you for your help.
Timo
Topic：Re: [ovs-discuss] [HELP] Question about icmp pkt marked Invalid by
userspace conntrack
It's very surprising.
Are you using a RISC architecture that insists on aligned accesses? On
the other hand, if you are using x86-64 or some other architecture that
ordinarily does not care, are you sure that this is about a misaligned
access (it is more likely to simply be a bad pointer)?
On Thu, Oct 10, 2019 at 10:50:33PM +0800, txfh2007 via discuss wrote:
>
Hi all:
I was using OVS-DPDK(version 2.10-1), and I have found pinging between two
VMs on different compute nodes failed. I have checked my env and found there is
one node's NIC cannot strip CRC of a frame, the other node's NIC is normal(I
mean it can strip CRC ). And the reason of ping fail is the icmp reply pkt
(from node whose NIC cannot strip CRC) is marked as invalid . So the icmp
request From Node A is 64 bytes， but the icmp reply From Node B is 68
bytes(with 4 bytes CRC). And when doing "check_l4_icmp", when we call csum
task(in lib/csum.c). Gcc emits unaligned accessor error. The backtrace is as
below:
I just want to confirm if this phenomenon is reasonable?
Many thanks
Timo
get_unaligned_be16 (p=0x7f2ad0b1ed5c) at lib/unaligned.h:89
89 GCC_UNALIGNED_ACCESSORS(ovs_be16, be16);
(gdb) bt
#0 get_unaligned_be16 (p=0x7f2ad0b1ed5c) at lib/unaligned.h:89
#1 0x000000000075a584 in csum_continue (partial=0, data_=0x7f2ad0b1ed5c, n=68)
at lib/csum.c:46
#2 0x000000000075a552 in csum (data=0x7f2ad0b1ed5c, n=68) at lib/csum.c:33
#3 0x00000000008ddf18 in check_l4_icmp (data=0x7f2ad0b1ed5c, size=68,
validate_checksum=true) at lib/conntrack.c:1638
#4 0x00000000008de650 in extract_l4 (key=0x7f32a20df120, data=0x7f2ad0b1ed5c,
size=68, related=0x7f32a20df15d, l3=0x7f2ad0b1ed48,
validate_checksum=true) at lib/conntrack.c:1888
#5 0x00000000008de90d in conn_key_extract (ct=0x7f32b42a2d98,
pkt=0x7f2ad0b1e9c0, dl_type=8, ctx=0x7f32a20df120, zone=4)
at lib/conntrack.c:1973
#6 0x00000000008dd49c in conntrack_execute (ct=0x7f32b42a2d98,
pkt_batch=0x7f32a20e08b0, dl_type=8, force=false, commit=false,
zone=4, setmark=0x0, setlabel=0x0, tp_src=0, tp_dst=0, helper=0x0,
nat_action_info=0x0, now=5395897849) at lib/conntrack.c:1318
#7 0x000000000076d651 in dp_execute_cb (aux_=0x7f32a20dfb00,
packets_=0x7f32a20e08b0, a=0x7f32a20e0ac8, should_steal=false)
at lib/dpif-netdev.c:6711
#8 0x00000000007b2d49 in odp_execute_actions (dp=0x7f32a20dfb00,
batch=0x7f32a20e08b0, steal=true, actions=0x7f32a20e0ac8,
actions_len=20, dp_execute_action=0x76ca60 <dp_execute_cb>) at
lib/odp-execute.c:726
#9 0x000000000076d71b in dp_netdev_execute_actions (pmd=0x7f2a6e1ce010,
packets=0x7f32a20e08b0, should_steal=true,
flow=0x7f32a20dfb60, actions=0x7f32a20e0ac8, actions_len=20) at
lib/dpif-netdev.c:6754
#10 0x000000000076b900 in handle_packet_upcall (pmd=0x7f2a6e1ce010,
packet=0x7f2ad0b1e9c0, key=0x7f32a20e1100,
actions=0x7f32a20e0a40, put_actions=0x7f32a20e0a80) at
lib/dpif-netdev.c:6056
#11 0x000000000076bdf0 in fast_path_processing (pmd=0x7f2a6e1ce010,
packets_=0x7f32a20e2b60, keys=0x7f32a20e10c0,
batches=0x7f32a20e0f90, n_batches=0x7f32a20e13c0, in_port=15) at
lib/dpif-netdev.c:6153
#12 0x000000000076c3df in dp_netdev_input__ (pmd=0x7f2a6e1ce010,
packets=0x7f32a20e2b60, md_is_valid=true, port_no=0)
at lib/dpif-netdev.c:6230
#13 0x000000000076c4d4 in dp_netdev_recirculate (pmd=0x7f2a6e1ce010,
packets=0x7f32a20e2b60) at lib/dpif-netdev.c:6265
#14 0x000000000076ceae in dp_execute_cb (aux_=0x7f32a20e1db0,
packets_=0x7f32a20e2b60, a=0x7f32a20e2d78, should_steal=true) discuss mailing
list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Ok. Is there a particular packet we can use to reproduce it?
_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
