Hi Darrell, Yes, it is hard to choose a proper value suitable for every network/situation. The network may even change from time to time, so indeed user need be involved for tuning.
So your idea is acceptable. Br, Wangzhike -----邮件原件----- 发件人: Darrell Ball [mailto:db...@vmware.com] 发送时间: 2017年6月1日 11:42 收件人: 王志克; Ben Pfaff; Darrell Ball 抄送: ovs-dev@openvswitch.org 主题: Re: 答复: 答复: 答复: 答复: [ovs-dev] Query for missing function On 5/31/17, 8:06 PM, "王志克" <wangzh...@jd.com> wrote: Hi Darrell, In my opinion, it may be also hard for user to decide "configurable buffer size". Yep, but the user knows their network or situation best. Also I guess the default value should be to enable the fragment support. ( If we give such option, I can imagine most user will enable it, right?) I agree. However, let us say we chose values for the memory thresholds for the user, like Linux. The user thinks “the fragmentation thing is taken care of”. That is likely wrong, maybe they should be thinking more upfront. My suggestion is to use Linux kernel as best practice. That is the stock answer; no doubt. Just my personal thought. Br, Wangzhike -----邮件原件----- 发件人: Darrell Ball [mailto:db...@vmware.com] 发送时间: 2017年6月1日 10:16 收件人: 王志克; Ben Pfaff; Darrell Ball 抄送: ovs-dev@openvswitch.org 主题: Re: 答复: 答复: 答复: [ovs-dev] Query for missing function On 5/31/17, 6:07 PM, "王志克" <wangzh...@jd.com> wrote: Hi, See my reply in line. Thanks. Br, Wangzhike -----邮件原件----- 发件人: Darrell Ball [mailto:db...@vmware.com] 发送时间: 2017年6月1日 3:29 收件人: 王志克; Ben Pfaff; Darrell Ball 抄送: ovs-dev@openvswitch.org 主题: Re: 答复: 答复: [ovs-dev] Query for missing function On 5/26/17, 6:24 PM, "王志克" <wangzh...@jd.com> 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. Yes, fragmentation is good at driving forwarding performance down and/or increasing attack surface. If one has control over the network boundaries, it can be avoided within those boundaries. In other scenarios, the fragments get into a control volume because of others fault, intentional or otherwise. If the fragments are legitimate and in large numbers for long enough, the misconfiguration must be fixed at source because they can’t be handled anyways in software. Fragments in low numbers/less often provide less pressure to fix the misconfiguration, since it is what we can handle with software, assuming they are legitimate. If OVS-DPDK adds support for IP fragmentation, it will be susceptible to the same issues the kernel datapath has. I don’t know of a configurable, non-zero default fragmentation buffer that will work in all unforeseen legitimate cases. Bigger fragmentation buffers are more susceptible to exploits. A zero default configurable buffer size seems most clear and then let the user decide how much “IP Fragmentation” they want. Thoughts ? 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:db...@vmware.com] 发送时间: 2017年5月27日 2:45 收件人: 王志克; Ben Pfaff; Darrell Ball 抄送: ovs-dev@openvswitch.org 主题: Re: 答复: [ovs-dev] Query for missing function On 5/26/17, 2:00 AM, "王志克" <wangzh...@jd.com> 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:db...@vmware.com] 发送时间: 2017年5月26日 9:45 收件人: Ben Pfaff; 王志克; Darrell Ball 抄送: ovs-dev@openvswitch.org 主题: Re: [ovs-dev] Query for missing function On 5/25/17, 2:04 PM, "ovs-dev-boun...@openvswitch.org on behalf of Ben Pfaff" <ovs-dev-boun...@openvswitch.org on behalf of b...@ovn.org> 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 d...@openvswitch.org 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 d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
