Ask Your Question

Revision history [back]

You wrote "I am hypothesizing that perhaps the patch port is just a configuration construct to tell the OVS kernel module that the ports on two OVS bridges are connected. "
See:-
http://blog.scottlowe.org/2012/11/27/connecting-ovs-bridges-with-patch-ports/

You wrote "I am hypothesizing that perhaps the patch port is just a configuration construct to tell the OVS kernel module that the ports on two OVS bridges are connected. "
See:-
http://blog.scottlowe.org/2012/11/27/connecting-ovs-bridges-with-patch-ports/
Per https://github.com/openvswitch/ovs/blob/master/FAQ.md

Are all features available with all datapaths?
A: Open vSwitch supports different datapaths on different platforms. Each datapath has a different feature set: the following tables try to summarize the status.
Supported datapaths:
1. Linux upstream: The datapath implemented by the kernel module shipped with Linux upstream. Since features have been gradually introduced into the kernel, the table mentions the first Linux release whose OVS module supports the feature.
2. Linux OVS tree: The datapath implemented by the Linux kernel module distributed with the OVS source tree. Some features of this module rely on functionality not available in older kernels: in this case the minumum Linux version (against which the feature can be compiled) is listed.
3.Userspace: Also known as DPDK, dpif-netdev or dummy datapath. It is the only datapath that works on NetBSD and FreeBSD.
4. Hyper-V: Also known as the Windows datapath.

image description

You wrote "I am hypothesizing that perhaps the patch port is just a configuration construct to tell the OVS kernel module that the ports on two OVS bridges are connected. "
See:-
http://blog.scottlowe.org/2012/11/27/connecting-ovs-bridges-with-patch-ports/
Per https://github.com/openvswitch/ovs/blob/master/FAQ.md

Are all features available with all datapaths?
A: Open vSwitch supports different datapaths on different platforms. Each datapath has a different feature set: the following tables try to summarize the status.
Supported datapaths:
1. Linux upstream: The datapath implemented by the kernel module shipped with Linux upstream. Since features have been gradually introduced into the kernel, the table mentions the first Linux release whose OVS module supports the feature.
2. Linux OVS tree: The datapath implemented by the Linux kernel module distributed with the OVS source tree. Some features of this module rely on functionality not available in older kernels: in this case the minumum Linux version (against which the feature can be compiled) is listed.
3.Userspace: Also known as DPDK, dpif-netdev or dummy datapath. It is the only datapath that works on NetBSD and FreeBSD.
4. Hyper-V: Also known as the Windows datapath.

image description
Per http://openvswitch.org/pipermail/discuss/2014-August/014686.html

> Looking at the log file (ovs-vswitchd.log below), it seems that Open vSwitch
> is looking for the kernel module to be loaded. Does this mean that userspace
> open vSwitch does not support VXLAN functionality?
Yes, that's correct. Only the Linux kernel datapath supports tunneling.

You wrote "I am hypothesizing that perhaps the patch port is just a configuration construct to tell the OVS kernel module that the ports on two OVS bridges are connected. "
See:-
http://blog.scottlowe.org/2012/11/27/connecting-ovs-bridges-with-patch-ports/
Per https://github.com/openvswitch/ovs/blob/master/FAQ.md

Are all features available with all datapaths?
A: Open vSwitch supports different datapaths on different platforms. Each datapath has a different feature set: the following tables try to summarize the status.
Supported datapaths:
1. Linux upstream: The datapath implemented by the kernel module shipped with Linux upstream. Since features have been gradually introduced into the kernel, the table mentions the first Linux release whose OVS module supports the feature.
2. Linux OVS tree: The datapath implemented by the Linux kernel module distributed with the OVS source tree. Some features of this module rely on functionality not available in older kernels: in this case the minumum Linux version (against which the feature can be compiled) is listed.
3.Userspace: Also known as DPDK, dpif-netdev or dummy datapath. It is the only datapath that works on NetBSD and FreeBSD.
4. Hyper-V: Also known as the Windows datapath.

image descriptionSee table right down in original document
Per http://openvswitch.org/pipermail/discuss/2014-August/014686.html

> Looking at the log file (ovs-vswitchd.log below), it seems that Open vSwitch
> is looking for the kernel module to be loaded. Does this mean that userspace
> open vSwitch does not support VXLAN functionality?
Yes, that's correct. Only the Linux kernel datapath supports tunneling.

So in picture bellow (Snapshot on RDO Kilo Controller/Network )

  Bridge br-int
        fail_mode: secure
        Port int-br-ex
            Interface int-br-ex
                type: patch
                options: {peer=phy-br-ex}
        Port "tap7107e523-3c"
            tag: 1
            Interface "tap7107e523-3c"
                type: internal
        Port "qr-5181525f-08"
            tag: 1
            Interface "qr-5181525f-08"
                type: internal
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
        Port br-int
            Interface br-int
                type: internal
    Bridge br-tun
        fail_mode: secure
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
        Port "vxlan-0c000089"
            Interface "vxlan-0c000089"
                type: vxlan
                options: {df_default="true", in_key=flow, local_ip="12.0.0.127", out_key=flow, remote_ip="12.0.0.137"}
        Port br-tun
            Interface br-tun
                type: internal
        Port "vxlan-0c00009d"
            Interface "vxlan-0c00009d"
                type: vxlan
                options: {df_default="true", in_key=flow, local_ip="12.0.0.127", out_key=flow, remote_ip="12.0.0.157"}
    ovs_version: "2.3.1"

So , Openstack Kilo (LIberty) with ML2&OVS&VXLAN setup is using kernel datapath
BR-TUN is connected to BR-INT via {patch-int,patch-tun} and vice/versa

You wrote "I am hypothesizing that perhaps the patch port is just a configuration construct to tell the OVS kernel module that the ports on two OVS bridges are connected. "
See:-
http://blog.scottlowe.org/2012/11/27/connecting-ovs-bridges-with-patch-ports/
Per https://github.com/openvswitch/ovs/blob/master/FAQ.md

Are all features available with all datapaths?
A: Open vSwitch supports different datapaths on different platforms. Each datapath has a different feature set: the following tables try to summarize the status.
Supported datapaths:
1. Linux upstream: The datapath implemented by the kernel module shipped with Linux upstream. Since features have been gradually introduced into the kernel, the table mentions the first Linux release whose OVS module supports the feature.
2. Linux OVS tree: The datapath implemented by the Linux kernel module distributed with the OVS source tree. Some features of this module rely on functionality not available in older kernels: in this case the minumum Linux version (against which the feature can be compiled) is listed.
3.Userspace: Also known as DPDK, dpif-netdev or dummy datapath. It is the only datapath that works on NetBSD and FreeBSD.
4. Hyper-V: Also known as the Windows datapath.

See table right down in original document
Per http://openvswitch.org/pipermail/discuss/2014-August/014686.html

> Looking at the log file (ovs-vswitchd.log below), it seems that Open vSwitch
> is looking for the kernel module to be loaded. Does this mean that userspace
> open vSwitch does not support VXLAN functionality?
Yes, that's correct. Only the Linux kernel datapath supports tunneling.

So in picture bellow (Snapshot on RDO Kilo Controller/Network )

  Bridge br-int
        fail_mode: secure
        Port int-br-ex
            Interface int-br-ex
                type: patch
                options: {peer=phy-br-ex}
        Port "tap7107e523-3c"
            tag: 1
            Interface "tap7107e523-3c"
                type: internal
        Port "qr-5181525f-08"
            tag: 1
            Interface "qr-5181525f-08"
                type: internal
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
        Port br-int
            Interface br-int
                type: internal
    Bridge br-tun
        fail_mode: secure
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
        Port "vxlan-0c000089"
            Interface "vxlan-0c000089"
                type: vxlan
                options: {df_default="true", in_key=flow, local_ip="12.0.0.127", out_key=flow, remote_ip="12.0.0.137"}
        Port br-tun
            Interface br-tun
                type: internal
        Port "vxlan-0c00009d"
            Interface "vxlan-0c00009d"
                type: vxlan
                options: {df_default="true", in_key=flow, local_ip="12.0.0.127", out_key=flow, remote_ip="12.0.0.157"}
    ovs_version: "2.3.1"

So , Openstack Kilo (LIberty) with ML2&OVS&VXLAN setup is using kernel datapath
BR-TUN is connected to BR-INT via {patch-int,patch-tun} and vice/versa

My guess is that flow patch-tun => patch-int (vice/versa) is using kernel data-path as well

UPDATE MSK 22:13 01/17/2015

Starting in version 1.9, OVS switched to using a single datapath that is shared by all bridges of that type
Due to Openstack Kilo (LIberty) with ML2&OVS&VXLAN setup is using kernel datapath. Network flow patch-tun => patch-int  and vice/versa is using kernel datapath as well

END UPDATE

You wrote "I am hypothesizing that perhaps the patch port is just a configuration construct to tell the OVS kernel module that the ports on two OVS bridges are connected. "
See:-
http://blog.scottlowe.org/2012/11/27/connecting-ovs-bridges-with-patch-ports/
Per https://github.com/openvswitch/ovs/blob/master/FAQ.md

Are all features available with all datapaths?
A: Open vSwitch supports different datapaths on different platforms. Each datapath has a different feature set: the following tables try to summarize the status.
Supported datapaths:
1. Linux upstream: The datapath implemented by the kernel module shipped with Linux upstream. Since features have been gradually introduced into the kernel, the table mentions the first Linux release whose OVS module supports the feature.
2. Linux OVS tree: The datapath implemented by the Linux kernel module distributed with the OVS source tree. Some features of this module rely on functionality not available in older kernels: in this case the minumum Linux version (against which the feature can be compiled) is listed.
3.Userspace: Also known as DPDK, dpif-netdev or dummy datapath. It is the only datapath that works on NetBSD and FreeBSD.
4. Hyper-V: Also known as the Windows datapath.

See table right down in original document
Per http://openvswitch.org/pipermail/discuss/2014-August/014686.html

> Looking at the log file (ovs-vswitchd.log below), it seems that Open vSwitch
> is looking for the kernel module to be loaded. Does this mean that userspace
> open vSwitch does not support VXLAN functionality?
Yes, that's correct. Only the Linux kernel datapath supports tunneling.

So in picture bellow (Snapshot on RDO Kilo Controller/Network )

  Bridge br-int
        fail_mode: secure
        Port int-br-ex
            Interface int-br-ex
                type: patch
                options: {peer=phy-br-ex}
        Port "tap7107e523-3c"
            tag: 1
            Interface "tap7107e523-3c"
                type: internal
        Port "qr-5181525f-08"
            tag: 1
            Interface "qr-5181525f-08"
                type: internal
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
        Port br-int
            Interface br-int
                type: internal
    Bridge br-tun
        fail_mode: secure
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
        Port "vxlan-0c000089"
            Interface "vxlan-0c000089"
                type: vxlan
                options: {df_default="true", in_key=flow, local_ip="12.0.0.127", out_key=flow, remote_ip="12.0.0.137"}
        Port br-tun
            Interface br-tun
                type: internal
        Port "vxlan-0c00009d"
            Interface "vxlan-0c00009d"
                type: vxlan
                options: {df_default="true", in_key=flow, local_ip="12.0.0.127", out_key=flow, remote_ip="12.0.0.157"}
    ovs_version: "2.3.1"

So , Openstack Kilo (LIberty) with ML2&OVS&VXLAN setup is using kernel datapath
BR-TUN is connected to BR-INT via {patch-int,patch-tun} and vice/versa

My guess is that flow patch-tun => patch-int (vice/versa) is using kernel data-path as well

UPDATE MSK 22:13 22:25 01/17/2015

Starting in version 1.9, OVS switched to using a single datapath that is shared by all bridges of that type
 Due to Openstack Kilo (LIberty) with ML2&OVS&VXLAN setup is using kernel datapath. reference http://textuploader.com/5zk6a
Network flow patch-tun => patch-int and vice/versa is using kernel datapath as well

datapath.
END UPDATE

You wrote "I am hypothesizing that perhaps the patch port is just a configuration construct to tell the OVS kernel module that the ports on two OVS bridges are connected. "
See:-
http://blog.scottlowe.org/2012/11/27/connecting-ovs-bridges-with-patch-ports/
Per https://github.com/openvswitch/ovs/blob/master/FAQ.md

Are all features available with all datapaths?
A: Open vSwitch supports different datapaths on different platforms. Each datapath has a different feature set: the following tables try to summarize the status.
Supported datapaths:
1. Linux upstream: The datapath implemented by the kernel module shipped with Linux upstream. Since features have been gradually introduced into the kernel, the table mentions the first Linux release whose OVS module supports the feature.
2. Linux OVS tree: The datapath implemented by the Linux kernel module distributed with the OVS source tree. Some features of this module rely on functionality not available in older kernels: in this case the minumum Linux version (against which the feature can be compiled) is listed.
3.Userspace: Also known as DPDK, dpif-netdev or dummy datapath. It is the only datapath that works on NetBSD and FreeBSD.
4. Hyper-V: Also known as the Windows datapath.

See table right down in original document
Per http://openvswitch.org/pipermail/discuss/2014-August/014686.html

> Looking at the log file (ovs-vswitchd.log below), it seems that Open vSwitch
> is looking for the kernel module to be loaded. Does this mean that userspace
> open vSwitch does not support VXLAN functionality?
Yes, that's correct. Only the Linux kernel datapath supports tunneling.

So in picture bellow (Snapshot on RDO Kilo Controller/Network )

  Bridge br-int
        fail_mode: secure
        Port int-br-ex
            Interface int-br-ex
                type: patch
                options: {peer=phy-br-ex}
        Port "tap7107e523-3c"
            tag: 1
            Interface "tap7107e523-3c"
                type: internal
        Port "qr-5181525f-08"
            tag: 1
            Interface "qr-5181525f-08"
                type: internal
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
        Port br-int
            Interface br-int
                type: internal
    Bridge br-tun
        fail_mode: secure
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
        Port "vxlan-0c000089"
            Interface "vxlan-0c000089"
                type: vxlan
                options: {df_default="true", in_key=flow, local_ip="12.0.0.127", out_key=flow, remote_ip="12.0.0.137"}
        Port br-tun
            Interface br-tun
                type: internal
        Port "vxlan-0c00009d"
            Interface "vxlan-0c00009d"
                type: vxlan
                options: {df_default="true", in_key=flow, local_ip="12.0.0.127", out_key=flow, remote_ip="12.0.0.157"}
    ovs_version: "2.3.1"

So , Openstack Kilo (LIberty) with ML2&OVS&VXLAN setup is using kernel datapath
BR-TUN is connected to BR-INT via {patch-int,patch-tun} and vice/versa

My guess is that flow patch-tun => patch-int (vice/versa) is using kernel data-path as well