Connecting OVS Bridges with Patch Ports

Spurred to action by a brief mention at the bottom of a blog post, I began digging into the use of patch ports to connect multiple Open vSwitch (OVS) bridges. In this post, I’ll show you how to connect two separate OVS bridges using a patch port, and then we’ll explore some possible use cases for this functionality.

You’ve seen me use the ovs-vsctl set interface <interface name> type=... syntax several times; I provided some insight on what it’s doing in this post. Basically, what we’re doing with this command is manipulating the OVS configuration database. This is how we configure internal interfaces that can be plumbed with an IP address (for use in Layer 3 routing with OVS). In this article, we’re going to use this command again, but this time we’re going to set type=patch.

I’d not seen any references to patch ports before before running into this blog post, where patch ports receive a brief mention at the end of the article. So, I did a little digging, and finally found the manpage for the OVS configuration database (visible by running man 5 ovs-vswitchd.conf.db from a system with OVS installed). In that manpage, it describes patch ports as “a pair of virtual devices that act as a patch cable.” A patch port only has a single option, and that single option is the name of the patch port at the opposite end.

Graphically, you can think of patch ports like this:

To create a patch port, it’s quite easy. This group of commands will create a patch port:

You would repeat these commands for each bridge you want connected to another bridge. To connect two bridges, you would repeat them twice—once for the first bridge (specifying the patch port on the 2nd bridge as the peer), and again for the second bridge (specifying the patch port on the 1st bridge as the peer). Or, as the manpage puts it:

That is, the two patch interfaces must have reversed name and peer values.

Once you’ve run through the commands, running ovs-vsctl show will reveal a configuration that would look something like this (obviously your bridge names, port names, and interface names will vary):

Let’s review this a bit:

  • The bridge ovsbr2 contains a port and interface named patch2-0, with a peer set to patch0-2. Note that ovsbr2 has no physical uplinks.
  • Likewise, the bridge ovsbr0 has a port and interface named patch0-2, whose type is patch and whose peer is set to patch2-0. Note that, just as the manpage stated, the two patch ports have reversed name and peer values—this creates the connection between the two bridges. This bridge has a bond with two interfaces that take it to the outside world.

With this configuration, I can start up a guest domain attached to ovsbr2—which has no physical uplinks—and gain connectivity to the outside world via the patch ports that connect it to ovsbr0 and its uplinks.

The next natural question (at least, it was the next natural question for me): how many levels of connected OVS bridges can you build? It turns out the answer is 5 (as described here).

OK, this is interesting (sort of), but what sort of uses does this have? Well, I’m still exploring that myself, and I’d love to hear from readers as to how they might see this functionality utilized. Here are two examples of which I know:

  • In the original post that sparked this work, the author used a separate OVS bridge (or datapath) for OpenFlow testing. So, one bridge that had no uplinks was connected to an OpenFlow controller and had a patch port to an externally-connected bridge. Thus, he could perform OpenFlow testing with some guests, while leaving other guests (on the other bridge) unaffected.
  • One other use case I saw was around XenServer integration. (I apologize but I can’t find the link where I saw it now—if any readers have it, please share it in the comments.) Basically, patch ports were used to connect an integration bridge that is manipulated/managed by XenServer to an external bridge that managed all the connectivity to the outside world. This is similar to the first example, but in this case it’s not OpenFlow that’s involved but XenServer instead.

I’ve racked my brain for other potential use cases, but they seem to be escaping me at the moment. If you have other use cases, feel free to share them in the comments. Likewise, if there are technical errors or corrections, please share those in the comments as well. Courteous comments are always welcome and encouraged.

Tags: , , ,

  1. Alex’s avatar

    Great article, and brilliant timing for me as I’m currently building an openstack environment on a hosted dedicated server which only has a single link. I’m currently struggling as when I configure this link into ovs I loose connectivity and have to bounce the host. Do you know if there’s any creative way this can be used to configure and ovs-br to connect to a traditional Linux bridge? I’ve tried using the veth module but it’s having issues forwarding arps (I’m going to be looking at working around that later)



  2. can.’s avatar

    Excellent! I think with this method I can create nearly any kind of topology inside a single machine and do some emulation or something. This is the virtualization for network, a great leap from just “virtual machines”.

  3. Pradeep’s avatar

    Excellent post. What are the other options that are available under “type=”? I didn’t find much in the ovs-vsctl manpage apart from “gre” and “internal”

  4. slowe’s avatar

    Alex, I don’t know if you could use this functionality to connect OVS to a traditional Linux bridge, although I strongly suspect that using patch ports would NOT work (patch ports are specific to OVS).

    Pradeep, if you have a look at the man page for ovs-vswitchd.conf.db (the OVS database), it lays out the different types of interfaces that are supported by OVS.

  5. Nico’s avatar

    Hi, thanks for a great post! It helped me;
    perhaps the link you couldn’t recall is this? — they talk about XenServer integration there

  6. Vikash’s avatar


    Patch ports are used in openstack networking. U can look to details in openstack site.

  7. Kumara Swamy’s avatar

    This use case is related to OpenFlow datapaths is as follows:
    * Add two logical OpenFlow switches say dp1 and dp2 in a OpenFlow physical switch.
    * Program dp1 as L2 bridge for L2 forwarding and dp2 as Router for L3 forwarding.
    * dp1 is attached with two lan ports and a patch port.
    * Two lan ports connected to LANs of same subnet.
    * dp2 is attached to a interface which is connected to external world.
    * Patch dp1 and dp2 with a pair of patch ports.
    * If receive a packet to dp1 through one of its port and destined to external
    world then that should be forwarded through dp2 which programmed as
    router. This can be done by forwarding the packet on patch port.
    * Thus the packet will be received by dp2 which will be forwarded to the external world through its l3 interface.


Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>