Hi, See my reply in line. Thanks.
Br, Wangzhike -----邮件原件----- 发件人: Darrell Ball [mailto:[email protected]] 发送时间: 2017年6月1日 3:29 收件人: 王志克; Ben Pfaff; Darrell Ball 抄送: [email protected] 主题: Re: 答复: 答复: [ovs-dev] Query for missing function On 5/26/17, 6:24 PM, "王志克" <[email protected]> wrote: Hi Darrell, I indeed observed IP fragment scenario in our other product deployment, and resulted some critical issue. Then I am wondering how to handle it in OVS+DPDK alternative solution. [Darrell] I am not sure what critical means here; it varies widely based on several considerations. Maybe you just describe what the situation was and what happened. Let me ask a few questions to draw that out. Q1) Was that “other deployment” using kernel datapath and experienced a transient input of fragmented traffic from a Vxlan tunnel that the kernel could not handle due to lower throughput for fragmented traffic and/or kernel fragmentation thresholds used and ended up dropping those packets (possibly retried with delay) ? Or something else ? [Wangzhike] I observed Linux kernel panic when handling IP fragmented packets both from OVS and general IP stack, like Vxlan tunnel packets and the overlay packets are both fragmented. I am preparing patch for that. Q2) Was the transient input of fragmented packets an intentional hack used to trash other traffic or just network misconfiguration or you have no clue ? [Wangzhike] I believe it is kind of attack. Lots of uncompleted IP fragments were received. Typical cases are: 1) VxLan segmented packet reaches Vswitch and need to pop the VxLan header for further handling. In kernel OVS, normally Linux kernel will reassemble it before sending to OVS module. Since this happens in real world, we need to handle it though the possibility of happening is quite low. [Darrell] It is possible that fragmented packets arrive from a Vxlan tunnel – that is obvious. 2) Segmented packets go through conntrack. In kernel OVS, it will reuse Kernel reassembly function to make reassembled packet go through conntrack. [Darrell] “2” is not a use case; it is simply a statement of what the kernel does when faced with fragmented packets, which is the topic of this thread. [Wangzhike] Let me revise it. We set some rule on OVS DPDK conntrack, and one VM app sends large packet (eg 9600 size while MTU is 1500). In this case, fragmented packet will reach OVS conntrack. We hope such packet can be handled as kernel ovs behavior(able to be reassembled before really go through conntrack) instead of tagging as INV state. FYI, there are several configuration parameters that determine the actual behavior obtained. The effective behavior could even be that the kernel drops all these fragments. Above cases really happen in current product deployment, and we want to keep it work when migrating to OVS+DPDK solution. Br, Wang Zhike -----邮件原件----- 发件人: Darrell Ball [mailto:[email protected]] 发送时间: 2017年5月27日 2:45 收件人: 王志克; Ben Pfaff; Darrell Ball 抄送: [email protected] 主题: Re: 答复: [ovs-dev] Query for missing function On 5/26/17, 2:00 AM, "王志克" <[email protected]> wrote: Hi Darrell, Ben, Thanks for your reply. Glad to hear that we are approaching useful candidate patch. What is the plan for disassemble and fragment for OVS+DPDK? Like 1, received underlay vxlan fragmented packets, 2, received overlay fragmented packets that will go through conntrack 3, output packet with size > out_port_mtu IP frag. is still on the radar: I have a large dataset of information regarding IP frag usage from a widely distributed virtualization product. However, I would like know your usage requirements for IP frag ? Do you want it for feature parity reasons with the kernel or does it solve some problems you are facing; can you explain your specific needs ? Br, Wang zhike -----邮件原件----- 发件人: Darrell Ball [mailto:[email protected]] 发送时间: 2017年5月26日 9:45 收件人: Ben Pfaff; 王志克; Darrell Ball 抄送: [email protected] 主题: Re: [ovs-dev] Query for missing function On 5/25/17, 2:04 PM, "[email protected] on behalf of Ben Pfaff" <[email protected] on behalf of [email protected]> wrote: On Wed, May 24, 2017 at 12:48:24PM +0000, 王志克 wrote: > Reading the release note of DPDK section for OVS2.6, I note below: > > * Basic connection tracking for the userspace datapath (no ALG, > fragmentation or NAT support yet) > > I am wondering for the missing part (no ALG, fragmentation, NAT), can > I have the release plan for such feature? Or is there draft version > for trial? I think that Darrell (CCed) is working on that for OVS 2.8. He has posted patches before. I expect to see a revision of it pretty soon. NAT patches have been out for a while and a minor reversion will come out next week along with a separate series for ftp alg support. The NAT patches have been tested by a couple other folks, externally and internally, as well. _______________________________________________ dev mailing list [email protected] https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=ZRe75F1jCPHXw_hLBQYBvV3rHd7_FN64hTeQsi0j3Xo&s=x1M4K22nb1JiegFLUNqxxap71zeRqVZbTdeWk86BPD4&e= _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
