Thanks, Ole, your patch works! May consider how to implement an optimized one. 
:-) 

BTW. I'm curious why it is IPv4 fragmentation error, not reassembly. 
From the trace, looks like dpdk-input node receives two fragmented packets, 
then try to reassemble them, then fail. Is my understanding not right? Thanks. 

-----Original Message-----
From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Ole Troan
Sent: Monday, August 06, 2018 4:35 PM
To: Ni, Hongjun <hongjun...@intel.com>
Cc: vpp-dev <vpp-dev@lists.fd.io>; Hu, Xuekun <xuekun...@intel.com>
Subject: Re: [vpp-dev] IP reassembly doesn't work in VPP 18.07

Looks to me like it’s IPv4 fragmentation that fails, not reassembly.
Currently fragmentation on buffer chains isn’t supported.
Try this patch for an ugly hack: https://gerrit.fd.io/r/#/c/13918/

Cheers,
Ole

> On 6 Aug 2018, at 08:34, Ni, Hongjun <hongjun...@intel.com> wrote:
> 
> Hi all,
>  
> We performed below test on VPP 18.07, and it seems that IP reassembly doesn't 
> work in VPP 18.07.
>  
> Below is the test topology:
> Machine A is the VPP DUT, while machine B is just a standard Linux server.
> Network topology: Machine A (VPP) <----> Machine B ; And set both MTU 
> to 1500
> Issue: “ping A_ip -s 2000” at B doesn’t get reply from A; While from VPP (A), 
> “ping B_ip size 1900” does.
>  
> Could you help to take a look at this issue?  Thanks a lot.
>  
> Below is the configuration and packet trace:
> VPP CLI: 
>               set interface state TenGigabitEthernetaf/0/1 up
>               set interface ip address TenGigabitEthernetaf/0/1 
> 10.1.1.2/24 set interface mtu 1500 TenGigabitEthernetaf/0/1 set 
> interface reassembly TenGigabitEthernetaf/0/1 on vpp# show errors
>      314                ip4-frag                malformed packet
> Vpp# show trace
> Packet 1
>  
> 00:04:02:492398: dpdk-input
>   TenGigabitEthernetaf/0/1 rx queue 0
>   buffer 0x2556: current data 14, length 1500, free-list 0, clone-count 0, 
> totlen-nifb 0, trace 0x0
>                  ext-hdr-valid
>                  l4-cksum-computed l4-cksum-correct l2-hdr-offset 0
>   PKT MBUF: port 0, nb_segs 1, pkt_len 1514
>     buf_len 2176, data_len 1514, ol_flags 0x180, data_off 128, phys_addr 
> 0x80095600
>     packet_type 0x391 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
>     rss 0x0 fdir.hi 0x0 fdir.lo 0x0
>     Packet Offload Flags
>       PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
>       PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
>     Packet Types
>       RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
>       RTE_PTYPE_L3_IPV4_EXT_UNKNOWN (0x0090) IPv4 packet with or without 
> extension headers
>       RTE_PTYPE_L4_FRAG (0x0300) Fragmented IP packet
>   IP4: 68:05:ca:3a:19:18 -> 3c:fd:fe:a9:cc:ed
>   ICMP: 10.1.1.1 -> 10.1.1.2
>     tos 0x00, ttl 64, length 1500, checksum 0x2eb6
>     fragment id 0x1067, flags MORE_FRAGMENTS
>   ICMP echo_request checksum 0x496a
> 00:04:02:492403: ip4-input-no-checksum
>   ICMP: 10.1.1.1 -> 10.1.1.2
>     tos 0x00, ttl 64, length 1500, checksum 0x2eb6
>     fragment id 0x1067, flags MORE_FRAGMENTS
>   ICMP echo_request checksum 0x496a
> 00:04:02:492406: ip4-reassembly-feature
>   reass id: 1000000118, op id: 0 first bi: 9558, data len: 1480, 
> ip/fragment[0, 1479]
>                                  new range: [0, 1479], off 0, len 1480, bi 
> 9558
>   reass id: 1000000118, op id: 2 first bi: 9558, data len: 2008, 
> ip/fragment[0, 1479]
>                                  finalize reassembly
> 00:04:02:492434: ip4-lookup
>   fib 0 dpo-idx 5 flow hash: 0x00000000
>   ICMP: 10.1.1.1 -> 10.1.1.2
>     tos 0x00, ttl 64, length 2028, checksum 0x4ca6
>     fragment id 0x1067
>   ICMP echo_request checksum 0x496a
> 00:04:02:492435: ip4-local
>     ICMP: 10.1.1.1 -> 10.1.1.2
>       tos 0x00, ttl 64, length 2028, checksum 0x4ca6
>       fragment id 0x1067
>     ICMP echo_request checksum 0x496a
> 00:04:02:492436: ip4-icmp-input
>   ICMP: 10.1.1.1 -> 10.1.1.2
>     tos 0x00, ttl 64, length 2028, checksum 0x4ca6
>     fragment id 0x1067
>   ICMP echo_request checksum 0x496a
> 00:04:02:492436: ip4-icmp-echo-request
>   ICMP: 10.1.1.1 -> 10.1.1.2
>     tos 0x00, ttl 64, length 2028, checksum 0x4ca6
>     fragment id 0x1067
>   ICMP echo_request checksum 0x496a
> 00:04:02:492436: ip4-load-balance
>   fib 0 dpo-idx 13 flow hash: 0x00000000
>   ICMP: 10.1.1.2 -> 10.1.1.1
>     tos 0x00, ttl 64, length 2028, checksum 0x2d49
>     fragment id 0x2fc4
>   ICMP echo_reply checksum 0x516a
> 00:04:02:492436: ip4-rewrite
>   tx_sw_if_index 0 dpo-idx 1 : ipv4 via 10.1.1.1 TenGigabitEthernetaf/0/1: 
> mtu:1500 6805ca3a19183cfdfea9cced0800 flow hash: 0x05dc0000
>   00000000: 450007ec2fc4000040012d490a0101020a0101010000516a3ef600723f805a48
>   00000020: 00000000bd7c0c0000000000101112131415161718191a1b1c1d1e1f
> 00:04:02:492436: ip4-frag
>   IPv4 offset: 0 mtu: 1500 fragments: 1
> 00:04:02:492437: ip4-drop
>     ICMP: 10.1.1.2 -> 10.1.1.1
>       tos 0x00, ttl 64, length 2028, checksum 0x2d49
>       fragment id 0x2fc4
>     ICMP echo_reply checksum 0x516a
> 00:04:02:492437: error-drop
>   ip4-frag: malformed packet
>  
> Thanks,
> Hongjun
>  
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#10040): 
> https://lists.fd.io/g/vpp-dev/message/10040
> Mute This Topic: https://lists.fd.io/mt/24206662/675193
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
> [otr...@employees.org]
> -=-=-=-=-=-=-=-=-=-=-=-

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10044): https://lists.fd.io/g/vpp-dev/message/10044
Mute This Topic: https://lists.fd.io/mt/24206662/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to