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
