Re: [ovs-discuss] OVS-DPDK IP fragmentation require

[Hui Xiang]

On Fri, Jul 28, 2017 at 12:52 PM, Darrell Ball  wrote:

>
>
>
>
> *From: *Hui Xiang 
> *Date: *Thursday, July 27, 2017 at 8:10 PM
>
> *To: *Darrell Ball 
> *Cc: *"ovs-discuss@openvswitch.org" 
> *Subject: *Re: [ovs-discuss] OVS-DPDK IP fragmentation require
>
>
>
>
>
>
>
> On Fri, Jul 28, 2017 at 10:54 AM, Darrell Ball  wrote:
>
>
>
>
>
> *From: *Hui Xiang 
> *Date: *Thursday, July 27, 2017 at 6:59 PM
> *To: *Darrell Ball 
> *Cc: *"ovs-discuss@openvswitch.org" 
> *Subject: *Re: [ovs-discuss] OVS-DPDK IP fragmentation require
>
>
>
>
>
>
>
> On Fri, Jul 28, 2017 at 1:12 AM, Darrell Ball  wrote:
>
>
>
>
>
> *From: *Hui Xiang 
> *Date: *Thursday, July 27, 2017 at 3:18 AM
> *To: *Darrell Ball 
> *Cc: *"ovs-discuss@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  wrote:
>
>
>
>
>
> *From: *Hui Xiang 
> *Date: *Wednesday, July 26, 2017 at 9:43 PM
> *To: *Darrell Ball 
> *Cc: *"ovs-discuss@openvswitch.org" 
> *Subject: *Re: [ovs-discuss] OVS-

Re: [ovs-discuss] OVS-DPDK IP fragmentation require

[Darrell Ball]

From: Hui Xiang 
Date: Thursday, July 27, 2017 at 8:10 PM
To: Darrell Ball 
Cc: "ovs-discuss@openvswitch.org" 
Subject: Re: [ovs-discuss] OVS-DPDK IP fragmentation require



On Fri, Jul 28, 2017 at 10:54 AM, Darrell Ball 
mailto:db...@vmware.com>> wrote:


From: Hui Xiang mailto:xiangh...@gmail.com>>
Date: Thursday, July 27, 2017 at 6:59 PM
To: Darrell Ball mailto:db...@vmware.com>>
Cc: "ovs-discuss@openvswitch.org" 
mailto:ovs-discuss@openvswitch.org>>
Subject: Re: [ovs-discuss] OVS-DPDK IP fragmentation require



On Fri, Jul 28, 2017 at 1:12 AM, Darrell Ball 
mailto:db...@vmware.com>> wrote:


From: Hui Xiang mailto:xiangh...@gmail.com>>
Date: Thursday, July 27, 2017 at 3:18 AM
To: Darrell Ball mailto:db...@vmware.com>>
Cc: "ovs-discuss@openvswitch.org" 
mailto:ovs-discuss@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.


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.


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.


[ine image 1]

On Thu, Jul 27, 2017 at 2:49 PM, Darrell Ball 
mailto:db...@vmware.com>> wrote:


From: Hui Xiang mailto:xiangh...@gmail.com>>
Date: Wednesday, July 26, 2017 at 9:43 PM
To: Darrell Ball mailto:db...@vmware.com>>
Cc: "ovs-discuss@openvswitch.org" 
mailto:ovs-discuss@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 Ba

Re: [ovs-discuss] OVS-DPDK IP fragmentation require

[Hui Xiang]

On Fri, Jul 28, 2017 at 10:54 AM, Darrell Ball  wrote:

>
>
>
>
> *From: *Hui Xiang 
> *Date: *Thursday, July 27, 2017 at 6:59 PM
> *To: *Darrell Ball 
> *Cc: *"ovs-discuss@openvswitch.org" 
> *Subject: *Re: [ovs-discuss] OVS-DPDK IP fragmentation require
>
>
>
>
>
>
>
> On Fri, Jul 28, 2017 at 1:12 AM, Darrell Ball  wrote:
>
>
>
>
>
> *From: *Hui Xiang 
> *Date: *Thursday, July 27, 2017 at 3:18 AM
> *To: *Darrell Ball 
> *Cc: *"ovs-discuss@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.
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.

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: line image 1]
>
>
>
> On Thu, Jul 27, 2017 at 2:49 PM, Darrell Ball  wrote:
>
>
>
>
>
> *From: *Hui Xiang 
> *Date: *Wednesday, July 26, 2017 at 9:43 PM
> *To: *Darrell Ball 
> *Cc: *"ovs-discuss@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  wrote:
>
>
>
>
>
> *From: * on behalf of Hui Xiang <
> xiangh...@gmail.com>
> *Date: *Wednesday, July 26, 2017 at 7:47 PM
> *To: *"ovs-discuss@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

Re: [ovs-discuss] OVS-DPDK IP fragmentation require

[Darrell Ball]

From: Hui Xiang 
Date: Thursday, July 27, 2017 at 6:59 PM
To: Darrell Ball 
Cc: "ovs-discuss@openvswitch.org" 
Subject: Re: [ovs-discuss] OVS-DPDK IP fragmentation require



On Fri, Jul 28, 2017 at 1:12 AM, Darrell Ball 
mailto:db...@vmware.com>> wrote:


From: Hui Xiang mailto:xiangh...@gmail.com>>
Date: Thursday, July 27, 2017 at 3:18 AM
To: Darrell Ball mailto:db...@vmware.com>>
Cc: "ovs-discuss@openvswitch.org" 
mailto:ovs-discuss@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’.

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.


[line image 1]

On Thu, Jul 27, 2017 at 2:49 PM, Darrell Ball 
mailto:db...@vmware.com>> wrote:


From: Hui Xiang mailto:xiangh...@gmail.com>>
Date: Wednesday, July 26, 2017 at 9:43 PM
To: Darrell Ball mailto:db...@vmware.com>>
Cc: "ovs-discuss@openvswitch.org" 
mailto:ovs-discuss@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 
mailto:db...@vmware.com>> wrote:


From: 
mailto:ovs-discuss-boun...@openvswitch.org>>
 on behalf of Hui Xiang mailto:xiangh...@gmail.com>>
Date: Wednesday, July 26, 2017 at 7:47 PM
To: "ovs-discuss@openvswitch.org" 
mailto:ovs-discuss@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.



___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS-DPDK IP fragmentation require

[Hui Xiang]

On Fri, Jul 28, 2017 at 1:12 AM, Darrell Ball  wrote:

>
>
>
>
> *From: *Hui Xiang 
> *Date: *Thursday, July 27, 2017 at 3:18 AM
> *To: *Darrell Ball 
> *Cc: *"ovs-discuss@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.

>
>
> 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.

>
>
>
>
> [image: nline image 1]
>
>
>
> On Thu, Jul 27, 2017 at 2:49 PM, Darrell Ball  wrote:
>
>
>
>
>
> *From: *Hui Xiang 
> *Date: *Wednesday, July 26, 2017 at 9:43 PM
> *To: *Darrell Ball 
> *Cc: *"ovs-discuss@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  wrote:
>
>
>
>
>
> *From: * on behalf of Hui Xiang <
> xiangh...@gmail.com>
> *Date: *Wednesday, July 26, 2017 at 7:47 PM
> *To: *"ovs-discuss@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.
>
>
>
>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] openflow with openwrt

[Blue Lang]

To further Ben's point, you should address this question to the OpenWRT
mailing list, not OVS.

https://lists.openwrt.org/cgi-bin/mailman/listinfo

Thanks,

On Thu, Jul 27, 2017 at 1:39 PM, Ben Pfaff  wrote:

> On July 27, 2017 10:36:52 AM PDT, Mohamed Ibrahem <
> mohamed_ibrahem1...@yahoo.com> wrote:
>>
>> no, i am using OVS software on my router and give me this error and i can 
>> not solve it any more
>> --
>>
>> On Thu, 7/27/17, Ben Pfaff  wrote:
>>
>>  Subject: Re: [ovs-discuss] openflow with openwrt
>>  To: "Mohamed Ibrahem" 
>>  Cc: ovs-discuss@openvswitch.org
>>  Date: Thursday, July 27, 2017, 6:55 PM
>>
>>  On Thu, Jul 27, 2017 at 03:32:22PM +,
>>  Mohamed Ibrahem via discuss wrote:
>>
>>>  hello guys,
  i have a problem with router tplink

>>>  wr841N , i have installed openwrt to
>>
>>>
>>>  install openflow and get the following message when
>>>
>>  starting the openflow
>>
>>>
  /etc/init.d.openflow/ start
>>
>>>
  appears,
>>
>>>  / sbin / ofup: line1:

>>>  ofdatapath: not found no need for further
>>
>>>  configuration out-of-band control
  / sbin / ofup: line4: ofprotocol: not

>>>  found
>>
>>>
>>>  can any one
>>>
>>  help me to solve this problem??
>>
>>  This mailing list is about OVS, but you
>>  aren't using OVS.
>>
>>  -Inline Attachment Follows-
>>
>>
>>
> The commands and output that you quoted are not part of OVS.
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
>


-- 
Blue Lang
PM *| *Veracity

3423 Piedmont Rd NE

Suite 350

Atlanta, GA  30305
Cell:  (770) 265-1381 <+17702651381>
https://www.linkedin.com/in/bluelang/
b...@veracity.io
www.veracity.io
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Multiple Virtual Wireless Ports

[Blue Lang]

You'd need to get your wifi NIC or WAP to act as a transparent bridge so
the end devices appear as multiple MACs on the WLAN0 interface. Then you
can use (should be able to?) use OF write actions to control the traffic
flow on the wifi guests.

There are quite a few hits on google covering very similar situations to
the one you're asking about here.

Thanks,

On Thu, Jul 27, 2017 at 1:59 PM, Michael Williams 
wrote:

> When I WiFi interface I mean WLAN0 and in this particular box we have
> WLAN0 for the 5 GHz radio.
>
>
> When you add it to OvS you are just adding it as an individual port to the
> bridge. But if you have for example 4 computers connect wirelessly its like
> they are all connecting via that single port unlike if you plugged in 4
> computers via the wired ports where each computer would plug into a single
> individual port.
>
>
> My problem is I want to be able to control the traffic between the
> wireless devices using OvS in the same way that I can control the traffic
> between the wired devices.
>
>
> When you said added multiple wifi interfaces do you mean that you have
> multiple radios? Because we only have two and are only using one.
>
>
> --
> *From:* Joo Yong-Seok 
> *Sent:* Thursday, July 27, 2017 1:33 PM
> *To:* Michael Williams
> *Cc:* Ben Pfaff; ovs-discuss@openvswitch.org
>
> *Subject:* Re: [ovs-discuss] Multiple Virtual Wireless Ports
>
> When you say, "wifi interface", do you mean wlan interface (which is VAP)
> at AP? or low-level wifi interface?
> I don't know rate-limit since I've never tried but it works well for
> regular OVS rules.
>
> - Drop everything
> - Allow ARP
> - Allow DHCP
> - Allow DNS
>
> I applied the rule in one of ovs bridge and added multiple wifi interface
> over GRE tunnel.
>
> At least, I've tried this on top of Linux kernel 4.4 / OVS 2.6 - OPENWRT
> package.
>
> Best regards,
>
> On Thu, Jul 27, 2017 at 10:28 AM, Michael Williams 
> wrote:
>
>> Hi Ben,
>>
>>
>> I don't think I explained it properly. Between the wired ports we
>> can apply Openflow rules to limit traffic between computers connected via
>> those wired ports, and that works with standard OvS. On the wireless WiFi
>> side I would like to be able do the same thing and to limit the traffic
>> between WiFi connected devices.
>>
>>
>> Since WiFi only has one interface and not multiple individual ports like
>> the wired stuff, my rules for dropping traffic between ports won't work. So
>> I was wondering if there was someway with OvS to limit or stop
>> traffic between WiFi connected computers?
>>
>>
>>
>> --
>> *From:* Ben Pfaff 
>> *Sent:* Thursday, July 27, 2017 12:57 PM
>> *To:* Michael Williams
>> *Cc:* ovs-discuss@openvswitch.org
>> *Subject:* Re: [ovs-discuss] Multiple Virtual Wireless Ports
>>
>> On Thu, Jul 27, 2017 at 01:33:23PM +, Michael Williams wrote:
>> > We have OvS running on a wireless router with 4 wired Ethernet
>> > ports. We can apply rules on the wired ports but when we try to apply
>> > rules on the wireless port the rules don't work between multiple
>> > wireless devices. Is there a way within OvS to treat the wireless
>> > interface like multiple virtual ports so that when a wireless device
>> > connects we can apply rules to govern behavior between the wireless
>> > devices like we can with the wired devices?
>>
>> OVS doesn't distinguish between different kinds of ports, so the
>> restrictions you're describing don't make sense; OVS doesn't work that
>> way.  You might be using a vendor's modified version of OVS.  If so,
>> then you should ask the vendor for assistance.
>>
>> ___
>> discuss mailing list
>> disc...@openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>>
>>
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
>


-- 
Blue Lang
PM *| *Veracity

3423 Piedmont Rd NE

Suite 350

Atlanta, GA  30305
Cell:  (770) 265-1381 <+17702651381>
https://www.linkedin.com/in/bluelang/
b...@veracity.io
www.veracity.io
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Multiple Virtual Wireless Ports

[Joo Yong-Seok]

You can easily get the wireless STA mac-address from your AP. Then, you can
plumb the rule based on your wifi STA mac-address. There is no such a
"port" concept - inside wifi driver - specially if you are talking about
AP-STA association.

Actually, logical connection is "association". You can retrieve association
table and use the mac-address. Before any kind of packets are delivered to
bridge, association should happen first. From hostapd or some user-space
auth managing application, plumb ovs rule based on client mac - call
ovs-ofctl or other tools to create flows.

Linux and wifi driver doesn't support "port concept" on wifi association.

I hope it will help.

Best regards,

On Thu, Jul 27, 2017 at 10:59 AM, Michael Williams 
wrote:

> When I WiFi interface I mean WLAN0 and in this particular box we have
> WLAN0 for the 5 GHz radio.
>
>
> When you add it to OvS you are just adding it as an individual port to the
> bridge. But if you have for example 4 computers connect wirelessly its like
> they are all connecting via that single port unlike if you plugged in 4
> computers via the wired ports where each computer would plug into a single
> individual port.
>
>
> My problem is I want to be able to control the traffic between the
> wireless devices using OvS in the same way that I can control the traffic
> between the wired devices.
>
>
> When you said added multiple wifi interfaces do you mean that you have
> multiple radios? Because we only have two and are only using one.
>
>
> --
> *From:* Joo Yong-Seok 
> *Sent:* Thursday, July 27, 2017 1:33 PM
> *To:* Michael Williams
> *Cc:* Ben Pfaff; ovs-discuss@openvswitch.org
>
> *Subject:* Re: [ovs-discuss] Multiple Virtual Wireless Ports
>
> When you say, "wifi interface", do you mean wlan interface (which is VAP)
> at AP? or low-level wifi interface?
> I don't know rate-limit since I've never tried but it works well for
> regular OVS rules.
>
> - Drop everything
> - Allow ARP
> - Allow DHCP
> - Allow DNS
>
> I applied the rule in one of ovs bridge and added multiple wifi interface
> over GRE tunnel.
>
> At least, I've tried this on top of Linux kernel 4.4 / OVS 2.6 - OPENWRT
> package.
>
> Best regards,
>
> On Thu, Jul 27, 2017 at 10:28 AM, Michael Williams 
> wrote:
>
>> Hi Ben,
>>
>>
>> I don't think I explained it properly. Between the wired ports we
>> can apply Openflow rules to limit traffic between computers connected via
>> those wired ports, and that works with standard OvS. On the wireless WiFi
>> side I would like to be able do the same thing and to limit the traffic
>> between WiFi connected devices.
>>
>>
>> Since WiFi only has one interface and not multiple individual ports like
>> the wired stuff, my rules for dropping traffic between ports won't work. So
>> I was wondering if there was someway with OvS to limit or stop
>> traffic between WiFi connected computers?
>>
>>
>>
>> --
>> *From:* Ben Pfaff 
>> *Sent:* Thursday, July 27, 2017 12:57 PM
>> *To:* Michael Williams
>> *Cc:* ovs-discuss@openvswitch.org
>> *Subject:* Re: [ovs-discuss] Multiple Virtual Wireless Ports
>>
>> On Thu, Jul 27, 2017 at 01:33:23PM +, Michael Williams wrote:
>> > We have OvS running on a wireless router with 4 wired Ethernet
>> > ports. We can apply rules on the wired ports but when we try to apply
>> > rules on the wireless port the rules don't work between multiple
>> > wireless devices. Is there a way within OvS to treat the wireless
>> > interface like multiple virtual ports so that when a wireless device
>> > connects we can apply rules to govern behavior between the wireless
>> > devices like we can with the wired devices?
>>
>> OVS doesn't distinguish between different kinds of ports, so the
>> restrictions you're describing don't make sense; OVS doesn't work that
>> way.  You might be using a vendor's modified version of OVS.  If so,
>> then you should ask the vendor for assistance.
>>
>> ___
>> discuss mailing list
>> disc...@openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>>
>>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Multiple Virtual Wireless Ports

[Michael Williams]

When I WiFi interface I mean WLAN0 and in this particular box we have WLAN0 for 
the 5 GHz radio.


When you add it to OvS you are just adding it as an individual port to the 
bridge. But if you have for example 4 computers connect wirelessly its like 
they are all connecting via that single port unlike if you plugged in 4 
computers via the wired ports where each computer would plug into a single 
individual port.


My problem is I want to be able to control the traffic between the wireless 
devices using OvS in the same way that I can control the traffic between the 
wired devices.


When you said added multiple wifi interfaces do you mean that you have multiple 
radios? Because we only have two and are only using one.



From: Joo Yong-Seok 
Sent: Thursday, July 27, 2017 1:33 PM
To: Michael Williams
Cc: Ben Pfaff; ovs-discuss@openvswitch.org
Subject: Re: [ovs-discuss] Multiple Virtual Wireless Ports

When you say, "wifi interface", do you mean wlan interface (which is VAP) at 
AP? or low-level wifi interface?
I don't know rate-limit since I've never tried but it works well for regular 
OVS rules.

- Drop everything
- Allow ARP
- Allow DHCP
- Allow DNS

I applied the rule in one of ovs bridge and added multiple wifi interface over 
GRE tunnel.

At least, I've tried this on top of Linux kernel 4.4 / OVS 2.6 - OPENWRT 
package.

Best regards,

On Thu, Jul 27, 2017 at 10:28 AM, Michael Williams 
mailto:mw7...@hotmail.com>> wrote:

Hi Ben,


I don't think I explained it properly. Between the wired ports we can apply 
Openflow rules to limit traffic between computers connected via those wired 
ports, and that works with standard OvS. On the wireless WiFi side I would like 
to be able do the same thing and to limit the traffic between WiFi connected 
devices.


Since WiFi only has one interface and not multiple individual ports like the 
wired stuff, my rules for dropping traffic between ports won't work. So I was 
wondering if there was someway with OvS to limit or stop traffic between WiFi 
connected computers?




From: Ben Pfaff mailto:b...@ovn.org>>
Sent: Thursday, July 27, 2017 12:57 PM
To: Michael Williams
Cc: ovs-discuss@openvswitch.org
Subject: Re: [ovs-discuss] Multiple Virtual Wireless Ports

On Thu, Jul 27, 2017 at 01:33:23PM +, Michael Williams wrote:
> We have OvS running on a wireless router with 4 wired Ethernet
> ports. We can apply rules on the wired ports but when we try to apply
> rules on the wireless port the rules don't work between multiple
> wireless devices. Is there a way within OvS to treat the wireless
> interface like multiple virtual ports so that when a wireless device
> connects we can apply rules to govern behavior between the wireless
> devices like we can with the wired devices?

OVS doesn't distinguish between different kinds of ports, so the
restrictions you're describing don't make sense; OVS doesn't work that
way.  You might be using a vendor's modified version of OVS.  If so,
then you should ask the vendor for assistance.

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] openflow with openwrt

[Ben Pfaff]

On July 27, 2017 10:36:52 AM PDT, Mohamed Ibrahem 
 wrote:
>no, i am using OVS software on my router and give me this error and i
>can not solve it any more
>
>On Thu, 7/27/17, Ben Pfaff  wrote:
>
> Subject: Re: [ovs-discuss] openflow with openwrt
> To: "Mohamed Ibrahem" 
> Cc: ovs-discuss@openvswitch.org
> Date: Thursday, July 27, 2017, 6:55 PM
> 
> On Thu, Jul 27, 2017 at 03:32:22PM +,
> Mohamed Ibrahem via discuss wrote:
> > > hello guys,
> > > i have a problem with router tplink
> wr841N , i have installed openwrt to
> >
> > install openflow and get the following message when
> starting the openflow
> > >
> /etc/init.d.openflow/ start    
> > >
> appears, 
> > > / sbin / ofup: line1:
> ofdatapath: not found no need for further
> > > configuration out-of-band control 
> > > / sbin / ofup: line4: ofprotocol: not
> found
> > 
> > can any one
> help me to solve this problem??
> 
> This mailing list is about OVS, but you
> aren't using OVS.
> 
> -Inline Attachment Follows-
> 
> 

The commands and output that you quoted are not part of OVS.___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Multiple Virtual Wireless Ports

[Joo Yong-Seok]

When you say, "wifi interface", do you mean wlan interface (which is VAP)
at AP? or low-level wifi interface?
I don't know rate-limit since I've never tried but it works well for
regular OVS rules.

- Drop everything
- Allow ARP
- Allow DHCP
- Allow DNS

I applied the rule in one of ovs bridge and added multiple wifi interface
over GRE tunnel.

At least, I've tried this on top of Linux kernel 4.4 / OVS 2.6 - OPENWRT
package.

Best regards,

On Thu, Jul 27, 2017 at 10:28 AM, Michael Williams 
wrote:

> Hi Ben,
>
>
> I don't think I explained it properly. Between the wired ports we
> can apply Openflow rules to limit traffic between computers connected via
> those wired ports, and that works with standard OvS. On the wireless WiFi
> side I would like to be able do the same thing and to limit the traffic
> between WiFi connected devices.
>
>
> Since WiFi only has one interface and not multiple individual ports like
> the wired stuff, my rules for dropping traffic between ports won't work. So
> I was wondering if there was someway with OvS to limit or stop
> traffic between WiFi connected computers?
>
>
>
> --
> *From:* Ben Pfaff 
> *Sent:* Thursday, July 27, 2017 12:57 PM
> *To:* Michael Williams
> *Cc:* ovs-discuss@openvswitch.org
> *Subject:* Re: [ovs-discuss] Multiple Virtual Wireless Ports
>
> On Thu, Jul 27, 2017 at 01:33:23PM +, Michael Williams wrote:
> > We have OvS running on a wireless router with 4 wired Ethernet
> > ports. We can apply rules on the wired ports but when we try to apply
> > rules on the wireless port the rules don't work between multiple
> > wireless devices. Is there a way within OvS to treat the wireless
> > interface like multiple virtual ports so that when a wireless device
> > connects we can apply rules to govern behavior between the wireless
> > devices like we can with the wired devices?
>
> OVS doesn't distinguish between different kinds of ports, so the
> restrictions you're describing don't make sense; OVS doesn't work that
> way.  You might be using a vendor's modified version of OVS.  If so,
> then you should ask the vendor for assistance.
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Multiple Virtual Wireless Ports

[Joo Yong-Seok]

I have tried to add wireless ports to OVS bridge and created GRE tunnel or
some sort of drop/allow rules on top of it.
Everything works for me.

I used Qualcomm's reference platform - which is arm based.

Also, bridge is already "vritual port" if it has multiple wireless
interfaces.

Best regards,

- yongseok

On Thu, Jul 27, 2017 at 6:33 AM, Michael Williams 
wrote:

> We have OvS running on a wireless router with 4 wired Ethernet ports. We
> can apply rules on the wired ports but when we try to apply rules on the
> wireless port the rules don't work between multiple wireless devices. Is
> there a way within OvS to treat the wireless interface like multiple
> virtual ports so that when a wireless device connects we can apply rules to
> govern behavior between the wireless devices like we can with the wired
> devices?
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Multiple Virtual Wireless Ports

[Michael Williams]

Hi Ben,


I don't think I explained it properly. Between the wired ports we can apply 
Openflow rules to limit traffic between computers connected via those wired 
ports, and that works with standard OvS. On the wireless WiFi side I would like 
to be able do the same thing and to limit the traffic between WiFi connected 
devices.


Since WiFi only has one interface and not multiple individual ports like the 
wired stuff, my rules for dropping traffic between ports won't work. So I was 
wondering if there was someway with OvS to limit or stop traffic between WiFi 
connected computers?




From: Ben Pfaff 
Sent: Thursday, July 27, 2017 12:57 PM
To: Michael Williams
Cc: ovs-discuss@openvswitch.org
Subject: Re: [ovs-discuss] Multiple Virtual Wireless Ports

On Thu, Jul 27, 2017 at 01:33:23PM +, Michael Williams wrote:
> We have OvS running on a wireless router with 4 wired Ethernet
> ports. We can apply rules on the wired ports but when we try to apply
> rules on the wireless port the rules don't work between multiple
> wireless devices. Is there a way within OvS to treat the wireless
> interface like multiple virtual ports so that when a wireless device
> connects we can apply rules to govern behavior between the wireless
> devices like we can with the wired devices?

OVS doesn't distinguish between different kinds of ports, so the
restrictions you're describing don't make sense; OVS doesn't work that
way.  You might be using a vendor's modified version of OVS.  If so,
then you should ask the vendor for assistance.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS-DPDK IP fragmentation require

[Darrell Ball]

From: Hui Xiang 
Date: Thursday, July 27, 2017 at 3:18 AM
To: Darrell Ball 
Cc: "ovs-discuss@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 ?

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.



[nline image 1]

On Thu, Jul 27, 2017 at 2:49 PM, Darrell Ball 
mailto:db...@vmware.com>> wrote:


From: Hui Xiang mailto:xiangh...@gmail.com>>
Date: Wednesday, July 26, 2017 at 9:43 PM
To: Darrell Ball mailto:db...@vmware.com>>
Cc: "ovs-discuss@openvswitch.org" 
mailto:ovs-discuss@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 
mailto:db...@vmware.com>> wrote:


From: 
mailto:ovs-discuss-boun...@openvswitch.org>>
 on behalf of Hui Xiang mailto:xiangh...@gmail.com>>
Date: Wednesday, July 26, 2017 at 7:47 PM
To: "ovs-discuss@openvswitch.org" 
mailto:ovs-discuss@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.


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Multiple Virtual Wireless Ports

[Ben Pfaff]

On Thu, Jul 27, 2017 at 01:33:23PM +, Michael Williams wrote:
> We have OvS running on a wireless router with 4 wired Ethernet
> ports. We can apply rules on the wired ports but when we try to apply
> rules on the wireless port the rules don't work between multiple
> wireless devices. Is there a way within OvS to treat the wireless
> interface like multiple virtual ports so that when a wireless device
> connects we can apply rules to govern behavior between the wireless
> devices like we can with the wired devices?

OVS doesn't distinguish between different kinds of ports, so the
restrictions you're describing don't make sense; OVS doesn't work that
way.  You might be using a vendor's modified version of OVS.  If so,
then you should ask the vendor for assistance.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] openflow with openwrt

[Ben Pfaff]

On Thu, Jul 27, 2017 at 03:32:22PM +, Mohamed Ibrahem via discuss wrote:
> > hello guys,
> > i have a problem with router tplink wr841N , i have installed openwrt to
> > install openflow and get the following message when starting the openflow
> > /etc/init.d.openflow/ start
> > appears, 
> > / sbin / ofup: line1: ofdatapath: not found no need for further
> > configuration out-of-band control 
> > / sbin / ofup: line4: ofprotocol: not found
> 
> can any one help me to solve this problem??

This mailing list is about OVS, but you aren't using OVS.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] 802.1ad (QinQ) Support

[Justin Pettit]

> On Jul 27, 2017, at 6:00 AM, Eric Garver  wrote:
> 
> On Thu, Jul 27, 2017 at 02:25:46PM +0530, Sudhanshu Gupta wrote:
>> Thanks Eric, for replying.
>> 
>> Is there any tentative date for release of OVS 2.8?
> 
> I don't think there is a set date, but I believe the branch for 2.8 is
> due to be created "soon".

I'm hoping that we branch this week.  The official plan is to release 2.8 in 
August.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] openflow with openwrt

[Justin Pettit]

> On Jul 27, 2017, at 8:32 AM, Mohamed Ibrahem via discuss 
>  wrote:
> 
>> hello guys,
>> i have a problem with router tplink wr841N , i have installed openwrt to
>> install openflow and get the following message when starting the openflow
>> /etc/init.d.openflow/ start
>> appears, 
>> / sbin / ofup: line1: ofdatapath: not found no need for further
>> configuration out-of-band control 
>> / sbin / ofup: line4: ofprotocol: not found
> 
> can any one help me to solve this problem??

I don't think you're running Open vSwitch.  I have heard of people running Open 
vSwitch on OpenWrt, though.

--Justin




___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] openflow with openwrt

[Mohamed Ibrahem via discuss]

> hello guys,
> i have a problem with router tplink wr841N , i have installed openwrt to
> install openflow and get the following message when starting the openflow
> /etc/init.d.openflow/ start
> appears, 
> / sbin / ofup: line1: ofdatapath: not found no need for further
> configuration out-of-band control 
> / sbin / ofup: line4: ofprotocol: not found

can any one help me to solve this problem??
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] openvswitch-2.5.0 ovs-vsctl slow

[Ben Pfaff]

On Tue, Jul 25, 2017 at 07:24:04PM +, MY-OVS DISCUSS via discuss wrote:
> Is there a way to set/remove/clear port's trunks using another command
> other than ovs-vsctl?ovs-vsctl is really slow in executing these
> operations, especially when there are more number of ports.  Currently
> we use ovs-vsctl add port foo1 trunks 123.

You could use a controller.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] 802.1ad (QinQ) Support

[Sudhanshu Gupta]

Thanks Eric, for replying.

Is there any tentative date for release of OVS 2.8?

Regards,
Sudhanshu

On Mon, Jul 24, 2017 at 6:08 PM, Eric Garver  wrote:

> On Tue, Jul 18, 2017 at 12:42:38PM +0530, Sudhanshu Gupta wrote:
> > Hi,
> >
> > I want to know whether double vlan tagged packets are supported in OVS
> > release 2.7.1 ?
>
> No. Not in the 2.7.x stream.
>
> >
> > If not, which version of OVS supports double vlan tagged packets?
>
> The next minor release, 2.8, will have support.
>
> >
> > Thanks,
> > Sudhanshu
>
> > ___
> > discuss mailing list
> > disc...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Multiple Virtual Wireless Ports

[Michael Williams]

We have OvS running on a wireless router with 4 wired Ethernet ports. We can 
apply rules on the wired ports but when we try to apply rules on the wireless 
port the rules don't work between multiple wireless devices. Is there a way 
within OvS to treat the wireless interface like multiple virtual ports so that 
when a wireless device connects we can apply rules to govern behavior between 
the wireless devices like we can with the wired devices?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] 802.1ad (QinQ) Support

[Eric Garver]

On Thu, Jul 27, 2017 at 02:25:46PM +0530, Sudhanshu Gupta wrote:
> Thanks Eric, for replying.
> 
> Is there any tentative date for release of OVS 2.8?

I don't think there is a set date, but I believe the branch for 2.8 is
due to be created "soon".

> 
> Regards,
> Sudhanshu
> 
> On Mon, Jul 24, 2017 at 6:08 PM, Eric Garver  wrote:
> 
> > On Tue, Jul 18, 2017 at 12:42:38PM +0530, Sudhanshu Gupta wrote:
> > > Hi,
> > >
> > > I want to know whether double vlan tagged packets are supported in OVS
> > > release 2.7.1 ?
> >
> > No. Not in the 2.7.x stream.
> >
> > >
> > > If not, which version of OVS supports double vlan tagged packets?
> >
> > The next minor release, 2.8, will have support.
> >
> > >
> > > Thanks,
> > > Sudhanshu
> >
> > > ___
> > > discuss mailing list
> > > disc...@openvswitch.org
> > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS-DPDK IP fragmentation require

[Hui Xiang]

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?
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.

[image: Inline image 1]

On Thu, Jul 27, 2017 at 2:49 PM, Darrell Ball  wrote:

>
>
>
>
> *From: *Hui Xiang 
> *Date: *Wednesday, July 26, 2017 at 9:43 PM
> *To: *Darrell Ball 
> *Cc: *"ovs-discuss@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  wrote:
>
>
>
>
>
> *From: * on behalf of Hui Xiang <
> xiangh...@gmail.com>
> *Date: *Wednesday, July 26, 2017 at 7:47 PM
> *To: *"ovs-discuss@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.
>
>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] less tcp perf with active-backup bonding mode on XL710

[gowrishankar muthukrishnan]

Hi,
I am using XL710 NIC (2 ports) as part of OVS bonding port in 
active-backup mode

in x86_64 servers. Setup is pretty simple. Two machines each with XL710 NIC
connected each other back-to-back on these ports. Bonding is setup 
through OVS

active-backup mode. After bonding port is created, I assign an IP address on
bridge and run iperf for TCP perf comparison.

iperf (with default params) between bonding ports shows very less 
throughput of
around 1 Mbps where as in same server, when I use 82599 (ixgbe) I find 
better
throughput of around 20 Mbps. I tried with dpdk poll mode driver as 
well. It helps

ixgbe to get near 250 Mbps but, same poor performance I get for i40e.

Has anyone observed this reduced throughput (with or without dpdk) in XL710
while in OVS active-backup bonding ?. Any pointer to find hot spot causing
trouble (I am trying perf for the moment).

OVS version of 2.6 as well as 2.7 tried (along with dpdk 16.11.1).

--
Regards,
Gowrishankar M

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Issue with offloading OVS flows into Mellanox-4 cards

[Sugu Deepthy]

Hi Roi,
Thank you for the help,
Upgraded the firmware to 14.20 and used latest kernel(4.10) in VM.
Now its working correctly. I can forward packets between VM and physical
ports in the NIC. The oflloaded flows are showing in the OVS.

Few suggestions while preparing the installation document for hardware
offload.
1) Must need to provide minimum kernel version to use this feature.
2) The default MLNX firmware is not supporting the hardware offload for
some reason. Must specify what version of firmware and supported NICs
3) Even though I use the ethernet NIC, I have to install the IB verbs src
in the VM for attaching the VF to the DPDK. Not sure why this is a
prerequisite

Once again thank for the suggestions to make it working. :)

On Mon, Jul 24, 2017 at 9:05 AM, Sugu Deepthy 
wrote:

>
>
> On Mon, Jul 24, 2017 at 5:46 AM, Roi Dayan  wrote:
> 
>
>>
>>
>>> [Sugu] I upgraded the system and now I dont see this error anymore.
>>> Instead I see this
>>>
>>> [ 1103.216355] mlx5_3:wait_for_async_commands:722:(pid 3097): done with
>>> all pending requests
>>> [ 1115.954770] mlx5_core :07:00.0: mlx5_cmd_check:697:(pid 3477):
>>> QUERY_VPORT_COUNTER(0x770) op_mod(0x0) failed, status bad system
>>> state(0x4), syndrome (0x368b01)
>>> [ 1115.954902] mlx5_core :07:00.0: mlx5_cmd_check:697:(pid 3477):
>>> QUERY_VPORT_COUNTER(0x770) op_mod(0x0) failed, status bad system
>>> state(0x4), syndrome (0x368b01)
>>>
>>> I am getting this error back to back for every command(2 entry for each
>>> command as I have 2 VFs, may be?)
>>> starting from unbind, devlink, ethtool and starting the VM.
>>> And inside the VM the VFs are not bound to any driver either. Is there
>>> any wrong with the NIC?
>>>
>>
>>
>> looks like the syndrome you get is caused by querying a counter while
>> the HCA is not yes configured properly.
>> can you verify you are using the latest firmware?
>> can you verify the steps you do? did you enable sriov and moved to
>> switchdev mode?
>
> [Sugu] Ok. SR-IOV is enabled on the board. and the device is moved to
> switchdev mode though it throws the error that shown above.
>
> The firmware version of the card is
> # ethtool -i ens786f0
> driver: mlx5_core
> version: 3.0-1 (January 2015)
> firmware-version: 14.17.2032
> expansion-rom-version:
> bus-info: :07:00.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: no
> supports-register-dump: no
> supports-priv-flags: yes
>
> Do you think this version firmware cannot support the offload??
> Will try to install the latest firmware and keep you posted.
>
>>
>>
>>
>>>
>>>
>>>
>>>
>>>
>>> I verfied that the ports named eth1, eth2, eth3 and et4 are
>>> created for
>>> my vfs, when
>>> I ran the commands 'devlink dev eswitch set pci/:07:00.0 mode
>>> switchdev' and
>>> 'devlink dev eswitch set pci/:07:00.1 mode switchdev'
>>>
>>> The detailed error in dmesg are given below,
>>> [ 1245.941287] mlx5_core :07:00.0: mlx5_cmd_check:697:(pid
>>> 3107):
>>> QUERY_VPORT_COUNTER(0x770) op_mod(0x0) failed, status bad system
>>> state(0x4), syndrome (0x368b01)
>>> [ 1245.941478] mlx5_core :07:00.1: mlx5_cmd_check:697:(pid
>>> 3107):
>>> QUERY_VPORT_COUNTER(0x770) op_mod(0x0) failed, status bad system
>>> state(0x4), syndrome (0x368b01)
>>>
>>> Please note I couldn't run the "inline-mode transport" command
>>> as its
>>> not supported.
>>>
>>>
>>> maybe you need newer iproute package. try to install latest upstream.
>>>
>>> [Sugu]
>>> I am using latest Ubuntu release
>>>

>>
>>> No LSB modules are available.
>>> Distributor ID: Ubuntu
>>> Description:Ubuntu Artful Aardvark (development branch)
>>> Release:17.10
>>> Codename:   artful
>>>

 and my kernel is
>>> 4.11.0-10-generic #15-Ubuntu SMP Thu Jun 29 15:03:41 UTC 2017 x86_64
>>> x86_64 x86_64 GNU/Linux
>>>
>>> And still it need to install the newer iproute package additonally? Is
>>> that the requirement to use the hardware offload in OVS?
>>> And my iproute version is
>>> ip -V
>>> ip utility, iproute2-ss161212
>>> Can you share which version of iproute you use for the testing?
>>>
>>
>> I'm using latest upstream. I'm not sure if all needed patches are in
>> Ubuntu distro.
>> my versions looks like this: ip utility, iproute2-ss170501
>>
>> if you have devlink and you can change mode to switchdev without an
>> error then it's ok to start going.
>>
> [Sugu] Ok. Thank you for confirming.
>
>>
>>
>>
>>>
>>>
>>>
>>>
>>> We still need to work on docs for this feature but for
>>> now I
>>> documented it a little here:
>>> https://github.com/roidayan/ovs/wiki
>>> >> 3A%2F%2Fgithub.com%2Froidayan%2Fovs%2Fwiki&data=02%7C01%7Cro
>>> id%40mellanox.com%7C2bbfa311e8124ec5ded508d4d212e423%7Ca6529