[ovs-discuss] OVS-DPDK IP fragmentation require

Hui Xiang xianghuir at gmail.com
Fri Jul 28 06:31:42 UTC 2017


On Fri, Jul 28, 2017 at 12:52 PM, Darrell Ball <dball at vmware.com> wrote:

>
>
>
>
> *From: *Hui Xiang <xianghuir at gmail.com>
> *Date: *Thursday, July 27, 2017 at 8:10 PM
>
> *To: *Darrell Ball <dball at vmware.com>
> *Cc: *"ovs-discuss at openvswitch.org" <ovs-discuss at openvswitch.org>
> *Subject: *Re: [ovs-discuss] OVS-DPDK IP fragmentation require
>
>
>
>
>
>
>
> On Fri, Jul 28, 2017 at 10:54 AM, Darrell Ball <dball at vmware.com> wrote:
>
>
>
>
>
> *From: *Hui Xiang <xianghuir at gmail.com>
> *Date: *Thursday, July 27, 2017 at 6:59 PM
> *To: *Darrell Ball <dball at vmware.com>
> *Cc: *"ovs-discuss at openvswitch.org" <ovs-discuss at openvswitch.org>
> *Subject: *Re: [ovs-discuss] OVS-DPDK IP fragmentation require
>
>
>
>
>
>
>
> On Fri, Jul 28, 2017 at 1:12 AM, Darrell Ball <dball at vmware.com> wrote:
>
>
>
>
>
> *From: *Hui Xiang <xianghuir at gmail.com>
> *Date: *Thursday, July 27, 2017 at 3:18 AM
> *To: *Darrell Ball <dball at vmware.com>
> *Cc: *"ovs-discuss at openvswitch.org" <ovs-discuss at openvswitch.org>
> *Subject: *Re: [ovs-discuss] OVS-DPDK IP fragmentation require
>
>
>
>
>
> Blow is the diagram (using OVS-DPDK):
>
>
>
> 1. For packets coming to vm1 from internet where could have MTU 1500,
> there could be including some fragmented packets,
>
>     how does the ALC/Security groups handle these fragmented packets? do
> nothing and pass it next which may pass the packets
>
>     should be dropped or any special handling?
>
>
>
> Lets assume the fragments get thru. the physical switch and/or firewall.
>
>
>
> Are you using DPDK in GW and using OVS kernel datapath in br-int where you
> apply ACL/Security groups policy ?
>
> All are using DPDK, the ACL/Security groups policy said is OVS-DPDK
> conntrack implementation.
>
> With the case that we should have dropped some packets by creating special
> security group rules, but now due to they are fragmented and get thru by
> default, this is not what is expected.
>
>
>
> I would check your configuration.
>
> The dpdk connection tracker marks fragments as ‘invalid’ today and your
> rules should drop ‘invalid’.
>
> OK, thanks. here are the two scenarios we are discussing:
>
> 1.      For packets out from vms, use Jumbo Frame supported physical
> switches/routers within OpenStack cloud and enable it in all OVS-DPDK or do
> not allow application to send large frames.
>
>
>
> Try to use jumbo frames for performance reasons.
>
>
>
> On going out, if you get fragmentation done in HW at the physical
> switches, then
>
> 1)      If it could go back into one of your dpdk networks, then
> encourage using smaller packets
>
> 2)      If it goes somewhere else, then it does not matter, keep bigger
> packets
>
> Are you sure the physical switches do not support jumbo frames?
>
> Maybe it is just a config. change fix there.
>
>
>
Few physical switches in my lab probably just support max MTU 2000..

>
>
> 2. For packets coming from internet to OVS-DPDK, fragmented packets could
> be arrived, they are all dropped due to marks as 'invalid'.
>
>  With above analysis,  if these fragments are marked as 'invalid' and
> being dropped, the best way I can think about is to not use security group
> in OVS-DPDK if there could be fragments generated.
>
>
>
> If you already trust what gets to GW because you have a HW firewall, yes
>
> This assumes internally generated is always safe.
>
>
>
> Otherwise, you want to keep security groups and ‘encourage’ no fragments
> coming in, if you can
>
> ‘Encourage’ can be done by dropping and triggering checking why the
> fragments got generated in the first place
>
> Fragments may also indicate an exploit attempt, in which case, dropping is
> good.
>
Thanks Darrell, yep these are the solutions so far.

>
>
>
>
> Please correct me if I misunderstand anything.
>
>
>
> 2. For packets egress from vm1, if all internal physical switch support
> Jumbo Frame, that's fine, but if there are some physical swithes
>
>     just support 1500/2000 MTU, then fragmented packets generated again.
> The ACL/Security groups face problem as item 1 as well.
>
>
>
>
>
> For packets that reach the physical switches on the way out, then the
> decision how to handle them is at the physical switch/router
>
> The packets may be fragmented at this point; depending on the switch;
> there will be HW firewall policies to contend with, so depends.
>
>
>
> Here, again what I mean is the packets are fragmented by the physical
> switch/router, and they are switching/routing to a next node where has the
> OVS-DPDK set with security group, and OVS-DPDK may let them thru with
> ignoring the security group rules.
>
>
>
> Sorry, you lost me a bit here; in point ‘2’ above you said packets are
> going from vm1 to internet and are fine until they hit the physical switch
>
> Where you are assuming they are fragmented because the mtu is lower.
>
> If this is not going to the internet but rather another set of nodes
> running dpdk, then this is another variation of ‘1’ and hence we don’t
>
> need to discuss it.
>
>
>
>
>
> [image: ine image 1]
>
>
>
> On Thu, Jul 27, 2017 at 2:49 PM, Darrell Ball <dball at vmware.com> wrote:
>
>
>
>
>
> *From: *Hui Xiang <xianghuir at gmail.com>
> *Date: *Wednesday, July 26, 2017 at 9:43 PM
> *To: *Darrell Ball <dball at vmware.com>
> *Cc: *"ovs-discuss at openvswitch.org" <ovs-discuss at openvswitch.org>
> *Subject: *Re: [ovs-discuss] OVS-DPDK IP fragmentation require
>
>
>
> Thanks Darrell, comment inline.
>
>
>
> On Thu, Jul 27, 2017 at 12:08 PM, Darrell Ball <dball at vmware.com> wrote:
>
>
>
>
>
> *From: *<ovs-discuss-bounces at openvswitch.org> on behalf of Hui Xiang <
> xianghuir at gmail.com>
> *Date: *Wednesday, July 26, 2017 at 7:47 PM
> *To: *"ovs-discuss at openvswitch.org" <ovs-discuss at openvswitch.org>
> *Subject: *[ovs-discuss] OVS-DPDK IP fragmentation require
>
>
>
> Hi guys,
>
>
>
>   Seems OVS-DPDK still missing IP fragmentation support, is there any
> schedule to have it?
>
> OVS 2.9
>
> I'm  transferring to use OVN, but for those nodes which have external
> network connection, they may face this problem,
>
> except to configure Jumbo frames, is there any other workaround?
>
>
>
> I am not clear on the situation however.
>
> You mention about configuring jumbo frames which means you can avoid the
> fragments by doing this ?
>
> No, I can't guarantee that, only can do it inside OpenStack, it is
> limited.
>
> If this is true, then this is the best way to proceed since performance
> will be better.
>
> What is wrong with jumbo frames ?
>
> It's good but it's limited can't be guaranteed, so I am asking is there
> any other way without IP fragmentation so far.
>
>
>
> It sounds like you want to avoid IP fragmentation; so far so good.
>
> I am not sure I understand the whole picture though.
>
> Maybe you can describe what you see ?; maybe a simple diagram would help ?
>
>
>
>
>
> BR.
>
> Hui.
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20170728/e3a8a561/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 70201 bytes
Desc: not available
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20170728/e3a8a561/attachment-0001.png>


More information about the discuss mailing list