Re: [ovs-discuss] Why the NSH is not been supported by the ovs-2.9.0?

[Yang, Yi Y]

Are you using OVS kernel datapath?  You can double check it by adding flows 
manually.

From: ovs-discuss-boun...@openvswitch.org 
[mailto:ovs-discuss-boun...@openvswitch.org] On Behalf Of hai tsing
Sent: Tuesday, September 25, 2018 9:57 PM
To: ovs-discuss@openvswitch.org
Subject: [ovs-discuss] Why the NSH is not been supported by the ovs-2.9.0?


Dear all:


I encounter a trouble that my ovs does't support nsh!

When the openstack networking-sfc was populating some flows,  the following 
ERROR occures.
when I was looking for resolution,  The ovs release note tells that nsh is 
supported on version 
2.9.0(http://www.openvswitch.org//releases/NEWS-2.10.0.txt).

so what should i do for enabling NSH of ovs?

2018-09-25 21:23:53.558 17403 ERROR neutron.agent.linux.utils 
[req-f484f89b-9acf-4303-9c79-7adc862bff5c - - - - -] Exit code: 1; Stdin: 
hard_timeout=0,idle_timeout=0,priority=30,cookie=8156743583516943314,nw_dst=0.0.0.0/0.0.0.0,eth_type=2048,tp_dst=0/0x0,table=0,tp_src=0/0x0,nw_src=192.168.6.5,in_port=21,actions=encap(hdr=nsh,prop(class=nsh,type=md_type,val=1)),set_field:0x1->nsh_spi,set_field:0xff->nsh_si,encap(hdr=ethernet),group:1;
 Stdout: ; Stderr: ovs-ofctl: -:1: Encap hdr not supported: nsh
2018-09-25 21:23:53.559 17403 ERROR neutron.agent.common.ovs_lib 
[req-f484f89b-9acf-4303-9c79-7adc862bff5c - - - - -] Unable to execute 
['ovs-ofctl', 'add-flows', '-O', 'OpenFlow13', 'br-int', '-']. Exception: Exit 
code: 1; Stdin: 
hard_timeout=0,idle_timeout=0,priority=30,cookie=8156743583516943314,nw_dst=0.0.0.0/0.0.0.0,eth_type=2048,tp_dst=0/0x0,table=0,tp_src=0/0x0,nw_src=192.168.6.5,in_port=21,actions=encap(hdr=nsh,prop(class=nsh,type=md_type,val=1)),set_field:0x1->nsh_spi,set_field:0xff->nsh_si,encap(hdr=ethernet),group:1;
 Stdout: ; Stderr: ovs-ofctl: -:1: Encap hdr not supported: nsh
: ProcessExecutionError: Exit code: 1; Stdin: 
hard_timeout=0,idle_timeout=0,priority=30,cookie=8156743583516943314,nw_dst=0.0.0.0/0.0.0.0,eth_type=2048,tp_dst=0/0x0,table=0,tp_src=0/0x0,nw_src=192.168.6.5,in_port=21,actions=encap(hdr=nsh,prop(class=nsh,type=md_type,val=1)),set_field:0x1->nsh_spi,set_field:0xff->nsh_si,encap(hdr=ethernet),group:1;
 Stdout: ; Stderr: ovs-ofctl: -:1: Encap hdr not supported: nsh





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

Re: [ovs-discuss] NSH rules

[Yang, Yi Y]

Are you using Opendaylight in your all-in-one deployment? I suggest you ask 
your question in networking-sfc mailing list, I can guide you to get the right 
contact person if you can provide more details.

From: ovs-discuss-boun...@openvswitch.org 
[mailto:ovs-discuss-boun...@openvswitch.org] On Behalf Of ???
Sent: Friday, July 6, 2018 8:13 PM
To: ovs-discuss@openvswitch.org
Subject: [ovs-discuss] NSH rules


Dear experts,
I am trying the networking-sfc with NSH support in the all-in-one Openstack 
deploying from devstack. But in my environment, the OVS always can not accept 
the NSH related flow rules from SFC driver. The following are the corresponding 
flows and the received error.

For table 5, I got:
"hard_timeout=0,idle_timeout=0,priority=0,cookie=18389747003163845,table=5,dl_dst=fa:16:3e:d3:ad:66,eth_type=2048,actions=encap(hdr=nsh,prop(class=nsh,type=md_type,val=1)),set_field:0x1->nsh_spi,set_field:0xff->nsh_si,encap(hdr=ethernet),mod_vlan_vid:16,,resubmit(,10)"
  -O openflow13
We got Encap header nsh not support

For table 10, I got:
 
hard_timeout=0,idle_timeout=0,priority=1,cookie=1291058868797254279,nsh_spi=1,nsh_mdtype=1,eth_type=35151,table=10,dl_dst=fa:16:3e:c8:ed:35,dl_vlan=17,nsh_si=255,actions=strip_vlan,move:NXM_OF_ETH_DST->OXM_OF_PKT_REG[0..47],decap(),decap(),move:OXM_OF_PKT_REG[0..47]->NXM_OF_ETH_DST,output:40;
 Stdout: ; Stderr: ovs-ofctl: -:1: OXM_OF_PKT_REG[0..47]: unknown field 
`OXM_OF_PKT_REG'

I saw the bug log of https://bugs.launchpad.net/networking-sfc/+bug/1753349. 
All of the corresponding rules can be well inserted. I have tried the OVS from 
2.8.1 to 2.9.0 by installing via apt-get or building from source. The result is 
the same. I would lie to ask if any further configuration need to set on my 
OVS? Thanks in advance.

Blessings

Alan JW Chang


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

Re: [ovs-discuss] Bad checksums observed with nsh encapsulation

[Yang, Yi Y]

Hi, Jaime

Thank you so much for trying this, Jiri Benc is expert on this. So cc him.

Jiri, do we need to calculate checksum before push_nsh if checksum offload is 
on?

-Original Message-
From: ovs-discuss-boun...@openvswitch.org 
[mailto:ovs-discuss-boun...@openvswitch.org] On Behalf Of Jaime Caamaño Ruiz
Sent: Monday, June 25, 2018 5:45 PM
To: jcaam...@suse.com; ovs-discuss@openvswitch.org
Subject: Re: [ovs-discuss] Bad checksums observed with nsh encapsulation

Hello

I looked a bit more into the issue.

This is happenning when OVS receives a CHECKSUM_PARTIAL. For a normal vm2vm non 
nsh scenario, OVS provides the same CHECKSUM_PARTIAL to the receiver which wont 
then verify the checksum.

But when we are pushing nsh headers, the first receiver may not be the final 
receiver and CHECKSUM_PARTIAL may not reach the final reciever which will then 
verify and reject a bad checksum.

So I think it may be necessary to handle the CHECKSUM_PARTIAL case on nsh_push, 
something like adding

if (skb->ip_summed == CHECKSUM_PARTIAL) {
skb_checksum_help(skb);
}

Tried that and got rid of my problem.

Any thoughts?

BR
Jaime.


-Original Message-
From: Jaime Caamaño Ruiz 
Reply-To: jcaam...@suse.com
To: jcaam...@suse.com, ovs-discuss@openvswitch.org
Subject: Re: [ovs-discuss] Bad checksums observed with nsh encapsulation
Date: Thu, 14 Jun 2018 18:15:10 +0200

Hello

I have done a follow-up test very similar to the previous one, but this time 
using two computes such that client and server reside in one of them and the 
vnf on the other one. This means that packets coming from either client/server 
that are being nsh encapsulated are then forwarded to the vnf compute egressing 
through a vxlan tunnel port (vxlan+eth+nsh+payload). 

In this scenario I dont observe the checksum problem. So it is a combination of 
nsh encasulation + tap port egress when the checksum is sometimes observed to 
be incorrect.

BR
Jaime.


-Original Message-
From: Jaime Caamaño Ruiz  
Reply-To: jcaam...@suse.com
To: ovs-discuss@openvswitch.org, jcaam...@suse.de
Subject: [ovs-discuss] Bad checksums observed with nsh encapsulation
Date: Wed, 13 Jun 2018 12:51:59 +0200

Hello

I am facing a problem where eth+nsh encapsulated packets egress OVS with 
incorrect checksum. 

The scenario is

client  vnf  server

all guests on the same host so this is vm2vm traffic, tap ports are directly 
added to the ovs bridge. TCP traffic from/to server port 80 is encapsulated 
with eth+nsh and traverse the vnf. I exercise the traffic by using nc both on 
client and server.

I include captures at the client [1] and at the vnf [2] where I attempt three 
tcp connections on port 80. The general observation is that packets generated 
on client/server are seen there with wrong checksums due to offloading but then 
arrive at the vnf with correct checksum. But not all of them. For the first 
conenction attempt you can see that SYN (frame 74) and ACK (78) are ok, but 
then FIN (79) is not ok. A retransmitted FIN (80) is still not ok and then a 
further FIN (93) retranmission is ok. Much of the same happens for the second 
attempt.
The third attempt shows a bad SYN (104) coming from the server.

Two additional observations:

- This does not happen if I try the same on a port different than 80 so that 
the traffic goes directly from the client to the server with no
eth+nsh encapsulation.

- This does not happen if I disable tx offloading both in the server and the 
client.

I include also the flows [3] and the ofproto trace [4] for the FIN (79), 
generated by the client, which is eth+nsh encapsulated and forwarded to the 
vnf. The decision on whether packet should be eth+nsh encapsulated or no 
happens on table 101 by setting reg2 which is then checked on 221. Packet is 
nsh encapsulated on table 222 and then ethernet encapsulated on table 83. If 
not encapsulated packet would go from 221 back to 220 and output there without 
any further actions.

Using OVS 2.9.2 with OVS tree kernel module. Kernel is 4.4.

I am understanding the problem correctly in regards to OVS being responsible 
for these checksums when offloading is enabled?
Any pointers on how I can debug this further?
Why would just some of the eth+nsh packets exhibit this problem and not all?
Why would these bad packets be ok after retransmissions?

[1] https://filebin.net/8mnypc2qm4vninof/client.pcap?t=b097kh0m
[2] https://filebin.net/8mnypc2qm4vninof/vnf_eth0.pcap?t=b097kh0m
[3] https://hastebin.com/nuhexufaze.sql
[4] https://hastebin.com/yevufanula.http

Thanks for your help,
Jaime.







___
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
___
discuss mailing list

Re: [ovs-discuss] NSH related questions

[Yang, Yi Y]

Also cc Brady Johnson who is Opendaylight SFC project lead, he can add more 
comments about your questions.

From: Yang, Yi Y
Sent: Wednesday, April 25, 2018 8:45 AM
To: 'Ashish Varma' <ava...@vmware.com>; ovs-discuss@openvswitch.org; 
jan.scheur...@ericsson.com
Cc: Justin Pettit <jpet...@vmware.com>; Pierluigi Rolando 
<prola...@vmware.com>; Raju Koganty <rkoga...@vmware.com>; Kantesh Mundaragi 
<kmundar...@vmware.com>; Niaz Khan <niazk...@vmware.com>
Subject: RE: NSH related questions

Sorry for late response, I’m busy doing other thing, so don’t check ovs mailing 
list. Replies inline.

From: Ashish Varma [mailto:ava...@vmware.com]
Sent: Tuesday, April 17, 2018 3:28 AM
To: ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>; 
jan.scheur...@ericsson.com<mailto:jan.scheur...@ericsson.com>; Yang, Yi Y 
<yi.y.y...@intel.com<mailto:yi.y.y...@intel.com>>
Cc: Justin Pettit <jpet...@vmware.com<mailto:jpet...@vmware.com>>; Pierluigi 
Rolando <prola...@vmware.com<mailto:prola...@vmware.com>>; Raju Koganty 
<rkoga...@vmware.com<mailto:rkoga...@vmware.com>>; Kantesh Mundaragi 
<kmundar...@vmware.com<mailto:kmundar...@vmware.com>>; Niaz Khan 
<niazk...@vmware.com<mailto:niazk...@vmware.com>>
Subject: NSH related questions

Hi Jan / Yi Yang,

We, at VMware, are working on integrating partner services on NSX using NSH 
support on OVS. It would be very helpful to understand the current NSH/SFC 
adaptation trend and deployment scenarios happening in the industry.
Regarding this, we have few questions and it would be very helpful to get any 
insight on these:

1. When the classifier classifies a packet (stream) to follow a particular 
Service Function Path, the path may consist of going to multiple Service 
Function Forwarders (e.g. to cover all the Service Functions which may be 
spread across the network or data center) The last SFF could be far from the 
classifier (assuming there is only one in this SFP) where the NSH header was 
added to the original packet.
How do packets generally go back on its original path? Are they sent back to 
the original classifier or there are cases where you see last SFF intelligent 
enough to know the next hop of the packet outside the SFC overlay?

[Yi] In Opendaylight SFC, we have ingress classifier and egress classifier for 
end-to-end traffic, we have two SFPs (called RSP rendered service path in ODL 
sfc) for an end-to-end traffic, a forward RSP, a reverse RSP, usually they are 
symmetric, it is also if they are asymmetric. We also have some tricky way to 
avoid egress classifier by openflow rules, in that case, NSH metadata (C1 to C4 
will save reverse SFP ID and original classifier source IP). Maybe written 
explanation is not enough to you, you can try Opendaylight SFC 103 and 104 demo 
(https://git.opendaylight.org/gerrit/gitweb?p=sfc.git;a=tree;f=sfc-demo;h=d8ff2d575b8eedb5e42b9696d9869303bad0be95;hb=HEAD
 ), you can dump flow tables once you run it successfully, those tables can 
help you understand how the traffic is steered to correct classifier and 
forwarders.

2. In your experience, have you seen SFC being deployed on an existing overlay 
network. e.g SFC on top of OVN where now there is an SFC overlay network over 
tunnel based OVN overlay network. Have you encountered any challenges with 
this? (e.g. increase in packet size)

[Yi] In China, Sangfor (an information security product vendor) is developing a 
product for security resources pool by using sfc to go through security 
services in resource pool, this is very typical solution in cloud environment, 
some other vendors are also doing similar thing.

3. Are there any third party Virtual Network Functions which are NSH/SFC 
compliant?

[Yi] F5 has such VNF, but I’m not sure how it handles NSH.

4. SFC proxy is supposed to de-capsulate the NSH header when sending the packet 
to Service Function and encapsulate NSH header back when sending back to SFF. 
The NSH header information (SPI/SI, context headers etc.) needs to be put back 
on the packet when going back to SFF. If this is to be done using OVS flows 
(without sending the packets to Controller which can remember the information), 
we will have to come up with some kind of ‘learn’ flow to dynamically put the 
header back.
What are your thoughts on this?

[Yi] It will be very complicated if let OVS use openflow to do NSH proxy 
because you have to maintain a map between (SPI, SI) and inner traffic. A 
better way is to has a special NSH proxy to handle this or VNF handles it by 
itself. Sangfor uses OVS openflow rules to handle this.


Thanks,

Ashish Varma


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

Re: [ovs-discuss] NSH related questions

[Yang, Yi Y]

Sorry for late response, I’m busy doing other thing, so don’t check ovs mailing 
list. Replies inline.

From: Ashish Varma [mailto:ava...@vmware.com]
Sent: Tuesday, April 17, 2018 3:28 AM
To: ovs-discuss@openvswitch.org; jan.scheur...@ericsson.com; Yang, Yi Y 
<yi.y.y...@intel.com>
Cc: Justin Pettit <jpet...@vmware.com>; Pierluigi Rolando 
<prola...@vmware.com>; Raju Koganty <rkoga...@vmware.com>; Kantesh Mundaragi 
<kmundar...@vmware.com>; Niaz Khan <niazk...@vmware.com>
Subject: NSH related questions

Hi Jan / Yi Yang,

We, at VMware, are working on integrating partner services on NSX using NSH 
support on OVS. It would be very helpful to understand the current NSH/SFC 
adaptation trend and deployment scenarios happening in the industry.
Regarding this, we have few questions and it would be very helpful to get any 
insight on these:

1. When the classifier classifies a packet (stream) to follow a particular 
Service Function Path, the path may consist of going to multiple Service 
Function Forwarders (e.g. to cover all the Service Functions which may be 
spread across the network or data center) The last SFF could be far from the 
classifier (assuming there is only one in this SFP) where the NSH header was 
added to the original packet.
How do packets generally go back on its original path? Are they sent back to 
the original classifier or there are cases where you see last SFF intelligent 
enough to know the next hop of the packet outside the SFC overlay?

[Yi] In Opendaylight SFC, we have ingress classifier and egress classifier for 
end-to-end traffic, we have two SFPs (called RSP rendered service path in ODL 
sfc) for an end-to-end traffic, a forward RSP, a reverse RSP, usually they are 
symmetric, it is also if they are asymmetric. We also have some tricky way to 
avoid egress classifier by openflow rules, in that case, NSH metadata (C1 to C4 
will save reverse SFP ID and original classifier source IP). Maybe written 
explanation is not enough to you, you can try Opendaylight SFC 103 and 104 demo 
(https://git.opendaylight.org/gerrit/gitweb?p=sfc.git;a=tree;f=sfc-demo;h=d8ff2d575b8eedb5e42b9696d9869303bad0be95;hb=HEAD
 ), you can dump flow tables once you run it successfully, those tables can 
help you understand how the traffic is steered to correct classifier and 
forwarders.

2. In your experience, have you seen SFC being deployed on an existing overlay 
network. e.g SFC on top of OVN where now there is an SFC overlay network over 
tunnel based OVN overlay network. Have you encountered any challenges with 
this? (e.g. increase in packet size)

[Yi] In China, Sangfor (an information security product vendor) is developing a 
product for security resources pool by using sfc to go through security 
services in resource pool, this is very typical solution in cloud environment, 
some other vendors are also doing similar thing.

3. Are there any third party Virtual Network Functions which are NSH/SFC 
compliant?

[Yi] F5 has such VNF, but I’m not sure how it handles NSH.

4. SFC proxy is supposed to de-capsulate the NSH header when sending the packet 
to Service Function and encapsulate NSH header back when sending back to SFF. 
The NSH header information (SPI/SI, context headers etc.) needs to be put back 
on the packet when going back to SFF. If this is to be done using OVS flows 
(without sending the packets to Controller which can remember the information), 
we will have to come up with some kind of ‘learn’ flow to dynamically put the 
header back.
What are your thoughts on this?

[Yi] It will be very complicated if let OVS use openflow to do NSH proxy 
because you have to maintain a map between (SPI, SI) and inner traffic. A 
better way is to has a special NSH proxy to handle this or VNF handles it by 
itself. Sangfor uses OVS openflow rules to handle this.


Thanks,

Ashish Varma


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

Re: [ovs-discuss] OVS layer3 GRE support

[Yang, Yi Y]

The userspace L3 patch set Zoltan posted has included L3 support for GRE, here 
it is.

https://mail.openvswitch.org/pipermail/ovs-dev/2017-April/330490.html


-Original Message-
From: ovs-discuss-boun...@openvswitch.org 
[mailto:ovs-discuss-boun...@openvswitch.org] On Behalf Of Hexin Wang
Sent: Tuesday, April 25, 2017 2:42 AM
To: Ben Pfaff 
Cc: simon.hor...@netronome.com; ovs-discuss@openvswitch.org
Subject: Re: [ovs-discuss] OVS layer3 GRE support

Right. I was specifically referring to the OVS layer3 tunnel support originated 
by Lorand Jakab and Simon Horman.
The changes made in kernel data path is merged back to Linux mainline by Jiri 
Benc. But the user space OVS changes are missing in ovs main tree.

Thanks.

Hexin




On 4/24/17, 11:37 AM, "Ben Pfaff"  wrote:

>On Mon, Apr 24, 2017 at 06:25:07PM +, Hexin Wang wrote:
>> I got a question on OVS layer3 GRE tunnel support. The OVS kernel 
>> piece that supports layer 3 GRE is merged into linux upstream since
>> 4.10 RC6. Do we need any extra user land OVS merge for it to work 
>> end-to-end? I am referring to the “options:layer3=true” ovs-vsctl 
>> interface changes. Essentially, how is “push_mpls” action triggering 
>> the pop_eth action in kernel data path?
>
>This is not a subject I know well.  That said, it looks like OVS 
>userspace doesn't currently support layer-3 GRE tunnels in an 
>appropriate way.  I mainly base this on the code in 
>netdev_vport_is_layer3(), which considers only LISP ports to be layer-3 
>ports.
___
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 2.7 on Ubuntu

[Yang, Yi Y]

Can http://docs.openvswitch.org/en/latest/intro/install/debian/ build ovs DPDK 
packages? I can’t find an existing debian script to build both ovs and ovs 
DPDK, but Ubuntu repo does provides both ovs and ovs DPDK, and you are able to 
switch to ovs or ovs DPDK on demand, that is really very very convenient.


From: ovs-discuss-boun...@openvswitch.org 
[mailto:ovs-discuss-boun...@openvswitch.org] On Behalf Of Guru Shetty
Sent: Friday, March 17, 2017 1:23 AM
To: Shivaram Mysore 
Cc: ovs-discuss@openvswitch.org
Subject: Re: [ovs-discuss] OVS 2.7 on Ubuntu



On 15 March 2017 at 10:58, Shivaram Mysore 
> wrote:
Does anyone know where I can get OVS 2.7 packages for Ubuntu 16.10 or when they 
would be available?

It is straightforward to build your own packages.
http://docs.openvswitch.org/en/latest/intro/install/debian/


thanks

___
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] Anybody knows how we can dynamically change vxlan dst_port by openflow load, move or set_field action?

[Yang, Yi Y]

Got it, so no way to do this in current ovs, thanks a lot.

-Original Message-
From: Pravin Shelar [mailto:pshe...@ovn.org] 
Sent: Monday, December 5, 2016 11:16 AM
To: Yang, Yi Y <yi.y.y...@intel.com>
Cc: Gerhard Stenzel <gsten...@linux.vnet.ibm.com>; Ben Pfaff <b...@ovn.org>; 
d...@openvswitch.org; ovs-discuss@openvswitch.org
Subject: Re: [ovs-discuss] Anybody knows how we can dynamically change vxlan 
dst_port by openflow load, move or set_field action?

On Sun, Dec 4, 2016 at 5:57 PM, Yang, Yi Y <yi.y.y...@intel.com> wrote:
> Let me explain my point in details.
>
>
> +---+   
> +---+ +---+
> |  vxlanX   |<- >|   vxlanY   
> |
> |dst_port:6633   |   |dst_port:6634   
>  |
> +---+  
> +---+ ++
>   ^   
>^
>\  
>/
>  \
>  /
>\  
>/
>  \
>  /
>\  
>/
>  \
>  /
>\ /
> v  v
>  ++
>  |  vxlanZ   |
>  |   dst_port:6635|
> +-+
>
> I mean we should let openflow set dst_port in tunnel metadata although we 
> only can have one default dst_port in configuration, this will make the above 
> use case possible. Otherwise do we have any way to make sure the above case 
> can work?
>
> So I think it is important to use dst_port in tunnel metadata if have.
>
This is already there. Kernel interface for vxlan allows setting dst-port from 
tunnel metadata.

But I do not think there is anyway to configure such tunnels using OVS. You can 
not control UDP port of the tunnel header using flow APIs. There is single port 
number (ingress and egress) associated with a tunnel port using OVSDB 
configuration.

> -Original Message-
> From: Pravin Shelar [mailto:pshe...@ovn.org]
> Sent: Monday, December 5, 2016 9:01 AM
> To: Yang, Yi Y <yi.y.y...@intel.com>
> Cc: Gerhard Stenzel <gsten...@linux.vnet.ibm.com>; Ben Pfaff 
> <b...@ovn.org>; d...@openvswitch.org; ovs-discuss@openvswitch.org
> Subject: Re: [ovs-discuss] Anybody knows how we can dynamically change vxlan 
> dst_port by openflow load, move or set_field action?
>
> On Sat, Dec 3, 2016 at 10:05 PM, Yang, Yi Y <yi.y.y...@intel.com> wrote:
>> Hi, Pravin
>>
>> I'm confused, I think dst_port is also for local UDP socket for vxlan port, 
>> what if I have dst_port 6634 on one side (machine A) vxlan port and have 
>> dts_port 6635 on the other side (machine B)?
>>
>> My point is vxlan should have ability to set different dst_port for 
>> different counterparts, in that way, one vxlan port can communicate with 
>> multiple counterpart vxlan ports with different dst_ports.
>>
>> Otherwise, we only can use the same dst_port for all the vxlan ports.
>>
> I am not sure if I understand your concern. But let me clarify that all UDP 
> based tunnels need to create separate netdevice for each dst port. I do not 
> think we can handle multiple UDP ports on single tunnel device.
>
>> -Original Message-
>> From: Pravin Shelar [mailto:pshe...@ovn.org]
>> Sent: Friday, December 2, 2016 3:54 PM
>> To: Yang, Yi Y <yi.y.y...@intel.com>
>> Cc: Gerhard Stenzel <gsten...@linux.vnet.ibm.com>; Ben Pfaff 
>> <b...@ovn.org>; d...@openvswitch.org; ovs-discuss@openvswitch.org
>> Subject: Re: [ovs-discuss] Anybody knows how we can dynamically change vxlan 
>> dst_port by openflow load, move or set_field action?
>>
>> On Wed, Nov 30, 2016 at 4:41 PM, Yang, Yi Y <yi.y.y...@intel.com> wrote:
>>> I think this issue is not that simple. It depends on how you use it.
>>>
>>> For normal use ca

Re: [ovs-discuss] Anybody knows how we can dynamically change vxlan dst_port by openflow load, move or set_field action?

[Yang, Yi Y]

I think this issue is not that simple. It depends on how you use it.

For normal use cases, a tunnel port will terminate the tunnel traffic, so a 
packet sent to a tunnel port will never be from another tunnel port, so no 
tunnel metadata is available for the first packet, but for the packets which 
are from the counterpart tunnel port (which is another host), I think this 
tunnel port will keep the tunnel metadata for the traffic so that it can use 
src_port as dst_port for the packets sent back to the counterpart tunnel port. 
So the original source code makes sense, it works well.

But for your use case (including the case I reported), you're send the packet 
from GENEVE port to VXLAN or from VXLAN to GENEVE, the tunnel metadata for 
GENEVE shouldn't be used by VXLAN, vice versa, but how can we pull this off? 
Actually this is a special use case, ovs doesn't realize we can use it in this 
way :-)

We're eager you OVS experts can come up with a good solution for this.



-Original Message-
From: Gerhard Stenzel [mailto:gsten...@linux.vnet.ibm.com] 
Sent: Wednesday, November 30, 2016 9:40 PM
To: Ben Pfaff <b...@ovn.org>; Yang, Yi Y <yi.y.y...@intel.com>
Cc: ovs-discuss@openvswitch.org
Subject: Re: [ovs-discuss] Anybody knows how we can dynamically change vxlan 
dst_port by openflow load, move or set_field action?

On 11/26/2016 11:08 PM, Ben Pfaff wrote:
> On Thu, Nov 24, 2016 at 02:39:43AM +0000, Yang, Yi Y wrote:
>> I noticed vxlan module always uses tp_dst from tunnel metadata in preference 
>> to vxlan->cfg.dst_port, this isn't the result we want in some use cases, for 
>> example, if we create two vxlan port which have different dst_port, when we 
>> forward the packet from the first vxlan port to the second one, we need the 
>> packet should be sent out with the second vxlan port's dst_port as tp_dst, 
>> but current vxlan module will use that one from the first vxlan port, the 
>> source code in vxlan module and our experiment have confirmed this.
>>
>> The line in file datapath/linux/compat/vxlan.c is here:
>>
>> dst_port = info->key.tp_dst ? : vxlan->cfg.dst_port;
>>
>> Anybody knows how we can change this? The below change seems more reasonable 
>> to me, or do we have some ways to dynamically change it by openflow actions?
>>
>> dst_port = vxlan->cfg.dst_port ? : info->key.tp_dst;
> 
> I think that this might be related to the bug that Gerhard reported, 
> starting here:
>
> https://mail.openvswitch.org/pipermail/ovs-discuss/2016-November/04298
> 4.html Gerhard, does Yang's fix make any difference for you?  (I don't 
> know whether you're using the compat code, but the upstream code may 
> have the same bug.)
> 

Ben, I finally managed to create a working setup with a newer kernel 
(4.8.10-200.fc24.x86_64) and current upstream ovs master. Unless I made a 
mistake, the fix does not make a difference for my scenario.

Here are the details:

# modinfo openvswitch
filename:   /lib/modules/4.8.10-200.fc24.x86_64/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: 8BF3A000492AA097034609E
depends:
nf_conntrack,nf_nat,udp_tunnel,libcrc32c,nf_nat_ipv6,nf_nat_ipv4,nf_defrag_ipv6
vermagic:   4.8.10-200.fc24.x86_64 SMP mod_unload 


// Before change:

# ovs-dpctl dump-flows
recirc_id(0),tunnel(tun_id=0x0,src=192.168.122.202,dst=192.168.122.227,ttl=64,flags(-df-csum+key)),in_port(1),skb_mark(0),eth(src=52:f9:67:de:f0:4b,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=10.0.0.68,tip=10.0.0.111,op=1/0xff),
 packets:23, bytes:966, used:0.003s, 
actions:set(tunnel(tun_id=0x0,dst=192.168.122.21,ttl=64,tp_src=7291,tp_dst=6081,flags(df|key))),3,2

# git diff
diff --git a/datapath/linux/compat/vxlan.c b/datapath/linux/compat/vxlan.c 
index 3abcab1..c84a280 100644
--- a/datapath/linux/compat/vxlan.c
+++ b/datapath/linux/compat/vxlan.c
@@ -1046,7 +1046,7 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct 
net_device *dev,
  dev->name);
goto drop;
}
-   dst_port = info->key.tp_dst ? : vxlan->cfg.dst_port;
+   dst_port = vxlan->cfg.dst_port ? : info->key.tp_dst;
vni = vxlan_tun_id_to_vni(info->key.tun_id);
remote_ip.sa.sa_family = ip_tunnel_info_af(info);
if (remote_ip.sa.sa_family == AF_INET) {

// Build and install OVS kernel module and reboot:
# ovs-dpctl dump-flows
recirc_id(0),tunnel(tun_id=0x0,src=192.168.122.202,dst=192.168.122.227,ttl=64,flags(-df-csum+key)),in_port(1),skb_mark(0),eth(s

[ovs-discuss] What is the minimum Linux kernel version ovs 2.6.1 build requires?

[Yang, Yi Y]

Hi, folks

I tried to build ovs 2.6.1 in Ubuntu trusty 64 with the below configuration 
options, but it failed, it is ok when I use the same way to build in Ubuntu 
16.04 which has Linux kernel 4.4. What is the minimum Linux kernel version ovs 
2.6.1 build requires?

./configure --prefix=/ --with-linux=/lib/modules/`uname -r`/build

Here is error log

/home/vagrant/ovs-2.6.1-build/ovs-2.6.1/datapath/linux/gso.c: In function 
'tnl_skb_gso_segment.isra.11.constprop.14':
include/linux/compiler.h:325:20: error: call to '__compiletime_assert_174' 
declared with attribute error: BUILD_BUG_ON failed: sizeof(struct ovs_gso_cb) > 
FIELD_SIZEOF(struct sk_buff, cb)
prefix ## suffix();\
^
include/linux/compiler.h:330:2: note: in expansion of macro 
'__compiletime_assert'
  __compiletime_assert(condition, msg, prefix, suffix)
  ^
include/linux/compiler.h:342:2: note: in expansion of macro 
'_compiletime_assert'
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
  ^
include/linux/bug.h:50:37: note: in expansion of macro 'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
 ^
include/linux/bug.h:74:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
  BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
  ^
/home/vagrant/ovs-2.6.1-build/ovs-2.6.1/datapath/linux/gso.c:174:2: note: in 
expansion of macro 'BUILD_BUG_ON'
  BUILD_BUG_ON(sizeof(struct ovs_gso_cb) > FIELD_SIZEOF(struct sk_buff, cb));
  ^
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss