Re: [ovs-discuss] rmmod: ERROR: Module openvswitch is in use -- when ovn config is added to conf.db

[Jesse Gross]

On Thu, Sep 22, 2016 at 5:44 PM, Flavio Fernandes <fla...@flaviof.com> wrote:
>> On Sep 22, 2016, at 6:53 PM, Jesse Gross <je...@kernel.org> wrote:
>> When an OVS vport is created, a reference is taken on the
>> corresponding vport-*.ko module. However, in the case of internal
>> ports created by the datapath, the internal device vport is actually
>> part of the main OVS module and so we are taking a reference on
>> ourselves. As a result, the only way to unload the module is to delete
>> all of the datapaths. It seems like this is what is happening here and
>> is what force-reload-kmod is working around.
>>
>> Obviously, there's no benefit in taking a reference on ourselves, so
>> we could just check for this and not take a reference. Combined with
>> the fact that lightweight tunnels eliminates the need for vport
>> modules that are not part of OVS (on new enough kernels), then
>> unloading the module would be enough to gracefully cleanup everything.
>
> Very interesting, Jesse. In my little experiment, I create no logical switches
> or any other config, so you are likely talking about datapath in terms of
> the connectivity between the ovn-controller and the ovsdb server that is
> managing the southbound database?!?

I was referring to datapaths as instantiated in the kernel module. If
you have any ports attached to OVS - VMs, containers, tunnels, etc.
then a datapath will exist.

Unfortunately, I'm not going to have a chance to create a patch for
this. However, if you want to give it a try, I would look at the call
to try_module_get() in datapath/vport.c:ovs_vport_add(). That's where
the reference to the vports are being taken and where we should check
if the module being refcounted is actually us.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] rmmod: ERROR: Module openvswitch is in use -- when ovn config is added to conf.db

[Jesse Gross]

I think this isn't actually related to tunnels - ovn-controller
deletes the tunnel ports that it creates when it exits gracefully.
Plus, it seems like vport-geneve was unloaded successfully.

When an OVS vport is created, a reference is taken on the
corresponding vport-*.ko module. However, in the case of internal
ports created by the datapath, the internal device vport is actually
part of the main OVS module and so we are taking a reference on
ourselves. As a result, the only way to unload the module is to delete
all of the datapaths. It seems like this is what is happening here and
is what force-reload-kmod is working around.

Obviously, there's no benefit in taking a reference on ourselves, so
we could just check for this and not take a reference. Combined with
the fact that lightweight tunnels eliminates the need for vport
modules that are not part of OVS (on new enough kernels), then
unloading the module would be enough to gracefully cleanup everything.

On Thu, Sep 22, 2016 at 7:59 AM, Guru Shetty  wrote:
> I think it usually happens because the geneve tunnel exists in the kernel
> datapath. The right way to do this is via '/etc/init.d/openvswitch-switch
> force-reload-kmod'
>
> On 22 September 2016 at 01:46, Flavio Fernandes  wrote:
>>
>> [cc: Jesse]
>>
>> Hi folks,
>>
>> While playing with branch-2.6, I've noticed that something may not be
>> cleaned properly
>> in the kernel with openvswitch module; [only] when ovn was configured.
>>
>> What I observe [below] is that as soon as I configure info used by
>> ovn-controller to
>> connect to sb db, I am unable to unload the ovs kernel module.
>>
>> Any ideas on what commands I could use to further determine what could be
>> causing
>> this? I did not try it on master, but suspect the issue exists there as
>> well.
>>
>> Thanks,
>>
>> -- flaviof
>>
>> ==
>>
>> $ lsb_release -sc
>> trusty
>>
>> cd ~/ovs.git
>>
>> ./boot.sh && \
>> ./configure --prefix=/usr --localstatedir=/var  --sysconfdir=/etc \
>>   --enable-ssl --with-linux=/lib/modules/$(uname -r)/build
>> && \
>> make -j$(nproc) && \
>> sudo make install ; echo $?
>>
>> for x in libcrc32c nf_conntrack nf_nat nf_nat_ipv6 nf_nat_ipv4
>> nf_defrag_ipv4 gre ; do \
>>sudo modprobe $x ; \
>> done
>>
>> sudo insmod ./datapath/linux/openvswitch.ko && \
>> sudo insmod ./datapath/linux/vport-geneve.ko && \
>> echo ok
>>
>> sudo cp ./debian/openvswitch-switch.init /etc/init.d/openvswitch-switch
>>
>> sudo /etc/init.d/openvswitch-switch start
>> sudo /usr/share/openvswitch/scripts/ovn-ctl restart_northd
>> sudo /usr/share/openvswitch/scripts/ovn-ctl restart_controller
>>
>>  insert commands that configure conf.db with OVN related commands
>>  to make issue happen :/
>>
>> sudo /usr/share/openvswitch/scripts/ovn-ctl stop_controller
>> sudo /usr/share/openvswitch/scripts/ovn-ctl stop_northd
>> sudo /etc/init.d/openvswitch-switch stop
>>
>> # as you can see there is nothing related to ovs running...
>> $ ps aux | grep "ov[sn]"
>> $
>>
>> $ sudo rmmod vport_geneve
>> $
>>
>> # Happy case...
>> $ # this works fine if commands that configure conf.db with ovn are not
>> used...
>> $ sudo rmmod openvswitch
>> $ sudo lsmod | grep openv
>> $
>>
>> ==
>>
>> # However, not as nice if conf.db is configured with encaps info:
>> $ sudo rmmod openvswitch
>> rmmod: ERROR: Module openvswitch is in use
>>
>> $ sudo lsmod | grep openv
>> openvswitch   253098  2
>> gre13796  1 openvswitch
>> nf_defrag_ipv4 12758  2 openvswitch,nf_conntrack_ipv4
>> nf_nat_ipv413263  1 openvswitch
>> nf_defrag_ipv6 34768  2 openvswitch,nf_conntrack_ipv6
>> nf_nat_ipv613279  1 openvswitch
>> nf_nat 21841  3 openvswitch,nf_nat_ipv4,nf_nat_ipv6
>> nf_conntrack   97201  6
>> openvswitch,nf_nat,nf_nat_ipv4,nf_nat_ipv6,nf_conntrack_ipv4,nf_conntrack_ipv6
>> libcrc32c  12644  1 openvswitch
>>
>> $ sudo modprobe --show-depends openvswitch
>> insmod /lib/modules/3.13.0-95-generic/kernel/lib/libcrc32c.ko
>> insmod /lib/modules/3.13.0-95-generic/kernel/net/ipv4/gre.ko
>> insmod /lib/modules/3.13.0-95-generic/kernel/net/ipv4/ip_tunnel.ko
>> insmod /lib/modules/3.13.0-95-generic/kernel/drivers/net/vxlan.ko
>> insmod
>> /lib/modules/3.13.0-95-generic/kernel/net/openvswitch/openvswitch.ko
>>
>>
>>  commands that configure conf.db with OVN related commands to make
>> rmmod fail
>>
>> HOST_IP=$(ip -4 addr show eth0 | grep -oP "(?<=inet ).*(?=/)")
>> OVN_DB_IP=$HOST_IP
>> OVN_SB_DB_PORT=${2-6642}
>> OVN_SB_REMOTE="tcp:${OVN_DB_IP}:${OVN_SB_DB_PORT}"
>> sudo ovs-vsctl --no-wait set open_vswitch .
>> external-ids:ovn-bridge="br-int"
>> sudo ovs-vsctl --no-wait set open_vswitch .
>> external-ids:ovn-encap-ip="$HOST_IP"
>> sudo ovs-vsctl --no-wait set open_vswitch .
>> external-ids:ovn-encap-type="geneve"
>> sudo ovs-vsctl --no-wait set open_vswitch .
>> external-ids:ovn-remote="$OVN_SB_REMOTE"
>>
>>
>>

Re: [ovs-discuss] Traffic loss after TEP deletion in OVS

[Jesse Gross]

On Mon, Sep 19, 2016 at 8:53 AM, Balazs Nemeth
 wrote:
> Dear All,
>
>
>
> I think we found a bug in OVS master. In the test case 3 OVS is used, VXLAN
> tunnels are configured among them in full mesh, so every node has 2 Tunnel
> End Point (TEP). BFD is turned on for monitoring the tunnel liveness. In the
> beginning, traffic and BFD messages are ongoing between all the nodes. If
> you delete 1 TEP from node-1 (TEP13 towards node-3), then the remaining TEP
> on node-1 (TEP12 towards node-2) will be affected also. I expect it to work
> after deleting another TEP, but it does not transmit packets. It will not be
> able to terminate VXLAN encapsulated packets any more! Due to this the BFD
> Forwarding status of the remaining TEP will go to False, and traffic will be
> dropped between this TEP and the another TEP of this remaining tunnel. I
> also see that dpctl flows for remaining tunnel will disappear after 10 sec.
>
>
>
> I think when you delete one TEP from the two, some data or setting of the
> remaining TEP will be overwritten improperly. Due to RFC 7348, OVS will
> accept VXLAN encapsulated packets on UDP dst_port 4789 by default. Perhaps
> this dst_port value will be overwritten. I made a port-mirroring on the
> physical interface and I can see packets like:
>
> d6:ee:ac:b9:6c:81 > 00:23:20:00:00:01, ethertype IPv4 (0x0800), length 66:
> 169.254.1.1.49186 > 169.254.1.0.3784: BFDv1, Control, State Down, Flags:
> [none], length: 24
>
> a0:36:9f:43:f2:f8 > a0:36:9f:43:f3:d8, ethertype IPv4 (0x0800), length 144:
> 10.85.46.4 > 10.85.46.7: ICMP 10.85.46.4 udp port 4789 unreachable, length
> 110
>
>
>
> The issue can be fixed if you change any parameter of the remaining TEP.
> After that TEP maybe reinitialized, and traffic can go through (BFD
> Forwarding will be True again), e.g. chaging remote_ip to random value and
> back:
>
> 1.   node-1: ovs-vsctl set Interface TEP12
> options:remote_ip=10.85.46.254
>
> node-1: ovs-vsctl set Interface TEP12 options:remote_ip=10.85.46.7
>
> The issue can be fixed also e.g. with modifying dst_port of TEPs between
> node-1 and node-2:
>
> 2.  node-1: ovs-vsctl set Interface TEP12 options:dst_port=4790
>
> node-2: ovs-vsctl set Interface TEP21 options:dst_port=4790
>
>
>
> We are working on the fix, any help or tips would be appreciated.

I agree it sounds like a bug :)

I haven't heard of this before, so I don't have any specific tips.
We'll look forward to seeing the patch.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] openvswitch2.3.0 kernel crash

[Jesse Gross]

There wasn't a direct followup but the problem was effectively
addressed by the lightweight tunnel changes and I don't believe that
it can happen at this point. Those changes were introduced in OVS 2.5.

I think it's unlikely that we will do another release off of the 2.3.x
series at this point so I'm not sure there is much more to do with
regards to backporting.

On Thu, Sep 8, 2016 at 4:34 AM, D. Herrendoerfer
<d.herrendoer...@herrendoerfer.name> wrote:
> Hello,
>
> was this issue ever followed up ?
> I see no corresponding changes in the kernel nor anywhere else,
> but I appear to have hit the same kernel crash.
>
> I see it on RHEL7.2 with openvswitch-2.3.2.
>
> Cheers,
>
> Dirk
>
>>Hi jesse,
>>
>>I will submit this patch to upstream then backport it to OVS
>>
>>
>>
>>
>>
>>At 2015-12-22 01:20:11, "Jesse Gross"  wrote:
>>>On Sun, Dec 20, 2015 at 9:29 PM, wenxu  wrote:
>>>> Hi all,
>>>>
>>>> I meet a crash problem in kernel with openvswitch2.3.0
>>>[...]
>>>> It crashed in ovs_flow_extract with _skb_pull the src mac address
>>>> (BUG_ON(skb->len < skb->data_len);)
>>>> int ovs_flow_extract(struct sk_buff *skb, u16 in_port, struct
>>>> sw_flow_key
>>>> *key)
>>>> {
>>>> .
>>>> __skb_pull(skb, 2 * ETH_ALEN);
>>>> .
>>>> }
>>>
>>>Thanks for tracking this down. I agree with your analysis.
>>>
>>>> I think ovs should check this mess situation in two ways.
>>>> 1. check the tpi->proto
>>>
>>>Your solution looks right to me but we also need to fix the upstream
>>>Linux kernel, which has the same issue. Can you please submit a patch
>>>to fix it there and then backport it to OVS? I should also point out
>>>that this does not affect the current version of either OVS or Linux
>>>as the code has changed and is not vulnerable to this. However, the
>>>older versions are still in use and being maintained.
>>>
>>>> 2. add pskb_may_pull before pull like ip_gre did
>>>
>>>I don't believe that this is necessary if we have #1. GRE does this
>>>for the Ethernet header if the protocol is set to TEB. Other Ethernet
>>>drivers are also required to enforce this invariant.
>
>
> ___
> discuss mailing list
> discuss@openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss
>
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] OVS - how to use geneve with variable length options ?

[Jesse Gross]

On Fri, Sep 2, 2016 at 3:38 AM, Manish Chopra  wrote:
> Thanks Jesse, I tried below and it actually used GENEVE header with options 
> [Total geneve header size = 16 bytes].
>
> ovs-vsctl add-br br2
> ifconfig br3 192.168.55.44
> ovs-vsctl add-port br2 gnv0 -- set interface gnv0 type=geneve 
> options:remote_ip=192.168.44.45
> ovs-ofctl add-tlv-map br2 "{class=0x,type=0x80,len=4}->tun_metadata0"
> ovs-ofctl add-flow br2 "in_port=LOCAL,actions=set_field:1234->tun_metadata0,1"
>
> I believe it used 4 bytes of Variable options data [with value 1234] in 
> option header.
>
> If I were to add more variable options data, How can I achieve that ??

There is a 'len' field in the add-tlv-map command you used. You can
change this to create options of different lengths. The length
represents the option payload data, not including the option header (4
bytes) or the base header (8 bytes). In this case you specified a
payload length of 4 bytes, so that plus 4 bytes for the option header
plus 8 bytes from the base header yields the 16 bytes you saw on the
wire.

In order to remap it you'll need to first delete the existing mapping and flows:
ovs-ofctl del-tlv-map br2 "{class=0x,type=0x80,len=4}->tun_metadata0"
ovs-ofctl del-flows br2 "in_port=LOCAL"

You can also add multiple options by creating additional mappings:
ovs-ofctl add-tlv-map br2 "{class=0x,type=0x80,len=4}->tun_metadata0"
ovs-ofctl add-tlv-map br2 "{class=0x,type=0,len=8}->tun_metadata1"
ovs-ofctl add-flow br2
"in_port=LOCAL,actions=set_field:1234->tun_metadata0,set_field:5678->tun_metadata1,1"
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Hi openvswitch team

[Jesse Gross]

On Thu, Sep 1, 2016 at 7:12 PM, Grace Lee  wrote:
> Hi my kernel version is 4.4.13-v7+ so the compatible openvswitch version
> should be 2.6.x. However, the latest openvswitch version is 2.5.0. when I
> ./configure -with linux, it gives me an error displaying "
>
> configure: error: Linux kernel in  is version , but
>version newer than  is not supported (please refer to the
>FAQ for advice).

In most case you can simply use the Open vSwitch module that is
packaged with your distribution kernel. You just need to build the OVS
without kernel support and modprobe openvswitch.

If there is a feature that is not available in that kernel module, you
can also use branch-2.6 from OVS git, which supports kernels up to
4.7.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] OVS - how to use geneve with variable length options ?

[Jesse Gross]

On Thu, Sep 1, 2016 at 11:40 AM, Manish Chopra <manish.cho...@qlogic.com> wrote:
>> -Original Message-----
>> From: Jesse Gross [mailto:je...@kernel.org]
>> Sent: Wednesday, August 31, 2016 10:26 PM
>> To: Manish Chopra <manish.cho...@qlogic.com>
>> Cc: pshe...@nicira.com; b...@openvswitch.org
>> Subject: Re: OVS - how to use geneve with variable length options ?
>>
>> On Wed, Aug 31, 2016 at 12:13 AM, Manish Chopra
>> <manish.cho...@qlogic.com> wrote:
>> >> -Original Message-
>> >> From: Jesse Gross [mailto:je...@kernel.org]
>> >> Sent: Wednesday, August 31, 2016 12:55 AM
>> >> To: Manish Chopra <manish.cho...@qlogic.com>
>> >> Cc: pshe...@nicira.com; b...@openvswitch.org
>> >> Subject: Re: OVS - how to use geneve with variable length options ?
>> >> On Tue, Aug 30, 2016 at 11:24 AM, Manish Chopra
>> >> <manish.cho...@qlogic.com> wrote:
>> >> > When I run traffic between both OVS bridge – I see that it uses geneve
>> >> > header of size 8 bytes.
>> >> >
>> >> > I was wondering if I could use GENEVE with options using OVS ? which
>> would
>> >> > have geneve header size more than 8 bytes ?
>> >> >
>> >> >
>> >> >
>> >> > I couldn’t find anything about what arguments I should be using with
>> >> > ovs-vsctl on both setups to use GENEVE with options ?
>> >> >
>> >> > Could you please supply necessary configuration/commands which I can try
>> to
>> >> > use GENEVE with options while running traffic ??
>> >>
>> >> In order to use options with Geneve tunnels, you'll need to map TLVs
>> >> onto a set of tun_metadataXXX fields, which can then be used with any
>> >> OVS flow mechanism, such as matches and actions. There is some
>> >> information on how to do this in the ovs-ofctl man page:
>> >> https://github.com/openvswitch/ovs/blob/v2.5.0/utilities/ovs-
>> ofctl.8.in#L427
>> >>
>> >> You'll need to be using OVS 2.5 or newer to do this.
>> >>
>> > Hi Jesse, I have tried below configuration using ovs-ofctl on top of 
>> > earlier
>> configuration using ovs-vsctl on both setups
>> > , as referenced in man page.
>> >
>> > ovs-ofctl add-tlv-map br2 "{class=0x,type=0x80,len=4}->tun_metadata0"
>> > ovs-ofctl add-flow br2 tun_metadata0=1234,actions=controller
>> >
>> > But I still see geneve header is used of size 8 Bytes when I run TCP stream
>> between OVS bridges.
>> > Not sure if I am missing something in the configuration using ovs-ofctl ?
>>
>> The flow that you have above will match incoming packets with that
>> particular option, rather than generate it. In this case, any incoming
>> packet with class 0x, type 0x80, and value 1234 will be sent to
>> the controller.
>>
>> To generate packets with options, you need an action such as
>> set_field. For example:
>> ovs-ofctl add-flow br2
>> "in_port=LOCAL,actions=set_field:1234->tun_metadata0,"
>
> Hi Jesse,
> I am not much familiar with OVS flow mechanism and these commands.
> I just want to try GENEVE tunnel traffic with OVS which could use variable 
> size geneve header in the packet to
> test if our NIC offloads works fine with variable length geneve header or not.
>
> Below is my setup configuration  - two physical hosts which are connected 
> back to back using NIC port [eth1 and eth2]
> Below are IP addresses of OVS bridges and NIC interfaces.
>
> eth1- 192.168.44.44
> eth2- 192.168.44.45
> br2  [Setup 1] – 192.168.55.44
> br2  [Setup 2] -  192.168.55.45
>
>
>Setup  1   
>Setup 2
>
> ##
>   #
> OVS br2 -- eth1 - ###  --- 
> ### - eth2 ---OVS br2
> ##
>  #
>
> Setup 1 -
> ovs-vsctl add-br br2
> ovs-vsctl add-port br2 gnv0 -- set interface gnv0 type=geneve 
> options:remote_ip=192.168.44.45
>
> Setup 2 -
> ovs-vsctl add-br br2
> ovs-vsctl add-port br2 gnv0 -- set interface gnv0 type=geneve 
> options:remote_ip=192.168.44.44
>
> After adding geneve port on both setups - I can ping and run TC

Re: [ovs-discuss] OVS - how to use geneve with variable length options ?

[Jesse Gross]

On Wed, Aug 31, 2016 at 12:13 AM, Manish Chopra
<manish.cho...@qlogic.com> wrote:
>> -Original Message-----
>> From: Jesse Gross [mailto:je...@kernel.org]
>> Sent: Wednesday, August 31, 2016 12:55 AM
>> To: Manish Chopra <manish.cho...@qlogic.com>
>> Cc: pshe...@nicira.com; b...@openvswitch.org
>> Subject: Re: OVS - how to use geneve with variable length options ?
>> On Tue, Aug 30, 2016 at 11:24 AM, Manish Chopra
>> <manish.cho...@qlogic.com> wrote:
>> > When I run traffic between both OVS bridge – I see that it uses geneve
>> > header of size 8 bytes.
>> >
>> > I was wondering if I could use GENEVE with options using OVS ? which would
>> > have geneve header size more than 8 bytes ?
>> >
>> >
>> >
>> > I couldn’t find anything about what arguments I should be using with
>> > ovs-vsctl on both setups to use GENEVE with options ?
>> >
>> > Could you please supply necessary configuration/commands which I can try to
>> > use GENEVE with options while running traffic ??
>>
>> In order to use options with Geneve tunnels, you'll need to map TLVs
>> onto a set of tun_metadataXXX fields, which can then be used with any
>> OVS flow mechanism, such as matches and actions. There is some
>> information on how to do this in the ovs-ofctl man page:
>> https://github.com/openvswitch/ovs/blob/v2.5.0/utilities/ovs-ofctl.8.in#L427
>>
>> You'll need to be using OVS 2.5 or newer to do this.
>>
> Hi Jesse, I have tried below configuration using ovs-ofctl on top of earlier 
> configuration using ovs-vsctl on both setups
> , as referenced in man page.
>
> ovs-ofctl add-tlv-map br2 "{class=0x,type=0x80,len=4}->tun_metadata0"
> ovs-ofctl add-flow br2 tun_metadata0=1234,actions=controller
>
> But I still see geneve header is used of size 8 Bytes when I run TCP stream 
> between OVS bridges.
> Not sure if I am missing something in the configuration using ovs-ofctl ?

The flow that you have above will match incoming packets with that
particular option, rather than generate it. In this case, any incoming
packet with class 0x, type 0x80, and value 1234 will be sent to
the controller.

To generate packets with options, you need an action such as
set_field. For example:
ovs-ofctl add-flow br2
"in_port=LOCAL,actions=set_field:1234->tun_metadata0,"
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] OVS - how to use geneve with variable length options ?

[Jesse Gross]

On Tue, Aug 30, 2016 at 11:24 AM, Manish Chopra
 wrote:
> Hi Jesse,
>
>
>
> I am trying GENEVE tunneling via OVS bridge port using ovs-vsctl tool on my
> two servers which are connected back to back
>
> and running latest net-next kernel.
>
>
>
> eth1- 192.168.44.44
>
> eth2- 192.168.44.45
>
> br2  [Setup 1] – 192.168.55.44
>
> br2  [Setup 2] -  192.168.55.45
>
>
>
>
>
>Setup  1
> Setup 2
>
> ##
> #
>
> OVS br2 -- eth1 - ###  ---
> ### - eth2 ---OVS br2
>
> ##
> #
>
>
>
> I have configured OVS using below commands  -
>
>
>
> Setup 1
>
> ovs-vsctl add-br br2
>
> ovs-vsctl add-port br2 gnv0 -- set interface gnv0 type=geneve
> options:remote_ip=192.168.44.45 options:key=01 options:dst_port=4789
>
>
>
> Setup 2
>
> ovs-vsctl add-br br2
>
> ovs-vsctl add-port br2 gnv0 -- set interface gnv0 type=geneve
> options:remote_ip=192.168.44.44 options:key=01 options:dst_port=4789
>
>
>
> When I run traffic between both OVS bridge – I see that it uses geneve
> header of size 8 bytes.
>
> I was wondering if I could use GENEVE with options using OVS ? which would
> have geneve header size more than 8 bytes ?
>
>
>
> I couldn’t find anything about what arguments I should be using with
> ovs-vsctl on both setups to use GENEVE with options ?
>
> Could you please supply necessary configuration/commands which I can try to
> use GENEVE with options while running traffic ??

In order to use options with Geneve tunnels, you'll need to map TLVs
onto a set of tun_metadataXXX fields, which can then be used with any
OVS flow mechanism, such as matches and actions. There is some
information on how to do this in the ovs-ofctl man page:
https://github.com/openvswitch/ovs/blob/v2.5.0/utilities/ovs-ofctl.8.in#L427

You'll need to be using OVS 2.5 or newer to do this.

I also noticed that you're configuring port 4789 for the tunnels. Any
port will work as long as both sides are configured the same way but
this is a bit odd since it is the port assigned to VXLAN. Geneve has
been assigned UDP port 6081 and OVS will use this by default if no
port is explicitly configured.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] most recent repo does not make (github)

[Jesse Gross]

Everything is building fine for me at the moment with Ubuntu 16.04.

On Mon, Aug 29, 2016 at 8:30 AM, Ben Pfaff  wrote:
> Does anyone else see this problem?  I still can't reproduce it, even
> from a new, completely clean checkout.
>
> On Mon, Aug 29, 2016 at 09:07:36AM -0500, Christopher Hannon wrote:
>> commit 03dabc3
>> on ubuntu vm
>>
>>
>>
>> On Sat, Aug 27, 2016 at 8:21 PM, Ben Pfaff  wrote:
>>
>> > On Sat, Aug 27, 2016 at 04:35:59PM -0500, Christopher Hannon wrote:
>> > > Make does not run:
>> > >
>> > > PYTHONPATH=./python":"$PYTHONPATH PYTHONDONTWRITEBYTECODE=yes
>> > > /usr/bin/python ./ovsdb/ovsdb-idlc.in c-idl-source
>> > lib/vswitch-idl.ovsidl >
>> > > lib/vswitch-idl.c.tmp && mv lib/vswitch-idl.c.tmp lib/vswitch-idl.c
>> > > Traceback (most recent call last):
>> > >   File "./ovsdb/ovsdb-idlc.in", line 1409, in 
>> > > func(*args[1:])
>> > >   File "./ovsdb/ovsdb-idlc.in", line 672, in printCIDLSource
>> > > column, True)
>> > >   File "./ovsdb/ovsdb-idlc.in", line 66, in cMembers
>> > > 'type': constify(type.key.toCType(prefix, refTable) + pointer,
>> > const),
>> > > TypeError: toCType() takes exactly 2 arguments (3 given)
>> > > make: *** [lib/vswitch-idl.c] Error 1
>> >
>> > I can't reproduce the problem, and travis-ci shows a clean build too.
>> >
>> > What commit is this?
>> >
> ___
> discuss mailing list
> discuss@openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] OVS gtp-u implementation

[Jesse Gross]

Please don't drop the mailing list.

There are no versions of OVS that support GTP. As I said, I don't know
of anyone currently working on it or patches that are available that
can readily be applied.

On Mon, Aug 22, 2016 at 1:32 AM, Ashish Kurian <ashish...@gmail.com> wrote:
> Dear Jesse,
>
> There is a kernel available online which was edited 4 weeks ago. Were you
> aware of that? There was some work done in 2012 and then there was no
> activity on this again til 2016 beginning. Do you have any idea on the
> performance of the kernel available now?
>
> Best Regards,
> Ashish Kurian
>
> On Fri, Aug 19, 2016 at 5:35 PM, Jesse Gross <je...@kernel.org> wrote:
>>
>> On Fri, Aug 19, 2016 at 1:16 AM, Ashish Kurian <ashish...@gmail.com>
>> wrote:
>> > Dear All,
>> >
>> > As part of my internship, I am trying to evaluate the GTP-U
>> > implementation
>> > on OVS. Is there a patch already available and if so, how good is that?
>>
>> There were some people that expressed interest in it a while ago but I
>> don't think there is any current work on it.
>
>
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] OVS gtp-u implementation

[Jesse Gross]

On Fri, Aug 19, 2016 at 1:16 AM, Ashish Kurian  wrote:
> Dear All,
>
> As part of my internship, I am trying to evaluate the GTP-U implementation
> on OVS. Is there a patch already available and if so, how good is that?

There were some people that expressed interest in it a while ago but I
don't think there is any current work on it.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Getting kernel panic on vxlan tunnel setup

[Jesse Gross]

On Wed, Jul 27, 2016 at 1:48 PM, Hasan H. Gürsoy
 wrote:
>
> Hi there,
>
> I'm trying to get a three node setup working with vxlan setup,  but every
> try with different configuration options fail after setup of the vxlan
> ports.
>
> Node0:
>
> # ovs-vsctl show
> 1c34bd9e-f6cd-4d8c-8096-c087f42a9b24
> Bridge "br0"
> Port "eth0"
> Interface "eth0"
> Port "br0"
> Interface "br0"
> type: internal
> Bridge "br1"
> Port "patch1-2"
> Interface "patch1-2"
> type: patch
> options: {peer="patch2-1"}
> Port "eth1"
> Interface "eth1"
> Port "vxlan-10.0.5.11"
> Interface "vxlan-10.0.5.11"
> type: vxlan
> options: {key=flow, remote_ip="10.0.5.11"}
> Port "vxlan-10.0.5.12"
> Interface "vxlan-10.0.5.12"
> type: vxlan
> options: {key=flow, remote_ip="10.0.5.12"}
> Port "br1"
> Interface "br1"
> type: internal
> Bridge "br2"
> Port "br2"
> Interface "br2"
> type: internal
> Port "patch2-1"
> Interface "patch2-1"
> type: patch
> options: {peer="patch1-2"}
> ovs_version: "2.5.0"
>
> Both other nodes get both vxlan interfaces with each two other node ip.
>
>
> node0
> # ip  addr show br1
> 9: br1:  mtu 1500 qdisc noqueue state
> UNKNOWN group default qlen 1
> link/ether xx:xx:xx:xx:xx:x0 brd ff:ff:ff:ff:ff:ff
> inet 10.0.5.10/24 brd 10.0.5.255 scope global br1
>valid_lft forever preferred_lft forever

It looks like you have a loop in your routing configuration. The route
to br1 is in the same subnet as the destination for your tunnels. As a
result, when a packet is transmitted from the tunnel, it will go back
to the bridge interface which will encapsulate it in a tunnel again
and so on.

Most likely eth1 should not be in the bridge and the IP address should
be on that instead. The underlay and overlay networks are logically
separate and shouldn't be bridged together.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] GUE support?

[Jesse Gross]

On Wed, Jul 27, 2016 at 5:37 PM, Luca Salvatore  wrote:
> I've found some random articles which talk about GUE (generic UDP
> encapsulation) but can anyone give me a solid yes or no answer if OVS
> support GUE
> (https://tools.ietf.org/html/draft-ietf-nvo3-gue-04#section-5.10)

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

Re: [ovs-discuss] [ovn] linux headers

[Jesse Gross]

On Mon, Jul 18, 2016 at 10:55 PM, Murali R  wrote:
>
>> The easiest thing to do is likely just to use the OVS module that is
>> shipped as part of your distribution kernel - it is pretty recent so
>> it should have most features. If you really need something that is
>> missing from that (NAT is the most obvious example) then the best path
>> is likely to wait a little while longer and use the master branch.
>
> Thank you.
> I am building code on top of master, so for now will stick with older trusty
> builds.
> Due to CT backports, I was not too sure to just remove that check, so was
> inquiring.
> Maybe we need a switch in build to use CT backport or use from current linux
> headers?
> I am not a kernel person, so not aware of complications there.
> Considering 4.4 is now a common place we  probably need to get a build
> process
> work with it IMO.

There are some patches under review to add support for up to kernel
4.6, so I would expect master to have support for these kernels in the
next couple days or so. Once that goes in, there shouldn't be any need
to worry about backports, conntrack or otherwise.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] [ovn] linux headers

[Jesse Gross]

On Fri, Jul 15, 2016 at 10:31 PM, Murali R  wrote:
> Some cloud images (like in digital ocean) are having kernels updated to 4.4
> for the standard 14.04.4 images. I had to really look around to get one with
> 3.13 headers. The ovs/ovn build is checking the headers and exiting for
> headers > 4.3. Don't recall if the check was in ovs build or in devstack
> stack.sh.
>
> Is there an issue that will prevent ovs/ovn from working in 4.4 kernel?
> Meaning if i remove that check what will fail?

There have been some reports that things work fine for kernels up to
4.6 just by removing the check. However, there have been a large
number of patches recently to bring in changes from new kernels (and
more are still coming) so I can't really recommend just hoping for the
best.

The easiest thing to do is likely just to use the OVS module that is
shipped as part of your distribution kernel - it is pretty recent so
it should have most features. If you really need something that is
missing from that (NAT is the most obvious example) then the best path
is likely to wait a little while longer and use the master branch.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] OVS and TCP checksum offloading

[Jesse Gross]

On Fri, Jul 15, 2016 at 12:44 AM, Eder Leão Fernandes
 wrote:
> Hi,
>
> Quick question.
> How does Open vSwitch handles TCP checksum offloading? Does it recalculates
> and rewrites the TCP checksum for every TCP packet?
>
> I am almost sure it does, since it looks like the only explanation to have
> TCP sessions working on my mininet setup. (Two hosts with checksum
> offloading connected by OVS. I am using iperf to create TCP sessions).
> Just asking to confirm if there is not some kind of special handling.

Unless there is an action that modifies the packet, OVS doesn't touch
the checksum of the packet, it just passes it through. If checksum
offloading is in use then the checksum would ultimately be calculated
by the NIC as it exits the machine.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] skb_warn_bad_offload+0xc8/0xd3() kernel warning on linux v3.14.57+ovs 2.5.0

[Jesse Gross]

On Wed, Jul 13, 2016 at 4:05 AM, 张东亚 <fortitude.zh...@gmail.com> wrote:
> Hi,
>
> Recently we upgraded to ovs 2.5 and use the datapath in the ovs code(means
> we do not use kernel datapath), however, when we test vxlan performance
> between two VMs on different compute node, we observed the bandwidth can
> only achieve 5Gbps on the 10Gbps intel nic pair, and we are still using
> kernel v3.14.57.
>
> We found lots of following warning (see stack in the PS) in dmesg and thinks
> it causes the bad performance.
>
> After trying to read the source code of the kernel and ovs 2.5 datapath
> code, it seems gso_type 513(0x201) cause the problem, since our VM tap
> interface does not have tx-udp_tnl-segmentation(NETIF_F_GSO_UDP_TUNNEL_BIT)
> flag enabled by default, net_gso_ok return false which cause
> __skb_gso_segment being called, and since tcpv4_gso_complete have set the
> skb->ip_summed to CHECKSUM_UNCESSARY, which cause skb_warn_bad_offload being
> called.
>
> My wonder is whether this is a desired behavior, or OVS should clear the
> NETIF_F_GSO_UDP_TUNNEL_BIT bit when send the inner packet (may be GSOed) to
> tap interface on the host?

This is an upstream kernel problem, fixed by:

commit a09a4c8dd1ec7f830e1fb9e59eb72bddc965d168
Author: Jesse Gross <je...@kernel.org>

tunnels: Remove encapsulation offloads on decap.

If a packet is either locally encapsulated or processed through GRO
it is marked with the offloads that it requires. However, when it is
decapsulated these tunnel offload indications are not removed. This
means that if we receive an encapsulated TCP packet, aggregate it with
GRO, decapsulate, and retransmit the resulting frame on a NIC that does
not support encapsulation, we won't be able to take advantage of hardware
offloads even though it is just a simple TCP packet at this point.

This fixes the problem by stripping off encapsulation offload indications
when packets are decapsulated.

The performance impacts of this bug are significant. In a test where a
Geneve encapsulated TCP stream is sent to a hypervisor, GRO'ed,
decapsulated,
and bridged to a VM performance is improved by 60% (5Gbps->8Gbps) as a
result of avoiding unnecessary segmentation at the VM tap interface.

Reported-by: Ramu Ramamurthy <srama...@linux.vnet.ibm.com>
    Fixes: 68c33163 ("v4 GRE: Add TCP segmentation offload for GRE")
Signed-off-by: Jesse Gross <je...@kernel.org>
Signed-off-by: David S. Miller <da...@davemloft.net>

The problem is not really related to OVS and so the right solution is
really to upgrade your base kernel. However, since it does affect OVS
users we have backported code into the OVS tree to avoid it.
Unfortunately, the fix is too large to bring to OVS 2.5, so you'll
need to use the current master branch.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Request for comments on Open vSwitch joining the Linux Foundation

[Jesse Gross]

On Fri, Jul 8, 2016 at 8:15 AM, Gray, Mark D  wrote:
>> On Wed, Jul 6, 2016 at 9:12 AM, Gray, Mark D 
>> wrote:
>> > Processes (not really dealt with by the charter but worth some discussion):
>> > * I think the following would improve transparency, I don't know if this
>> should be in the charter, but I think it would be good to address:
>> >  a. A more open roadmap to avoid duplication, encourage collaboration
>> and avoid disappointment when a lot of work has been put into something
>> that doesn't get a lot of support from the community. I really liked the way
>> OVN started, Ben circulated some development documents which gave
>> everyone a good idea of what was going on before code was written and an
>> opportunity to help out or comment on. You could take this to the extreme
>> and do something like blueprints in Openstack (but this is probably a too
>> heavyweight?)
>> >  b: When the TSC members meet, it would be good that it was
>> documented and shared so we can understand the decision making process
>> for the technical direction.
>> >
>> > Voting:
>> > * The charter states that "While it is the goal of OVS to operate as a
>> consensus based community, if any TSC decision requires a vote to move
>> forward, the Committers shall vote on a one vote per Committer basis."
>> >Due to b) above, the distribution of the TSC inevitably weighted towards
>> the Nicira team which effectively gives veto to one group. I believe this is
>> something we should as a community attempt to change. This is obviously
>> not going to happen immediately but if we put the right processes in place, 
>> it
>> should make it easier. One example may be to limit the number of votes
>> allocated to one group? Maybe there are other suggestions?
>> >
>> > * There doesn't seem to be a process to propose a committer unless you
>> are a committer. Maybe this could change?
>>
>> I think one thing that might be useful for context is that the
>> committers as a group (soon to be TSC) have never discussed or voted
>> on anything other than administrative matters - meaning things like
>> electing new committers and now this transition to the Linux
>> Foundation. There aren't any meetings where roadmaps are planned or
>> otherwise decide on anything related to technical direction - all of
>> that would take place on the public mailing list. In that light,
>> anyone can send out proposals for roadmaps, etc. to the mailing list
>> in the same way that anyone can submit patches. (And there actually
>> isn't much advantage to being a committer - a committer better not be
>> applying patches that haven't been reviewed or aren't supported by the
>> community.)
>
> Actually, I didn’t think that you guys did discuss other matters. However, I 
> think
> that this is a gap. I think it would be beneficial to have a better 
> understanding of
> what contributors are working on or are thinking of working on as it
> may help encourage collaboration early in the design phase of features and
> get early feedback.
>
> Again, this is more related to process than the charter but I would
> encourage the TSC to look at these processes. Also, on the subject of process
> a bug tracking database of some description may be useful. I'm sure the
> Linux Foundation could provide the infrastructure for this.

Just one quick note on the bug tracker - there actually is one already
as part of the OVS project in github
(https://github.com/openvswitch/ovs-issues/issues). It's mostly used
by the Windows guys but I think that if more people started using it
then more developers would start looking at it carefully.

I agree that the development process is probably separate from what
goes into the charter but it's absolutely important to discuss how we
can improve things. The main thing is likely how to balance any
processes with what I think is a pretty strong desire to keep things
lightweight. I actually really would encourage people to send
development plans/proposals to the mailing list in advance - I know
that some open source communities only want to see code but my feeling
is that people here are pretty open to giving comments on proposals.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Not getting traffic through ipsec_gre

[Jesse Gross]

On Thu, Jul 7, 2016 at 10:55 AM, Bolesław Tokarski
 wrote:
> Hello,
>
> I installed Ubuntu 16.04 on the hostB to check the behaviour between the two
> OSes.
>
> The setup is the same as with two hosts running OpenSUSE:
>
>
>>> >
>>> > hostA:
>>> >
>>> > ovs-vsctl add-br secure
>>> > ip link set secure up
>>> > ip addr add 192.168.20.1/24 broadcast 192.168.20.255 dev secure
>>> > ovs-vsctl add-port secure gre3 -- set interface gre3 type=ipsec_gre
>>> > options:remote_ip=2.2.2.2 options:psk=secret
>>> >
>>> > hostB:
>>> >
>>> > ovs-vsctl add-br secure
>>> > ip link set secure up
>>> > ip addr add 192.168.20.2/24 broadcast 192.168.20.255 dev secure
>>> > ovs-vsctl add-port secure gre3 -- set interface gre3 type=ipsec_gre
>>> > options:remote_ip=1.1.1.1 options:psk=secret
>>> >
>
>
> As mentioned, both sides manage to negotiate IPsec connection, set the
> interfaces up, etc.
>
> Now, when I ping from hostA to hostB, I can see ARP request going out the
> "secure" interface, through eth0 as an ESP packet, to eth0 on hostB,
> decyphered and arriving at "secure" on hostB.
>
> Then, there's an ARP reply from hostB, going through eth0 as ESP on hostB,
> arriving at eth0 on hostA.
>
> I can even see the response in ovs-dpctl dump-flows on hostA. However,
> nothing is received on the "secure" interface on hostA.
>
> Is there something I can do to debug further? Maybe there's a missing return
> flow rule that does not get automatically setup on OpenSUSE while it is on
> Ubuntu? Is there some known issue with the particular OVS/kernel versions
> that OpenSUSE runs (ovs 2.3.1, kernel 4.1.26-21)? Or maybe there's a
> mismatch between the OVS and kernel datapath module? OpenSUSE seems to ship
> the one from the kernel.

Did you also port the iptables rules that are setup by the init script
on Debian? If those are missing then that would likely cause the
behavior that you are describing since OVS would consider the incoming
traffic to be an attempt to inject unauthenticated traffic into the
secure port.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Request for comments on Open vSwitch joining the Linux Foundation

[Jesse Gross]

On Wed, Jul 6, 2016 at 9:12 AM, Gray, Mark D  wrote:
> Processes (not really dealt with by the charter but worth some discussion):
> * I think the following would improve transparency, I don't know if this 
> should be in the charter, but I think it would be good to address:
>  a. A more open roadmap to avoid duplication, encourage collaboration and 
> avoid disappointment when a lot of work has been put into something that 
> doesn't get a lot of support from the community. I really liked the way OVN 
> started, Ben circulated some development documents which gave everyone a good 
> idea of what was going on before code was written and an opportunity to help 
> out or comment on. You could take this to the extreme and do something like 
> blueprints in Openstack (but this is probably a too heavyweight?)
>  b: When the TSC members meet, it would be good that it was documented 
> and shared so we can understand the decision making process for the technical 
> direction.
>
> Voting:
> * The charter states that "While it is the goal of OVS to operate as a 
> consensus based community, if any TSC decision requires a vote to move 
> forward, the Committers shall vote on a one vote per Committer basis."
>Due to b) above, the distribution of the TSC inevitably weighted towards 
> the Nicira team which effectively gives veto to one group. I believe this is 
> something we should as a community attempt to change. This is obviously not 
> going to happen immediately but if we put the right processes in place, it 
> should make it easier. One example may be to limit the number of votes 
> allocated to one group? Maybe there are other suggestions?
>
> * There doesn't seem to be a process to propose a committer unless you are a 
> committer. Maybe this could change?

I think one thing that might be useful for context is that the
committers as a group (soon to be TSC) have never discussed or voted
on anything other than administrative matters - meaning things like
electing new committers and now this transition to the Linux
Foundation. There aren't any meetings where roadmaps are planned or
otherwise decide on anything related to technical direction - all of
that would take place on the public mailing list. In that light,
anyone can send out proposals for roadmaps, etc. to the mailing list
in the same way that anyone can submit patches. (And there actually
isn't much advantage to being a committer - a committer better not be
applying patches that haven't been reviewed or aren't supported by the
community.)
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] vxlan over IPv6

[Jesse Gross]

No, the situation is the same as before. I think you'll have to wait
until the OVS 2.6 release later this year.

On Wed, Jul 6, 2016 at 4:56 AM, zhangqunjian <zhangqunjian2...@126.com> wrote:
>
>
> HI，does support for IPv6 tunneling backport to the OVS out-of-tree kernel
> module for now?
> On 01/25/2016 23:53, Jesse Gross wrote:
>
> On Sat, Jan 23, 2016 at 3:59 AM, zhangqunjian <zhangqunjian2...@126.com>
> wrote:
>>
>> Hi,  I use OVS created vxlan tunnel based on IPv6. As far as I know,
>> GitHub
>> master branch has been commited part code of this function. when I used it
>> into my project，I found that vxlan over IPv6 configuration is working
>> properly，but function worked not well. I built the vxlan tunnel over IPv6
>> between two virtual machines through OVS, the Ping of veth0 of the two
>> virtual machines was blocked. Excuse me, is this my wrong use or OVS don't
>> support the vxlan over IPv6 Tunnel ? If OVS don't support vxlan over
>> ipv6,there is have any time for support .
>
> Support for IPv6 tunneling hasn't been backported yet to the OVS
> out-of-tree kernel module. As a result, you'll need to run the module
> from Linux 4.4 or newer.
>
>
>
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Not getting traffic through ipsec_gre

[Jesse Gross]

On Tue, Jul 5, 2016 at 4:04 PM, Bolesław Tokarski
 wrote:
> Hello,
>
> For some reason machine receiving traffic through ipsec_gre is not putting
> it through to the LOCAL interface.
>
> I have a basic test setup:
>
> hostA - ip network - hostB
>
> Both hosts have just a single eth0 interface. I managed to get a regular gre
> tunnel working (thanks to Mathy Vanvoorden's blogpost) with - hostA:
>
> ovs-vsctl add-br insecure
> ip link set insecure up
> ip addr add 192.168.10.1/24 broadcast 192.168.10.255 dev insecure
> ovs-vsctl add-port insecure gre0 -- set interface gre0 type=gre
> options:remote_ip=2.2.2.2
>
> hostB:
>
> ovs-vsctl add-br insecure
> ip link set insecure up
> ip addr add 192.168.10.2/24 broadcast 192.168.10.255 dev insecure
> ovs-vsctl add-port insecure gre0 — set interface gre0 type=gre
> options:remote_ip=1.1.1.1
>
> on hostB.
>
> Now, I am able to ping both hostA and hostB between each other using the
> 192.168.10.1 and 192.168.10.2 IP addresses.
>
> However, changing this to ipsec_gre causes some problems - hostA:
>
> ovs-vsctl add-br secure
> ip link set secure up
> ip addr add 192.168.20.1/24 broadcast 192.168.20.255 dev secure
> ovs-vsctl add-port secure gre3 -- set interface gre3 type=ipsec_gre
> options:remote_ip=2.2.2.2 options:psk=secret
>
> hostB:
>
> ovs-vsctl add-br secure
> ip link set secure up
> ip addr add 192.168.20.2/24 broadcast 192.168.20.255 dev secure
> ovs-vsctl add-port secure gre3 -- set interface gre3 type=ipsec_gre
> options:remote_ip=1.1.1.1 options:psk=secret
>
> Pinging the machines between each with the internal IPs gives no response.
> On the machine attempting ping, tcpdump shows arp requests on the "secure"
> interface, ESP outgoing packets on eth0. On the machine receiving I see
> incoming ESP packets on eth0, and nothing on the "secure" interface.
>
> I checked the logs and I can confirm that ipsec session was initiated
> successfully. Increasing the ovs-vswitchd log verbosity to DEBUG I could
> even spot packets arp packets on the receiving machine:
>
> 2016-07-05T22:24:12.771Z|34809|dpif(revalidator35)|DBG|system@ovs-system:
> flow_dump
> recirc_id(0),dp_hash(0/0),skb_priority(0),tunnel(tun_id=0x0,src=1.1.1.1,dst=2.2.2.2,tos=0x0,ttl=63,flags()),in_port(1),skb_mark(0),eth(src=11:22:33:44:55:66,dst=ff:ff:ff:ff:ff:f
> f),eth_type(0x0806),arp(sip=192.168.20.1/255.255.255.255,tip=192.168.20.2/255.255.255.255,op=1/0xff,sha=22:33:44:55:66:77/00:00:00:00:00:00,tha=00:00:00:00:00:00/00:00:00:00:00:00),
> packets:13, bytes:546, used:0.476s, actions:3
>
> So, iiuc, it means that the ARP request got through the ipsec tunnel and was
> received by vswitchd on the other side, but for some reason, vswitchd did
> not put the request to the "secure" interface.
>
> I think it is some bug, but I can't rule out that this is an expected
> behaviour. Please point me out if you notice anything missing from my setup.
>
> The machines are running OpenSUSE 42.1, with kernel 4.1.21, ipsec-tools
> 0.8.0 and openvswitch 2.3.1.

Interfaces with type ipsec_gre require running the ovs-monitor-ipsec
script to function but this is only available for Debian. However, you
can just use normal GRE interfaces in OVS and then configure IPsec by
hand.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Bug OpenVSwitch 2.5.0 - Enabling IPFIX in OpenVSwitch breaks VXLAN tunneling

[Jesse Gross]

On Fri, Jul 1, 2016 at 5:19 AM, Lluís Gifre  wrote:
> Dear all,
>
> I'm experiencing a problem when enabling IPFIX on an OpenVSwitch where VXLAN
> tunnels are configured to interconnect 2 VMs (Virtual Box).

Wenyu and Daniel, this is an area that you guys have been working in,
can you please take a look?
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] [ovs-dev] Request for comments on Open vSwitch joining the Linux Foundation

[Jesse Gross]

On Mon, Jun 27, 2016 at 4:51 PM, Flavio Leitner <f...@sysclose.org> wrote:
> On Mon, Jun 27, 2016 at 01:30:03PM -0700, Jesse Gross wrote:
>> On Mon, Jun 27, 2016 at 1:03 PM, Flavio Leitner <f...@sysclose.org> wrote:
>> > On Sun, Jun 19, 2016 at 12:35:34PM -0700, Ben Pfaff wrote:
>> >> On Sun, Jun 19, 2016 at 09:36:47AM -0700, Ben Pfaff wrote:
>> >> > LF expects OVS to be a rather small budgetary burden, due to the
>> >> > project's simple structure.  The TSC will coordinate with LF for any
>> >> > budgetary needs.
>> >
>> > Moving to Linux Foundation seems to be a step in a good direction and
>> > the attached document looks good enough that the community is pretty
>> > much unaffected by the change.
>> >
>> > You mentioned OVS is expected to have small budgetary burden but we
>> > usually had a conference once in a year that has a significant cost.
>> > Has this been considered? Any expected changes for this year?
>>
>> My understanding is the conference is something that the Linux
>> Foundation is willing to cover (and organize as well). Regardless, the
>> plans for this year are unchanged and essentially the same as last
>> year.
>
> OK.
>
>> > You also mentioned that VMware is on board, so I assume that we have
>> > at least one official sponsor signing in?
>> >
>> > I suspect some companies out there would be willing to support OVS,
>> > but it's not clear what will be required to signing in and/or the
>> > advantages to do so.
>>
>> I think it would ultimately be up to the Linux Foundation to decide
>> how to handle this. Obviously, anything along these lines would not
>> conflict with the structure set out by the proposed charter.
>
> Sort of, I see that as a requirement for the proposed charter to
> succeed. A small budget is still a budget and it is not clear if
> Linux Foundation will provide it or if the project needs other
> sponsors as well.

The Linux Foundation is aware of the current budget (which is minimal
with the exception of the conference) and has said they are willing to
cover it as part of their general funds. Obviously if there was a
significant expansion of that - for example, building out a testing
lab - then there would probably need to be further discussion of where
that money comes from and it might involve sponsors. I don't really
see that affecting the success or failure of the charter though. More
specifically, I don't think anyone would be willing to change the
structure of the project in order to collect money.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] MTU considerations for OVN

[Jesse Gross]

I think that if we come up with a good overall design, it should be
able to handle different MTUs without needing to special case them -
after all, we're already talking about 2 different MTUs (encapsulated
and not) - so I don't think that having more would really make a
significant difference. I would encourage you to read through this
thread if you haven't already:
https://www.spinics.net/lists/netdev/msg257830.html

On Fri, Jun 10, 2016 at 6:50 AM, Matt Kassawara <mkassaw...@gmail.com> wrote:
> If it helps any, the entire underlying physical network should use the same
> MTU, at least in the simplest case. In other words, all provider networks
> use the native MTU and all self-service/project networks use the native MTU
> minus overlay protocol overhead, or 58 bytes for Geneve with IPv4 endpoints.
> Corner cases exist, but are rare and we can worry about them later.
>
> On Thu, Jun 9, 2016 at 7:06 PM, Jesse Gross <je...@kernel.org> wrote:
>>
>> In my previous message, this is what I mentioned (reproducing it here
>> just because it doesn't appear in the quoted conversation below):
>>
>> "One possible solution is to introduce an action in the kernel that
>> would check packets flowing through the switch against a length
>> specified by the user (where the 'user' is OVS userspace/OVN in this
>> case). To use this, we would do a route lookup of the tunnel endpoint
>> to find the outgoing device, subtract the encapsulation overhead, and
>> install a flow that checks this length and punts the packet to OVN to
>> generate an ICMP message."
>>
>> A possible way of getting the MTU to OVS userspace would be through a
>> configuration option. I don't think that this is really the hard part
>> though and so rest of the discussion around this should still apply.
>> In particular, it's not really that hard for OVS userspace to do a
>> route lookup, so if we are totally sure that the MTU is static we
>> could just have OVS fetch it. I'm not sure that either approach is all
>> that generic though.
>>
>> On Thu, Jun 9, 2016 at 10:27 AM, Matt Kassawara <mkassaw...@gmail.com>
>> wrote:
>> > Jesse,
>> >
>> > I know this sounds too easy, but can we just tell OVS about the
>> > underlying
>> > physical network MTU via config option?
>> >
>> > On Fri, May 6, 2016 at 1:08 PM, Jesse Gross <je...@kernel.org> wrote:
>> >>
>> >> On Fri, May 6, 2016 at 11:53 AM, Ryan Moats <rmo...@us.ibm.com> wrote:
>> >> > Jesse Gross <je...@kernel.org> wrote on 05/06/2016 11:11:10 AM:
>> >> >
>> >> >> From: Jesse Gross <je...@kernel.org>
>> >> >> To: Ryan Moats/Omaha/IBM@IBMUS
>> >> >> Cc: Matt Kassawara <mkassaw...@gmail.com>, discuss
>> >> >> <discuss@openvswitch.org>, Thomas Graf <tg...@suug.ch>
>> >> >> Date: 05/06/2016 11:11 AM
>> >> >
>> >> >
>> >> >> Subject: Re: [ovs-discuss] MTU considerations for OVN
>> >> >>
>> >> >> On Fri, May 6, 2016 at 8:40 AM, Ryan Moats <rmo...@us.ibm.com>
>> >> >> wrote:
>> >> >> > "discuss" <discuss-boun...@openvswitch.org> wrote on 05/04/2016
>> >> >> > 06:09:04
>> >> >> > PM:
>> >> >> >
>> >> >> >> From: Jesse Gross <je...@kernel.org>
>> >> >> >> To: Matt Kassawara <mkassaw...@gmail.com>
>> >> >> >> Cc: discuss <discuss@openvswitch.org>
>> >> >> >> Date: 05/04/2016 06:09 PM
>> >> >> >> Subject: Re: [ovs-discuss] MTU considerations for OVN
>> >> >> >> Sent by: "discuss" <discuss-boun...@openvswitch.org>
>> >> >> >>
>> >> >> >> On Tue, May 3, 2016 at 3:50 PM, Matt Kassawara
>> >> >> >> <mkassaw...@gmail.com>
>> >> >> >> wrote:
>> >> >> >> > Jesse,
>> >> >> >> >
>> >> >> >> > I'm resurrecting this thread after a fairly lengthy discussion
>> >> >> >> > of
>> >> >> >> > MTU
>> >> >> >> > with
>> >> >> >> > Ben at the recent OpenStack summit. Have you given the topic
>> >> >> >> > any
>> >> >> >> > further
>> >> >> >> > thought toward implementat

Re: [ovs-discuss] MTU considerations for OVN

[Jesse Gross]

In my previous message, this is what I mentioned (reproducing it here
just because it doesn't appear in the quoted conversation below):

"One possible solution is to introduce an action in the kernel that
would check packets flowing through the switch against a length
specified by the user (where the 'user' is OVS userspace/OVN in this
case). To use this, we would do a route lookup of the tunnel endpoint
to find the outgoing device, subtract the encapsulation overhead, and
install a flow that checks this length and punts the packet to OVN to
generate an ICMP message."

A possible way of getting the MTU to OVS userspace would be through a
configuration option. I don't think that this is really the hard part
though and so rest of the discussion around this should still apply.
In particular, it's not really that hard for OVS userspace to do a
route lookup, so if we are totally sure that the MTU is static we
could just have OVS fetch it. I'm not sure that either approach is all
that generic though.

On Thu, Jun 9, 2016 at 10:27 AM, Matt Kassawara <mkassaw...@gmail.com> wrote:
> Jesse,
>
> I know this sounds too easy, but can we just tell OVS about the underlying
> physical network MTU via config option?
>
> On Fri, May 6, 2016 at 1:08 PM, Jesse Gross <je...@kernel.org> wrote:
>>
>> On Fri, May 6, 2016 at 11:53 AM, Ryan Moats <rmo...@us.ibm.com> wrote:
>> > Jesse Gross <je...@kernel.org> wrote on 05/06/2016 11:11:10 AM:
>> >
>> >> From: Jesse Gross <je...@kernel.org>
>> >> To: Ryan Moats/Omaha/IBM@IBMUS
>> >> Cc: Matt Kassawara <mkassaw...@gmail.com>, discuss
>> >> <discuss@openvswitch.org>, Thomas Graf <tg...@suug.ch>
>> >> Date: 05/06/2016 11:11 AM
>> >
>> >
>> >> Subject: Re: [ovs-discuss] MTU considerations for OVN
>> >>
>> >> On Fri, May 6, 2016 at 8:40 AM, Ryan Moats <rmo...@us.ibm.com> wrote:
>> >> > "discuss" <discuss-boun...@openvswitch.org> wrote on 05/04/2016
>> >> > 06:09:04
>> >> > PM:
>> >> >
>> >> >> From: Jesse Gross <je...@kernel.org>
>> >> >> To: Matt Kassawara <mkassaw...@gmail.com>
>> >> >> Cc: discuss <discuss@openvswitch.org>
>> >> >> Date: 05/04/2016 06:09 PM
>> >> >> Subject: Re: [ovs-discuss] MTU considerations for OVN
>> >> >> Sent by: "discuss" <discuss-boun...@openvswitch.org>
>> >> >>
>> >> >> On Tue, May 3, 2016 at 3:50 PM, Matt Kassawara
>> >> >> <mkassaw...@gmail.com>
>> >> >> wrote:
>> >> >> > Jesse,
>> >> >> >
>> >> >> > I'm resurrecting this thread after a fairly lengthy discussion of
>> >> >> > MTU
>> >> >> > with
>> >> >> > Ben at the recent OpenStack summit. Have you given the topic any
>> >> >> > further
>> >> >> > thought toward implementation in a reasonable way? Can you
>> >> >> > elaborate
>> >> >> > on
>> >> >> > the
>> >> >> > architectural limitations? At the moment, the OpenStack
>> >> >> > implementation
>> >> >> > of
>> >> >> > OVN doesn't use DPDK.
>> >> >>
>> >> >> The issue that I alluded to before is that when OVS (and by
>> >> >> extension
>> >> >> OVN) does L3 processing the packets aren't traversing the Linux IP
>> >> >> stack and so the usual MTU checks don't apply. Instead OVS just does
>> >> >> a
>> >> >> single combined lookup for all flow processing and then applies some
>> >> >> actions like set SMAC/DMAC and decrement TTL. Not only is there no
>> >> >> code to check the outgoing MTU but there's no obvious outgoing
>> >> >> device
>> >> >> to fetch the desired MTU from.
>> >> >
>> >> > I'm not 100% sure why this would be an issue - IIRC (based on my
>> >> > scanning
>> >> > the code)
>> >> > when a packet is going to be outputed, it looks like the MTU of the
>> >> > physical
>> >> > device
>> >> > is checked and a fragmentation decision made.  Isn't that good enough
>> >> > for
>> >> > our
>> >> > purposes?
>> >>
>> >> Which check in particular

Re: [ovs-discuss] No ovs virtual interface on ubuntu 16.04

[Jesse Gross]

On Tue, Jun 7, 2016 at 12:51 AM, Christophe VILLA <tn.technic...@ted.fr> wrote:
> On 06/06/2016 22:25, Jesse Gross wrote:
>> On Mon, Jun 6, 2016 at 8:33 AM, Christophe VILLA <tn.technic...@ted.fr> 
>> wrote:
>>> Hello,
>>>
>>> i use ovs 2.0.2 on Ubuntu 14.04 with kvm and run well.
>>>
>>> I have install on Ubuntu 16.04 with ovs 2.5.0 and i can not see virtual
>>> interface directly on ubuntu 16.04.
>>> The interfaces are present in ovs configuration but no appear with ifconfig.
>>> It's embarrasing when i want use virtual interface with Virtual Machine
>>> Manager.
>>>
>>> Is this normal ?
>> What type of virtual interfaces are they?
> Interfaces are type internal.

Please keep messages on the mailing list.

Internal ports should show up in ifconfig on all versions of OVS. I
would recommend looking ovs-vswitchd.log to see if there were errors
when creating the ports.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] No ovs virtual interface on ubuntu 16.04

[Jesse Gross]

On Mon, Jun 6, 2016 at 8:33 AM, Christophe VILLA  wrote:
> Hello,
>
> i use ovs 2.0.2 on Ubuntu 14.04 with kvm and run well.
>
> I have install on Ubuntu 16.04 with ovs 2.5.0 and i can not see virtual
> interface directly on ubuntu 16.04.
> The interfaces are present in ovs configuration but no appear with ifconfig.
> It's embarrasing when i want use virtual interface with Virtual Machine
> Manager.
>
> Is this normal ?

What type of virtual interfaces are they?
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] compose_output_action__ doesn't use err return value from build_tunnel_send

[Jesse Gross]

On Thu, Jun 2, 2016 at 11:59 AM, David Evans  wrote:
> Hi OVSers..
>
> ofproto/ofproto-dpif-xlate.c fn compose_output_action__ doesn't deal with
> errors reported by build_tunnel_send. eg (invalid arp cache value)
>
> It shoots out invalid packet while waiting for an arp reply to fix the
> cache.
> Wouldn't it be better if somehow it dropped the packets until we got a good
> arp?

Did you verify that this is actually happening? Looking at the code,
it seems to me that the output is generated by build_tunnel_send
itself and it will stop if it encounters an error. As a result,
there's nothing that the calling function needs to do further since
lack of an action will effectively drop the packet.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] MTU considerations for OVN

[Jesse Gross]

On Fri, May 6, 2016 at 11:53 AM, Ryan Moats <rmo...@us.ibm.com> wrote:
> Jesse Gross <je...@kernel.org> wrote on 05/06/2016 11:11:10 AM:
>
>> From: Jesse Gross <je...@kernel.org>
>> To: Ryan Moats/Omaha/IBM@IBMUS
>> Cc: Matt Kassawara <mkassaw...@gmail.com>, discuss
>> <discuss@openvswitch.org>, Thomas Graf <tg...@suug.ch>
>> Date: 05/06/2016 11:11 AM
>
>
>> Subject: Re: [ovs-discuss] MTU considerations for OVN
>>
>> On Fri, May 6, 2016 at 8:40 AM, Ryan Moats <rmo...@us.ibm.com> wrote:
>> > "discuss" <discuss-boun...@openvswitch.org> wrote on 05/04/2016 06:09:04
>> > PM:
>> >
>> >> From: Jesse Gross <je...@kernel.org>
>> >> To: Matt Kassawara <mkassaw...@gmail.com>
>> >> Cc: discuss <discuss@openvswitch.org>
>> >> Date: 05/04/2016 06:09 PM
>> >> Subject: Re: [ovs-discuss] MTU considerations for OVN
>> >> Sent by: "discuss" <discuss-boun...@openvswitch.org>
>> >>
>> >> On Tue, May 3, 2016 at 3:50 PM, Matt Kassawara <mkassaw...@gmail.com>
>> >> wrote:
>> >> > Jesse,
>> >> >
>> >> > I'm resurrecting this thread after a fairly lengthy discussion of MTU
>> >> > with
>> >> > Ben at the recent OpenStack summit. Have you given the topic any
>> >> > further
>> >> > thought toward implementation in a reasonable way? Can you elaborate
>> >> > on
>> >> > the
>> >> > architectural limitations? At the moment, the OpenStack
>> >> > implementation
>> >> > of
>> >> > OVN doesn't use DPDK.
>> >>
>> >> The issue that I alluded to before is that when OVS (and by extension
>> >> OVN) does L3 processing the packets aren't traversing the Linux IP
>> >> stack and so the usual MTU checks don't apply. Instead OVS just does a
>> >> single combined lookup for all flow processing and then applies some
>> >> actions like set SMAC/DMAC and decrement TTL. Not only is there no
>> >> code to check the outgoing MTU but there's no obvious outgoing device
>> >> to fetch the desired MTU from.
>> >
>> > I'm not 100% sure why this would be an issue - IIRC (based on my
>> > scanning
>> > the code)
>> > when a packet is going to be outputed, it looks like the MTU of the
>> > physical
>> > device
>> > is checked and a fragmentation decision made.  Isn't that good enough
>> > for
>> > our
>> > purposes?
>>
>> Which check in particular do you have in mind?
>>
>> There are two possibilities that I can think of:
>>  * ovs_vport_send() has one but the device it looks at for the MTU is
>> a tunnel device, which has an essentially infinite MTU. The real MTU
>> that we would need to check also depends on the destination IP address
>> of the tunnel but we haven't done a route lookup at this point.
>>  * ip_finish_output() in the IP stack. This one does have the
>> information that we need but it is outside of the tunnel. Any ICMP
>> packets that are generated will be processed through the hypervisor's
>> IP stack and won't make it back to the VM. In addition, this check
>> doesn't handle GSO packets.
>
> I see, I was misreading code... my mistake.
>
> I certainly dislike the idea of separating the MTU calculation from the
> datapath. What I was hoping to find that it would be possible to do the
> fragmentation check on the tunnel after the route has been looked up and
> the outgoing device is known, but looking through this, I'm not seeing
> a good way to do this cleanly (yet) ...

I agree.

There was a thread a while back on the netdev mailing list related
this but no real conclusion:
https://www.spinics.net/lists/netdev/msg257830.html
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] MTU considerations for OVN

[Jesse Gross]

On Fri, May 6, 2016 at 8:40 AM, Ryan Moats <rmo...@us.ibm.com> wrote:
> "discuss" <discuss-boun...@openvswitch.org> wrote on 05/04/2016 06:09:04 PM:
>
>> From: Jesse Gross <je...@kernel.org>
>> To: Matt Kassawara <mkassaw...@gmail.com>
>> Cc: discuss <discuss@openvswitch.org>
>> Date: 05/04/2016 06:09 PM
>> Subject: Re: [ovs-discuss] MTU considerations for OVN
>> Sent by: "discuss" <discuss-boun...@openvswitch.org>
>>
>> On Tue, May 3, 2016 at 3:50 PM, Matt Kassawara <mkassaw...@gmail.com>
>> wrote:
>> > Jesse,
>> >
>> > I'm resurrecting this thread after a fairly lengthy discussion of MTU
>> > with
>> > Ben at the recent OpenStack summit. Have you given the topic any further
>> > thought toward implementation in a reasonable way? Can you elaborate on
>> > the
>> > architectural limitations? At the moment, the OpenStack implementation
>> > of
>> > OVN doesn't use DPDK.
>>
>> The issue that I alluded to before is that when OVS (and by extension
>> OVN) does L3 processing the packets aren't traversing the Linux IP
>> stack and so the usual MTU checks don't apply. Instead OVS just does a
>> single combined lookup for all flow processing and then applies some
>> actions like set SMAC/DMAC and decrement TTL. Not only is there no
>> code to check the outgoing MTU but there's no obvious outgoing device
>> to fetch the desired MTU from.
>
> I'm not 100% sure why this would be an issue - IIRC (based on my scanning
> the code)
> when a packet is going to be outputed, it looks like the MTU of the physical
> device
> is checked and a fragmentation decision made.  Isn't that good enough for
> our
> purposes?

Which check in particular do you have in mind?

There are two possibilities that I can think of:
 * ovs_vport_send() has one but the device it looks at for the MTU is
a tunnel device, which has an essentially infinite MTU. The real MTU
that we would need to check also depends on the destination IP address
of the tunnel but we haven't done a route lookup at this point.
 * ip_finish_output() in the IP stack. This one does have the
information that we need but it is outside of the tunnel. Any ICMP
packets that are generated will be processed through the hypervisor's
IP stack and won't make it back to the VM. In addition, this check
doesn't handle GSO packets.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] MTU considerations for OVN

[Jesse Gross]

On Tue, May 3, 2016 at 3:50 PM, Matt Kassawara  wrote:
> Jesse,
>
> I'm resurrecting this thread after a fairly lengthy discussion of MTU with
> Ben at the recent OpenStack summit. Have you given the topic any further
> thought toward implementation in a reasonable way? Can you elaborate on the
> architectural limitations? At the moment, the OpenStack implementation of
> OVN doesn't use DPDK.

The issue that I alluded to before is that when OVS (and by extension
OVN) does L3 processing the packets aren't traversing the Linux IP
stack and so the usual MTU checks don't apply. Instead OVS just does a
single combined lookup for all flow processing and then applies some
actions like set SMAC/DMAC and decrement TTL. Not only is there no
code to check the outgoing MTU but there's no obvious outgoing device
to fetch the desired MTU from.

One possible solution is to introduce an action in the kernel that
would check packets flowing through the switch against a length
specified by the user (where the 'user' is OVS userspace/OVN in this
case). To use this, we would do a route lookup of the tunnel endpoint
to find the outgoing device, subtract the encapsulation overhead, and
install a flow that checks this length and punts the packet to OVN to
generate an ICMP message.

Although I think that would work, I have a couple of concerns. The
first is that it decouples the MTU check into several pieces and these
could get out of sync. For example, since the target MTU is calculated
separate from the datapath, we'd have to make sure that if routes/MTUs
or encapsulation header size change then the flows are updated as
well. The second issue is that this is starting to encroach on the
territory of the routing stack and that type of duplication might not
be well received by the upstream Linux community.

I'm also CC'ing Thomas who had interest in this area as well before.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Incorrect UDP checksum for IP fragmented datagrams that have mod_nw_dst action

[Jesse Gross]

This will show you the commits on the 2.3.x release series:
https://github.com/openvswitch/ovs/commits/branch-2.3

On Fri, Apr 29, 2016 at 1:20 PM, Michael Ben-Ami
<mben...@digitalocean.com> wrote:
> Thank you, is there any where we can see what commits are part of which
> release?
>
> On Fri, Apr 29, 2016 at 4:02 PM, Jesse Gross <je...@kernel.org> wrote:
>>
>> On Fri, Apr 29, 2016 at 12:11 PM, Michael Ben-Ami
>> <mben...@digitalocean.com> wrote:
>> >
>> > OVS version:
>> >
>> > ovs-ofctl (Open vSwitch) 2.3.2
>> > Compiled Aug 24 2015 18:39:15
>> > OpenFlow versions 0x1:0x4
>> >
>> > Linux version:
>> >
>> > Linux version 3.13.0-52-generic (buildd@comet) (gcc version 4.8.2
>> > (Ubuntu 4.8.2-19ubuntu1) ) #86-Ubuntu SMP Mon May 4 04:32:59 UTC 2015
>> >
>> > When IP-fragemented UDP datagrams hit a rule that looks like:
>> >
>> >  cookie=0x0, duration=176936.052s, table=1, n_packets=68911,
>> > n_bytes=8452972, idle_age=8, hard_age=65534,
>> > priority=1020,ip,dl_dst=04:01:d7:6f:80:01,nw_dst=xx.xx.104.241
>> > actions=strip_vlan,mod_nw_dst:10.19.0.5,output:10
>> >
>> > All IP traffic that hits this flow is successfully received by the VM
>> > with IP address 10.19.0.5, besides UDP traffic that is IP fragmented.
>> >
>> > We used netcat and wireshark to test. An example case is a VM receiving
>> > 5000 bytes of UDP traffic over netcat. If the sender does UDP segmentation
>> > to sizes of 2048, 2048, and 904 bytes, and the first two segments are
>> > further IP fragmented on the wire (before hitting OVS), the listening 
>> > netcat
>> > on the VM will receive 904 bytes, and the counter of Udp InCsumErrors in
>> > netstat -su output will increase by 2.
>>
>> I looks like you should upgrade to 2.3.3 (or later). I see the
>> following commit that will presumably fix the problem:
>> 8247b1ac ("datapath: Fix L4 checksum handling when dealing with IP
>> fragments")
>
>
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Pre 2.4 Stateful NAT

[Jesse Gross]

This is not going to be possible in 2.3. It's a feature for an
upcoming release (presumably the next one).

On Fri, Apr 29, 2016 at 10:57 AM, Michael Ben-Ami
 wrote:
> I could use help with the OVS requirements, Linux kernel requirements, any
> any flow examples to implement what is described in slide 11, here:
> http://www.slideshare.net/ThomasGraf5/linuxcon-2015-stateful-nat-with-ovs?next_slideshow=2
>
> On Fri, Apr 29, 2016 at 1:45 PM, Michael Ben-Ami 
> wrote:
>>
>> Can anyone point me to a configuration example for Stateful destination
>> NAT assuming we are using OVS version 2.3.2? What I am mainly interested in
>> is IP fragment reassembly so that UDP checksums are correct after the NAT.
>
>
>
> ___
> discuss mailing list
> discuss@openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss
>
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Incorrect UDP checksum for IP fragmented datagrams that have mod_nw_dst action

[Jesse Gross]

On Fri, Apr 29, 2016 at 12:11 PM, Michael Ben-Ami
 wrote:
>
> OVS version:
>
> ovs-ofctl (Open vSwitch) 2.3.2
> Compiled Aug 24 2015 18:39:15
> OpenFlow versions 0x1:0x4
>
> Linux version:
>
> Linux version 3.13.0-52-generic (buildd@comet) (gcc version 4.8.2 (Ubuntu 
> 4.8.2-19ubuntu1) ) #86-Ubuntu SMP Mon May 4 04:32:59 UTC 2015
>
> When IP-fragemented UDP datagrams hit a rule that looks like:
>
>  cookie=0x0, duration=176936.052s, table=1, n_packets=68911, n_bytes=8452972, 
> idle_age=8, hard_age=65534, 
> priority=1020,ip,dl_dst=04:01:d7:6f:80:01,nw_dst=xx.xx.104.241 
> actions=strip_vlan,mod_nw_dst:10.19.0.5,output:10
>
> All IP traffic that hits this flow is successfully received by the VM with IP 
> address 10.19.0.5, besides UDP traffic that is IP fragmented.
>
> We used netcat and wireshark to test. An example case is a VM receiving 5000 
> bytes of UDP traffic over netcat. If the sender does UDP segmentation to 
> sizes of 2048, 2048, and 904 bytes, and the first two segments are further IP 
> fragmented on the wire (before hitting OVS), the listening netcat on the VM 
> will receive 904 bytes, and the counter of Udp InCsumErrors in netstat -su 
> output will increase by 2.

I looks like you should upgrade to 2.3.3 (or later). I see the
following commit that will presumably fix the problem:
8247b1ac ("datapath: Fix L4 checksum handling when dealing with IP fragments")
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Error when popping mpls tag from vlan tagged packet

[Jesse Gross]

On Wed, Apr 20, 2016 at 4:32 AM, Alatalo Janne  wrote:
> Hello,
>
> I'm testing mpls and vlan tagging with OpenFlow on OpenvSwitch and faced a
> problem when trying to pop mpls tag from a vlan tagged packet. The problem
> can be seen in the following example in a simple mininet network:
> ```
> # mn --topo linear,2 --controller none
> # ovs-vsctl set bridge s1 protocols=OpenFlow13
> # ovs-vsctl set bridge s2 protocols=OpenFlow13
> # ovs-ofctl -O OpenFlow13 add-flow s1
> in_port=1,actions=push_mpls:0x8847,set_field:100-\>mpls_label,push_vlan:0x8100,set_field:0x1005-\>vlan_vid,output:2
> # ovs-ofctl -O OpenFlow13 add-flow s2
> mpls,vlan_vid=0x1005,actions=pop_vlan,pop_mpls:0x0806,output:1
>
> # Then generate traffic from host1
>> h1 ping h2
> ```
> The traffic is tagged correctly on the `s1` and the packets are matched to
> the correct flow in `s2` but the `s2` is not outputting anything from port
> 1. In the kernel log there is messages generated that say:
> ```
> openvswitch: netlink: Flow actions may not be safe on all matching packets.
> ```
>
> If the actions in the `s2` are changed to only pop the vlan tag everything
> works as expected. If the actions in the `s2` are changed to pop only the
> mpls tag the same problem occurs.
>
> Is it not possible to pop mpls from vlan tagged packet? Is this a
> restriction in the OpenFlow protocol? Am I missing some required match
> fields in the flows or is this a bug in OpenvSwitch?

It's a restriction in the way that the OVS datapath is implemented and
verifies correctness of actions. There are many possible combination
of MPLS and vlan tag orderings, which can be complicated and not all
of them are safe to execute. As a result, the use of these actions
together was restricted for simplicity.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Matching on tun_id in a flow rule

[Jesse Gross]

On Sun, Apr 17, 2016 at 9:43 AM, Keith Holleman
 wrote:
>
> I have GRE traffic transiting an OVS switch, in other words the tunnel
> source and destination is not in this OVS instance.  I had wanted to match
> on the GRE key ID in this to apply some very specific policy to it.  The
> transit traffic looks like this:
>
> :~# tcpdump proto gre -ne
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
> 16:27:04.742520 dc:39:79:80:29:48 > dc:39:79:80:29:02, ethertype IPv4
> (0x0800), length 102: 10.0.12.254 > 10.0.13.1: GREv0, key=0x3f3, proto TEB
> (0x6558), length 68: 00:0c:29:45:34:a7 > dc:39:79:80:29:33, ethertype ARP
> (0x0806), length 60: Request who-has 10.11.169.25 tell 10.11.1.239, length
> 46
>
> And I created these rules:
>
> :~# ovs-ofctl dump-flows br0 table=5 | grep nw_proto=47
>  cookie=0x1234, duration=90.802s, table=5, n_packets=0, n_bytes=0,
> idle_age=90,
> priority=60001,ip,tun_id=0x3f3/0x,nw_src=10.0.12.254,nw_dst=10.0.13.1,nw_proto=47
> actions=resubmit(,4)
>  cookie=0x3ea000b, duration=43112.786s, table=5, n_packets=395700,
> n_bytes=60045295, idle_age=0,
> priority=3,ip,nw_src=10.0.12.254,nw_dst=10.0.13.1,nw_proto=47
> actions=resubmit(,6)
>
> I was expecting the first flow to see all the traffic but it sees none.
> After reading more of the documentation and looking at and experimenting
> with tun_src and tun_dst usage, I think I know what the problem is.  The
> tun_* fields can only be used if OVS is aware of the GRE tunnel and has
> terminated the GRE tunnel and is looking at packets after the GRE
> decapsulation has occurred.  Or put another way, the GRE tunnel must be the
> incoming port to use those fields in the match criteria.
>
> I couldn't find any documentation that clearly stated that although in
> hindsight, it could be considered obvious.  But I also think my usage and
> assumptions aren't completely insane either.  Is my current understanding
> correct?  Is there any other way to match on a GRE key for GRE traffic
> transiting an OVS switch?

I understand what you are trying to do but you are correct that this
isn't currently possible with OVS.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Error compiling kernel module for OVS 2.5.0

[Jesse Gross]

Future releases of OVS - both 2.5.x and follow on major releases -
will include this patch. Once that happens, there will be no need to
manually patch the source.

On Thu, Apr 14, 2016 at 2:01 PM, Luca Prete  wrote:
> Joe,
>
> It worked out perfectly! Do you think would be possible to create a patch -
> depending on the kernel version - so that people won't have to modify this
> in the future?
>
> Thanks,
>
> Luca
>
> On Wed, Apr 13, 2016 at 6:09 PM, Luca Prete  wrote:
>>
>> Cool!
>>
>> I'll give it a try and I'll let you know how it goes.
>>
>> Thanks
>>
>> Luca
>>
>> > Il giorno 13 apr 2016, alle ore 17:03, Joe Stringer  ha
>> > scritto:
>> >
>> >> On 13 April 2016 at 13:53, Luca Prete  wrote:
>> >> Hello everyone,
>> >>
>> >> I'm trying to install the latest version of OVS (2.5.0)
>> >>
>> >> I'm getting some errors when trying to install the kernel module,
>> >> either
>> >> when compiling from src or when I create and then install the deb
>> >> (specifically in this last case the error happens when I do sudo dpkg
>> >> -i
>> >> sudo dpkg -i openvswitch-datapath-dkms_2.5.0-1_all.deb)
>> >>
>> >> The error I get is the following:
>> >> make -C /lib/modules/3.16.0-70-generic/build
>> >> M=/var/lib/dkms/openvswitch/2.5.0/build/datapath/linux modules
>> >> make[1]: Entering directory `/usr/src/linux-headers-3.16.0-70-generic'
>> >>  CC [M]  /var/lib/dkms/openvswitch/2.5.0/build/datapath/linux/actions.o
>> >> /var/lib/dkms/openvswitch/2.5.0/build/datapath/linux/actions.c: In
>> >> function
>> >> ‘ovs_fragment’:
>> >> /var/lib/dkms/openvswitch/2.5.0/build/datapath/linux/actions.c:730:3:
>> >> warning: passing argument 1 of ‘v6ops->fragment’ from incompatible
>> >> pointer
>> >> type [enabled by default]
>> >>   v6ops->fragment(skb->sk, skb, ovs_vport_output);
>> >>   ^
>> >> /var/lib/dkms/openvswitch/2.5.0/build/datapath/linux/actions.c:730:3:
>> >> note:
>> >> expected ‘struct sk_buff *’ but argument is of type ‘struct sock *’
>> >> /var/lib/dkms/openvswitch/2.5.0/build/datapath/linux/actions.c:730:3:
>> >> warning: passing argument 2 of ‘v6ops->fragment’ from incompatible
>> >> pointer
>> >> type [enabled by default]
>> >> /var/lib/dkms/openvswitch/2.5.0/build/datapath/linux/actions.c:730:3:
>> >> note:
>> >> expected ‘int (*)(struct sk_buff *)’ but argument is of type ‘struct
>> >> sk_buff
>> >> *’
>> >> /var/lib/dkms/openvswitch/2.5.0/build/datapath/linux/actions.c:730:3:
>> >> error:
>> >> too many arguments to function ‘v6ops->fragment’
>> >> make[2]: ***
>> >> [/var/lib/dkms/openvswitch/2.5.0/build/datapath/linux/actions.o] Error
>> >> 1
>> >> make[1]: ***
>> >> [_module_/var/lib/dkms/openvswitch/2.5.0/build/datapath/linux]
>> >> Error 2
>> >> make[1]: Leaving directory `/usr/src/linux-headers-3.16.0-70-generic'
>> >> make: *** [default] Error 2
>> >> make: Leaving directory
>> >> `/var/lib/dkms/openvswitch/2.5.0/build/datapath/linux'
>> >>
>> >> I'm running the following version of Ubuntu:
>> >> ubuntu:~/ovs$ sudo lsb_release -a
>> >> No LSB modules are available.
>> >> Distributor ID:Ubuntu
>> >> Description:Ubuntu 14.04.4 LTS
>> >> Release:14.04
>> >> Codename:trusty
>> >>
>> >> with the following kernel:
>> >> ubuntu:~/ovs$ sudo uname -a
>> >> Linux i2-mn-ubuntu 3.16.0-70-generic #90~14.04.1-Ubuntu SMP Wed Apr 6
>> >> 22:56:34 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
>> >>
>> >> Any help would be greatly appreciated.
>> >
>> > Hi Luca,
>> >
>> > It looks like Ubuntu backported a custom fix into some of their newer
>> > kernels, leading to this build breakage in conjunction with OVS-2.5.0
>> > dkms. I didn't see a problem with some 3.16.0-5x versions. If it's
>> > viable, you can just use the openvswitch module that comes with the
>> > Ubuntu kernel.
>> >
>> > Alternatively to fix it, you'll need to apply this patch to your tree
>> > (picking up branch-2.5 on github should also fix the issue):
>> >
>> > https://github.com/openvswitch/ovs/commit/a35342879f1a7d8b1503d4945bd0791c58f5fc87
>
>
>
> ___
> discuss mailing list
> discuss@openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss
>
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Datapath implementation query

[Jesse Gross]

On Thu, Apr 14, 2016 at 6:19 PM, Prathap T  wrote:
> Hi Jesse:
>
>   "Imagine a 1 bit long flow. The flow in the table has the value 0 and
> the mask is 1 (significant). There is also another mask with the value
> 0 (not significant). If a packet came in with the header value of 1
> and it tried the second mask first then the value would become 0,
> matching the flow in table on the basis of a strict comparison.
> However, in reality these flows don't match."
>
> I could guess this, but I could not really understand on when this would
> happen. In the case you have mentioned, dosen't the flow with the
> mask of 1 be of a higher priority then the other one in the userspace?
> dosen't the userspace take care to generate datapath flows that will have
> the masks of higher priority entries, and in the example, it is almost
> impossible to have the 1 bit flow that has a mask with value 0 because of
> priority? Please help me understand.

Priority of flows is defined by the user, not by the structure of the
those flows, so you can't say that one should be chosen over another.
A 1 bit flow is clearly a simplified use case - you can generalize to
mean that you are looking at 1 bit of a longer n-bit flow, where the
rest of the bits might have some combination of masks.

However, the question of priority doesn't even need to come into play
here. You can view this as a binary decision on that one flow - either
it matches or it doesn't. If there is a mask floating around that
causes you to match on a flow when you should not, then the behavior
is incorrect. In the realistic case of multi-bit flows, there might be
plenty of masks floating around that could cause this situation for a
single bit while still having non-overlapping equal priority flows.
(Example: add a second bit where one flow has a 0 value and another
has a 1 value, both masked as significant.)
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Datapath implementation query

[Jesse Gross]

On Thu, Apr 14, 2016 at 11:09 AM, Prathap T  wrote:
> Hi OVS-Team:
>
>   We are porting OVS onto one of our hardware and I had a question in the
> kernel datapath implementation.
>
> In the function - masked_flow_lookup
>
> ovs_flow_mask_key(_key, unmasked, mask);
> hash = flow_hash(_key, >range);
> head = find_bucket(ti, hash);
> (*n_mask_hit)++;
> hlist_for_each_entry_rcu(flow, head, flow_table.node[ti->node_ver]) {
> if (flow->mask == mask && flow->flow_table.hash == hash &&
> flow_cmp_masked_key(flow, _key, >range))
> return flow;
> }
>
> why is that the code compares the flow->mask == mask; is it not enough to
> just compare the key?? Is it just an optimization??
> If mask comparison is needed, can you please explain the traffic context
> that makes this necessary?

It's not an optimization, it's necessary for correctness.

Masks are inherently tied to the flows that they are masking. The
simplest implementation of what is being done here would be a linear
search over each flow, masking the incoming packet headers and doing a
comparison with the stored flow. As an optimization, we do the masking
once for each mask and then do a hash table lookup over all flows that
use that mask since it is common for flows to share masks. However, we
still must act as if the mask and flow are paired.

Imagine a 1 bit long flow. The flow in the table has the value 0 and
the mask is 1 (significant). There is also another mask with the value
0 (not significant). If a packet came in with the header value of 1
and it tried the second mask first then the value would become 0,
matching the flow in table on the basis of a strict comparison.
However, in reality these flows don't match.

> The reason I'm asking is that, we have some space issues and cannot store
> anymore than the keys in the hardware structure. If the mask comparison is
> not needed, we may want to skip it. If it is needed, we will have to
> compromise on some of the key elements.

I suspect that there are better ways of using your hardware rather
than directly porting this logic. For example, this function is pretty
much exactly mirroring the logic implemented in a TCAM.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] hello when i build on centos6.X there is a bug said redefinition of 'ip_is_fragment' hwo could i fix it

[Jesse Gross]

On Thu, Apr 7, 2016 at 4:37 AM,   wrote:
> When I build openvswitch 2.3.3 and 2.41.
>
>
>
> /root/rpmbuild/BUILD/openvswitch-2.3.1/_default/../datapath/linux/compat/include/net/ip.h:9:
> error: redefinition of 'ip_is_fragment'
>
> include/net/ip.h:249: note: previous definition of 'ip_is_fragment' was here
>
> In file included from include/net/xfrm.h:18,
>
>  from
> /root/rpmbuild/BUILD/openvswitch-2.3.1/_default/../datapath/linux/../compat.h:26,
>
>  from
> /root/rpmbuild/BUILD/openvswitch-2.3.1/_default/../datapath/linux/../datapath.h:29,
>
>  from
> /root/rpmbuild/BUILD/openvswitch-2.3.1/_default/datapath/linux/vport.c:34:
>
> /root/rpmbuild/BUILD/openvswitch-2.3.1/_default/../datapath/linux/compat/include/net/ip.h:9:
> error: redefinition of 'ip_is_fragment'
>
> include/net/ip.h:249: note: previous definition of 'ip_is_fragment' was here
>
> make[2]: ***
> [/root/rpmbuild/BUILD/openvswitch-2.3.1/_default/datapath/linux/dp_notify.o]
> Error 1
>
> make[2]: *** Waiting for unfinished jobs
>
> In file included from include/net/xfrm.h:18,
>
>  from
> /root/rpmbuild/BUILD/openvswitch-2.3.1/_default/datapath/linux/vport-gre.c:39:
>
> /root/rpmbuild/BUILD/openvswitch-2.3.1/_default/../datapath/linux/compat/include/net/ip.h:9:
> error: redefinition of 'ip_is_fragment'
>
> include/net/ip.h:249: note: previous definition of 'ip_is_fragment' was here
>
> make[2]: ***
> [/root/rpmbuild/BUILD/openvswitch-2.3.1/_default/datapath/linux/datapath.o]
> Error 1
>
> make[2]: ***
> [/root/rpmbuild/BUILD/openvswitch-2.3.1/_default/datapath/linux/flow.o]
> Error 1
>
> make[2]: ***
> [/root/rpmbuild/BUILD/openvswitch-2.3.1/_default/datapath/linux/actions.o]
> Error 1
>
> make[2]: ***
> [/root/rpmbuild/BUILD/openvswitch-2.3.1/_default/datapath/linux/vport.o]
> Error 1
>
> make[2]: ***
> [/root/rpmbuild/BUILD/openvswitch-2.3.1/_default/datapath/linux/flow_netlink.o]
> Error 1
>
> make[2]: ***
> [/root/rpmbuild/BUILD/openvswitch-2.3.1/_default/datapath/linux/flow_table.o]
> Error 1
>
> make[2]: ***
> [/root/rpmbuild/BUILD/openvswitch-2.3.1/_default/datapath/linux/vport-gre.o]
> Error 1
>
> make[1]: ***
> [_module_/root/rpmbuild/BUILD/openvswitch-2.3.1/_default/datapath/linux]
> Error 2
>
> make[1]: Leaving directory `/usr/src/kernels/2.6.32-573.22.1.el6.x86_64'
>
> make: *** [default] Error 2
>
> make: Leaving directory
> `/root/rpmbuild/BUILD/openvswitch-2.3.1/_default/datapath/linux'
>
> error: Bad exit status from /var/tmp/rpm-tmp.mm7hiY (%build)
>
>
>
>
>
> this is the report how could I fix it ? pleas help!

I would double check that you tested 2.4.1 because it looks like the
fix should already be part of that release. (You also said that you
used 2.3.3 but based on the directory name it was actually 2.3.1). No
version of 2.3 has the fix for this issue but I applied the patch to
that branch in the event that we end up doing another release off of
it.

In any event, I would recommend using OVS 2.5 as that is the current
long term stable release.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] dpif inline documentation needs to be updated

[Jesse Gross]

On Thu, Apr 7, 2016 at 2:22 PM, Zhang Qiang  wrote:
> Hi all,
>
> At lib/dpif.h line 117(as of git master d61fbed) the comment says:
>> Refer to OVS_KEY_ATTR_* and "struct ovs_key_*" in include/odp-netlink.h
>> for details.
>
> But the file include/odp-netlink.h doesn't exist any more. Quick searches
> with OVS_KEY_ATTR_ and ovs_key_ didn't indicate where odp-netlink.h was
> refactored to. Maybe the comment needs an update?

The authoritative source for these definitions is in
include/uapi/linux/openvswitch.h in the Linux kernel tree. There is
also a local copy in the OVS tree in
datapath/linux/compat/include/linux/openvswitch.h. Feel free to send a
patch to update the comments if they are out of date.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] GRE over IPV6

[Jesse Gross]

On Thu, Apr 7, 2016 at 12:04 PM, Vasiliy Tolstov  wrote:
> 2016-04-07 17:27 GMT+03:00 Thadeu Lima de Souza Cascardo 
> :
>>
>> Should be all supported. But really not sure about GRE on kernel datapath. In
>> any case, support in the kernel datapath will depend on kernel version or
>> external module version you are using.
>
>
> On which version this supported by kernel datapath? I'm using 4.4.6
> and ovs master branch.

IPv6 tunnels are supported on Linux 4.4 and above but you need to use
the module shipped with the upstream kernel at the moment. The module
that is part of the OVS distribution doesn't currently support IPv6
tunneling.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] What's this '?' mean in logical tunnel port in OVS?

[Jesse Gross]

That configuration still appears to work for me. What steps did you do
to configure this? Does traffic flow? Is there anything in the logs?

On Thu, Mar 24, 2016 at 10:12 PM, yewgang <batmanu...@gmail.com> wrote:
> It's openvswitch-2.3.0, and this port is GRE tunnel port.
>
> 2016-03-25 11:50 GMT+08:00 Jesse Gross <je...@kernel.org>:
>>
>> On Thu, Mar 24, 2016 at 8:31 PM, yewgang <batmanu...@gmail.com> wrote:
>> > Hi all,
>> >
>> > When I configure a logical tunnel port in OVS, I found the statistics is
>> > ?
>> > like this, Why?
>> >
>> >   port 3074: rx pkts=?, bytes=?, drop=?, errs=?, frame=?, over=?, crc=?
>> >tx pkts=?, bytes=?, drop=?, errs=?, coll=?
>>
>> What version is this? It seems to work for me:
>>
>>   port  1: rx pkts=3, bytes=238, drop=0, errs=0, frame=0, over=0, crc=0
>>tx pkts=10, bytes=816, drop=0, errs=0, coll=0
>
>
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] What's this '?' mean in logical tunnel port in OVS?

[Jesse Gross]

On Thu, Mar 24, 2016 at 8:31 PM, yewgang  wrote:
> Hi all,
>
> When I configure a logical tunnel port in OVS, I found the statistics is ?
> like this, Why?
>
>   port 3074: rx pkts=?, bytes=?, drop=?, errs=?, frame=?, over=?, crc=?
>tx pkts=?, bytes=?, drop=?, errs=?, coll=?

What version is this? It seems to work for me:

  port  1: rx pkts=3, bytes=238, drop=0, errs=0, frame=0, over=0, crc=0
   tx pkts=10, bytes=816, drop=0, errs=0, coll=0
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Fedora 23 update kernel (4.4) support

[Jesse Gross]

On Thu, Mar 24, 2016 at 2:22 PM, Rakesh Sharma 
wrote:

> STT tunnel does not get established and see the following in the log:
>
>
> 2016-01-09T22:24:00.480Z|01228|dpif|WARN|system@ovs-system: failed to add
> stt3232235967 as port: Address family not supported by protocol
>
> Do not see the issue in 3.xx kernel
> I can provide additional information as needed.
>

This message indicates that the loaded kernel module does not have support
for STT. Only the out of tree module has STT capability, not the upstream
one so I would verify that you are running the module packaged with the OVS
release and not one shipped with your distribution.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Fedora 23 update kernel (4.4) support

[Jesse Gross]

On Wed, Mar 23, 2016 at 9:27 PM, Rakesh Sharma
 wrote:
> What are plans for support of Fedora 23 update kernel (4.4)? FAQ.md table
> says max kernel level support for 2.5x and even 2.6x is 4.3. Need this
> support because STT appears to be broken in 4.0...

What is the problem with STT? That should work on 4.0.

Support for future kernels will come when a patch is submitted...
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] compile problem with 3.13.0-83-generic (was: installing datapath-dkms deb package fails on 3.13.0-83-generic kernel)

[Jesse Gross]

I sent out a patch that I believe should fix this:
http://openvswitch.org/pipermail/dev/2016-March/068150.html

However, I don't have this exact kernel running anywhere so I only
tested that it doesn't break other kernels. Would one of you mind
trying it out? As long as it builds cleanly, I'm reasonably confident
that it should be OK.

On Mon, Mar 21, 2016 at 5:56 AM, Russell Bryant  wrote:
> I believe this is caused by backports done for this bug:
>
> https://bugs.launchpad.net/nova/+bug/1463911
>
> --
> Russell Bryant
>
> On Mon, Mar 21, 2016 at 5:16 AM, Russell Bryant  wrote:
>>
>> FWIW, this issue has broken OpenStack CI with OVN.  It was also reported
>> here:
>>
>> http://openvswitch.org/pipermail/dev/2016-March/067987.html
>>
>> On Thu, Mar 17, 2016 at 9:27 AM, Ben Pfaff  wrote:
>>>
>>> Hi Zoltán.  It looks like this is really a build problem against a
>>> particular kernel instead of anything to do with Debian packaging.  I'm
>>> concerned that the kernel developers might skip over it because it
>>> sounds packaging-specific, so I'm following up with an updated subject
>>> line.
>>>
>>> On Thu, Mar 17, 2016 at 04:03:54PM +, Zoltán Balogh wrote:
>>> > Hi,
>>> >
>>> > Recently, I upgraded to Linux kernel version 3.13.0-83-generic from
>>> > version 3.13.0-79-generic. Then I rebuilt the debian packages and tried to
>>> > install them. Installing the datapath-dkms package failed.
>>> >
>>> > make -C /lib/modules/3.13.0-83-generic/build
>>> > M=/var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux modules
>>> > make[1]: Entering directory `/usr/src/linux-headers-3.13.0-83-generic'
>>> >   CC [M]
>>> > /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.o
>>> > /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.c:
>>> > In function 'ovs_fragment':
>>> >
>>> > /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.c:730:3:
>>> > warning: passing argument 1 of 'v6ops->fragment' from incompatible pointer
>>> > type [enabled by default]
>>> >v6ops->fragment(skb->sk, skb, ovs_vport_output);
>>> >^
>>> >
>>> > /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.c:730:3:
>>> > note: expected 'struct sk_buff *' but argument is of type 'struct sock *'
>>> >
>>> > /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.c:730:3:
>>> > warning: passing argument 2 of 'v6ops->fragment' from incompatible pointer
>>> > type [enabled by default]
>>> >
>>> > /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.c:730:3:
>>> > note: expected 'int (*)(struct sk_buff *)' but argument is of type 'struct
>>> > sk_buff *'
>>> >
>>> > /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.c:730:3:
>>> > error: too many arguments to function 'v6ops->fragment'
>>> > make[2]: ***
>>> > [/var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.o]
>>> > Error 1
>>> > make[1]: ***
>>> > [_module_/var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux] 
>>> > Error
>>> > 2
>>> > make[1]: Leaving directory `/usr/src/linux-headers-3.13.0-83-generic'
>>> > make: *** [default] Error 2
>>> > make: Leaving directory
>>> > `/var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux'
>>> >
>>> > I compared the include/linux/netfilter_ipv6.h files of  the two kernel
>>> > sources:
>>> >
>>> > diff
>>> > /usr/src/linux-headers-3.13.0-83-generic/include/linux/netfilter_ipv6.h
>>> > /usr/src/linux-headers-3.13.0-79-generic/include/linux/netfilter_ipv6.h
>>> > 28d27
>>> > <   int (*fragment)(struct sk_buff *skb, int (*output)(struct
>>> > sk_buff *));
>>> >
>>> > It seems the new struct member fragment was introduced in nf_ipv6_ops
>>> > in version 3.13.0-83-general:
>>> >
>>> > /*
>>> >  * Hook functions for ipv6 to allow xt_* modules to be built-in even
>>> >  * if IPv6 is a module.
>>> >  */
>>> > struct nf_ipv6_ops {
>>> >   int (*chk_addr)(struct net *net, const struct in6_addr *addr,
>>> >   const struct net_device *dev, int strict);
>>> >   int (*fragment)(struct sk_buff *skb, int (*output)(struct sk_buff
>>> > *));
>>> > };
>>> >
>>> > While the ovs code defines fragment with three arguments in
>>> > netfilter_ipv6.h and ip6_route.h:
>>> >
>>> > #ifndef HAVE_NF_IPV6_OPS_FRAGMENT
>>> > /* Try to minimise changes required to the actions.c code for calling
>>> > IPv6
>>> >  * fragmentation. We can keep the fragment() API mostly the same,
>>> > except that
>>> >  * the callback parameter needs to be in the form that older kernels
>>> > accept.
>>> >  * We don't backport the other ipv6_ops as they're currently unused by
>>> > OVS. */
>>> > struct ovs_nf_ipv6_ops {
>>> >   int (*fragment)(struct sock *sk, struct sk_buff *skb,
>>> >   int (*output)(OVS_VPORT_OUTPUT_PARAMS));
>>> > };
>>> > #define nf_ipv6_ops ovs_nf_ipv6_ops
>>> >
>>> > #if defined(OVS_FRAGMENT_BACKPORT)
>>> > static struct 

Re: [ovs-discuss] Kernel cache flow match error with linux bond port as physical NIC GRO on

[Jesse Gross]

On Thu, Feb 25, 2016 at 11:06 PM, 康敬亭  wrote:
> Hi guys:
>
> I hava test environment as below:
> ENV: Neutron + ovs(2.1.2) with linux bond(eth2,eth3), vm in compute node
> couldn't get ip from dhcp server.
>
> I had flow [1] added  in br-int, and with eth2 and eth3 GRO on, the kernel
> cache flow was [3],and packets droped. But with eth2 and eth3 GRO off, the
> kernel cache flow was[2], and the packets will be forward with pop_vlan, and
> works OK.
>
> In the failed situation, I found error msg in log as below:
>  openvswitch: netlink: Flow modification message rejected, unmasked key does
> not match.
>
> Anyone have idea about what wrong about ovs does not works with the linux
> bond?
> OVS can't get field of vlan to match for packets from linux bond port with
> gro on?
>
> BR
> Jingting
>
> [1]  cookie=0x0, duration=1383.630s, table=0, n_packets=237, n_bytes=68899,
> idle_age=3, priority=3,in_port=37,dl_vlan=2001 actions=mod_vlan_vid:1,NORMAL
>
> [2]skb_priority(0),in_port(6),eth(src=fa:16:3e:09:58:b6,dst=fa:16:3e:32:b3:d5),eth_type(0x8100),vlan(vid=2001,pcp=0),encap(eth_type(0x0800),ipv4(src=172.30.248.4/0.0.0.0,dst=172.30.248.210/0.0.0.0,proto=17/0,tos=0xc0/0,ttl=64/0,frag=no/0xff)),
> packets:0, bytes:0, used:never, actions:pop_vlan,7
>
> [3]skb_priority(0),in_port(6),eth(src=fa:16:3e:09:58:b6,dst=fa:16:3e:32:b3:d5),eth_type(0x8100),vlan(vid=2001/0xfff,pcp=0/0x0,cfi=1/1),encap(eth_type(0x0800),ipv4(src=172.30.248.4/0.0.0.0,dst=172.30.248.210/0.0.0.0,proto=17/0,tos=0xc0/0,ttl=64/0,frag=no/0xff)),
> packets:0, bytes:0, used:never, actions:drop

These flows are very odd - for one thing, the basic incoming flow
without any mask applied is the same, meaning that it doesn't appear
that GRO is really having an effect (as it shouldn't) and another is
that they are overlapping, which is not allowed. Finally, the
wildcards in the second datapath flow doesn't make any sense given the
input OpenFlow flow.

I think the best thing to at this point is try a newer OVS version.
The specific warning that you mentioned has been fixed but more
generally, a lot of the flow generation code was in flux around 2.1
and things have calmed down since then.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] vxlan udp csum and openstack ovs performance

[Jesse Gross]

On Thu, Feb 25, 2016 at 5:14 AM, kldeng  wrote:
> Hi, ALL.
>
> Recently, we're trying to fix the poor VXLAN throughput issue by applying
> the series of patches @Ramu posted in ovs-dev mailing-list.
> http://openvswitch.org/pipermail/dev/2015-August/059337.html
>
> Our test environment are as belows.
> --
> OVS: 2.4.0
> Kernel: 3.18.22
>
> Topology:
> --
> vm1 -- bridge -- vxlan -- 10Gnic -- 10Gnic -- vxlan -- bridge -- vm2
>
> vxlan port settings:
> --
> Port "vxlan-0acd614d"
> Interface "vxlan-0acd614d"
> type: vxlan
> options: {csum="true", df_default="true", in_key=flow,
> local_ip="10.205.97.135", out_key=flow, remote_ip="10.205.97.77"}
>
>
> Patch applied:
> --
> --- a/src/net/openvswitch/vport-vxlan.c
> +++ b/src/net/openvswitch/vport-vxlan.c
> @@ -100,6 +100,7 @@ static struct vport *vxlan_tnl_create(const struct
> vport_parms *parms)
> struct nlattr *a;
> u16 dst_port;
> int err;
> + u32 vxlan_sock_flags = 0;
>
> if (!options) {
> err = -EINVAL;
> @@ -122,7 +123,8 @@ static struct vport *vxlan_tnl_create(const struct
> vport_parms *parms)
> vxlan_port = vxlan_vport(vport);
> strncpy(vxlan_port->name, parms->name, IFNAMSIZ);
>
> - vs = vxlan_sock_add(net, htons(dst_port), vxlan_rcv, vport, true, 0);
> + vxlan_sock_flags |= VXLAN_F_UDP_CSUM;
> + vs = vxlan_sock_add(net, htons(dst_port), vxlan_rcv, vport, true,
> vxlan_sock_flags);
> if (IS_ERR(vs)) {
>
>
> But, it seems doesn't work, the VXLAN throughput is still very low(about
> 1.7Gbps).
>
> After inspecting, we found GRO is seems effective for VXLAN traffic for we
> can see aggregated packets on receiver nic and the function call graph also
> proves that.
>
> - 0.60% 0.12% vhost-31236 [kernel.kallsyms] [k] tcp_gro_receive ▒
> - tcp_gro_receive ▒
> - 99.74% tcp4_gro_receive ▒
> inet_gro_receive ▒
> vxlan_gro_receive ▒
> udp_gro_receive ◆
> udp4_gro_receive ▒
> inet_gro_receive ▒
> dev_gro_receive ▒
> napi_gro_receive ▒
> ixgbe_clean_rx_irq ▒
> ixgbe_poll ▒
> net_rx_action ▒
> + __do_softirq
>
> But, on the qvo, qvb interface, the packet is fragemented again.

If the problem is that packets are getting aggregated and then
segmented again, the issue is likely the same as the one here:
http://openvswitch.org/pipermail/dev/2016-January/064445.html

I'm working on a solution.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] OVS support for OpenWRT on TP-Link 8980

[Jesse Gross]

On Thu, Feb 18, 2016 at 4:19 PM, Hassan Habibi  wrote:
> Hi all,
>
> My objective is to have OpenFlow enabled on a fairly low cost “ADSL modem
> router” which is available in the market today.
>
> After a bit of investigation in OpenWrt community, I realized that Lantiq
> based “TP-Link 8980” is the hardware which meets my requirements (ADSL,
> Ethernet LAN, and WiFi in single box) and is officially supported by "only"
> OpenWRT trunk DD.
>
> Then, we tried to build a firmware for the TD-W8980 using the current trunk
> version of OpenWrt (i.e. DD) and included OVS into the build. However, OVS
> failed to build as it has its own internal Kernel version check.
> We discovered that OVS is only supported up to Kernel 4.3 and the current
> trunk version of OpenWRT is at kernel 4.4.

OVS is part of the Linux kernel so the best solution is to use the
module packaged as part of the kernel tree rather than with the OVS
release - they do the same thing. That like would involve rebuilding
the OpenWRT kernel to enable OVS, I don't know easy that is.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] MTU considerations for OVN

[Jesse Gross]

On Wed, Jan 27, 2016 at 5:02 PM, Matt Kassawara  wrote:
> Hi,
>
> Conventional OpenStack Networking service (neutron) drivers such as Open
> vSwitch and Linux bridge have a long history of MTU issues involving overlay
> networks. For example, consider the following typical virtual network
> architecture:
>
> 1) A provider network using native Ethernet or 802.1q tagging connects the
> physical and virtual network infrastructure. Typically uses a 1500 or 9000
> MTU.
> 2) A private network using an overlay such as VXLAN or GRE. Overlay protocol
> overhead reduces the effective MTU available to a VM.
> 3) A VM attaching to the private network.
> 4) A virtual router connecting the provider and private networks.
>
> For a packet outbound from a VM, we can simply set the MTU of the network
> interface in the VM to account for overlay protocol overhead. For example,
> if the underlying network supports a 1500 MTU, a VM attaching to a VXLAN
> overlay network should use a 1450 MTU. We can provide this MTU to the VM via
> DHCP, RA, or manual configuration of the interface.
>
> For a packet inbound to a VM, the situation becomes more interesting. The
> host sending the packet usually resides outside of the overlay network and
> attempts to use the MTU available to it, typically 1500 or greater. The
> provider network also uses a 1500 MTU. The virtual router contains
> interfaces on the provider network using a 1500 MTU and the private network
> using a 1450 MTU. As the packet attempts to traverse the router, it hits the
> MTU disparity between 1500 and 1450 which causes the provider interface to
> originate an ICMP message for PMTU discovery containing the 1450 MTU. The
> host receives this message and sends the packet again using the 1450 MTU.
>
> Currently, both the Open vSwitch and Linux bridge drivers incorrectly place
> MTU disparities in layer-2 components which cannot originate ICMP messages
> and drop packets that exceed the MTU.
>
> Using the native layer-3 implementation, how does OVN handle MTU disparities
> between provider networks and private networks using an overlay protocol?

As you say, the right way to handle this is to emit ICMP messages for
PMTUD or worst case do fragmentation. Unfortunately, at the Linux
kernel level there isn't a good way to handle this currently this with
any kind of programmable datapath, which is why the issue is common to
all of the various implementations. The only way that I have seen this
really handled is to use a separate namespace containing a Linux
router which isn't really all that satisfactory.

Long term, we'll need to implement some primitives in the OVS datapath
to detect over-MTU packets so that OVN can react appropriately.
However, it's likely that this will require some architectural changes
so it's probably not likely to happen in the immediate future.

I should also mention that another way to handle this is to raise the
MTU of the underlay network so that you don't reduce the MTU as seen
by the VM/outside world. However, I realize that this does not apply
to all situations.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] MTU considerations for OVN

[Jesse Gross]

On Tue, Feb 2, 2016 at 6:03 PM, Matt Kassawara  wrote:
> Jesse,
>
> We can raise the MTU of the underlying network until it reaches the maximum
> value for the physical equipment, a common situation for 10+ Gbps data
> center networks. For example, if the physical equipment supports a maximum
> 9000 MTU, we can't further increase it to account for overlay protocol
> overhead. We can easily reduce the VM MTU to account for outbound traffic,
> but inbound traffic assumes it can use 9000 bytes and therefore requires
> PMTUD... or (grudgingly) reducing the MTU of all hosts on the physical
> network... effectively moving the problem rather than solving it.
>
> I think we need to solve this problem sooner than later to prevent the
> current loathing by operators using conventional OpenStack neutron drivers
> from seeping into OVN before it has a chance at success. Right now, the
> ability to eliminate (often obscure) problems for any underlying network MTU
> provides a huge selling point, at least for OpenStack.

The architectural limitations that I was referring to earlier are
mostly in the Linux kernel and since the DPDK datapath will be the
preferred software gateway for OVN, perhaps they don't really apply.
I'm a little hesitant to introduce actions that can only be handled in
one place but since this would be purely internal to OVS it might not
matter since we could change the implementation in the future if
necessary. That would potentially allow us to handle this in an
cleaner way in the near future.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] vxlan over IPv6

[Jesse Gross]

On Sat, Jan 23, 2016 at 3:59 AM, zhangqunjian  wrote:
>
> Hi,  I use OVS created vxlan tunnel based on IPv6. As far as I know, GitHub
> master branch has been commited part code of this function. when I used it
> into my project，I found that vxlan over IPv6 configuration is working
> properly，but function worked not well. I built the vxlan tunnel over IPv6
> between two virtual machines through OVS, the Ping of veth0 of the two
> virtual machines was blocked. Excuse me, is this my wrong use or OVS don't
> support the vxlan over IPv6 Tunnel ? If OVS don't support vxlan over
> ipv6,there is have any time for support .

Support for IPv6 tunneling hasn't been backported yet to the OVS
out-of-tree kernel module. As a result, you'll need to run the module
from Linux 4.4 or newer.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] vxlan udp csum and openstack ovs performance

[Jesse Gross]

The out of tree module of OVS 2.4 doesn't support VXLAN GRO (which
would be the source of the performance improvements that you are
looking for). You'll need to either use the upcoming OVS 2.5 release
(currently in testing) or the upstream module with a newer kernel.

On Thu, Jan 21, 2016 at 9:38 PM, 康敬亭 <jingt...@unitedstack.com> wrote:
> The linux kernel is 3.12.21 on both reciever and sender.
> The version of ovs is 2.4 release.
> I do insmod openvswitch.ko and vport-vxlan.ko.
>
> -- Original --
> From:  "Jesse Gross"<je...@kernel.org>;
> Date:  Fri, Jan 22, 2016 12:49 PM
> To:  "康敬亭"<jingt...@unitedstack.com>;
> Cc:  "discuss"<discuss@openvswitch.org>;
> Subject:  Re: [ovs-discuss] vxlan udp csum and openstack ovs performance
>
> On Thu, Jan 21, 2016 at 7:41 PM, 康敬亭 <jingt...@unitedstack.com> wrote:
>> Hi Gross:
>> Thank you for your reply.
>> I know that OVS2.4 already supports vxlan csum，and I create a port in
>> accordance with the following command:
>> “ovs-vsctl add-port ovs-vx vxlan0 -- set interface vxlan0 type=vxlan
>> options:remote_ip=10.0.28.65 options:dst_port=4789 options:key=9
>> 9 options:csum=true”
>>
>> But I found no effect with vxlan performance，so I try to do it with
>> coding.
>> what do you suggest how to do it.
>
> The above syntax is correct, so modifying the code shouldn't have any
> effect. What kernel are you running this on (both sender and
> receiver)? Is this the OVS out-of-tree or upstream module?
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] vxlan udp csum and openstack ovs performance

[Jesse Gross]

On Wed, Jan 20, 2016 at 11:41 PM, 康敬亭  wrote:
> Hi ALL：
>We are running openstack J with neutron OVS2.4 using intel 10G
> adapters(82599es) with  vxlan tunnels.
>We find this patch below to resolve problem of vxlan throughput.
> http://openvswitch.org/pipermail/dev/2015-August/059335.html
>
> We modify vport-vxlan.c as the patch，and make the udp csum flag fixed as
> param when calling vxlan_sock_add in func vxlan_tnl_create , but the
> throughput we got does not exceed 3Gbps on the 10Gb link.

OVS 2.4 has VXLAN checksum support built in so you don't need to
modify the code. You can just set the option csum=true on the VXLAN
port.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] openvswitch: netlink: Flow actions may not be safe on all matching packets - MPLS packets hitting flood entry

[Jesse Gross]

On Wed, Jan 13, 2016 at 10:43 PM, Farhad Sunavala  wrote:
>
> I keep getting several of these messages in kern.log
>
> Jan 10 19:27:42 controller-160 kernel: [175640.463342] openvswitch: netlink:
> Flow actions may not be safe on all matching packets.
>
> The packets being dropped are MPLS packets which need to be sent over a
> VXLAN tunnel.
>
> Specifically, "unknown destination" MPLS packets matching the multicast
> flood entry shown below
>
> cookie=0x8e9ca45d1a13c3ab, duration=12089.542s, table=22, n_packets=3724,
> n_bytes=364064, priority=1,dl_vlan=2
> actions=pop_vlan,set_field:0x203d->tun_id,output:2,output:4"
>
>
> In addition, this only happens when there are atleast two tunnels through
> which the packets need to be flooded out.
> The problem does not happen if the flow entry is as follows
>
> cookie=0x8e9ca45d1a13c3ab, duration=12089.542s, table=22, n_packets=3724,
> n_bytes=364064, priority=1,dl_vlan=2
> actions=pop_vlan,set_field:0x203d->tun_id,output:2"
>
> ovs_nla_copy_actions() is most probably returning an error.  Any pointers.

The combination of MPLS and tunnels is not supported since they use
the same fields internally in the kernel. You can see the check for
if (eth_p_mpls(eth_type))
return -EINVAL;
in validate_set() under the case OVS_KEY_ATTR_TUNNEL.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] A issue about MPLS over VxLAN via OVS

[Jesse Gross]

On Wed, Jan 13, 2016 at 11:15 PM, Chao Hu  wrote:
> Hi,
>
>
>
> I find an issue with OVS 2.4.0 that MPLS over VxLAN is failed.  Is it a
> limitation or bug?

It's a limitation - it's not currently possible to support both MPLS
and tunnels at the same time. I suspect that this could actually be
relaxed in the most recent kernels but historically they required use
of some of the same fields.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] null ptr exception in ovs_vport_get_stats+0x6a/0x130 [openvswitch]

[Jesse Gross]

On Wed, Jan 6, 2016 at 8:25 PM, Flavio Fernandes <ffern...@redhat.com> wrote:
>
>
> On Wed, Jan 6, 2016 at 10:58 PM, Jesse Gross <je...@kernel.org> wrote:
>>
>> On Tue, Jan 5, 2016 at 3:09 PM, Flavio Fernandes <ffern...@redhat.com>
>> wrote:
>> >
>> > Let me start by saying sorry for all the noise on this subject! This is
>> > a
>> > wrap up message, I promise. :)
>> >
>> > With help of Flavio L [fbl], I got a better insight on what I did wrong.
>> > When I set the type of the [tap1] interface to
>> > internal, ovsdb was happy to accept it, but that -- of course -- turns
>> > out
>> > to 1) be a stupid thing to do and 2) leave
>> > things in a half baked state.
>> >
>> > There is not much in the logs, but as OVS fails to set the type, it
>> > frees up
>> > the interface, but that clean up is not
>> > completely done as far as the kernel datapath goes. It then becomes a
>> > booby
>> > trap later when VM was created,
>> > as something is still hanging on to its address and calling into
>> > dev_get_stats() with a stale net_device pointer.
>> >
>> > All in all, this is an artifact of a user error and while code could be
>> > made
>> > more resilient, it gave me what I
>> > deserved. ;)
>>
>> I agree with Ben that this still seems like a bug - userspace commands
>> shouldn't be able to crash the kernel, even if they are invalid.
>>
>> The commands you gave are actually the opposite of what I initially
>> thought - they are trying to convert a tap device to an internal
>> device rather than the other way around. However, I'm not sure how
>> this could cause a problem because when the internal device is
>> created, it should fail if there is another device of the same name
>> and then bail out without doing anything else. I tried reproducing it
>> and that does seem to be what happens on my system, so I'm not sure
>> what is happening on yours.
>
>
> Very interesting... what system (kernel/distro) are you using, Jesse? I
> wonder if Centos 7.2 is required to make this bug happen. If you think this
> is a good idea, I could also try to use the .ko from the the ovs tree
> instead
> of the kernel module that is part of Centos 7.2.

I just used an old Centos 6 machine that I had laying around along
with the kernel module packaged with OVS 2.4. Obviously, this could be
affected by different kernel versions in theory although to the best
of my knowledge that code hasn't changed in a long time.

When I ran the commands that you gave, I got the result which I would
normally expect. Changing the type of the tap interface to "internal"
results in it disconnecting from the OVS datapath and in the OVS log I
see a File Exists error message. If I run ifconfig, the tap port still
exists on the system and there doesn't seem to be any problem fetching
the stats. I'm not sure why this is different between our two systems.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] null ptr exception in ovs_vport_get_stats+0x6a/0x130 [openvswitch]

[Jesse Gross]

On Tue, Jan 5, 2016 at 3:09 PM, Flavio Fernandes  wrote:
>
> Let me start by saying sorry for all the noise on this subject! This is a
> wrap up message, I promise. :)
>
> With help of Flavio L [fbl], I got a better insight on what I did wrong.
> When I set the type of the [tap1] interface to
> internal, ovsdb was happy to accept it, but that -- of course -- turns out
> to 1) be a stupid thing to do and 2) leave
> things in a half baked state.
>
> There is not much in the logs, but as OVS fails to set the type, it frees up
> the interface, but that clean up is not
> completely done as far as the kernel datapath goes. It then becomes a booby
> trap later when VM was created,
> as something is still hanging on to its address and calling into
> dev_get_stats() with a stale net_device pointer.
>
> All in all, this is an artifact of a user error and while code could be made
> more resilient, it gave me what I
> deserved. ;)

I agree with Ben that this still seems like a bug - userspace commands
shouldn't be able to crash the kernel, even if they are invalid.

The commands you gave are actually the opposite of what I initially
thought - they are trying to convert a tap device to an internal
device rather than the other way around. However, I'm not sure how
this could cause a problem because when the internal device is
created, it should fail if there is another device of the same name
and then bail out without doing anything else. I tried reproducing it
and that does seem to be what happens on my system, so I'm not sure
what is happening on yours.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] null ptr exception in ovs_vport_get_stats+0x6a/0x130 [openvswitch]

[Jesse Gross]

t; 0xa04eead7 <ovs_vport_get_stats+71>:je 0xa04eeae3
> <ovs_vport_get_stats+83>
> 0xa04eead9 <ovs_vport_get_stats+73>:movl   $0x0,(%rdi)
> 0xa04eeadf <ovs_vport_get_stats+79>:add$0x4,%rdi
> 0xa04eeae3 <ovs_vport_get_stats+83>:test   $0x2,%dl
> 0xa04eeae6 <ovs_vport_get_stats+86>:je 0xa04eeaf2
> <ovs_vport_get_stats+98>
> 0xa04eeae8 <ovs_vport_get_stats+88>:xor%eax,%eax
> 0xa04eeaea <ovs_vport_get_stats+90>:add$0x2,%rdi
> 0xa04eeaee <ovs_vport_get_stats+94>:mov%ax,-0x2(%rdi)
> 0xa04eeaf2 <ovs_vport_get_stats+98>:and$0x1,%edx
> 0xa04eeaf5 <ovs_vport_get_stats+101>:   je 0xa04eeafa
> <ovs_vport_get_stats+106>
> 0xa04eeaf7 <ovs_vport_get_stats+103>:   movb   $0x0,(%rdi)
> /usr/src/debug/kernel-3.10.0-327.3.1.el7/linux-3.10.0-327.3.1.el7.x86_64/arch/x86/include/asm/atomic64_64.h:
> 21
> 0xa04eeafa <ovs_vport_get_stats+106>:   mov0x60(%r12),%rax
> 0xa04eeaff <ovs_vport_get_stats+111>:   mov
> -0x1ee90836(%rip),%r13# 0x8165e2d0 
> /usr/src/debug/kernel-3.10.0-327.3.1.el7/linux-3.10.0-327.3.1.el7.x86_64/net/openvswitch/vport.c:
> 311
> 0xa04eeb06 <ovs_vport_get_stats+118>:   mov$0x,%edx
> /usr/src/debug/kernel-3.10.0-327.3.1.el7/linux-3.10.0-327.3.1.el7.x86_64/net/openvswitch/vport.c:
> 306
> 0xa04eeb0b <ovs_vport_get_stats+123>:   mov%rax,0x20(%rbx)
> /usr/src/debug/kernel-3.10.0-327.3.1.el7/linux-3.10.0-327.3.1.el7.x86_64/arch/x86/include/asm/atomic64_64.h:
> 21
> 0xa04eeb0f <ovs_vport_get_stats+127>:   mov0x70(%r12),%rax
> /usr/src/debug/kernel-3.10.0-327.3.1.el7/linux-3.10.0-327.3.1.el7.x86_64/net/openvswitch/vport.c:
> 307
> 0xa04eeb14 <ovs_vport_get_stats+132>:   mov%rax,0x28(%rbx)
> /usr/src/debug/kernel-3.10.0-327.3.1.el7/linux-3.10.0-327.3.1.el7.x86_64/arch/x86/include/asm/atomic64_64.h:
> 21
> 0xa04eeb18 <ovs_vport_get_stats+136>:   mov0x68(%r12),%rax
> /usr/src/debug/kernel-3.10.0-327.3.1.el7/linux-3.10.0-327.3.1.el7.x86_64/net/openvswitch/vport.c:
> 308
> 0xa04eeb1d <ovs_vport_get_stats+141>:   mov%rax,0x38(%rbx)
> /usr/src/debug/kernel-3.10.0-327.3.1.el7/linux-3.10.0-327.3.1.el7.x86_64/arch/x86/include/asm/atomic64_64.crash>
>
> ==
>
> crash> bt -f
> …
>  #8 [88082c1df7c0] page_fault at 8163d388
> [exception RIP: ovs_vport_get_stats+106]
> RIP: a04eeafa  RSP: 88082c1df870  RFLAGS: 00010246
> RAX:   RBX: 88082c1df898  RCX: 
> RDX:   RSI: 88082c1df898  RDI: 88082c1df8d8
> RBP: 88082c1df888   R8: 88084d9ed010   R9: 880853324118
> R10: 88085f003400  R11: 0048  R12: 
> R13: 0008  R14: 880853324000  R15: 8808533240b8
> ORIG_RAX:   CS: 0010  SS: 0018
> 88082c1df7c8: 8808533240b8 880853324000
> 88082c1df7d8: 0008 
> 88082c1df7e8: 88082c1df888 88082c1df898
> 88082c1df7f8: 0048 88085f003400
> 88082c1df808: 880853324118 88084d9ed010
> 88082c1df818:  
> 88082c1df828:  88082c1df898
> 88082c1df838: 88082c1df8d8 
> 88082c1df848: a04eeafa 0010
> 88082c1df858: 00010246 88082c1df870
> 88082c1df868: 0018 88082c1dfa58
> 88082c1df878: 880035e2b000 0008
> 88082c1df888: 88082c1df8e8 a04ef079
>  #9 [88082c1df890] internal_dev_get_stats at a04ef079
> [openvswitch]
> 88082c1df898:  
> 88082c1df8a8:  
> crash>
>
> ==
>
> $ sed -n 291,308p
> /usr/src/debug/kernel-3.10.0-327.3.1.el7/linux-3.10.0-327.3.1.el7.x86_64/net/openvswitch/vport.c
> void ovs_vport_get_stats(struct vport *vport, struct ovs_vport_stats *stats)
> {
> int i;
>
> memset(stats, 0, sizeof(*stats));
>
> /* We potentially have 2 sources of stats that need to be combined:
>  * those we have collected (split into err_stats and percpu_stats) from
>  * set_stats() and device error stats from netdev->get_stats() (for
>  * errors that happen  downstream and therefore aren't reported through
>  * our vport_record_error() function).
>  * Stats from first source are reported by ovs (OVS_V

Re: [ovs-discuss] trace route for vxlan overlay network

[Jesse Gross]

BFD is built into OVS, not an external application. It should not be
hard to find out how it works by grepping the OVS source code.

On Sun, Dec 27, 2015 at 2:40 AM, Avi Cohen <avi.co...@huawei.com> wrote:
> Jesse,
> Thanks for your immediate response.
> Can u refer me to a sample applications/architecture  (bfd?)  
> injecting/receiving  packet to/from  OVS
> Regards  avi
>
> -Original Message-
> From: Jesse Gross [mailto:je...@kernel.org]
> Sent: Wednesday, 23 December, 2015 2:46 AM
> To: Avi Cohen
> Cc: discuss@openvswitch.org
> Subject: Re: [ovs-discuss] trace route for vxlan overlay network
>
> On Tue, Dec 22, 2015 at 7:53 AM, Avi Cohen <avi.co...@huawei.com> wrote:
>> Hello all
>>
>> I saw in
>> https://www.mail-archive.com/discuss@openvswitch.org/msg15373.html
>> ,
>>
>> that trace-route is not implemented yet in OVS.
>
> Well, that discussion is not really related to this since its about 
> traceroute where OVS is a transit switch.
>
>> I need to implement a more enhanced trace-route for vxlan overlay.
>>
>> As we use the OVS as a vTEP device I need to trace-route the actual
>> data-path for a given vxlan-segment (since there are multi ecmp paths
>> – this should traverse a specific path based on the source UDP port)
>>
>> This is  done by transmitting a series an vxlan encapsulated packets with an
>> incremental TTL , IP-destined to the remote vTEP.   an intermediate device
>> (which are generally traditional routers in the underlay)  replies
>> with ICMP ttl expired.
>>
>> 2 questions:
>>
>> -  How to initiate  these packets transmission in the originating
>> vTEP ? can I do it from the vTEP/ a local application ?
>
> Packets can be injected from OVS userspace, similar to STP/BFD. When setting 
> up the encapsulation parameters, you can set the TTL.
>
>> -  How the ICMP  replies  can be delivered/ if any  to a local
>> application that is connected to the vTEP via a TAP device ?
>
> I think you could probably capture ICMP errors using a raw socket.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] null ptr exception in ovs_vport_get_stats+0x6a/0x130 [openvswitch]

[Jesse Gross]

On Mon, Jan 4, 2016 at 1:41 PM, Flavio Fernandes  wrote:
> So, I'm a happy camper, but can't help but worry a little about the
> fragility of the
> system when one attempts to use a port type internal 'directly' as bridged.
> The fix
> I have in mind is relatively simple:  add a check in  internal_dev_get_stats
> to gracefully handle cases when ovs_internal_dev_get_vport returns null. Too
> simple?

I don't think that the problem is simply that we are returning NULL
from ovs_internal_dev_get_vport(). ovs_internal_dev_get_vport() should
never return NULL to internal_dev_get_stats() because it is checking
whether the device has a ops structure that is equal to the one that
leads to internal_dev_get_stats(). And in fact, if you look at the
full stack trace, the address being dereferenced is 0x0060
rather than 0x0 from a real NULL.

This looks like something is overwriting the vport pointer in the
device structure. If you follow where this is coming from you'll wind
up at ovs_netdev_get_vport() which is a maze of twisty conditions that
depend on what kernel version you are using. Particularly on the RHEL
kernels (which based on your email address I'm guessing you're using),
the pointer is stashed in a variety of places. My guess is that these
are not entirely safe in some conditions - likely related to tap
devices based on your other description. I think the best path forward
is to try to see which of the conditions your kernel version falls
into and try to see what might be stomping on the pointer.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] trace route for vxlan overlay network

[Jesse Gross]

On Tue, Dec 22, 2015 at 7:53 AM, Avi Cohen  wrote:
> Hello all
>
> I saw in https://www.mail-archive.com/discuss@openvswitch.org/msg15373.html
> ,
>
> that trace-route is not implemented yet in OVS.

Well, that discussion is not really related to this since its about
traceroute where OVS is a transit switch.

> I need to implement a more enhanced trace-route for vxlan overlay.
>
> As we use the OVS as a vTEP device I need to trace-route the actual
> data-path for a given vxlan-segment (since there are multi ecmp paths – this
> should traverse a specific path based on the source UDP port)
>
> This is  done by transmitting a series an vxlan encapsulated packets with an
> incremental TTL , IP-destined to the remote vTEP.   an intermediate device
> (which are generally traditional routers in the underlay)  replies with ICMP
> ttl expired.
>
> 2 questions:
>
> -  How to initiate  these packets transmission in the originating
> vTEP ? can I do it from the vTEP/ a local application ?

Packets can be injected from OVS userspace, similar to STP/BFD. When
setting up the encapsulation parameters, you can set the TTL.

> -  How the ICMP  replies  can be delivered/ if any  to a local
> application that is connected to the vTEP via a TAP device ?

I think you could probably capture ICMP errors using a raw socket.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] openvswitch2.3.0 kernel crash

[Jesse Gross]

On Sun, Dec 20, 2015 at 9:29 PM, wenxu  wrote:
> Hi all,
>
> I meet a crash problem in kernel with openvswitch2.3.0
[...]
> It crashed in ovs_flow_extract with _skb_pull the src mac address
> (BUG_ON(skb->len < skb->data_len);)
> int ovs_flow_extract(struct sk_buff *skb, u16 in_port, struct sw_flow_key
> *key)
> {
> .
> __skb_pull(skb, 2 * ETH_ALEN);
> .
> }

Thanks for tracking this down. I agree with your analysis.

> I think ovs should check this mess situation in two ways.
> 1. check the tpi->proto

Your solution looks right to me but we also need to fix the upstream
Linux kernel, which has the same issue. Can you please submit a patch
to fix it there and then backport it to OVS? I should also point out
that this does not affect the current version of either OVS or Linux
as the code has changed and is not vulnerable to this. However, the
older versions are still in use and being maintained.

> 2. add pskb_may_pull before pull like ip_gre did

I don't believe that this is necessary if we have #1. GRE does this
for the Ethernet header if the protocol is set to TEB. Other Ethernet
drivers are also required to enforce this invariant.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Fw: TSO not working for VM iperf data packets.

[Jesse Gross]

On Sat, Dec 19, 2015 at 7:26 AM, Piyush R Srivastava1 
wrote:

> Hi,
>
> One other thing i noticed is that... For starting I DO SEE offloaded
> packets... However, after a few initial packets, Offloading seems to be
> reduced drastically and i see purely 1464 sized Ethernet Frames.
>
[...]

> This seem to suggests that the issue is for the packets that are getting
> encapsulated at compute node and decapsulated at Network Node only
> We are using software GRO patch mentioned here at Network Nodes-
> http://openvswitch.org/pipermail/dev/2015-August/059335.html
>
> Does this info help in debugging the issue?
>

There is no issue then. GRO is simply best effort aggregation and does not
wait to get a full 64k frame so when the packet is transmitted on the
physical NIC, TSO will be limited what was aggregated. You're only
guaranteed to get big TSO packets all the time when you generate them on
the local machine like you did in your later tests.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] TSO not working for VM iperf data packets.

[Jesse Gross]

On Fri, Dec 18, 2015 at 11:17 AM, Piyush R Srivastava1
 wrote:
> Hi,
>
> Problem-
>
> We have a testbed OpenStack setup which uses VXLAN Tunneling for connecting
> the network and compute nodes.
> On doing an iperf (TCP stream) from VM (client) to external network node
> (server), we see that the TCP packets
> ( which are encapsulated by VTEP on compute node and decapsulated by VTEP on
> network node ) are NOT getting segment offloaded (TSO)
> by the external network NIC on Network Node.
> However, TCP stream iperf packets are getting offloaded when doing iperf
> between the Network Node (client) and External Node (server)
>
> Any help on what is causing this anomaly?

I'm guessing that the tcpdump for the device inside the network
namespace is on the ingress port. I would look at the ethtool settings
for the egress since that seems to be the point at which packets are
no longer larger than MTU size.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] TSO not working for VM iperf data packets.

[Jesse Gross]

On Fri, Dec 18, 2015 at 12:25 PM, Piyush R Srivastava1 
wrote:

> Hi Jesse,
>
> Yeah that was the tcpdump for ingress port.
> Kindly find the tcpdump for egress port in namespace as well-
>
>
> [root@rhel7-23 ~]# ip netns exec
> qrouter-223d91ae-3025-4070-83d0-63faa58d819b tcpdump -ennqi qg-ab10ec1d-2b
> -c 30 host 1.1.1.34
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on qg-ab10ec1d-2b, link-type EN10MB (Ethernet), capture size
> 65535 bytes
>
 This has the same name as the interface as you showed before, so I'm not
sure which is right. However, I would look at each interface in the path
and try to pinpoint where TSO stops occurring. There's not much more that I
can suggest.

>
> Both the egress port of Namespace and physical NIC for external network
> (eth1) are mapped to BR-EX, however, BR-EX has 1500 MTU.
> Do you think that is affecting, even with TSO ON for eth1?
>
The MTU should not matter if TSO is set. However, TSO needs to be set on
all interfaces, not just the egress Ethernet interface.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Is there any plan to support IP multicast required in RFC standard in OVS?

[Jesse Gross]

On Thu, Dec 10, 2015 at 7:19 PM, Shi Xin Ruan  wrote:

> Thanks Jesse.
>
> In fact I need some deployment in production network.
> But good news is that it's not the limitation of ovs, just nobody
> implement it. Right?
>

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

Re: [ovs-discuss] Is there any plan to support IP multicast required in RFC standard in OVS?

[Jesse Gross]

On Wed, Dec 9, 2015 at 5:49 PM, Shi Xin Ruan  wrote:
> Hi OVS developers,
>
>
> I am trying to connect a OVS switch to physical hardware switch.
> Physical hardware switch support RFC standard VXLAN, it will use IP
> multicast group for broadcast packet.
> But OVS will receive IP multicast packet. So the connection can NOT be
> setup.
>
> Is there any plan to support IP multicast in OVS?

There's no objection to it but nobody has ever actually bothered to
implement it since people rarely deploy VXLAN this way in practice.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] ovs not triggering vxlan offload

[Jesse Gross]

On Wed, Nov 18, 2015 at 10:59 PM, Yushen Lin  wrote:
> Hello,
>
> I am testing OVS 2.4.0 on Linux 3.19 kernel.
>
> Not sure when it got changed, but VXLAN offload is no longer on by
> default in 3.19 - it used to be the case in 3.19. So, normally I have:
> ethtool -k eth4 | grep tnl
> tx-udp_tnl-segmentation: off [fixed]

It's true, it's a known problem. It looks like it's unlikely to be
fixed in 2.4 at this point. However, you should be able to use the
upstream kernel module from your distribution to avoid this problem.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] ipfix leads to kernel crash

[Jesse Gross]

This is the relevant commit:
https://github.com/openvswitch/ovs/commit/b953042214201e2693a485a8ba8b19f69e5bdf34

Unfortunately, it's not very obvious from the commit message that this is a
bug fix.

On Sunday, November 8, 2015, ZHANG Zhiming <zhangzhim...@yunshan.net.cn>
wrote:

> Hi Gross,
>
> Thank you very much.
>
> You save me so much time.
>
> The version of OVS may not be changed due to some reasons. So I have to
> fix it on versoin 2.31.
> Could you tell me which patch solved this bug?
> I checked a commit logs, and found no clues.
>
> Best regards,
>
> --
> ZHANG Zhiming
> Yunshan Networks
>
> *From:* Jesse Gross <javascript:_e(%7B%7D,'cvml','je...@nicira.com');>
> *Date:* 2015-11-07 11:40
> *To:* zhangzhiming
> <javascript:_e(%7B%7D,'cvml','zhangzhim...@yunshan.net.cn');>
> *CC:* discuss <javascript:_e(%7B%7D,'cvml','discuss@openvswitch.org');>
> *Subject:* Re: [ovs-discuss] ipfix leads to kernel crash
> On Monday, November 2, 2015, ZHANG Zhiming <zhangzhim...@yunshan.net.cn
> <javascript:_e(%7B%7D,'cvml','zhangzhim...@yunshan.net.cn');>> wrote:
>
>> Hi,
>>
>> Could someone help me check this kernel crash?
>> I set ipfix to send report to a collector, and the kernel crashed after
>> several hours.
>> Thanks!
>>
>> ovs-vsctl (Open vSwitch) 2.3.1
>> Compiled Aug 11 2015 05:18:30
>> DB Schema 7.6.2
>>
>
> This bug has already been fixed. Please upgrade to either OVS 2.3.2 or
> 2.4.
>
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] ipfix leads to kernel crash

[Jesse Gross]

On Monday, November 2, 2015, ZHANG Zhiming 
wrote:

> Hi,
>
> Could someone help me check this kernel crash?
> I set ipfix to send report to a collector, and the kernel crashed after
> several hours.
> Thanks!
>
> ovs-vsctl (Open vSwitch) 2.3.1
> Compiled Aug 11 2015 05:18:30
> DB Schema 7.6.2
>

This bug has already been fixed. Please upgrade to either OVS 2.3.2 or 2.4.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] 2.3.2 kernel module build error on rhel7

[Jesse Gross]

On Sat, Oct 10, 2015 at 3:32 AM, Tashi Lu  wrote:
> Hi all,
>
> When building LTS version of ovs kernel module from tarball on CentOS 7,
> kernel version 3.10.0-229.el7.x86_64, I encountered following errors. What I
> did wrong here?

RHEL 7 has the OVS kernel module built in, so you shouldn't need to
build it at all. If you really want to use the out of tree module for
some reason, then OVS 2.4 should be compatible with RHEL 7.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Early addition of flows in the kernel.

[Jesse Gross]

On Mon, Oct 12, 2015 at 5:17 AM, jimson chacko
 wrote> Hi,
>
> As per my understanding, OVS inserts the flow in the kernel when an
> exception packet is handled by the vswitchd (ofcourse when matching flow is
> present in the vswitchd).
>
> Is it possible to push the flow into the kernel as soon as the flow gets
> added to vswitchd ? This enables in avoiding the exception mechanism and
> hence faster processing.

No.

> Can you briefly let me know why the design was kept so ?

It's not possible to do in a general and efficient manner. The flows
kept by the kernel are significantly simpler than the ones in
userspace to make them easier to process. The consequence is that they
are less expressive and you can potentially need a lot more of them to
cover the entire space, which is prohibitively expensive.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] [PATCH-RFC 1/2] Improve ARP latency

[Jesse Gross]

On Wed, Oct 7, 2015 at 5:02 PM,  <dwil...@us.ibm.com> wrote:
>
> Quoting Jesse Gross <je...@nicira.com>:
>
>> On Thu, Oct 1, 2015 at 4:19 PM,  <dwil...@us.ibm.com> wrote:
>>>
>>>
>>> Quoting Jesse Gross <je...@nicira.com>:
>>>
>>>> On Tue, Sep 29, 2015 at 10:50 PM,  <dwil...@us.ibm.com> wrote:
>>>>>
>>>>>
>>>>> Hi-
>>>>>
>>>>> I have been conducting scaling tests with OVS and docker. My tests
>>>>> revealed
>>>>> that the latency of ARP packets can become very large resulting in many
>>>>> ARP
>>>>> re-transmissions and time-outs. I found the source of the poor latency
>>>>> to
>>>>> be
>>>>> with the handling of arp packets in ovs_vport_find_upcall_portid().
>>>>> Each
>>>>> packet is hashed in ovs_vport_find_upcall_portid() by calling
>>>>> skb_get_hash().  This hash is used to select a netlink socket in which
>>>>> to
>>>>> send the packet to userspace.  However, skb_get_hash() is not
>>>>> supporting
>>>>> ARP
>>>>> packets returning a 0 (invalid hash) for every ARP.  This results in a
>>>>> single ovs-vswitchd handler thread processing every arp packet thus
>>>>> severely
>>>>> impacting the average latency of ARPs. I am purposing a change to
>>>>> ovs_vport_find_upcall_portid() that spreads the ARP packets evenly
>>>>> between
>>>>> all the handler threads (patch to follow).  Please let me know if you
>>>>> have
>>>>> suggestions/comments.
>>>>
>>>>
>>>>
>>>> This is definitely an interesting analysis but I'm a little surprised
>>>> at the basic scenario. First, I guess it seems to me that the L2
>>>> domain is too large if there are this many ARPs.
>>>
>>>
>>>
>>> I can imagine running a couple of thousand docker containers, so I think
>>> this is a reasonable size test.
>>
>>
>> Having thousands of nodes (regardless of whether they are containers
>> or VMs) on a single L2 segment is really not a good idea. I would
>> expect them to be segmented into smaller groups with L3 boundaries in
>> the middle.
>
>
>
> Something I am not clear on. Creating smaller L2 segments would reduce the
> impact of a broadcast packet, fewer ports to flood the packet to. But would
> it affect the performance of the upcall datapath?  Comparing a single 512
> port switch to two 256 port switches (on a single host).  Wont they have the
> same number of ports, queues, threads and upcalls?

If it's all on the same host then it would be roughly the same impact
on that OVS. However, OVS instances on other hosts wouldn't have to
see these packets and it's just generally better design to have
smaller L2.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] MPLS header on a VLAN packet

[Jesse Gross]

On Fri, Oct 2, 2015 at 6:48 AM, Michele Santuari
 wrote:
> Hi all,
> we are trying to tag with MPLS a VLAN packet.
>
> The rule installed into the ovs is:
> cookie=0x24465aa58e, duration=5.452s, table=0, n_packets=0, n_bytes=0,
> idle_age=5, priority=100,in_port=1,dl_vlan=10,dl_type=0x8100
> actions=push_mpls:0x8847,load:0x1b->OXM_OF_MPLS_LABEL[],output:2
>
> The strange think is that packets with VLAN 10 coming from port 1 are not
> matching this rule.
> The ovs log shows this error:
>
> 2015-10-02T12:37:51.757Z|2|dpif(handler22)|WARN|system@ovs-system:
> execute push_mpls(label=25,tc=0,ttl=64,bos=1,eth_type=0x8847),2 failed
> (Invalid argument) on packet
> icmp,in_port=0,dl_vlan=10,dl_vlan_pcp=0,dl_src=00:00:00:00:00:01,dl_dst=00:00:00:00:00:02,nw_src=10.0.0.1,nw_dst=10.0.0.2,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0
> 2015-10-02T12:37:52.636Z|3|dpif(handler22)|WARN|system@ovs-system:
> failed to put[create] (Invalid argument)
> ufid:586b5f05798f165219b201bac96b56bb
> recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(1),skb_mark(0/0),eth(src=00:00:00:00:00:01/00:00:00:00:00:00,dst=00:00:00:00:00:02/00:00:00:00:00:00),eth_type(0x8100),vlan(vid=10,pcp=0/0x0),encap(eth_type(0x0800),ipv4(src=10.0.0.1/0.0.0.0,dst=10.0.0.2/0.0.0.0,proto=1/0,tos=0/0xfc,ttl=64,frag=no),icmp(type=8/0,code=0/0)),
> actions:push_mpls(label=25,tc=0,ttl=64,bos=1,eth_type=0x8847),2
>
>
> We do not know if adding an MPLS tag on a VLAN frame is a permitted
> operation.
> Do you have any idea?

Yes, it's not supported. The nesting of various tags resulted in a
number of complications and so it was disallowed for the time being.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] [PATCH-RFC 1/2] Improve ARP latency

[Jesse Gross]

On Thu, Oct 1, 2015 at 4:19 PM,  <dwil...@us.ibm.com> wrote:
>
> Quoting Jesse Gross <je...@nicira.com>:
>
>> On Tue, Sep 29, 2015 at 10:50 PM,  <dwil...@us.ibm.com> wrote:
>>>
>>> Hi-
>>>
>>> I have been conducting scaling tests with OVS and docker. My tests
>>> revealed
>>> that the latency of ARP packets can become very large resulting in many
>>> ARP
>>> re-transmissions and time-outs. I found the source of the poor latency to
>>> be
>>> with the handling of arp packets in ovs_vport_find_upcall_portid().  Each
>>> packet is hashed in ovs_vport_find_upcall_portid() by calling
>>> skb_get_hash().  This hash is used to select a netlink socket in which to
>>> send the packet to userspace.  However, skb_get_hash() is not supporting
>>> ARP
>>> packets returning a 0 (invalid hash) for every ARP.  This results in a
>>> single ovs-vswitchd handler thread processing every arp packet thus
>>> severely
>>> impacting the average latency of ARPs. I am purposing a change to
>>> ovs_vport_find_upcall_portid() that spreads the ARP packets evenly
>>> between
>>> all the handler threads (patch to follow).  Please let me know if you
>>> have
>>> suggestions/comments.
>>
>>
>> This is definitely an interesting analysis but I'm a little surprised
>> at the basic scenario. First, I guess it seems to me that the L2
>> domain is too large if there are this many ARPs.
>
>
> I can imagine running a couple of thousand docker containers, so I think
> this is a reasonable size test.

Having thousands of nodes (regardless of whether they are containers
or VMs) on a single L2 segment is really not a good idea. I would
expect them to be segmented into smaller groups with L3 boundaries in
the middle.

> On a related issue, I am looking into the memory consumed by the netlink
> sockets, OVS on linux can create many of these sockets. Do you have any
> thought as to why the current model was picked?

Independent queues are the easiest way to provide lockless access to
incoming packets on different cores and, in some case, give higher
priority to certain types of packets.

>> The speed also
>> generally seems slower than I would expect but in any case I don't
>> disagree that it is better to spread the load among all the cores.
>>
>> On the patch itself, can't we just make skb_get_hash() be able to
>> decode ARP? It seems like that is cleaner and more generic.
>
>
> My first thought was to make a change in skb_get_hash().  However, the
> comment in __skb_get_hash() state that the hash is generated from the
> 4-tuple (address and ports).  ARPs have no ports so a return value of 0
> looked correct.
>
> /*
>   * __skb_get_hash: calculate a flow hash based on src/dst addresses
>   * and src/dst port numbers.  Sets hash in skb to non-zero hash value
>   * on success, zero indicates no valid hash.  Also, sets l4_hash in skb
>   * if hash is a canonical 4-tuple hash over transport ports.
>   */
>
> What do you think?

I don't think that this is really a strict definition. In particular,
IP packets that aren't TCP or UDP will still return a hash based on
the IP addresses.

However, I believe that you are looking at an old version of this
function. Any changes would need to be made to the upstream Linux
tree, not purely in OVS.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] [PATCH-RFC 1/2] Improve ARP latency

[Jesse Gross]

On Tue, Oct 6, 2015 at 2:42 PM,   wrote:
>
> Quoting dwil...@us.ibm.com:
>>>
>>>
>>> On the patch itself, can't we just make skb_get_hash() be able to
>>> decode ARP? It seems like that is cleaner and more generic.
>>
>>
>> My first thought was to make a change in skb_get_hash().  However, the
>> comment in __skb_get_hash() state that the hash is generated from the
>> 4-tuple (address and ports).  ARPs have no ports so a return value of 0
>> looked correct.
>>
>> /*
>>   * __skb_get_hash: calculate a flow hash based on src/dst addresses
>>   * and src/dst port numbers.  Sets hash in skb to non-zero hash value
>>   * on success, zero indicates no valid hash.  Also, sets l4_hash in skb
>>   * if hash is a canonical 4-tuple hash over transport ports.
>>   */
>>
>> What do you think?
>>
>
>
> Hi Jesse
>
> I did not get a response so I was unsure how to proceed.
>
> I am willing to pursue enhancing skb_get_hash() if you think that is the
> best approach.  However what would you think of something like this?
>
> hash = skb_get_hash(skb);
> if ( ! hash )
>return ids->ids[vport->port_no%ids->n_ids];
>
> return ids->ids[hash - ids->n_ids * reciprocal_divide(hash, ids->rn_ids)];
>
> This would solve my problem on kernels without the enhanced skb_get_hash()
> and no further change to ovs would be required once shb_get_hash() is
> updated.

OVS has an extensive system of backports from newer kernels. You
should strive to get your changes accepted in the upstream Linux tree
and then they can be backported to the OVS out-of-tree kernel module
for existing kernels.

> PS:  Should I move this discussion to ovs-dev ?

It would have been a better place to start it but it doesn't really
matter at this point.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] centos6.7_64 cannot build openswitch

[Jesse Gross]

On Fri, Sep 25, 2015 at 6:55 AM, 少帅 <4554...@qq.com> wrote:
> my OS info
> uname -a
> Linux localhost.localdomain 2.6.32-573.el6.x86_64 #1 SMP Thu Jul 23 15:44:03
> UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

It's true, 2.4.0 doesn't work on at least some versions of Centos 6.
If you build branch-2.4 from git then this should resolve the problem.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] The Compatibility between Openvswitch and Physical NIC

[Jesse Gross]

On Wednesday, September 16, 2015, zhi  wrote:

> Hi, everyone.
>   Recently, we met a strange problem. We use Openstack by openvswitch. The
> network node(physical server) crashes when vm send TCP packages. By my
> analysis, the information of the physical nic (public network nic) is below:
>

This is a pretty common NIC so I don't think there is a general issue
here. You'll need to capture some of kind of stack trace for anyone to be
able to take a look.

You are also using a pretty old version of OVS, so I would try upgrading.
Are you using the OVS kernel module or the one packed with the upstream
kernel?
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] tnl arp causes infinite reentrant stack death.

[Jesse Gross]

That's great, thanks a lot for testing.

On Wed, Sep 16, 2015 at 9:32 AM, David Evans <davidjoshuaev...@gmail.com> wrote:
> Thank you Jesse,
> The patch stopped the program call stack from killing ovs.
> Awesome.
> Will do some more tests today.
>
>
> On 9/15/15, 10:54 PM, "Jesse Gross" <je...@nicira.com> wrote:
>
>>On Tue, Sep 15, 2015 at 7:38 PM, David Evans <davidjoshuaev...@gmail.com>
>>wrote:
>>> Thanks Jesse!
>>> I think you may be close, but it is the ovs code that is re-entering
>>>it's
>>> self, this isn't an arp storm from a circle of traffic path, as far as
>>>i can
>>> tell. it is an attempt to transmit a single packet.. but never gets
>>>even the
>>> arp out to the stack at all.
>>> you can see build_tunnel_send 3 times as the stack trace goes in the
>>> original post. but no packets make it out. the program call stack is
>>>13000
>>> frames deep - which is why it crashed.
>>
>>When tunneling is done in userspace (such as with DPDK), the Linux
>>stack is not involved at all since the point of DPDK is to avoid the
>>kernel for performance reasons. That's why you see OVS reentering
>>itself repeatedly as it tries to forward and then generate more ARP
>>frames.
>>
>>I just sent out a patch CC'd to you that should fix this issue. Can
>>you test it? Note that in this case 'fix' means that it will prevent
>>OVS from crashing. However, traffic won't flow until the loop in the
>>configuration is resolved. Based on the stack trace, my guess is that
>>you have one or more patch ports connecting the bridges.
>
>
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] tnl arp causes infinite reentrant stack death.

[Jesse Gross]

On Tue, Sep 15, 2015 at 7:38 PM, David Evans  wrote:
> Thanks Jesse!
> I think you may be close, but it is the ovs code that is re-entering it's
> self, this isn't an arp storm from a circle of traffic path, as far as i can
> tell. it is an attempt to transmit a single packet.. but never gets even the
> arp out to the stack at all.
> you can see build_tunnel_send 3 times as the stack trace goes in the
> original post. but no packets make it out. the program call stack is 13000
> frames deep - which is why it crashed.

When tunneling is done in userspace (such as with DPDK), the Linux
stack is not involved at all since the point of DPDK is to avoid the
kernel for performance reasons. That's why you see OVS reentering
itself repeatedly as it tries to forward and then generate more ARP
frames.

I just sent out a patch CC'd to you that should fix this issue. Can
you test it? Note that in this case 'fix' means that it will prevent
OVS from crashing. However, traffic won't flow until the loop in the
configuration is resolved. Based on the stack trace, my guess is that
you have one or more patch ports connecting the bridges.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] tnl arp causes infinite reentrant stack death.

[Jesse Gross]

On Mon, Sep 14, 2015 at 9:57 PM, David Evans  wrote:
> Hi OVS.
>
> i am using rev 2.3.2+29bae5412ea3c6a1e20d79afd25c11b968dffa05-r0
>
> As you can see from my gdb backtrace 13K frames deep below we get an arp
> request because build_tunnel_send (frame 13659 below) decided we're starting
> to use a gre tunnel on a bridge and there's no arp cache for the destination
> yet.
>
> so what follows is  xlate_flood_packet -> ofproto_dpif_execute_actions ->
> xlate_actions -> do_xlate_actions -> xlate_output_action -> flood_packet
> -> compose_output_action -> compose_output_action__ -> xlate_table_action ->
> xlate_recusively
> -> do_xlate_actions (* a few actions) then we get back to
> compose_output_action__ and build_tunnel_send again.
>
> So infinitely the code will generate arp packets, but never deliver any of
> the arps out to the linux stack and keeps re-entering till it exhausts the
> stack
>
> How do i stop this?

OVS should protect itself better but fundamentally the issue is that
there is a loop somewhere in your configuration. Most likely the
remote_ip on your GRE port is pointing back into br0. Another
possibility is that a patch port is bridging packets between br0 and
breth1. In both of these cases, ARP packets from the IP stack are
re-entering the inside of the tunnel, which causes another ARP packet
and so on.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] [OVS v2.4.0] - VXLAN UDP port configuration is not notified to L2 driver/interface.

[Jesse Gross]

On Thu, Sep 10, 2015 at 12:23 AM, Manish Chopra
<manish.cho...@qlogic.com> wrote:
>> -Original Message-----
>> From: Jesse Gross [mailto:je...@nicira.com]
>> Sent: Thursday, September 10, 2015 2:09 AM
>> To: Manish Chopra; Thomas Graf
>> Cc: b...@openvswitch.org; pshe...@nicira.com; Yuval Mintz; Ashish Kumar
>> Subject: Re: [OVS v2.4.0] - VXLAN UDP port configuration is not notified to 
>> L2
>> driver/interface.
>>
>> On Wed, Sep 9, 2015 at 1:06 PM, Manish Chopra <manish.cho...@qlogic.com>
>> wrote:
>> >> -Original Message-
>> >> From: Jesse Gross [mailto:je...@nicira.com]
>> >> Sent: Wednesday, September 09, 2015 10:41 PM
>> >> To: Manish Chopra
>> >> Cc: b...@openvswitch.org; pshe...@nicira.com; Yuval Mintz; Ashish
>> >> Kumar
>> >> Subject: Re: [OVS v2.4.0] - VXLAN UDP port configuration is not
>> >> notified to L2 driver/interface.
>> >>
>> >> On Wed, Sep 9, 2015 at 3:03 AM, Manish Chopra
>> >> <manish.cho...@qlogic.com>
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > Detailed Description :
>> >> >
>> >> > I am trying to test VXLAN with OVS bridge with L2 driver. With OVS
>> >> > release version [2.4.0] package VXLAN udp port configuration is not
>> >> > notified to L2 driver
>> >> >
>> >> > via ndo_add_vxlan_port interface. Due to this hardware is not able
>> >> > to do offload of features [like checksum etc.], Hence TCP/IP
>> >> > traffic with encapsulated offload enabled on NIC is not working.
>> >>
>> >> You mean offloads aren't being performed and therefore things are
>> >> slower than if it was done in hardware or traffic doesn't flow?
>> >> Offloads should never be mandatory.
>> >>
>> >> What is the base kernel version?
>> >
>> > Traffic doesn't flow at all. Our hardware is supportive for encap offloads 
>> > only
>> when UDP port is configured on hardware.
>> >
>> > We claim to support below features for encapsulation  -
>> > ndev->hw_enc_features = NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM
>>
>> I believe that the correctness issue is actually in the driver. You can't 
>> assume
>> that encapsulation means VXLAN or that the port will be registered. There are
>> other protocols that set this and there are also other sources for offloaded
>> encapsulation packets, such as VMs. You're going to have to do some 
>> filtering of
>> offloads in ndo_features_check to support this hardware.
>>
>> That being said, there is a performance regression in OVS. Thomas, I believe 
>> that
>> this is a result of the GBP changes since that caused kernels that previously
>> supported receive offloads and GRO to use the compat code, which doesn't
>> support them. Would you mind taking a look?
>
> I didn't get it much. What would have caused performance regression due to 
> notifying UDP port ?
> Not sure how it is doable the said filtering ? "ndev->hw_enc_features" is the 
> mask of the features inherited by encapsulating device, it could be 
> geneve/gre on top of
> base device. Given that VXLAN udp port is not notified we can't just remove 
> these features from " ndev->hw_enc_features" as it might affect other encap 
> device features.

What I mean is that I agree that OVS is not notifying drivers about
VXLAN ports in 2.4 on certain kernels. However, I consider that to be
a performance regression due to the loss of receive side offloads,
such as checksum. The fact that traffic is not flowing I believe is an
issue with the driver.

Here's an example: You mentioned Geneve, which is also a UDP-based
encapsulation but does not currently have support for registering the
receive UDP port, thereby making the netdevice very similar to VXLAN
in OVS 2.4. If you send Geneve traffic with offloads, will the packets
get dropped? My guess is yes.

Assuming that is true, I see three possible solutions in your driver:
 * Ideally, find a way to decouple transmit and receive offload.
 * Continue advertising transmit offloads but for those that can't be
supported, dynamically remove their offloads using
ndo_features_check() (See the Intel fm10k driver for an example of
this.)
 * Don't advertise encapsulation offloads.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] ovs not triggering vxlan offload

[Jesse Gross]

On Thu, Sep 10, 2015 at 7:36 PM, Xu (Simon) Chen  wrote:
> Hello,
>
> I am testing OVS 2.4.0 on Linux 3.18 kernel.
>
> Not sure when it got changed, but VXLAN offload is no longer on by
> default in 3.18 - it used to be the case in 3.14. So, normally I have:
> ethtool -k eth4 | grep tnl
> tx-udp_tnl-segmentation: off [fixed]
>
> Configuring a VXLAN interface manually would trigger that option to
> turn on. Something like:
> ip link add vxlan0 type vxlan id 11 group 239.1.1.1 dev eth4
> ip addr add 1.2.4.5/24 dev vxlan0
> ip link set up vxlan0
>
> Then we have:
> ethtool -k eth4 | grep tnl
> tx-udp_tnl-segmentation: on [requested off]
>
> I imagined that when OVS created the VXLAN tunneled ports, it should
> turn on VXLAN offload as well, but it's not happening.

This was reported just yesterday:
http://openvswitch.org/pipermail/discuss/2015-September/018714.html

I'm assuming that this is with the out of tree OVS kernel module. In
that case, the change is in OVS 2.4 and shouldn't be a difference
between Linux 3.14 and 3.18.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] ovs not triggering vxlan offload

[Jesse Gross]

It actually is the same root cause. The only difference is the NIC is
not the same and the driver is reacting in a different way.

On Thu, Sep 10, 2015 at 7:53 PM, Xu (Simon) Chen <xche...@gmail.com> wrote:
> I looked at that thread, and it's slightly different from mine...
>
> My traffic is flowing, just VXLAN offload isn't kicking in, which
> obviously has a significant performance hit. I am using a datapath
> kernel module built from OVS 2.4.0.
>
> On Thu, Sep 10, 2015 at 10:48 PM, Jesse Gross <je...@nicira.com> wrote:
>> On Thu, Sep 10, 2015 at 7:36 PM, Xu (Simon) Chen <xche...@gmail.com> wrote:
>>> Hello,
>>>
>>> I am testing OVS 2.4.0 on Linux 3.18 kernel.
>>>
>>> Not sure when it got changed, but VXLAN offload is no longer on by
>>> default in 3.18 - it used to be the case in 3.14. So, normally I have:
>>> ethtool -k eth4 | grep tnl
>>> tx-udp_tnl-segmentation: off [fixed]
>>>
>>> Configuring a VXLAN interface manually would trigger that option to
>>> turn on. Something like:
>>> ip link add vxlan0 type vxlan id 11 group 239.1.1.1 dev eth4
>>> ip addr add 1.2.4.5/24 dev vxlan0
>>> ip link set up vxlan0
>>>
>>> Then we have:
>>> ethtool -k eth4 | grep tnl
>>> tx-udp_tnl-segmentation: on [requested off]
>>>
>>> I imagined that when OVS created the VXLAN tunneled ports, it should
>>> turn on VXLAN offload as well, but it's not happening.
>>
>> This was reported just yesterday:
>> http://openvswitch.org/pipermail/discuss/2015-September/018714.html
>>
>> I'm assuming that this is with the out of tree OVS kernel module. In
>> that case, the change is in OVS 2.4 and shouldn't be a difference
>> between Linux 3.14 and 3.18.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] [OVS v2.4.0] - VXLAN UDP port configuration is not notified to L2 driver/interface.

[Jesse Gross]

On Wed, Sep 9, 2015 at 1:06 PM, Manish Chopra <manish.cho...@qlogic.com> wrote:
>> -Original Message-----
>> From: Jesse Gross [mailto:je...@nicira.com]
>> Sent: Wednesday, September 09, 2015 10:41 PM
>> To: Manish Chopra
>> Cc: b...@openvswitch.org; pshe...@nicira.com; Yuval Mintz; Ashish Kumar
>> Subject: Re: [OVS v2.4.0] - VXLAN UDP port configuration is not notified to 
>> L2
>> driver/interface.
>>
>> On Wed, Sep 9, 2015 at 3:03 AM, Manish Chopra <manish.cho...@qlogic.com>
>> wrote:
>> > Hi,
>> >
>> > Detailed Description :
>> >
>> > I am trying to test VXLAN with OVS bridge with L2 driver. With OVS
>> > release version [2.4.0] package VXLAN udp port configuration is not
>> > notified to L2 driver
>> >
>> > via ndo_add_vxlan_port interface. Due to this hardware is not able to
>> > do offload of features [like checksum etc.], Hence TCP/IP traffic with
>> > encapsulated offload enabled on NIC is not working.
>>
>> You mean offloads aren't being performed and therefore things are slower than
>> if it was done in hardware or traffic doesn't flow?
>> Offloads should never be mandatory.
>>
>> What is the base kernel version?
>
> Traffic doesn't flow at all. Our hardware is supportive for encap offloads 
> only when UDP port is configured on hardware.
>
> We claim to support below features for encapsulation  -
> ndev->hw_enc_features = NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM

I believe that the correctness issue is actually in the driver. You
can't assume that encapsulation means VXLAN or that the port will be
registered. There are other protocols that set this and there are also
other sources for offloaded encapsulation packets, such as VMs. You're
going to have to do some filtering of offloads in ndo_features_check
to support this hardware.

That being said, there is a performance regression in OVS. Thomas, I
believe that this is a result of the GBP changes since that caused
kernels that previously supported receive offloads and GRO to use the
compat code, which doesn't support them. Would you mind taking a look?
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] [OVS v2.4.0] - VXLAN UDP port configuration is not notified to L2 driver/interface.

[Jesse Gross]

On Wed, Sep 9, 2015 at 3:03 AM, Manish Chopra  wrote:
> Hi,
>
> Detailed Description :
>
> I am trying to test VXLAN with OVS bridge with L2 driver. With OVS release
> version [2.4.0] package VXLAN udp port configuration is not notified to L2
> driver
>
> via ndo_add_vxlan_port interface. Due to this hardware is not able to do
> offload of features [like checksum etc.], Hence TCP/IP traffic with
> encapsulated offload enabled on NIC is not working.

You mean offloads aren't being performed and therefore things are
slower than if it was done in hardware or traffic doesn't flow?
Offloads should never be mandatory.

What is the base kernel version?
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Forward VxLAN packets in network namespace?

[Jesse Gross]

On Monday, September 7, 2015, Xiao Liang (xiaolia) <xiao...@cisco.com>
wrote:

>
> > -Original Message-
> > From: Jesse Gross [mailto:je...@nicira.com <javascript:;>]
> > Sent: Monday, September 07, 2015 21:55
> > To: Xiao Liang (xiaolia)
> > Cc: discuss@openvswitch.org <javascript:;>
> > Subject: Re: [ovs-discuss] Forward VxLAN packets in network namespace?
> >
> > On Monday, September 7, 2015, Xiao Liang (xiaolia) <xiao...@cisco.com
> <javascript:;>>
> > wrote:
> >
> >
> >   Hi,
> >
> >   The problem is that I want to add a VxLAN port to OVS bridge and
> let
> > the tunnel packets be routed in a particular netns.
> >
> >   In VxLAN vport code I found that the namespace of the tunnel sock
> is
> > inherited from dp. I could add a dp by "ip netns exec ns1 ovs-dpctl
> add-dp
> > br1", but how can I use it then? I've also tried "ip netns exec ns1
> ovs-vsctl
> > add-br br1" and "ip link set br1 netns ns1", but seems not work.
> >
> >
> >
> > You can only change the namespace of OVS as whole. To do that you, you
> > should start ovs-vswitchd in that namespace. If you want to route tunnel
> > packets to a different namespace, you'll have to do that through the
> routing
> > table.
>
> Thanks! If I start multiple ovs-vswitchd each in a different namespace,
> need I also start multiple ovsdb?
>
>
Yes, since they are operating as independent switches.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Forward VxLAN packets in network namespace?

[Jesse Gross]

On Monday, September 7, 2015, Xiao Liang (xiaolia) 
wrote:

> Hi,
>
> The problem is that I want to add a VxLAN port to OVS bridge and let the
> tunnel packets be routed in a particular netns.
>
> In VxLAN vport code I found that the namespace of the tunnel sock is
> inherited from dp. I could add a dp by "ip netns exec ns1 ovs-dpctl add-dp
> br1", but how can I use it then? I've also tried "ip netns exec ns1
> ovs-vsctl add-br br1" and "ip link set br1 netns ns1", but seems not work.
>

You can only change the namespace of OVS as whole. To do that you, you
should start ovs-vswitchd in that namespace. If you want to route tunnel
packets to a different namespace, you'll have to do that through the
routing table.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Build issues on linux kernel version 2.6.32-573.3.1 RHEL6

[Jesse Gross]

On Friday, September 4, 2015, Tashi Lu  wrote:

> Hi Jesse, thanks for your reply. Building from repo eliminated the compile
> error, but there are still two minor errors in the build process, I fixed
> them and submitted a pull request on Github
> https://github.com/openvswitch/ovs/pull/65. Hope it will help.
>

Would you mind posting them as patches to the dev mailing list? My guess is
more people will look at them at way.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Build issues on linux kernel version 2.6.32-573.3.1 RHEL6

[Jesse Gross]

On Thu, Sep 3, 2015 at 3:00 AM, Tashi Lu  wrote:
> Hi all,
>
> Seems there're some issues with linux kernel version 2.6.32-573.3.1, I've
> tried to build both ovs 2.3.2 and 2.4.0 on both CentOS 6.4 and CentOS 6.6,
> all ended with errors shown below.

A number of fixes for CentOS 6 were just applied to branch-2.4 in git,
so I would recommend trying that to see if that solves the issue.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Preserve vxlan headers when sending to a non-vxlan port on bridge?

[Jesse Gross]

On Fri, Aug 21, 2015 at 7:24 PM, Sam Hague sha...@gmail.com wrote:
 On Fri, Aug 21, 2015 at 8:57 PM, Jesse Gross je...@nicira.com wrote:
 On Thu, Aug 20, 2015 at 1:58 PM, Sam Hague sha...@gmail.com wrote:
  On Thu, Aug 20, 2015 at 1:32 PM, Jesse Gross je...@nicira.com wrote:
  On Thu, Aug 20, 2015 at 8:20 AM, Sam Hague sha...@gmail.com wrote:
   Is it possible to send vxlan encapsulated packets to a bridge port
   and
   keep
   the vxlan headers?
 
  It's not possible unless you don't terminate the tunnels, in which
  case you can't match on anything in the header.
 
 
  Is the only way to add vxlan headers by sending a packet out a vxlan
  port -
  whether the key/srcip/dstip are port or flow-based?

 Yes.

  Is there any way to overload the vm port such that if I sent a vxlan
  packet froma normal vxlan port on the bridge it could come back into the
  bridge and to that vm port such that the vm would terminate the tunnel?
 
  The use case is for the typical openstack setup where the VMs are ports
  hanging off the bridge and flows are added to simply push normal l2-l4
  packets to the port. But I would like to terminate vxlan inside the VM
  itself but under this constraint that is was OpenStack that instantiated
  the
  VM in the way it typically does.
 
  So I could see adding some flows to send a vxlan packet out a port on
  the
  bridge, and somehow getting it to come back into the bridge and not have
  the
  header stripped. Typically those VM addresses are internal addresses
  which
  the host wouldn't know about so if I sent a vxlan out a bridge port, the
  network stack wouldn't send it back.

 Presumably, in this case the destination IP address is owned by the
 hypervisor. In that case, the hypervisor IP stack is going to consume
 the packet regardless of what the OVS or VXLAN configuration is. The
 only way around that is either to actually address packets to the VM
 (either on the remote side or by re-encapsulating the packet locally)
 or hack together some rules to prevent the hypervisor IP stack from
 seeing the packet altogether, likely using NAT.


 Yeah, was hoping I could find the trickery to get around this. I assigned IP
 addresses to the two bridges and used those address as the src/dst for the
 vxlan tunnel - without adding a vxlan port on the destination bridge,
 thinking maybe it would sneak into the bridge as a l3 packet. But looks like
 somewhere in the stack the packet was identified as vxlan and got into OVS
 and OVS dropped it.

Yes, as I said before, this is not specific to OVS or VXLAN. You can't
expect to send a packet destined to the local host's IP address and
expect the stack not to consume it. If there is no VXLAN listener, it
still won't get forwarded - you'll get an ICMP unreachable message.

Fundamentally, there are two communication paths here: remote vSwitch
to local vSwitch and local vSwitch to VM. I think you need to actually
model it this way rather than as forwarding, otherwise you will be
forever running into addressing problems.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] openvswitch install on centos 6.6 issue

[Jesse Gross]

Flavio, there's been a few reports of compilation problems on
RHEL/Centos 6. Would it be possible for you to take a look?

On Fri, Aug 21, 2015 at 12:09 PM, Gurucharan Shetty shet...@nicira.com wrote:
 Okay, then I was wrong about branch 2.4 supporting Centos 6.6. I have
 CC'd a couple of Kernel developers that will know the correct answer.

 On Fri, Aug 21, 2015 at 12:03 PM, ShapeHost cont...@shape.host wrote:
 Hello,

 Thanks for the information, i tested the new 2.4. and i have the same
 problem. :(

 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:987:
 warning: type defaults to 'int' in declaration of 'type name'
 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:987:
 error: invalid type argument of 'unary *' (have 'int')
 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:987:
 warning: type defaults to 'int' in declaration of 'ret__'
 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:987:
 warning: type defaults to 'int' in declaration of 'type name'
 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:987:
 error: invalid type argument of 'unary *' (have 'int')
 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:987:
 warning: type defaults to 'int' in declaration of 'ret__'
 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:987:
 warning: type defaults to 'int' in declaration of 'type name'
 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:987:
 error: invalid type argument of 'unary *' (have 'int')
 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:999:
 warning: type defaults to 'int' in declaration of 'type name'
 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:999:
 error: invalid type argument of 'unary *' (have 'int')
 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:999:
 warning: type defaults to 'int' in declaration of 'type name'
 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:999:
 error: invalid type argument of 'unary *' (have 'int')
 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:999:
 warning: type defaults to 'int' in declaration of 'type name'
 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:999:
 error: invalid type argument of 'unary *' (have 'int')
 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:999:
 warning: type defaults to 'int' in declaration of 'type name'
 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:999:
 error: invalid type argument of 'unary *' (have 'int')
 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:1006:
 warning: type defaults to 'int' in declaration of 'type name'
 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:1006:
 error: invalid type argument of 'unary *' (have 'int')
 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:1006:
 warning: type defaults to 'int' in declaration of 'type name'
 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:1006:
 warning: type defaults to 'int' in declaration of 'type name'
 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:1006:
 error: invalid type argument of 'unary *' (have 'int')
 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:1006:
 warning: type defaults to 'int' in declaration of 'type name'
 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:1006:
 warning: type defaults to 'int' in declaration of 'type name'
 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:1006:
 error: invalid type argument of 'unary *' (have 'int')
 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:1006:
 warning: type defaults to 'int' in declaration of 'type name'
 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:1006:
 warning: type defaults to 'int' in declaration of 'type name'
 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:1006:
 error: invalid type argument of 'unary *' (have 'int')
 /root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.c:1006:
 warning: type defaults to 'int' in declaration of 'type name'
 make[2]: ***
 [/root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/datapath.o]
 Error 1
 make[2]: ***
 [/root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/actions.o]
 Error 1
 make[2]: ***
 [/root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/vport-internal_dev.o]
 Error 1
 make[2]: ***
 [/root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/flow_table.o]
 Error 1
 make[2]: ***
 [/root/rpmbuild/BUILD/openvswitch-2.4.0/_default/datapath/linux/flow_netlink.o]
 Error 1
 make[2]: ***
 

Re: [ovs-discuss] [ovs-announce] Open vSwitch 2.4.0 Available

[Jesse Gross]

On Saturday, August 22, 2015, Vasiliy Tolstov v.tols...@selfip.ru wrote:

 2015-08-21 20:51 GMT+03:00 Justin Pettit jpet...@nicira.com
 javascript:;:
  The Open vSwitch team is pleased to announce the release of Open vSwitch
 2.4.0:
 
 http://openvswitch.org/releases/openvswitch-2.4.0.tar.gz
 
  This release contains the largest number of new features of an Open
 vSwitch release.  A few feature highlights of 2.4.0 include:


 Very good job! Thanks! What is the status of ipv6 tunneling support
 for current ovs master ?


There is work going on but no code is checked in yet.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Preserve vxlan headers when sending to a non-vxlan port on bridge?

[Jesse Gross]

On Thu, Aug 20, 2015 at 8:20 AM, Sam Hague sha...@gmail.com wrote:
 Is it possible to send vxlan encapsulated packets to a bridge port and keep
 the vxlan headers?

It's not possible unless you don't terminate the tunnels, in which
case you can't match on anything in the header.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Deep Packet Inspection possible?

[Jesse Gross]

On Fri, Aug 14, 2015 at 5:29 PM, Dave Waters davewaters1...@gmail.com wrote:
 I took a look at P4 and i thought it was primarily for HW devices. Let me
 see how i can use that with OVS.

 Can you give me the function in the code that i could start looking at if i
 want to make custom changes to deep inspect the packet in OVS. Some starting
 point would help.

From the FAQ:

### Q: How do I add support for a new field or header?

A: Add new members for your field to struct flow in lib/flow.h, and
   add new enumerations for your new field to enum mf_field_id in
   lib/meta-flow.h, following the existing pattern.  Also, add support
   to miniflow_extract() in lib/flow.c for extracting your new field
   from a packet into struct miniflow.  Then recompile and fix all of
   the new warnings, implementing new functionality for the new field
   or header as needed.  (If you configure with --enable-Werror, as
   described in [INSTALL.md], then it is impossible to miss any
   warnings.)

   If you want kernel datapath support for your new field, you also
   need to modify the kernel module for the operating systems you are
   interested in.  This isn't mandatory, since fields understood only
   by userspace work too (with a performance penalty), so it's
   reasonable to start development without it.  If you implement
   kernel module support for Linux, then the Linux kernel netdev
   mailing list is the place to submit that support first; please read
   up on the Linux kernel development process separately.  The Windows
   datapath kernel module support, on the other hand, is maintained
   within the OVS tree, so patches for that can go directly to
   ovs-dev.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Questions about Openvswitch on FreeBSD 10.1 Release

[Jesse Gross]

On Tue, Aug 11, 2015 at 11:16 PM, 1214781...@qq.com 1214781...@qq.com wrote:
 Hello:
 Sorry for bothering you, but I got a strange bug while trying to build a GRE
 tunnel using Openvswitch between 2 virtual machines based on KVM. The OS of
 2 virtual machines are FreeBSD 10.1 Release, and the host OS is CentOS 6.3,
 Openvswitch version 2.3.2 on virtual machines. I’ll describe my bug in the
 following paragraphs.

 INSTALLATION: I checked all the optional modules while installing FreeBSD,
 and installed openvswitch 2.3.2 by typing “pkg install openvswitch” into
 FreeBSD’s console, then “pkg install python” because the console said some
 additional modules needs to be installed (2KB).

 CONFIGURATION:
 1) “rm -f /var/db/openvswitch/conf.db”
 2) “ovsdb-tool create /var/db/openvswitch/conf.db
 /usr/local/share/openvswitch/vswitch.ovsschema”
 3) “ovsdb-server --remote=punix:/var/run/openvswitch/db.sock
 --remote=db.Open_vSwitch,manager_options --pidfile --detach”
 4) “ovs-vsctl --no-wait init”
 5) “ova-vswichd --pidfile --detach —mlockall
 NO ERROR during the procedures above.

 THEN COMES THE BUG: When I try to add a bridge “ovs-vsctl add-br br0, it
 said: ovs-vsctl: Error detected while setting up 'br0'.  See ovs-vswitchd
 log for details.” Then i tried “ovs-vswitchd log”:

 2015-08-11T05:48:55Z|1|reconnect|INFO|log: connecting...
 2015-08-11T05:48:55Z|2|reconnect|INFO|log: connection attempt failed
 (Address family not supported by protocol family)
 2015-08-11T05:48:55Z|3|reconnect|INFO|log: waiting 1 seconds before
 reconnect

Tunnels, including GRE, are currently only supported on Linux.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss