On 5/31/17, 6:07 PM, "王志克" <[email protected]> wrote:
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.
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:[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
