[ovs-dev] Mail System Error - Returned Mail

2016-09-26 Thread Post Office 
The original message was received at Tue, 27 Sep 2016 11:39:38 +0530 from 
160.24.197.253

- The following addresses had permanent fatal errors -




___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v2] INSTALL.md: Add details about kernel module preference.

2016-09-26 Thread Darrell Ball 
On Mon, Sep 26, 2016 at 8:52 PM, Darrell Ball  wrote:

>
>
> On Mon, Sep 26, 2016 at 7:34 AM, Gurucharan Shetty  wrote:
>
>> Signed-off-by: Gurucharan Shetty 
>> ---
>>  INSTALL.md | 23 ++-
>>  1 file changed, 22 insertions(+), 1 deletion(-)
>>
>> diff --git a/INSTALL.md b/INSTALL.md
>> index bb40e4a..6ecefdf 100644
>> --- a/INSTALL.md
>> +++ b/INSTALL.md
>> @@ -322,9 +322,30 @@ Building the Sources
>>  4. Run "make install" to install the executables and manpages into the
>> running system, by default under /usr/local.
>>
>> -5. If you built kernel modules, you may install and load them, e.g.:
>> +5. If you built kernel modules, you may install them, e.g.:
>>
>>`% make modules_install`
>> +
>> +It is possible that you already had a Open vSwitch kernel module
>> +installed on your machine that came from upstream Linux (in a
>> +different directory).  To make sure that you insert the Open vSwitch
>> +kernel module you built from this repository, you should create a
>> +depmod.d file that prefers your newly installed kernel modules over
>> +the kernel modules from upstream Linux.  The following snippet of
>> +code achieves the same.
>> +
>> +```
>> +% config_file="/etc/depmod.d/openvswitch.conf"
>> +% for module in datapath/linux/*.ko; do
>> +  modname="$(basename ${module})"
>> +  echo "override $modname * extra" >> "$config_file"
>> +  echo "override $modname * weak-updates" >> "$config_file"
>> +  done
>> +% depmod -a
>> +```
>> +
>>
>
> I tried the script
>
> #!/bin/bash
> config_file="/etc/depmod.d/openvswitch.conf"
> for module in datapath/linux/*.ko; do
> modname="$(basename ${module})"
> echo "override $modname * extra" >> "$config_file"
> echo "override $modname * weak-updates" >> "$config_file"
> done
> depmod -a
>
> on Ubuntu 14.04 and the script generated the expected
> file contents
>
> dball@ubuntu:~/openvswitch/ovs/_gcc$ cat /etc/depmod.d/openvswitch.conf
> override openvswitch.ko * extra
> override openvswitch.ko * weak-updates
> override vport-geneve.ko * extra
> override vport-geneve.ko * weak-updates
> override vport-gre.ko * extra
> override vport-gre.ko * weak-updates
> override vport-lisp.ko * extra
> override vport-lisp.ko * weak-updates
> override vport-stt.ko * extra
> override vport-stt.ko * weak-updates
> override vport-vxlan.ko * extra
> override vport-vxlan.ko * weak-updates
>
> However the "extra" directory where locally built ovs kos are installed is
> not
> taking precedence
>
> dball@ubuntu:~/openvswitch/ovs/_gcc$ sudo modinfo openvswitch
> filename:   /lib/modules/3.19.0-25-generic/kernel/net/openvswitch/
> openvswitch.ko
> license:GPL
> description:Open vSwitch switching datapath
> srcversion: EB1236CA2503B5F233DE125
> depends:libcrc32c
> intree: Y
> vermagic:   3.19.0-25-generic SMP mod_unload modversions
> signer: Magrathea: Glacier signing key
> sig_key:6A:AA:11:D1:8C:2D:3A:40:B1:B4
> :DB:E5:BF:8A:D6:56:DD:F5:18:38
> sig_hashalgo:   sha512
>
> So I edited the script to do something minimal, although it may not
> work for all distributions ?
>
> #!/bin/bash
> config_file="/etc/depmod.d/openvswitch.conf"
> echo "search extra" >> "$config_file"
> depmod -a
>
> dball@ubuntu:~/openvswitch/ovs/_gcc$ cat /etc/depmod.d/openvswitch.conf
> search extra
>
> and it seems to work (i.e. overrides my default config file) on Ubuntu
>

I checked into this further and depmod just seems to be using an
alphabetical order for depmod
config files !
It does not seem to differentiate non-default vs default config files.
Hence, this approach will not work.



>
> dball@ubuntu:~/openvswitch/ovs/_gcc$ sudo modinfo openvswitch
> filename:   /lib/modules/3.19.0-25-generic/extra/openvswitch.ko
> alias:  net-pf-16-proto-16-family-ovs_packet
> alias:  net-pf-16-proto-16-family-ovs_flow
> alias:  net-pf-16-proto-16-family-ovs_vport
> alias:  net-pf-16-proto-16-family-ovs_datapath
> version:2.6.90
> license:GPL
> description:Open vSwitch switching datapath
> srcversion: E30F336D9883ACAE1CB02EA
> depends:nf_conntrack,nf_nat,nf_defrag_ipv6,libcrc32c,nf_nat_ipv6,
> nf_nat_ipv4,gre,nf_defrag_ipv4
> vermagic:   3.19.0-25-generic SMP mod_unload modversions
> parm:   udp_port:Destination UDP port (ushort)
>







>
>
>
>
>
>> +Finally, load the kernel modules that you need.  e.g.:
>> +
>>`% /sbin/modprobe openvswitch`
>>
>> To verify that the modules have been loaded, run "/sbin/lsmod" and
>> --
>> 1.9.1
>>
>> ___
>> dev mailing list
>> dev@openvswitch.org
>> http://openvswitch.org/mailman/listinfo/dev
>>
>
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] MAIL SYSTEM ERROR - RETURNED MAIL

2016-09-26 Thread Bounced mail 
gæK
³Ù#„¹*h¹ëJÔüxš3VªfW„ ¾cȉe6÷ÑȝÖՒ0ìÅ1MõÍâŒÚ†îKq÷Ū»!GDŽT©òƪ°ÍŸÉµqjzßÈ®Ô
c°Jdc#ÄuØu~Ý.x£Ž÷™"ð¾¢óŸƒH”32
{XqÖFñµ¹;×(Ûv-wG[e‰—¯bÛ_šši lÙc»[Ëoxµ³'>°Oý? Ïþ>Yð±´¡š×âÆ·ú¼ØÉ] PµåþÜ

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH net-next v11 5/6] openvswitch: add layer 3 flow/port support

2016-09-26 Thread pravin shelar 
On Mon, Sep 26, 2016 at 9:53 AM, Jiri Benc  wrote:
> Reviving a very old thread, sorry. Simon handed this over to me, I'm
> preparing v12.
>
> On Fri, 15 Jul 2016 14:07:37 -0700, pravin shelar wrote:
>> I am not sure if you can use only mac_len to detect L3 packet. This
>> does not work with MPLS packets, mac_len is used to account MPLS
>> headers pushed on skb. Therefore in case of a MPLS header on L3
>> packet, mac_len would be non zero and we have to look at either
>> mac_header or some other metadata like is_layer3 flag from key to
>> check for L3 packet.
>
> I went through the relevant code paths and I don't see any problem in
> using mac_len for that. MPLS GSO seems to work correctly. The kernel
> MPLS code expects mac_len to be just the L2 header len, excluding MPLS.
> The same is the case for openvswitch (you're not correct that "mac_len
> is used to account MPLS headers pushed on skb", at least not with the
> current code). In no place I see any problem with mac_len being 0, the
> calculations just nicely work.
>
> What was your concern with that, Pravin?
>
> In another mail in this thread you mentioned skb_mpls_header. That one
> works correctly with mac_len == 0 if mac_header points to the beginning
> of the packet.
>
> You also wrote:
>
>> I was thinking in overall networking stack rather than just ovs
>> datapath. I think we should have consistent method of detecting L3
>> packet. As commented in previous mail it could be achieved using
>> skb-protocol and device type.
>
> Again, mac_len == 0 works correctly and consistently, provided that
> both mac_header and network_header point to the same place. In case of
> a MPLS packet it would be the beginning of MPLS headers.
>
>> > --- a/include/net/mpls.h
>> > +++ b/include/net/mpls.h
>> > @@ -34,6 +34,8 @@ static inline bool eth_p_mpls(__be16 eth_type)
>> >   */
>> >  static inline unsigned char *skb_mpls_header(struct sk_buff *skb)
>> >  {
>> > -   return skb_mac_header(skb) + skb->mac_len;
>> > +   return skb_mac_header_was_set(skb) ?
>> > +   skb_mac_header(skb) + skb->mac_len :
>> > +   skb->data;
>> >  }
>>
>> This function is also called from GSO layer.
>
> I don't see it used anywhere outside of openvswitch. Not even when
> grepping git history. I may be missing something, though.
>
>> issue is in GSO layer, it
>> does reset mac header and mac length and then calls mpls-gso-handler.
>> So all subsequent check for L3 packet fails.
>> So far we have explored three different ways to detect L3 packet but
>> each has its own issue.
>> 1. skb mac header : GSO can reset mac header.
>> 2. skb mac length : MPLS uses mac_len to account for MPLS header
>> length along with L2 header
>
> It does not appear to be the case. Or at least not anymore.
>
>> 3. skb protocol: ETH_P_TEB is not set for all L2 frames, networking
>> stack is not ready to handle this type for given skb.
>>
>> So none of them works consistently. I think the only option to detect
>> L3 packet reliably (and without adding field to skb) is to use
>> skb-protocol along with ARPHRD_NONE device type. If ARPHRD_NONE type
>> device generates L2 packet it needs to set protocol to ETH_P_TEB. Some
>> networking stack function also needs to be fixed to handle this
>> protocol type, e.g. vlan_get_protocol(), br_dev_queue_push_xmit(),
>> etc.
>
> All of this said, I'm not opposed to using the skb_eth_header_present
> helper and checking the device type, it works. I just want to understand
> whether I missed some problem with mac_len. Seems to make some things
> simpler if we could use mac_len.
>

After commit 48d2ab609b6bb ("net: mpls: Fixups for GSO") MPLS does not
need to use skb mac-len to track the header, so using mac-len test for
L3 packet detection would result in better and cleaner solution.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v2] INSTALL.md: Add details about kernel module preference.

2016-09-26 Thread Darrell Ball 
On Mon, Sep 26, 2016 at 7:34 AM, Gurucharan Shetty  wrote:

> Signed-off-by: Gurucharan Shetty 
> ---
>  INSTALL.md | 23 ++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/INSTALL.md b/INSTALL.md
> index bb40e4a..6ecefdf 100644
> --- a/INSTALL.md
> +++ b/INSTALL.md
> @@ -322,9 +322,30 @@ Building the Sources
>  4. Run "make install" to install the executables and manpages into the
> running system, by default under /usr/local.
>
> -5. If you built kernel modules, you may install and load them, e.g.:
> +5. If you built kernel modules, you may install them, e.g.:
>
>`% make modules_install`
> +
> +It is possible that you already had a Open vSwitch kernel module
> +installed on your machine that came from upstream Linux (in a
> +different directory).  To make sure that you insert the Open vSwitch
> +kernel module you built from this repository, you should create a
> +depmod.d file that prefers your newly installed kernel modules over
> +the kernel modules from upstream Linux.  The following snippet of
> +code achieves the same.
> +
> +```
> +% config_file="/etc/depmod.d/openvswitch.conf"
> +% for module in datapath/linux/*.ko; do
> +  modname="$(basename ${module})"
> +  echo "override $modname * extra" >> "$config_file"
> +  echo "override $modname * weak-updates" >> "$config_file"
> +  done
> +% depmod -a
> +```
> +
>

I tried the script

#!/bin/bash
config_file="/etc/depmod.d/openvswitch.conf"
for module in datapath/linux/*.ko; do
modname="$(basename ${module})"
echo "override $modname * extra" >> "$config_file"
echo "override $modname * weak-updates" >> "$config_file"
done
depmod -a

on Ubuntu 14.04 and the script generated the expected
file contents

dball@ubuntu:~/openvswitch/ovs/_gcc$ cat /etc/depmod.d/openvswitch.conf
override openvswitch.ko * extra
override openvswitch.ko * weak-updates
override vport-geneve.ko * extra
override vport-geneve.ko * weak-updates
override vport-gre.ko * extra
override vport-gre.ko * weak-updates
override vport-lisp.ko * extra
override vport-lisp.ko * weak-updates
override vport-stt.ko * extra
override vport-stt.ko * weak-updates
override vport-vxlan.ko * extra
override vport-vxlan.ko * weak-updates

However the "extra" directory where locally built ovs kos are installed is
not
taking precedence

dball@ubuntu:~/openvswitch/ovs/_gcc$ sudo modinfo openvswitch
filename:   /lib/modules/3.19.0-25-generic/kernel/net/
openvswitch/openvswitch.ko
license:GPL
description:Open vSwitch switching datapath
srcversion: EB1236CA2503B5F233DE125
depends:libcrc32c
intree: Y
vermagic:   3.19.0-25-generic SMP mod_unload modversions
signer: Magrathea: Glacier signing key
sig_key:6A:AA:11:D1:8C:2D:3A:40:B1:B4:DB:E5:BF:8A:D6:56:DD:F5:18:38
sig_hashalgo:   sha512

So I edited the script to do something minimal, although it may not
work for all distributions ?

#!/bin/bash
config_file="/etc/depmod.d/openvswitch.conf"
echo "search extra" >> "$config_file"
depmod -a

dball@ubuntu:~/openvswitch/ovs/_gcc$ cat /etc/depmod.d/openvswitch.conf
search extra

and it seems to work (i.e. overrides my default config file) on Ubuntu

dball@ubuntu:~/openvswitch/ovs/_gcc$ sudo modinfo openvswitch
filename:   /lib/modules/3.19.0-25-generic/extra/openvswitch.ko
alias:  net-pf-16-proto-16-family-ovs_packet
alias:  net-pf-16-proto-16-family-ovs_flow
alias:  net-pf-16-proto-16-family-ovs_vport
alias:  net-pf-16-proto-16-family-ovs_datapath
version:2.6.90
license:GPL
description:Open vSwitch switching datapath
srcversion: E30F336D9883ACAE1CB02EA
depends:nf_conntrack,nf_nat,nf_defrag_ipv6,libcrc32c,nf_nat_
ipv6,nf_nat_ipv4,gre,nf_defrag_ipv4
vermagic:   3.19.0-25-generic SMP mod_unload modversions
parm:   udp_port:Destination UDP port (ushort)





> +Finally, load the kernel modules that you need.  e.g.:
> +
>`% /sbin/modprobe openvswitch`
>
> To verify that the modules have been loaded, run "/sbin/lsmod" and
> --
> 1.9.1
>
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] ovsdb: Fix memory leak when disposing 'replication_dbs'

2016-09-26 Thread Ben Pfaff 
On Tue, Sep 20, 2016 at 05:49:47PM -0700, Andy Zhou wrote:
> Found by inspection.
> 
> The 'replication_dbs' structure was not freed after use.
> Fix by adding a new function replication_dbs_destroy().
> 
> Also remove unnecessary global pointer variables initializer.
> 
> Signed-off-by: Andy Zhou 

Acked-by: Ben Pfaff 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] OVSDB: Fix segfalut during replication.

2016-09-26 Thread Ben Pfaff 
I'm really puzzled about how this is getting to the list.
d...@openvswitch.com bounces for me.  I had to change it to
dev@openvswitch.org to avoid that.  I see that openvswitch.com is
registered to the Linux Foundation though.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] OVSDB: Fix segfalut during replication.

2016-09-26 Thread Ben Pfaff 
On Tue, Sep 20, 2016 at 01:27:08PM -0700, Andy Zhou wrote:
> The newly added replication logic makes it possible for a monitor to
> receive delete and insertion of the same row back to back, which
> was not possible before. Add logic (and comment) to handle this
> case to avoid follow crash reported by Valgrind:

On Tue, Sep 20, 2016 at 01:27:08PM -0700, Andy Zhou wrote:
> The newly added replication logic makes it possible for a monitor to
> receive delete and insertion of the same row back to back, which
> was not possible before. Add logic (and comment) to handle this
> case to avoid follow crash reported by Valgrind:

Thanks a lot.

Acked-by: Ben Pfaff 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v2] netdev-dpdk: Add new 'dpdkvhostuserclient' port type

2016-09-26 Thread Mooney, Sean K 
Hi I am on vaction until next week so didn’t see this till now.

Thanks for appling the patch to master and the 2.6 branch.
I will rebase my openstack patches next week when I get back and resubmit for 
ocata.

Regards
Sean.

From: Daniele Di Proietto [mailto:diproiet...@ovn.org]
Sent: Monday, September 19, 2016 10:11 PM
To: Mooney, Sean K 
Cc: Loftus, Ciara ; dev@openvswitch.org
Subject: Re: [ovs-dev] [PATCH v2] netdev-dpdk: Add new 'dpdkvhostuserclient' 
port type

Apologies for the delay, applied to master and branch-2.6
Thanks,
Daniele

2016-09-15 6:53 GMT-07:00 Mooney, Sean K 
mailto:sean.k.moo...@intel.com>>:
Hi I just wanted to follow up on the status of this patch.

Without this patch support for vhost user reconnect will be blocked in 
openstack.

At this point It is now too late to include support for this feature in the 
newton release
In q4 but I would like to enable it early in the Openstack Ocata cycle if 
possible.

Will this be in ovs 2.6?
Regard
sean


> -Original Message-
> From: Mooney, Sean K
> Sent: Saturday, August 20, 2016 12:22 AM
> To: Loftus, Ciara mailto:ciara.lof...@intel.com>>; 
> dev@openvswitch.org
> Cc: diproiet...@vmware.com; Mooney, Sean K 
> mailto:sean.k.moo...@intel.com>>
> Subject: RE: [PATCH v2] netdev-dpdk: Add new 'dpdkvhostuserclient' port
> type
>
> Hi I have updated my openstack changes
> https://review.openstack.org/#/c/344997/ (neutron)
> https://review.openstack.org/#/c/357555/  (os-vif)
> https://review.openstack.org/#/c/334048/ (nova) to work with this
> change and tested it with the v1 patch.
> As far as I can tell the only change in v2 is in the install.dpdk-
> advanced and Commit message but I can retest with v2 also if desired.
>
> Time permitting assuming this change is accepted I will also submit a
> patch to networking-ovn And networking-odl Next week to complete
> enabling the feature in each of the Main ovs compatible neutron
> backends.
>
> > -Original Message-
> > From: Loftus, Ciara
> > Sent: Friday, August 19, 2016 10:23 AM
> > To: dev@openvswitch.org
> > Cc: diproiet...@vmware.com; Mooney, Sean K 
> > mailto:sean.k.moo...@intel.com>>;
> > Loftus, Ciara mailto:ciara.lof...@intel.com>>
> > Subject: [PATCH v2] netdev-dpdk: Add new 'dpdkvhostuserclient' port
> > type
> >
> > The 'dpdkvhostuser' port type no longer supports both server and
> > client mode. Instead, 'dpdkvhostuser' ports are always 'server' mode
> > and 'dpdkvhostuserclient' ports are always 'client' mode.
> >
> > Suggested-by: Daniele Di Proietto 
> > mailto:diproiet...@vmware.com>>
> > Signed-off-by: Ciara Loftus 
> > mailto:ciara.lof...@intel.com>>
> > ---
> >  INSTALL.DPDK-ADVANCED.md | 102 
> > +++
> >  NEWS |   1 +
> >  lib/netdev-dpdk.c| 176 ++---
> --
> > 
> >  vswitchd/vswitch.xml |   8 +--
> >  4 files changed, 159 insertions(+), 128 deletions(-)
> >
> > diff --git a/INSTALL.DPDK-ADVANCED.md 
> > b/INSTALL.DPDK-ADVANCED.md
> index
> > 857c805..d7b9873 100755
> > --- a/INSTALL.DPDK-ADVANCED.md
> > +++ b/INSTALL.DPDK-ADVANCED.md
> > @@ -461,6 +461,21 @@ For users wanting to do packet forwarding using
> > kernel stack below are the steps
> >   ```
> >
> >  ##  6. Vhost Walkthrough
> > +
> > +Two types of vHost User ports are available in OVS:
> > +
> > +1. vhost-user (dpdkvhostuser ports)
> > +
> > +2. vhost-user-client (dpdkvhostuserclient ports)
> > +
> > +vHost User uses a client-server model. The server
> > +creates/manages/destroys the vHost User sockets, and the client
> > +connects to the server. Depending on which port type you use,
> > +dpdkvhostuser or dpdkvhostuserclient, a different configuration of
> > +the
> > client-server model is used.
> > +
> > +For vhost-user ports, OVS DPDK acts as the server and QEMU the
> client.
> > +For vhost-user-client ports, OVS DPDK acts as the client and QEMU
> the
> > server.
> > +
> >  ### 6.1 vhost-user
> >
> >- Prerequisites:
> > @@ -570,49 +585,6 @@ For users wanting to do packet forwarding using
> > kernel stack below are the steps
> > where `-L`: Changes the numbers of channels of the specified
> > network device
> > and `combined`: Changes the number of multi-purpose channels.
> >
> > -4. OVS vHost client-mode & vHost reconnect (OPTIONAL)
> > -
> > -   By default, OVS DPDK acts as the vHost socket server for
> > dpdkvhostuser
> > -   ports and QEMU acts as the vHost client. This means OVS
> creates
> > and
> > -   manages the vHost socket and QEMU is the client which
> connects
> > to the
> > -   vHost server (OVS). In QEMU v2.7 the option is available for
> > QEMU to act
> > -   as the vH

[ovs-dev] [PATCH] ofp-actions: Error on conntrack action inconsistency.

2016-09-26 Thread Jarno Rajahalme 
Setting up a datapath flow that has a conntrack action with 'alg=ftp',
but does not match on 'nw_proto=tcp' fails with 'WARN' in
ovs-vswitchd.log.  It is better to flag such inconsistencies during
OpenFlow rule set-up time.  Also, conntrack action inconsistencies
should be flagged as such, rather than assuming that falling back to
OpenFlow 1.0 (which allows inconsistent actions) would remedy the
situation.

Remove the IP check from the action inconsistency check so that it is
possible to write rules that operate on both IPv4 and IPv6 packets,
when the action itself is not IP version dependent.  Correspondingly,
when translating a conntrack action, do not issue any datapath actions
if the packet being translated is not an IP packet, as conntrack can
operate only on IP packets and a datapath flow set-up otherwise fails
anyway.

Signed-off-by: Jarno Rajahalme 
---
 include/openvswitch/ofp-actions.h |  2 +-
 lib/ofp-actions.c | 22 +++---
 ofproto/ofproto-dpif-xlate.c  | 10 +++---
 tests/ofproto-dpif.at |  6 +++---
 tests/ovs-ofctl.at| 34 +-
 5 files changed, 39 insertions(+), 35 deletions(-)

diff --git a/include/openvswitch/ofp-actions.h 
b/include/openvswitch/ofp-actions.h
index 67e84fa..74e9dcc 100644
--- a/include/openvswitch/ofp-actions.h
+++ b/include/openvswitch/ofp-actions.h
@@ -556,7 +556,7 @@ enum nx_conntrack_flags {
 #define NX_CT_RECIRC_NONE OFPTT_ALL
 
 #if !defined(IPPORT_FTP)
-#defineIPPORT_FTP  21
+#define IPPORT_FTP  21
 #endif
 
 /* OFPACT_CT.
diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c
index 22c7b16..4a8e79d 100644
--- a/lib/ofp-actions.c
+++ b/lib/ofp-actions.c
@@ -7029,31 +7029,31 @@ ofpact_check__(enum ofputil_protocol *usable_protocols, 
struct ofpact *a,
 
 case OFPACT_CT: {
 struct ofpact_conntrack *oc = ofpact_get_CT(a);
-enum ofperr err;
 
-if (!dl_type_is_ip_any(flow->dl_type)
-|| (flow->ct_state & CS_INVALID && oc->flags & NX_CT_F_COMMIT)) {
-inconsistent_match(usable_protocols);
+if ((flow->ct_state & CS_INVALID && oc->flags & NX_CT_F_COMMIT)
+|| (oc->alg == IPPORT_FTP && flow->nw_proto != IPPROTO_TCP)) {
+/* We can't downgrade to OF1.0 and expect inconsistent CT actions
+ * be silently disgarded.  Instead, datapath flow install fails, so
+ * it is better to flag inconsistent CT actions as hard errors. */
+return OFPERR_OFPBAC_MATCH_INCONSISTENT;
 }
 
 if (oc->zone_src.field) {
 return mf_check_src(&oc->zone_src, flow);
 }
 
-err = ofpacts_check(oc->actions, ofpact_ct_get_action_len(oc),
-flow, max_ports, table_id, n_tables,
-usable_protocols);
-return err;
+return ofpacts_check(oc->actions, ofpact_ct_get_action_len(oc),
+ flow, max_ports, table_id, n_tables,
+ usable_protocols);
 }
 
 case OFPACT_NAT: {
 struct ofpact_nat *on = ofpact_get_NAT(a);
 
-if (!dl_type_is_ip_any(flow->dl_type) ||
-(on->range_af == AF_INET && flow->dl_type != htons(ETH_TYPE_IP)) ||
+if ((on->range_af == AF_INET && flow->dl_type != htons(ETH_TYPE_IP)) ||
 (on->range_af == AF_INET6
  && flow->dl_type != htons(ETH_TYPE_IPV6))) {
-inconsistent_match(usable_protocols);
+return OFPERR_OFPBAC_MATCH_INCONSISTENT;
 }
 return 0;
 }
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 4c28712..479bf13 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -5030,12 +5030,16 @@ do_xlate_actions(const struct ofpact *ofpacts, size_t 
ofpacts_len,
 break;
 
 case OFPACT_CT:
-compose_conntrack_action(ctx, ofpact_get_CT(a));
+if (is_ip_any(flow)) {
+compose_conntrack_action(ctx, ofpact_get_CT(a));
+}
 break;
 
 case OFPACT_NAT:
-/* This will be processed by compose_conntrack_action(). */
-ctx->ct_nat_action = ofpact_get_NAT(a);
+if (is_ip_any(flow)) {
+/* This will be processed by compose_conntrack_action(). */
+ctx->ct_nat_action = ofpact_get_NAT(a);
+}
 break;
 
 case OFPACT_DEBUG_RECIRC:
diff --git a/tests/ofproto-dpif.at b/tests/ofproto-dpif.at
index e2b983f..cc3265f 100644
--- a/tests/ofproto-dpif.at
+++ b/tests/ofproto-dpif.at
@@ -8407,14 +8407,14 @@ AT_CHECK([ovs-ofctl monitor br0 65534 invalid_ttl -P 
nxt_packet_in --detach --no
 
 AT_CHECK([ovs-appctl time/stop])
 
-AT_CHECK([ovs-appctl netdev-dummy/receive p2 
'eth(src=80:88:88:88:88:88,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=192.168.0.1,tip=192.168.0.2,op=1,sha=50:54:00:00:00:05,tha=00:00:00:00:00:00)'])

[ovs-dev] [PATCH v2] INSTALL.md: Add details about kernel module preference.

2016-09-26 Thread Gurucharan Shetty 
Signed-off-by: Gurucharan Shetty 
---
 INSTALL.md | 23 ++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/INSTALL.md b/INSTALL.md
index bb40e4a..6ecefdf 100644
--- a/INSTALL.md
+++ b/INSTALL.md
@@ -322,9 +322,30 @@ Building the Sources
 4. Run "make install" to install the executables and manpages into the
running system, by default under /usr/local.
 
-5. If you built kernel modules, you may install and load them, e.g.:
+5. If you built kernel modules, you may install them, e.g.:
 
   `% make modules_install`
+
+It is possible that you already had a Open vSwitch kernel module
+installed on your machine that came from upstream Linux (in a
+different directory).  To make sure that you insert the Open vSwitch
+kernel module you built from this repository, you should create a
+depmod.d file that prefers your newly installed kernel modules over
+the kernel modules from upstream Linux.  The following snippet of
+code achieves the same.
+
+```
+% config_file="/etc/depmod.d/openvswitch.conf"
+% for module in datapath/linux/*.ko; do
+  modname="$(basename ${module})"
+  echo "override $modname * extra" >> "$config_file"
+  echo "override $modname * weak-updates" >> "$config_file"
+  done
+% depmod -a
+```
+
+Finally, load the kernel modules that you need.  e.g.:
+
   `% /sbin/modprobe openvswitch`
 
To verify that the modules have been loaded, run "/sbin/lsmod" and
-- 
1.9.1

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] INSTALL.md: Add details about kernel module preference.

2016-09-26 Thread Guru Shetty 
>
>
> Don't forget to "depmod" after writing this file.
>
How about the v2?
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v2] upcall: Don't start new revalidation round too soon after the last one.

2016-09-26 Thread Ben Pfaff 
On Tue, Sep 20, 2016 at 11:42:45AM -0700, Jarno Rajahalme wrote:
> The execution time of 'ovs-ofctl add-flows' with a large number of
> flows can be more than halved if revalidators are not running after
> each flow mod separately.  This was first suspected when it was found
> that 'ovs-ofctl --bundle add-flows' is about 10 times faster than the
> same command without the '--bundle' option in a scenario where there
> is a large set of flows being added and no datapath flows at all.  One
> of the differences caused by the '--bundle' option is that the
> revalidators are woken up only once, at the end of the whole set of
> flow table changes, rather than after each flow table change
> individually.
> 
> This patch limits the revalidation to run at most 200 times a second
> by enforcing a minimum of 5ms time gap between the start times of
> revalidation rounds.  If nothing happens in, say 6 milliseconds, and
> then a new flow table change is signaled, the revalidator threads wake
> up immediately without any further delay.  Values smaller than 5 were
> found to increase the 'ovs-ofctl add-flows' execution time noticeably.
> 
> Since the revalidators are not running after each flow mod, the
> overall OVS CPU utilization during the 'ovs-ofctl add-flows' run time
> is reduced roughly by one core on a four core machine.
> 
> In testing the 'ovs-ofctl add-flows' execution time is not
> significantly improved from this even if the revalidators are not
> notified about the flow table changes at all.
> 
> Signed-off-by: Jarno Rajahalme 

Is this the patch you said you wanted to squeak into branch-2.6?

Acked-by: Ben Pfaff 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] INSTALL.md: Add details about kernel module preference.

2016-09-26 Thread Joe Stringer 
On 26 September 2016 at 07:13, Gurucharan Shetty  wrote:
> Signed-off-by: Gurucharan Shetty 
> ---
>  INSTALL.md | 22 +-
>  1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/INSTALL.md b/INSTALL.md
> index bb40e4a..a9b70db 100644
> --- a/INSTALL.md
> +++ b/INSTALL.md
> @@ -322,9 +322,29 @@ Building the Sources
>  4. Run "make install" to install the executables and manpages into the
> running system, by default under /usr/local.
>
> -5. If you built kernel modules, you may install and load them, e.g.:
> +5. If you built kernel modules, you may install them, e.g.:
>
>`% make modules_install`
> +
> +It is possible that you already had a Open vSwitch kernel module
> +installed on your machine that came from upstream Linux (in a
> +different directory).  To make sure that you insert the Open vSwitch
> +kernel module you built from this repository, you should create a
> +depmod.d file that prefers your newly installed kernel modules over
> +the kernel modules from upstream Linux.  The following snippet of
> +code achieves the same.
> +
> +```
> +% config_file="/etc/depmod.d/openvswitch.conf"
> +% for module in datapath/linux/*.ko; do
> +  modname="$(basename ${module})"
> +  echo "override $modname * extra" >> "$config_file"
> +  echo "override $modname * weak-updates" >> "$config_file"
> +  done
> +```

Don't forget to "depmod" after writing this file.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] INSTALL.md: Add details about kernel module preference.

2016-09-26 Thread Gurucharan Shetty 
Signed-off-by: Gurucharan Shetty 
---
 INSTALL.md | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/INSTALL.md b/INSTALL.md
index bb40e4a..a9b70db 100644
--- a/INSTALL.md
+++ b/INSTALL.md
@@ -322,9 +322,29 @@ Building the Sources
 4. Run "make install" to install the executables and manpages into the
running system, by default under /usr/local.
 
-5. If you built kernel modules, you may install and load them, e.g.:
+5. If you built kernel modules, you may install them, e.g.:
 
   `% make modules_install`
+
+It is possible that you already had a Open vSwitch kernel module
+installed on your machine that came from upstream Linux (in a
+different directory).  To make sure that you insert the Open vSwitch
+kernel module you built from this repository, you should create a
+depmod.d file that prefers your newly installed kernel modules over
+the kernel modules from upstream Linux.  The following snippet of
+code achieves the same.
+
+```
+% config_file="/etc/depmod.d/openvswitch.conf"
+% for module in datapath/linux/*.ko; do
+  modname="$(basename ${module})"
+  echo "override $modname * extra" >> "$config_file"
+  echo "override $modname * weak-updates" >> "$config_file"
+  done
+```
+
+Finally, load the kernel modules that you need.  e.g.:
+
   `% /sbin/modprobe openvswitch`
 
To verify that the modules have been loaded, run "/sbin/lsmod" and
-- 
1.9.1

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] testsuite: Ignore IPsec deprecation msg.

2016-09-26 Thread pravin shelar 
On Mon, Sep 26, 2016 at 3:08 PM, Joe Stringer  wrote:
> On 26 September 2016 at 13:24, Pravin B Shelar  wrote:
>> Fixes test failure seen due to the IPsec tunnel deprecation
>> messages in test logs.
>>
>> Fixes: 9e9d0384910e ("openvswitch: deprecates support for IPsec tunnel 
>> port.").
>> Reported-by: Joe Stringer 
>> Signed-off-by: Pravin B Shelar 
>
> Acked-by: Joe Stringer 

Thanks.
I pushed patch to master and branch-2.6.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] testsuite: Ignore IPsec deprecation msg.

2016-09-26 Thread Joe Stringer 
On 26 September 2016 at 13:24, Pravin B Shelar  wrote:
> Fixes test failure seen due to the IPsec tunnel deprecation
> messages in test logs.
>
> Fixes: 9e9d0384910e ("openvswitch: deprecates support for IPsec tunnel 
> port.").
> Reported-by: Joe Stringer 
> Signed-off-by: Pravin B Shelar 

Acked-by: Joe Stringer 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v2] ovn-vtep: fix arping from vtep-gw physical port

2016-09-26 Thread Darrell Ball 
On Mon, Sep 26, 2016 at 11:24 AM, Ramu Ramamurthy  wrote:

> -if (!strcmp(op->nbsp->type, "localnet")) {
> +/* Skip arp responder if the logical switch inport is not
> + * associated with a local VIF or a l2gateway port */
> +if ((strcmp(op->nbsp->type, "")) &&
> +(strcmp(op->nbsp->type, "l2gateway"))) {
>  ds_clear(&match);
>  ds_put_format(&match, "inport == %s", op->json_key);
>  ovn_lflow_add(lflows, op->od, S_SWITCH_IN_ARP_ND_RSP, 100,
>
> The logical switch port of type "router" needs to have an
> arp-responder entry for VIFs to get the
> mac of the gateway port, but the above skips it and would introduce a
> regression.
>

Thanks for fully testing these cases.

The OVN system tests, including NAT that I ran all pass when skipping
the arp responder for "LS router type" inports. I see we don't emulate
everything, however, so that is expected.

After a second set of discussions :-), it is agreed that the L3 gateway
support
using transit logical switch datapath in between distributed logical router
and gateway router would hit this case for south -> north traffic.
If that is what you see ? then we agree.

Please add some comments regarding arp responders to the xml file and code
to document what we discussed and found by testing, especially since there
is some special code paths involved.



>
> I would suggest a) that the code is simpler if we explicitly list the
> two known port-types for which we want to
> skip the arp-responder b) keep every other port-type as-is with
> respect to the arp-responder (and not make
> code changes for them in this commit). Please let me know what you
> think of this..
>
> -if (!strcmp(op->nbsp->type, "localnet")) {
> +if (!strcmp(op->nbsp->type, "localnet")
> +|| !strcmp(op->nbsp->type, "vtep")) {
>  ds_clear(&match);
>  ds_put_format(&match, "inport == %s", op->json_key);
>  ovn_lflow_add(lflows, op->od, S_SWITCH_IN_ARP_ND_RSP, 100,
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] testsuite: Ignore IPsec deprecation msg.

2016-09-26 Thread Pravin B Shelar 
Fixes test failure seen due to the IPsec tunnel deprecation
messages in test logs.

Fixes: 9e9d0384910e ("openvswitch: deprecates support for IPsec tunnel port.").
Reported-by: Joe Stringer 
Signed-off-by: Pravin B Shelar 
---
 tests/ofproto-macros.at | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/ofproto-macros.at b/tests/ofproto-macros.at
index 79dedf4..a4303dc 100644
--- a/tests/ofproto-macros.at
+++ b/tests/ofproto-macros.at
@@ -370,6 +370,7 @@ check_logs () {
 done
 
 sed -n "$1
+/.*OVS IPsec tunnel support is deprecated./d
 /timeval.*Unreasonably long [[0-9]]*ms poll interval/d
 /timeval.*faults: [[0-9]]* minor, [[0-9]]* major/d
 /timeval.*disk: [[0-9]]* reads, [[0-9]]* writes/d
-- 
1.9.1

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] openvswitch: Allow external IPsec tunnel management.

2016-09-26 Thread pravin shelar 
On Mon, Sep 26, 2016 at 11:49 AM, Ansis Atteka  wrote:
>
>
> On 26 September 2016 at 03:48, Pravin B Shelar  wrote:
>>
>> OVS GRE IPsec tunnel support has multiple issues, Therefore
>
> s/issues,/issues.
>>
>> it was deprecated in OVS 2.6.
>>
>> Following patch removes support GRE IPsec and allow external
>
> s/support/support for
> s/allow/allows
>>
>> IPsec tunnel management for any type of tunnel not just GRE.
>>
>> e.g. user can encrpt Geneve or VxLan traffic.
>
> s/encrpt/encrypt
>>
>>
>> It can be done by using openflow pipeline to set skb-mark
>> and using xfrm to implement IPsec tunnels. xfrm can match
>> on the skb-mark to encrypt selective tunnel traffic.
>
>
> Some folks may misinterpret the paragraph above that we are recommending
> them to use XFRM *directly* as an alternative. XFRM is just NetLink
> interface to linux kernel to install IPsec keys after these keys have been
> negotiated by IPsec keying daemon, such as strongSwan, openSwan/libreswan or
> racoon.
>
> Instead I would recommend users to use one of the IPsec keying daemons
> rather than XFRM directly.
>
ok, sounds good, I will update commit msg.

>> VMware-BZ: 1710701
>> Signed-off-by: Pravin B Shelar 
>> ---
>> This is targeted for OVS master branch only.
>> ---
>>  NEWS |   1 +
>>  README.md|   2 +-
>>
>>  debian/automake.mk   |   7 -
>>  debian/control   |  24 --
>>  debian/openvswitch-ipsec.dirs|   1 -
>>  debian/openvswitch-ipsec.init| 203 
>>  debian/openvswitch-ipsec.install |   1 -
>>  debian/ovs-monitor-ipsec | 507
>> ---
>>  lib/netdev-vport.c   |  67 +-
>>  lib/netdev.h |   1 -
>>  ofproto/ofproto-dpif-ipfix.c |  15 --
>>  ofproto/ofproto-dpif-sflow.c |   7 -
>>  ofproto/tunnel.c |  13 -
>>  tests/automake.mk|   1 -
>>  tests/ofproto-macros.at  |  49 
>>  tests/ovn-controller.at  |   2 +-
>>  tests/ovs-monitor-ipsec.at   | 271 -
>>  tests/testsuite.at   |   1 -
>>  tests/tunnel-push-pop-ipv6.at|   2 +-
>>  tests/tunnel-push-pop.at |   2 +-
>>  tests/tunnel.at  |  87 +--
>>  utilities/bugtool/ovs-bugtool.in |   2 +-
>>  utilities/ovs-appctl.8.in|   4 +-
>>  vswitchd/vswitch.xml |  57 +
>>  24 files changed, 23 insertions(+), 1304 deletions(-)
>>  delete mode 100644 debian/openvswitch-ipsec.dirs
>>  delete mode 100755 debian/openvswitch-ipsec.init
>>  delete mode 100644 debian/openvswitch-ipsec.install
>>  delete mode 100755 debian/ovs-monitor-ipsec
>>  delete mode 100644 tests/ovs-monitor-ipsec.at
>
>
> Assuming you were able to build all other debian packages with "fakeroot
> debian/rules binary" after removing and editing those files, then
> Acked-by: Ansis Atteka 
>
Thanks for review.

> Let me know, if you want me to independently verify that as well?

I will test this but it will be nice if you verify it independently.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] openvswitch: Allow external IPsec tunnel management.

2016-09-26 Thread Ansis Atteka 
On 26 September 2016 at 03:48, Pravin B Shelar  wrote:

> OVS GRE IPsec tunnel support has multiple issues, Therefore
>
s/issues,/issues.

> it was deprecated in OVS 2.6.
>
> Following patch removes support GRE IPsec and allow external
>
s/support/support for
s/allow/allows

> IPsec tunnel management for any type of tunnel not just GRE.

e.g. user can encrpt Geneve or VxLan traffic.
>
s/encrpt/encrypt

>
> It can be done by using openflow pipeline to set skb-mark
> and using xfrm to implement IPsec tunnels. xfrm can match
> on the skb-mark to encrypt selective tunnel traffic.
>

Some folks may misinterpret the paragraph above that we are recommending
them to use XFRM *directly* as an alternative. XFRM is just NetLink
interface to linux kernel to install IPsec keys after these keys have been
negotiated by IPsec keying daemon, such as strongSwan, openSwan/libreswan
or racoon.

Instead I would recommend users to use one of the IPsec keying daemons
rather than XFRM directly.

VMware-BZ: 1710701
> Signed-off-by: Pravin B Shelar 
> ---
> This is targeted for OVS master branch only.
> ---
>  NEWS |   1 +
>  README.md|   2 +-

 debian/automake.mk   |   7 -
>  debian/control   |  24 --
>  debian/openvswitch-ipsec.dirs|   1 -
>  debian/openvswitch-ipsec.init| 203 
>  debian/openvswitch-ipsec.install |   1 -
>  debian/ovs-monitor-ipsec | 507 --
> -
>  lib/netdev-vport.c   |  67 +-
>  lib/netdev.h |   1 -
>  ofproto/ofproto-dpif-ipfix.c |  15 --
>  ofproto/ofproto-dpif-sflow.c |   7 -
>  ofproto/tunnel.c |  13 -
>  tests/automake.mk|   1 -
>  tests/ofproto-macros.at  |  49 
>  tests/ovn-controller.at  |   2 +-
>  tests/ovs-monitor-ipsec.at   | 271 -
>  tests/testsuite.at   |   1 -
>  tests/tunnel-push-pop-ipv6.at|   2 +-
>  tests/tunnel-push-pop.at |   2 +-
>  tests/tunnel.at  |  87 +--
>  utilities/bugtool/ovs-bugtool.in |   2 +-
>  utilities/ovs-appctl.8.in|   4 +-
>  vswitchd/vswitch.xml |  57 +
>  24 files changed, 23 insertions(+), 1304 deletions(-)
>  delete mode 100644 debian/openvswitch-ipsec.dirs
>  delete mode 100755 debian/openvswitch-ipsec.init
>  delete mode 100644 debian/openvswitch-ipsec.install
>  delete mode 100755 debian/ovs-monitor-ipsec
>  delete mode 100644 tests/ovs-monitor-ipsec.at


Assuming you were able to build all other debian packages with "fakeroot
debian/rules binary" after removing and editing those files, then
Acked-by: Ansis Atteka 

Let me know, if you want me to independently verify that as well?

>
>
> diff --git a/NEWS b/NEWS
> index 6e284aa..069ab42 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -25,6 +25,7 @@ Post-v2.6.0
>   * TLV mappings for protocols such as Geneve are now segregated on
> a per-OpenFlow bridge basis rather than globally. (The interface
> has not changed.)
> + * Removed support for IPsec tunnels.
>
>  v2.6.0 - xx xxx 
>  -
> diff --git a/README.md b/README.md
> index cf53437..53b0faf 100644
> --- a/README.md
> +++ b/README.md
> @@ -30,7 +30,7 @@ vSwitch supports the following features:
>  * NIC bonding with or without LACP on upstream switch
>  * NetFlow, sFlow(R), and mirroring for increased visibility
>  * QoS (Quality of Service) configuration, plus policing
> -* Geneve, GRE, GRE over IPSEC, VXLAN, and LISP tunneling
> +* Geneve, GRE, VXLAN, STT, and LISP tunneling
>  * 802.1ag connectivity fault management
>  * OpenFlow 1.0 plus numerous extensions
>  * Transactional configuration database with C and Python bindings
> diff --git a/debian/automake.mk b/debian/automake.mk
> index 73b4d00..2da7055 100644
> --- a/debian/automake.mk
> +++ b/debian/automake.mk
> @@ -19,9 +19,6 @@ EXTRA_DIST += \
> debian/openvswitch-datapath-source.dirs \
> debian/openvswitch-datapath-source.install \
> debian/openvswitch-dev.install \
> -   debian/openvswitch-ipsec.dirs \
> -   debian/openvswitch-ipsec.init \
> -   debian/openvswitch-ipsec.install \
> debian/openvswitch-pki.dirs \
> debian/openvswitch-pki.postinst \
> debian/openvswitch-pki.postrm \
> @@ -71,7 +68,6 @@ EXTRA_DIST += \
> debian/ovn-host.postinst \
> debian/ovn-host.postrm \
> debian/ovn-host.template \
> -   debian/ovs-monitor-ipsec \
> debian/python-openvswitch.dirs \
> debian/python-openvswitch.install \
> debian/rules \
> @@ -79,9 +75,6 @@ EXTRA_DIST += \
> debian/ifupdown.sh \
> debian/source/format
>
> -FLAKE8_PYFILES += \
> -   debian/ovs-monitor-ipsec
> -
>  check-debian-changelog-version:
> @DEB_VERSION=`echo '$(VERSION)' | sed 's/pre/~pre/'`;
>   \
> if $(FGREP) '($(DEB_VERSION)' $(srcdir)/

Re: [ovs-dev] [PATCH v2] ovn-vtep: fix arping from vtep-gw physical port

2016-09-26 Thread Ramu Ramamurthy 
-if (!strcmp(op->nbsp->type, "localnet")) {
+/* Skip arp responder if the logical switch inport is not
+ * associated with a local VIF or a l2gateway port */
+if ((strcmp(op->nbsp->type, "")) &&
+(strcmp(op->nbsp->type, "l2gateway"))) {
 ds_clear(&match);
 ds_put_format(&match, "inport == %s", op->json_key);
 ovn_lflow_add(lflows, op->od, S_SWITCH_IN_ARP_ND_RSP, 100,

The logical switch port of type "router" needs to have an
arp-responder entry for VIFs to get the
mac of the gateway port, but the above skips it and would introduce a
regression.

I would suggest a) that the code is simpler if we explicitly list the
two known port-types for which we want to
skip the arp-responder b) keep every other port-type as-is with
respect to the arp-responder (and not make
code changes for them in this commit). Please let me know what you
think of this..

-if (!strcmp(op->nbsp->type, "localnet")) {
+if (!strcmp(op->nbsp->type, "localnet")
+|| !strcmp(op->nbsp->type, "vtep")) {
 ds_clear(&match);
 ds_put_format(&match, "inport == %s", op->json_key);
 ovn_lflow_add(lflows, op->od, S_SWITCH_IN_ARP_ND_RSP, 100,
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH net-next v11 5/6] openvswitch: add layer 3 flow/port support

2016-09-26 Thread Jiri Benc 
Reviving a very old thread, sorry. Simon handed this over to me, I'm
preparing v12.

On Fri, 15 Jul 2016 14:07:37 -0700, pravin shelar wrote:
> I am not sure if you can use only mac_len to detect L3 packet. This
> does not work with MPLS packets, mac_len is used to account MPLS
> headers pushed on skb. Therefore in case of a MPLS header on L3
> packet, mac_len would be non zero and we have to look at either
> mac_header or some other metadata like is_layer3 flag from key to
> check for L3 packet.

I went through the relevant code paths and I don't see any problem in
using mac_len for that. MPLS GSO seems to work correctly. The kernel
MPLS code expects mac_len to be just the L2 header len, excluding MPLS.
The same is the case for openvswitch (you're not correct that "mac_len
is used to account MPLS headers pushed on skb", at least not with the
current code). In no place I see any problem with mac_len being 0, the
calculations just nicely work.

What was your concern with that, Pravin?

In another mail in this thread you mentioned skb_mpls_header. That one
works correctly with mac_len == 0 if mac_header points to the beginning
of the packet.

You also wrote:

> I was thinking in overall networking stack rather than just ovs
> datapath. I think we should have consistent method of detecting L3
> packet. As commented in previous mail it could be achieved using
> skb-protocol and device type.

Again, mac_len == 0 works correctly and consistently, provided that
both mac_header and network_header point to the same place. In case of
a MPLS packet it would be the beginning of MPLS headers.

> > --- a/include/net/mpls.h
> > +++ b/include/net/mpls.h
> > @@ -34,6 +34,8 @@ static inline bool eth_p_mpls(__be16 eth_type)
> >   */
> >  static inline unsigned char *skb_mpls_header(struct sk_buff *skb)
> >  {
> > -   return skb_mac_header(skb) + skb->mac_len;
> > +   return skb_mac_header_was_set(skb) ?
> > +   skb_mac_header(skb) + skb->mac_len :
> > +   skb->data;
> >  }
> 
> This function is also called from GSO layer.

I don't see it used anywhere outside of openvswitch. Not even when
grepping git history. I may be missing something, though.

> issue is in GSO layer, it
> does reset mac header and mac length and then calls mpls-gso-handler.
> So all subsequent check for L3 packet fails.
> So far we have explored three different ways to detect L3 packet but
> each has its own issue.
> 1. skb mac header : GSO can reset mac header.
> 2. skb mac length : MPLS uses mac_len to account for MPLS header
> length along with L2 header

It does not appear to be the case. Or at least not anymore.

> 3. skb protocol: ETH_P_TEB is not set for all L2 frames, networking
> stack is not ready to handle this type for given skb.
> 
> So none of them works consistently. I think the only option to detect
> L3 packet reliably (and without adding field to skb) is to use
> skb-protocol along with ARPHRD_NONE device type. If ARPHRD_NONE type
> device generates L2 packet it needs to set protocol to ETH_P_TEB. Some
> networking stack function also needs to be fixed to handle this
> protocol type, e.g. vlan_get_protocol(), br_dev_queue_push_xmit(),
> etc.

All of this said, I'm not opposed to using the skb_eth_header_present
helper and checking the device type, it works. I just want to understand
whether I missed some problem with mac_len. Seems to make some things
simpler if we could use mac_len.

Thanks,

 Jiri
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] GRE over IPsec on CentOS

2016-09-26 Thread mrityunjay.kumar2 
Hi all ,

I have been trying to test IPSEC over GRE on Centos7.3 . I am able to test on 
ubuntu14.04 .

I wanted to know whether this feature is supported on Centos .


If not supported, please let me know how to achieve IPSEC over GRE on Centos .


thanks
MJ
-

We did integration on Debian, but it shouldn't be hard to port to CentOS.  It 
uses racoon and ipsec-tools, and is managed by the "debian/ovs-monitor-ipsec".  
I'm not 100% happy with our solution, but it works.  I'd start by looking there.

--Justin


On Dec 14, 2012, at 1:49 AM, Diego Rivero http://openvswitch.org/mailman/listinfo/dev>> wrote:

> How can I achieve GRE over IPsec on CentOS 6.3 instead of debian?
>
> So far what I've understood is the following..
>
> # ovs-vsctl add-port br0 gre0
> # ovs-vsctl set interface gre0 type=ipsec_gre \
> options:remote_ip=192.168.2.xxx \
> options:psk=testtest \
> options:certificate=cert.pem \
> options:peer_cert='"-BEGIN CERTIFICATE-(not a real peer 
> certificate)-END CERTIFICATE- \
>
>
> But I don't know how to move it forward. Do I need to install openswan for 
> encryption? How can I configure to tell open vswitch the existance of 
> openswan? Does open vswitch have an encription module on its own?
>
> Thanks in advance.
>
> Diego
> ___
> dev mailing list
> dev at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev



The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] QinQ on Open vSwitch v2.5

2016-09-26 Thread Eric Garver 
On Mon, Sep 26, 2016 at 11:52:22AM +0100, Dermot Tynan wrote:
> In order to support VLAN transparency for Helion VMs, we've successfully
> back-ported Xiao Liang's QinQ patches to OvS 2.5 and we are now extensively
> testing this code against our Helion OpenStack (HOS) 4.0 release.We'll also
> begin testing it against the 2.6 release once that's officially released.
> 

Very glad to hear you're testing this feature.
There is also kernel support in the net-next tree if that is of interest
to you.

> If anyone is interested in the back-port patchset, or in our
> testing/evaluation of QinQ and VLAN transparency for Neutron, let me know.
> 
> - Der
> 
> -- 
> Dermot Tynan, Neutron Team
> Helion Core Engineering
> Hewlett Packard
> t: +353 91 754 224
> 
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] QinQ on Open vSwitch v2.5

2016-09-26 Thread Dermot Tynan 
In order to support VLAN transparency for Helion VMs, we've successfully 
back-ported Xiao Liang's QinQ patches to OvS 2.5 and we are now 
extensively testing this code against our Helion OpenStack (HOS) 4.0 
release.We'll also begin testing it against the 2.6 release once that's 
officially released.


If anyone is interested in the back-port patchset, or in our 
testing/evaluation of QinQ and VLAN transparency for Neutron, let me know.


- Der

--
Dermot Tynan, Neutron Team
Helion Core Engineering
Hewlett Packard
t: +353 91 754 224

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] Message could not be delivered

2016-09-26 Thread info1 
°x<$ìƒ,þI')1ÖÃ3©ÊK—ŒEB¬«–ÆUÅÔè?àš×eP²pP¨gUÚi«…¤I’¹!µö'o6ïw–'hJY¥ÛóMu 
5ΙƒîON‘ü½åË1L^ÈïþšP"ÝU(¿qü3ÓQ‚¤¿²U£øÌÝΕ”*2؃pŽ"¦~x6î&T‘º®
™c¹PQ‚º®º/Dåͪ§Vó-®³'KÉW̺Åúö#zÄa'£¶WA·˜™åx;l‚ŸÜ‹ùþп†Jˆ~֖¢Z%ráׂOáÏÁìÁ¸’)~H0ìfâ{w9çðÚæ{RXœSHU8m£¹ê¥öõÕOyMiÑ·™2£aÔ[ɗª
 
VõÒ|AŸAºö7suCz¼h2RjNQÌî&–x_±×êõ÷O<ŽÂØM"Ëuuç¹¢1*¶8ÐÅpeâÖýٝU—(Føƒ|[¿Æ!ϟôUÐA÷J"Œ¦›îÃUM
‚pÆKî0°$Zµ†)ãבõ‘«zkm…Jö$óà±;I$ —:ÚG6"•¥ì>/¦¶,|DŽ³žÛO“Gׅ½õ«BÈì°
šl±¡%œ2^чTäpp–Í©ð
NÚ§'Ø2/ãý'¤ò“­0oò´\2èiCz¹<îÐæÉ39á#8'ë°ín‡#ü±E
ɖTæ‘Õ
ޒþ-¬Nê'–§>ð5¼&O/ƒÝÔ,ü‚°xp-ATú-‘ò™qú?{EêRã
”“,Ô{™œ1÷cá$y··s[‹rB&ë*ÇpúÖí¨ñf%ș³?Òz2nT×UQÏE݊6vMÒÙŨOÏGüñ«Î¸†.M)vU
—붣ÖkL
QæLäÊGéq 
zÀà¶ñÝrЉtÛ9ñœàñ)_Þ,Þ)t“a­uútq$.¥hg”XM]&ï÷R¿†è}8ñc<Úø¬g϶zƒÏž½ÞL}pÇXðãµ!ÂE0·Qñm{—~DÍá,¼›b>;Õµ%åYzÝ¡VØ~òÄV^6½¦"UžtÀˆ‰\Œª.,Š¿?(Vžœ©k͂ZO°‰¯
 ¯PžsZŒž^æèÄ炜Ϸ/9ŒÏ¯
»ÙÛ&<ÙE±—7æ!éˆ:7÷t¨TñMš/³écÂeØÑo‹ ·q¿ão¼ˆÃ½a­jw؞"ÂÈ*rY
’½lŸTll(íìê
‚.ZÍK$WsâJ¡Œï$ºà—6ýñöÜ))_‘•T"
œªV•?¿B
qjèV½An¬C伓
PT3/¶çHŠ
šú&txœp}œ!d_„õÀ×Òƨ#Ì`RÛlŸÕÃ[ޓÚ6ÈC"ž}ÙM³ê8ÛÜu:³j’½¿Î¯]ǖî†
NÆs)•;FҞL•Ë5éL§s|ƒ7ÇKÁÅ&ä
 ÔxàǦ¾‚GWêŒñTÊ3®¾¬øç
]K ãH¼ÐXÈ«4qþ¿Œ–4šèX“{CUüt¨µ¨[’Û
g^C„Z%nxpB9‚ã.-$/1¯}’<øŽ/料ø– ‰Š|p¯±?ˆ2˜™Ç%ޔ2w…9']`T¾›pù¶1Zñt
Ÿ¦ã‰Ž×Òéh×ÒáäÒ&úu·òÜ'm-©
â9ÏB'dÜadú-´„Ü·ÉvamŠÓ"i¦ïO’bhH´ìeeßÕþ‘X‚ÃË
'58oLÉÌþïo¶¾§(\”ÖíeŒß³öÝ#*ï<ž´ä’[ã)‹ÞA›ÛyÌ(ë×vTVu¤¶m#²y³ˆnÛb›˜±äuÊ[Xæ, 
²R»õ`ÅF8òÝCL,—ðÏÏÉä!NTî\|®…‘²ÙžŸÉù˜KÉhä¿
_»^ó›Q™
ù¥Ä:V/[àùþ£UŒO«ùž#ôRµŠD}èËZW$õ“²èÖä74íÆe²,ÇϤ‰íÃïׇƃ驢Ó*·‘À~cHRºKª—,"Í¢¸­SºÄk}C`°wäñø»ÙËÙ©U.”‹óŽ
?!c™È&2´·!Fï¥?"è*»^y>A•ÜýX¥òR:¤q
›6Yb*0Á¡Åâ`&£{“"ãs(ò¥þ«N`”FÒ°k}çQ˜µœUžÔúbø¯ÒÌÝRv끚<<œþ*•¤2Nò£gi˜·¢óÓ7û²öA
œž–Õp÷îIþÚx›sAó¥,"þ>¼1Óåiœâ í|(”Í0zúæڌ8pc~ÚVPZ\`¾Å±âÝÓçþóQ¾åÊ 
S°Îû¿÷mL3qx{½çjã
©ž½ ˆë!÷’BïÏ&S\r²«¬>¦tVÔ¡™³dN/b‚ßéÇ¥‡¢‡©×Í~”“·Ùáìë¿dmW
.Ø3ê|<
IzDx÷£/FÊDÇŸ!Ø/מöµÖE÷߅DuÐîä
C*4*¼iàˆZª:Ã'xœã(fÐÔJœŒ^>éFL¾Œ4ug
n¡¡ô\Ä·†xÆ3o¶G¤¹_×`ú} 
‡«GUOÜâk~2$óJz»—Ò›«¢flYŸüI2ižà*æûŠßóAÑÝ]>rŽÓ>j,æÁ!û!õuǯ—ÏþÐi¬ì¡lÁ_ÚßÆ&X,Y
b÷
~j Ԅ\H²ªªg<Q%3 
»¿Ç»ç9hz;¢>¾39¹ç˜Ø!8J¸m´äeÖXPWŠKQþC:ƒá‰ 
°ÇÍi)ÉËÁùeûã"®zÏléjÀDÌ8`hNj“â2mÂ`&ÑZ³ÓræH×DˆE2y;B×¢<\cTzG7ºm0Ý N&àùQZ›ìE|Ñ

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev