FAQ

   1                  Open vSwitch <http://openvswitch.org>
   2
   3 Frequently Asked Questions
   4 ==========================
   5
   6 General
   7 -------
   8
   9 Q: What is Open vSwitch?
  10
  11 A: Open vSwitch is a production quality open source software switch
  12    designed to be used as a vswitch in virtualized server environments.  A
  13    vswitch forwards traffic between different VMs on the same physical host
  14    and also forwards traffic between VMs and the physical network.  Open
  15    vSwitch supports standard management interfaces (e.g. sFlow, NetFlow,
  16    RSPAN, CLI), and is open to programmatic extension and control using
  17    OpenFlow and the OVSDB management protocol.
  18
  19    Open vSwitch as designed to be compatible with modern switching
  20    chipsets.  This means that it can be ported to existing high-fanout
  21    switches allowing the same flexible control of the physical
  22    infrastructure as the virtual infrastructure.  It also means that
  23    Open vSwitch will be able to take advantage of on-NIC switching
  24    chipsets as their functionality matures.
  25
  26 Q: What virtualization platforms can use Open vSwitch?
  27
  28 A: Open vSwitch can currently run on any Linux-based virtualization
  29    platform (kernel 2.6.18 and newer), including: KVM, VirtualBox, Xen,
  30    Xen Cloud Platform, XenServer. As of Linux 3.3 it is part of the
  31    mainline kernel.  The bulk of the code is written in platform-
  32    independent C and is easily ported to other environments.  We welcome
  33    inquires about integrating Open vSwitch with other virtualization
  34    platforms.
  35
  36 Q: How can I try Open vSwitch?
  37
  38 A: The Open vSwitch source code can be built on a Linux system.  You can
  39    build and experiment with Open vSwitch on any Linux machine.
  40    Packages for various Linux distributions are available on many
  41    platforms, including: Debian, Ubuntu, Fedora.
  42
  43    You may also download and run a virtualization platform that already
  44    has Open vSwitch integrated.  For example, download a recent ISO for
  45    XenServer or Xen Cloud Platform.  Be aware that the version
  46    integrated with a particular platform may not be the most recent Open
  47    vSwitch release.
  48
  49 Q: Does Open vSwitch only work on Linux?
  50
  51 A: No, Open vSwitch has been ported to a number of different operating
  52    systems and hardware platforms.  Most of the development work occurs
  53    on Linux, but the code should be portable to any POSIX system.  We've
  54    seen Open vSwitch ported to a number of different platforms,
  55    including FreeBSD, Windows, and even non-POSIX embedded systems.
  56
  57    By definition, the Open vSwitch Linux kernel module only works on
  58    Linux and will provide the highest performance.  However, a userspace
  59    datapath is available that should be very portable.
  60
  61 Q: What's involved with porting Open vSwitch to a new platform or
  62    switching ASIC?
  63
  64 A: The PORTING document describes how one would go about porting Open
  65    vSwitch to a new operating system or hardware platform.
  66
  67 Q: Why would I use Open vSwitch instead of the Linux bridge?
  68
  69 A: Open vSwitch is specially designed to make it easier to manage VM
  70    network configuration and monitor state spread across many physical
  71    hosts in dynamic virtualized environments.  Please see WHY-OVS for a
  72    more detailed description of how Open vSwitch relates to the Linux
  73    Bridge.
  74
  75 Q: How is Open vSwitch related to distributed virtual switches like the
  76    VMware vNetwork distributed switch or the Cisco Nexus 1000V?
  77
  78 A: Distributed vswitch applications (e.g., VMware vNetwork distributed
  79    switch, Cisco Nexus 1000V) provide a centralized way to configure and
  80    monitor the network state of VMs that are spread across many physical
  81    hosts.  Open vSwitch is not a distributed vswitch itself, rather it
  82    runs on each physical host and supports remote management in a way
  83    that makes it easier for developers of virtualization/cloud
  84    management platforms to offer distributed vswitch capabilities.
  85
  86    To aid in distribution, Open vSwitch provides two open protocols that
  87    are specially designed for remote management in virtualized network
  88    environments: OpenFlow, which exposes flow-based forwarding state,
  89    and the OVSDB management protocol, which exposes switch port state.
  90    In addition to the switch implementation itself, Open vSwitch
  91    includes tools (ovs-controller, ovs-ofctl, ovs-vsctl) that developers
  92    can script and extend to provide distributed vswitch capabilities
  93    that are closely integrated with their virtualization management
  94    platform.
  95
  96 Q: Why doesn't Open vSwitch support distribution?
  97
  98 A: Open vSwitch is intended to be a useful component for building
  99    flexible network infrastructure. There are many different approaches
 100    to distribution which balance trade-offs between simplicity,
 101    scalability, hardware compatibility, convergence times, logical
 102    forwarding model, etc. The goal of Open vSwitch is to be able to
 103    support all as a primitive building block rather than choose a
 104    particular point in the distributed design space.
 105
 106 Q: How can I contribute to the Open vSwitch Community?
 107
 108 A: You can start by joining the mailing lists and helping to answer
 109    questions.  You can also suggest improvements to documentation.  If
 110    you have a feature or bug you would like to work on, send a mail to
 111    one of the mailing lists:
 112
 113        http://openvswitch.org/mlists/
 114
 115
 116
 117 Releases
 118 --------
 119
 120 Q: What does it mean for an Open vSwitch release to be LTS (long-term
 121    support)?
 122
 123 A: All official releases have been through a comprehensive testing
 124    process and are suitable for production use.  Planned releases will
 125    occur several times a year.  If a significant bug is identified in an
 126    LTS release, we will provide an updated release that includes the
 127    fix.  Releases that are not LTS may not be fixed and may just be
 128    supplanted by the next major release.  The current LTS release is
 129    1.4.x.
 130
 131 Q: What Linux kernel versions does each Open vSwitch release work with?
 132
 133 A: The following table lists the Linux kernel versions against which the
 134    given versions of the Open vSwitch kernel module will successfully
 135    build.  The Linux kernel versions are upstream kernel versions, so
 136    Linux kernels modified from the upstream sources may not build in
 137    some cases even if they are based on a supported version.  This is
 138    most notably true of Red Hat Enterprise Linux (RHEL) kernels, which
 139    are extensively modified from upstream.
 140
 141    Open vSwitch   Linux kernel
 142    ------------   -------------
 143        1.4.x      2.6.18 to 3.2
 144        1.5.x      2.6.18 to 3.2
 145        1.6.x      2.6.18 to 3.2
 146        1.7.x      2.6.18 to 3.3
 147        1.8.x      2.6.18 to 3.4
 148        1.9.x      2.6.18 to 3.7
 149
 150    Open vSwitch userspace should also work with the Linux kernel module
 151    built into Linux 3.3 and later.
 152
 153    Open vSwitch userspace is not sensitive to the Linux kernel version.
 154    It should build against almost any kernel, certainly against 2.6.18
 155    and later.
 156
 157 Q: What features are not available in the Open vSwitch kernel datapath
 158    that ships as part of the upstream Linux kernel?
 159
 160 A: The kernel module in upstream Linux 3.3 and later does not include
 161    the following features:
 162
 163        - Tunnel virtual ports, that is, interfaces with type "gre",
 164          "ipsec_gre", "capwap".  It is possible to create tunnels in
 165          Linux and attach them to Open vSwitch as system devices.
 166          However, they cannot be dynamically created through the OVSDB
 167          protocol or set the tunnel ids as a flow action.
 168
 169          Work is in progress in adding these features to the upstream
 170          Linux version of the Open vSwitch kernel module.  For now, if
 171          you need these features, use the kernel module from the Open
 172          vSwitch distribution instead of the upstream Linux kernel
 173          module.
 174
 175        - Patch virtual ports, that is, interfaces with type "patch".
 176          You can use Linux "veth" devices as a substitute.
 177
 178          We don't have any plans to add patch ports upstream.
 179
 180 Q: What features are not available when using the userspace datapath?
 181
 182 A: Tunnel and patch virtual ports are not supported, as described in the
 183    previous answer.  It is also not possible to use queue-related
 184    actions.  On Linux kernels before 2.6.39, maximum-sized VLAN packets
 185    may not be transmitted.
 186
 187
 188 Terminology
 189 -----------
 190
 191 Q: I thought Open vSwitch was a virtual Ethernet switch, but the
 192    documentation keeps talking about bridges.  What's a bridge?
 193
 194 A: In networking, the terms "bridge" and "switch" are synonyms.  Open
 195    vSwitch implements an Ethernet switch, which means that it is also
 196    an Ethernet bridge.
 197
 198 Q: What's a VLAN?
 199
 200 A: See the "VLAN" section below.
 201
 202
 203 Basic Configuration
 204 -------------------
 205
 206 Q: How do I configure a port as an access port?
 207
 208 A: Add "tag=VLAN" to your "ovs-vsctl add-port" command.  For example,
 209    the following commands configure br0 with eth0 as a trunk port (the
 210    default) and tap0 as an access port for VLAN 9:
 211
 212        ovs-vsctl add-br br0
 213        ovs-vsctl add-port br0 eth0
 214        ovs-vsctl add-port br0 tap0 tag=9
 215
 216    If you want to configure an already added port as an access port,
 217    use "ovs-vsctl set", e.g.:
 218
 219        ovs-vsctl set port tap0 tag=9
 220
 221 Q: How do I configure a port as a SPAN port, that is, enable mirroring
 222    of all traffic to that port?
 223
 224 A: The following commands configure br0 with eth0 and tap0 as trunk
 225    ports.  All traffic coming in or going out on eth0 or tap0 is also
 226    mirrored to tap1; any traffic arriving on tap1 is dropped:
 227
 228        ovs-vsctl add-br br0
 229        ovs-vsctl add-port br0 eth0
 230        ovs-vsctl add-port br0 tap0
 231        ovs-vsctl add-port br0 tap1 \
 232            -- --id=@p get port tap1 \
 233            -- --id=@m create mirror name=m0 select-all=true output-port=@p \
 234            -- set bridge br0 mirrors=@m
 235
 236    To later disable mirroring, run:
 237
 238        ovs-vsctl clear bridge br0 mirrors
 239
 240 Q: How do I configure a VLAN as an RSPAN VLAN, that is, enable
 241    mirroring of all traffic to that VLAN?
 242
 243 A: The following commands configure br0 with eth0 as a trunk port and
 244    tap0 as an access port for VLAN 10.  All traffic coming in or going
 245    out on tap0, as well as traffic coming in or going out on eth0 in
 246    VLAN 10, is also mirrored to VLAN 15 on eth0.  The original tag for
 247    VLAN 10, in cases where one is present, is dropped as part of
 248    mirroring:
 249
 250        ovs-vsctl add-br br0
 251        ovs-vsctl add-port br0 eth0
 252        ovs-vsctl add-port br0 tap0 tag=10
 253        ovs-vsctl \
 254            -- --id=@m create mirror name=m0 select-all=true select-vlan=10 \
 255                                     output-vlan=15 \
 256            -- set bridge br0 mirrors=@m
 257
 258    To later disable mirroring, run:
 259
 260        ovs-vsctl clear bridge br0 mirrors
 261
 262    Mirroring to a VLAN can disrupt a network that contains unmanaged
 263    switches.  See ovs-vswitchd.conf.db(5) for details.  Mirroring to a
 264    GRE tunnel has fewer caveats than mirroring to a VLAN and should
 265    generally be preferred.
 266
 267 Q: Can I mirror more than one input VLAN to an RSPAN VLAN?
 268
 269 A: Yes, but mirroring to a VLAN strips the original VLAN tag in favor
 270    of the specified output-vlan.  This loss of information may make
 271    the mirrored traffic too hard to interpret.
 272
 273    To mirror multiple VLANs, use the commands above, but specify a
 274    comma-separated list of VLANs as the value for select-vlan.  To
 275    mirror every VLAN, use the commands above, but omit select-vlan and
 276    its value entirely.
 277
 278    When a packet arrives on a VLAN that is used as a mirror output
 279    VLAN, the mirror is disregarded.  Instead, in standalone mode, OVS
 280    floods the packet across all the ports for which the mirror output
 281    VLAN is configured.  (If an OpenFlow controller is in use, then it
 282    can override this behavior through the flow table.)  If OVS is used
 283    as an intermediate switch, rather than an edge switch, this ensures
 284    that the RSPAN traffic is distributed through the network.
 285
 286    Mirroring to a VLAN can disrupt a network that contains unmanaged
 287    switches.  See ovs-vswitchd.conf.db(5) for details.  Mirroring to a
 288    GRE tunnel has fewer caveats than mirroring to a VLAN and should
 289    generally be preferred.
 290
 291 Q: How do I configure mirroring of all traffic to a GRE tunnel?
 292
 293 A: The following commands configure br0 with eth0 and tap0 as trunk
 294    ports.  All traffic coming in or going out on eth0 or tap0 is also
 295    mirrored to gre0, a GRE tunnel to the remote host 192.168.1.10; any
 296    traffic arriving on gre0 is dropped:
 297
 298        ovs-vsctl add-br br0
 299        ovs-vsctl add-port br0 eth0
 300        ovs-vsctl add-port br0 tap0
 301        ovs-vsctl add-port br0 gre0 \
 302            -- set interface gre0 type=gre options:remote_ip=192.168.1.10 \
 303            -- --id=@p get port gre0 \
 304            -- --id=@m create mirror name=m0 select-all=true output-port=@p \
 305            -- set bridge br0 mirrors=@m
 306
 307    To later disable mirroring and destroy the GRE tunnel:
 308
 309        ovs-vsctl clear bridge br0 mirrors
 310        ovs-vcstl del-port br0 gre0
 311
 312 Q: Does Open vSwitch support ERSPAN?
 313
 314 A: No.  ERSPAN is an undocumented proprietary protocol.  As an
 315    alternative, Open vSwitch supports mirroring to a GRE tunnel (see
 316    above).
 317
 318
 319 Configuration Problems
 320 ----------------------
 321
 322 Q: I created a bridge and added my Ethernet port to it, using commands
 323    like these:
 324
 325        ovs-vsctl add-br br0
 326        ovs-vsctl add-port br0 eth0
 327
 328    and as soon as I ran the "add-port" command I lost all connectivity
 329    through eth0.  Help!
 330
 331 A: A physical Ethernet device that is part of an Open vSwitch bridge
 332    should not have an IP address.  If one does, then that IP address
 333    will not be fully functional.
 334
 335    You can restore functionality by moving the IP address to an Open
 336    vSwitch "internal" device, such as the network device named after
 337    the bridge itself.  For example, assuming that eth0's IP address is
 338    192.168.128.5, you could run the commands below to fix up the
 339    situation:
 340
 341        ifconfig eth0 0.0.0.0
 342        ifconfig br0 192.168.128.5
 343
 344    (If your only connection to the machine running OVS is through the
 345    IP address in question, then you would want to run all of these
 346    commands on a single command line, or put them into a script.)  If
 347    there were any additional routes assigned to eth0, then you would
 348    also want to use commands to adjust these routes to go through br0.
 349
 350    If you use DHCP to obtain an IP address, then you should kill the
 351    DHCP client that was listening on the physical Ethernet interface
 352    (e.g. eth0) and start one listening on the internal interface
 353    (e.g. br0).  You might still need to manually clear the IP address
 354    from the physical interface (e.g. with "ifconfig eth0 0.0.0.0").
 355
 356    There is no compelling reason why Open vSwitch must work this way.
 357    However, this is the way that the Linux kernel bridge module has
 358    always worked, so it's a model that those accustomed to Linux
 359    bridging are already used to.  Also, the model that most people
 360    expect is not implementable without kernel changes on all the
 361    versions of Linux that Open vSwitch supports.
 362
 363    By the way, this issue is not specific to physical Ethernet
 364    devices.  It applies to all network devices except Open vswitch
 365    "internal" devices.
 366
 367 Q: I created a bridge and added a couple of Ethernet ports to it,
 368    using commands like these:
 369
 370        ovs-vsctl add-br br0
 371        ovs-vsctl add-port br0 eth0
 372        ovs-vsctl add-port br0 eth1
 373
 374    and now my network seems to have melted: connectivity is unreliable
 375    (even connectivity that doesn't go through Open vSwitch), all the
 376    LEDs on my physical switches are blinking, wireshark shows
 377    duplicated packets, and CPU usage is very high.
 378
 379 A: More than likely, you've looped your network.  Probably, eth0 and
 380    eth1 are connected to the same physical Ethernet switch.  This
 381    yields a scenario where OVS receives a broadcast packet on eth0 and
 382    sends it out on eth1, then the physical switch connected to eth1
 383    sends the packet back on eth0, and so on forever.  More complicated
 384    scenarios, involving a loop through multiple switches, are possible
 385    too.
 386
 387    The solution depends on what you are trying to do:
 388
 389        - If you added eth0 and eth1 to get higher bandwidth or higher
 390          reliability between OVS and your physical Ethernet switch,
 391          use a bond.  The following commands create br0 and then add
 392          eth0 and eth1 as a bond:
 393
 394              ovs-vsctl add-br br0
 395              ovs-vsctl add-bond br0 bond0 eth0 eth1
 396
 397          Bonds have tons of configuration options.  Please read the
 398          documentation on the Port table in ovs-vswitchd.conf.db(5)
 399          for all the details.
 400
 401        - Perhaps you don't actually need eth0 and eth1 to be on the
 402          same bridge.  For example, if you simply want to be able to
 403          connect each of them to virtual machines, then you can put
 404          each of them on a bridge of its own:
 405
 406              ovs-vsctl add-br br0
 407              ovs-vsctl add-port br0 eth0
 408
 409              ovs-vsctl add-br br1
 410              ovs-vsctl add-port br1 eth1
 411
 412          and then connect VMs to br0 and br1.  (A potential
 413          disadvantage is that traffic cannot directly pass between br0
 414          and br1.  Instead, it will go out eth0 and come back in eth1,
 415          or vice versa.)
 416
 417        - If you have a redundant or complex network topology and you
 418          want to prevent loops, turn on spanning tree protocol (STP).
 419          The following commands create br0, enable STP, and add eth0
 420          and eth1 to the bridge.  The order is important because you
 421          don't want have to have a loop in your network even
 422          transiently:
 423
 424              ovs-vsctl add-br br0
 425              ovs-vsctl set bridge br0 stp_enable=true
 426              ovs-vsctl add-port br0 eth0
 427              ovs-vsctl add-port br0 eth1
 428
 429          The Open vSwitch implementation of STP is not well tested.
 430          Please report any bugs you observe, but if you'd rather avoid
 431          acting as a beta tester then another option might be your
 432          best shot.
 433
 434 Q: I can't seem to use Open vSwitch in a wireless network.
 435
 436 A: Wireless base stations generally only allow packets with the source
 437    MAC address of NIC that completed the initial handshake.
 438    Therefore, without MAC rewriting, only a single device can
 439    communicate over a single wireless link.
 440
 441    This isn't specific to Open vSwitch, it's enforced by the access
 442    point, so the same problems will show up with the Linux bridge or
 443    any other way to do bridging.
 444
 445 Q: Is there any documentation on the database tables and fields?
 446
 447 A: Yes.  ovs-vswitchd.conf.db(5) is a comprehensive reference.
 448
 449 Q: When I run ovs-dpctl I no longer see the bridges I created.  Instead,
 450    I only see a datapath called "ovs-system".  How can I see datapath
 451    information about a particular bridge?
 452
 453 A: In version 1.9.0, OVS switched to using a single datapath that is
 454    shared by all bridges of that type.  The "ovs-appctl dpif/*"
 455    commands provide similar functionality that is scoped by the bridge.
 456
 457
 458 VLANs
 459 -----
 460
 461 Q: What's a VLAN?
 462
 463 A: At the simplest level, a VLAN (short for "virtual LAN") is a way to
 464    partition a single switch into multiple switches.  Suppose, for
 465    example, that you have two groups of machines, group A and group B.
 466    You want the machines in group A to be able to talk to each other,
 467    and you want the machine in group B to be able to talk to each
 468    other, but you don't want the machines in group A to be able to
 469    talk to the machines in group B.  You can do this with two
 470    switches, by plugging the machines in group A into one switch and
 471    the machines in group B into the other switch.
 472
 473    If you only have one switch, then you can use VLANs to do the same
 474    thing, by configuring the ports for machines in group A as VLAN
 475    "access ports" for one VLAN and the ports for group B as "access
 476    ports" for a different VLAN.  The switch will only forward packets
 477    between ports that are assigned to the same VLAN, so this
 478    effectively subdivides your single switch into two independent
 479    switches, one for each group of machines.
 480
 481    So far we haven't said anything about VLAN headers.  With access
 482    ports, like we've described so far, no VLAN header is present in
 483    the Ethernet frame.  This means that the machines (or switches)
 484    connected to access ports need not be aware that VLANs are
 485    involved, just like in the case where we use two different physical
 486    switches.
 487
 488    Now suppose that you have a whole bunch of switches in your
 489    network, instead of just one, and that some machines in group A are
 490    connected directly to both switches 1 and 2.  To allow these
 491    machines to talk to each other, you could add an access port for
 492    group A's VLAN to switch 1 and another to switch 2, and then
 493    connect an Ethernet cable between those ports.  That works fine,
 494    but it doesn't scale well as the number of switches and the number
 495    of VLANs increases, because you use up a lot of valuable switch
 496    ports just connecting together your VLANs.
 497
 498    This is where VLAN headers come in.  Instead of using one cable and
 499    two ports per VLAN to connect a pair of switches, we configure a
 500    port on each switch as a VLAN "trunk port".  Packets sent and
 501    received on a trunk port carry a VLAN header that says what VLAN
 502    the packet belongs to, so that only two ports total are required to
 503    connect the switches, regardless of the number of VLANs in use.
 504    Normally, only switches (either physical or virtual) are connected
 505    to a trunk port, not individual hosts, because individual hosts
 506    don't expect to see a VLAN header in the traffic that they receive.
 507
 508    None of the above discussion says anything about particular VLAN
 509    numbers.  This is because VLAN numbers are completely arbitrary.
 510    One must only ensure that a given VLAN is numbered consistently
 511    throughout a network and that different VLANs are given different
 512    numbers.  (That said, VLAN 0 is usually synonymous with a packet
 513    that has no VLAN header, and VLAN 4095 is reserved.)
 514
 515 Q: VLANs don't work.
 516
 517 A: Many drivers in Linux kernels before version 3.3 had VLAN-related
 518    bugs.  If you are having problems with VLANs that you suspect to be
 519    driver related, then you have several options:
 520
 521        - Upgrade to Linux 3.3 or later.
 522
 523        - Build and install a fixed version of the particular driver
 524          that is causing trouble, if one is available.
 525
 526        - Use a NIC whose driver does not have VLAN problems.
 527
 528        - Use "VLAN splinters", a feature in Open vSwitch 1.4 and later
 529          that works around bugs in kernel drivers.  To enable VLAN
 530          splinters on interface eth0, use the command:
 531
 532            ovs-vsctl set interface eth0 other-config:enable-vlan-splinters=true
 533
 534          For VLAN splinters to be effective, Open vSwitch must know
 535          which VLANs are in use.  See the "VLAN splinters" section in
 536          the Interface table in ovs-vswitchd.conf.db(5) for details on
 537          how Open vSwitch infers in-use VLANs.
 538
 539          VLAN splinters increase memory use and reduce performance, so
 540          use them only if needed.
 541
 542        - Apply the "vlan workaround" patch from the XenServer kernel
 543          patch queue, build Open vSwitch against this patched kernel,
 544          and then use ovs-vlan-bug-workaround(8) to enable the VLAN
 545          workaround for each interface whose driver is buggy.
 546
 547          (This is a nontrivial exercise, so this option is included
 548          only for completeness.)
 549
 550    It is not always easy to tell whether a Linux kernel driver has
 551    buggy VLAN support.  The ovs-vlan-test(8) and ovs-test(8) utilities
 552    can help you test.  See their manpages for details.  Of the two
 553    utilities, ovs-test(8) is newer and more thorough, but
 554    ovs-vlan-test(8) may be easier to use.
 555
 556 Q: VLANs still don't work.  I've tested the driver so I know that it's OK.
 557
 558 A: Do you have VLANs enabled on the physical switch that OVS is
 559    attached to?  Make sure that the port is configured to trunk the
 560    VLAN or VLANs that you are using with OVS.
 561
 562 Q: Outgoing VLAN-tagged traffic goes through OVS to my physical switch
 563    and to its destination host, but OVS seems to drop incoming return
 564    traffic.
 565
 566 A: It's possible that you have the VLAN configured on your physical
 567    switch as the "native" VLAN.  In this mode, the switch treats
 568    incoming packets either tagged with the native VLAN or untagged as
 569    part of the native VLAN.  It may also send outgoing packets in the
 570    native VLAN without a VLAN tag.
 571
 572    If this is the case, you have two choices:
 573
 574        - Change the physical switch port configuration to tag packets
 575          it forwards to OVS with the native VLAN instead of forwarding
 576          them untagged.
 577
 578        - Change the OVS configuration for the physical port to a
 579          native VLAN mode.  For example, the following sets up a
 580          bridge with port eth0 in "native-tagged" mode in VLAN 9:
 581
 582              ovs-vsctl add-br br0
 583              ovs-vsctl add-port br0 eth0 tag=9 vlan_mode=native-tagged
 584
 585          In this situation, "native-untagged" mode will probably work
 586          equally well.  Refer to the documentation for the Port table
 587          in ovs-vswitchd.conf.db(5) for more information.
 588
 589 Q: I added a pair of VMs on different VLANs, like this:
 590
 591        ovs-vsctl add-br br0
 592        ovs-vsctl add-port br0 eth0
 593        ovs-vsctl add-port br0 tap0 tag=9
 594        ovs-vsctl add-port br0 tap1 tag=10
 595
 596     but the VMs can't access each other, the external network, or the
 597     Internet.
 598
 599 A: It is to be expected that the VMs can't access each other.  VLANs
 600    are a means to partition a network.  When you configured tap0 and
 601    tap1 as access ports for different VLANs, you indicated that they
 602    should be isolated from each other.
 603
 604    As for the external network and the Internet, it seems likely that
 605    the machines you are trying to access are not on VLAN 9 (or 10) and
 606    that the Internet is not available on VLAN 9 (or 10).
 607
 608 Q: Can I configure an IP address on a VLAN?
 609
 610 A: Yes.  Use an "internal port" configured as an access port.  For
 611    example, the following configures IP address 192.168.0.7 on VLAN 9.
 612    That is, OVS will forward packets from eth0 to 192.168.0.7 only if
 613    they have an 802.1Q header with VLAN 9.  Conversely, traffic
 614    forwarded from 192.168.0.7 to eth0 will be tagged with an 802.1Q
 615    header with VLAN 9:
 616
 617        ovs-vsctl add-br br0
 618        ovs-vsctl add-port br0 eth0
 619        ovs-vsctl add-port br0 vlan9 tag=9 -- set interface vlan9 type=internal
 620        ifconfig vlan9 192.168.0.7
 621
 622 Q: My OpenFlow controller doesn't see the VLANs that I expect.
 623
 624 A: The configuration for VLANs in the Open vSwitch database (e.g. via
 625    ovs-vsctl) only affects traffic that goes through Open vSwitch's
 626    implementation of the OpenFlow "normal switching" action.  By
 627    default, when Open vSwitch isn't connected to a controller and
 628    nothing has been manually configured in the flow table, all traffic
 629    goes through the "normal switching" action.  But, if you set up
 630    OpenFlow flows on your own, through a controller or using ovs-ofctl
 631    or through other means, then you have to implement VLAN handling
 632    yourself.
 633
 634    You can use "normal switching" as a component of your OpenFlow
 635    actions, e.g. by putting "normal" into the lists of actions on
 636    ovs-ofctl or by outputting to OFPP_NORMAL from an OpenFlow
 637    controller.  This will only be suitable for some situations,
 638    though.
 639
 640 Q: I configured ports on a bridge as access ports with different VLAN
 641    tags, like this:
 642
 643        ovs-vsctl add-br br0
 644        ovs-vsctl set-controller br0 tcp:192.168.0.10:6633
 645        ovs-vsctl add-port br0 eth0
 646        ovs-vsctl add-port br0 tap0 tag=9
 647        ovs-vsctl add-port br0 tap1 tag=10
 648
 649    but the VMs running behind tap0 and tap1 can still communicate,
 650    that is, they are not isolated from each other even though they are
 651    on different VLANs.
 652
 653 A: Do you have a controller configured on br0 (as the commands above
 654    do)?  If so, then this is a variant on the previous question, "My
 655    OpenFlow controller doesn't see the VLANs that I expect," and you
 656    can refer to the answer there for more information.
 657
 658
 659 Controllers
 660 -----------
 661
 662 Q: What versions of OpenFlow does Open vSwitch support?
 663
 664 A: Open vSwitch supports OpenFlow 1.0.  It also includes a number of
 665    extensions that bring many of the features from later versions of
 666    OpenFlow.  Work is underway to provide support for later versions and
 667    can be tracked here:
 668
 669        http://openvswitch.org/development/openflow-1-x-plan/
 670
 671 Q: I'm getting "error type 45250 code 0".  What's that?
 672
 673 A: This is a Open vSwitch extension to OpenFlow error codes.  Open
 674    vSwitch uses this extension when it must report an error to an
 675    OpenFlow controller but no standard OpenFlow error code is
 676    suitable.
 677
 678    Open vSwitch logs the errors that it sends to controllers, so the
 679    easiest thing to do is probably to look at the ovs-vswitchd log to
 680    find out what the error was.
 681
 682    If you want to dissect the extended error message yourself, the
 683    format is documented in include/openflow/nicira-ext.h in the Open
 684    vSwitch source distribution.  The extended error codes are
 685    documented in lib/ofp-errors.h.
 686
 687 Q1: Some of the traffic that I'd expect my OpenFlow controller to see
 688     doesn't actually appear through the OpenFlow connection, even
 689     though I know that it's going through.
 690 Q2: Some of the OpenFlow flows that my controller sets up don't seem
 691     to apply to certain traffic, especially traffic between OVS and
 692     the controller itself.
 693
 694 A: By default, Open vSwitch assumes that OpenFlow controllers are
 695    connected "in-band", that is, that the controllers are actually
 696    part of the network that is being controlled.  In in-band mode,
 697    Open vSwitch sets up special "hidden" flows to make sure that
 698    traffic can make it back and forth between OVS and the controllers.
 699    These hidden flows are higher priority than any flows that can be
 700    set up through OpenFlow, and they are not visible through normal
 701    OpenFlow flow table dumps.
 702
 703    Usually, the hidden flows are desirable and helpful, but
 704    occasionally they can cause unexpected behavior.  You can view the
 705    full OpenFlow flow table, including hidden flows, on bridge br0
 706    with the command:
 707
 708        ovs-appctl bridge/dump-flows br0
 709
 710    to help you debug.  The hidden flows are those with priorities
 711    greater than 65535 (the maximum priority that can be set with
 712    OpenFlow).
 713
 714    The DESIGN file at the top level of the Open vSwitch source
 715    distribution describes the in-band model in detail.
 716
 717    If your controllers are not actually in-band (e.g. they are on
 718    localhost via 127.0.0.1, or on a separate network), then you should
 719    configure your controllers in "out-of-band" mode.  If you have one
 720    controller on bridge br0, then you can configure out-of-band mode
 721    on it with:
 722
 723        ovs-vsctl set controller br0 connection-mode=out-of-band
 724
 725 Q: I configured all my controllers for out-of-band control mode but
 726    "ovs-appctl bridge/dump-flows" still shows some hidden flows.
 727
 728 A: You probably have a remote manager configured (e.g. with "ovs-vsctl
 729    set-manager").  By default, Open vSwitch assumes that managers need
 730    in-band rules set up on every bridge.  You can disable these rules
 731    on bridge br0 with:
 732
 733        ovs-vsctl set bridge br0 other-config:disable-in-band=true
 734
 735    This actually disables in-band control entirely for the bridge, as
 736    if all the bridge's controllers were configured for out-of-band
 737    control.
 738
 739 Q: My OpenFlow controller doesn't see the VLANs that I expect.
 740
 741 A: See answer under "VLANs", above.
 742
 743 Q: I ran "ovs-ofctl add-flow br0 nw_dst=192.168.0.1,actions=drop"
 744    but I got a funny message like this:
 745
 746        ofp_util|INFO|normalization changed ofp_match, details:
 747        ofp_util|INFO| pre: nw_dst=192.168.0.1
 748        ofp_util|INFO|post:
 749
 750    and when I ran "ovs-ofctl dump-flows br0" I saw that my nw_dst
 751    match had disappeared, so that the flow ends up matching every
 752    packet.
 753
 754 A: The term "normalization" in the log message means that a flow
 755    cannot match on an L3 field without saying what L3 protocol is in
 756    use.  The "ovs-ofctl" command above didn't specify an L3 protocol,
 757    so the L3 field match was dropped.
 758
 759    In this case, the L3 protocol could be IP or ARP.  A correct
 760    command for each possibility is, respectively:
 761
 762        ovs-ofctl add-flow br0 ip,nw_dst=192.168.0.1,actions=drop
 763
 764    and
 765
 766        ovs-ofctl add-flow br0 arp,nw_dst=192.168.0.1,actions=drop
 767
 768    Similarly, a flow cannot match on an L4 field without saying what
 769    L4 protocol is in use.  For example, the flow match "tp_src=1234"
 770    is, by itself, meaningless and will be ignored.  Instead, to match
 771    TCP source port 1234, write "tcp,tp_src=1234", or to match UDP
 772    source port 1234, write "udp,tp_src=1234".
 773
 774 Q: How can I figure out the OpenFlow port number for a given port?
 775
 776 A: The OFPT_FEATURES_REQUEST message requests an OpenFlow switch to
 777    respond with an OFPT_FEATURES_REPLY that, among other information,
 778    includes a mapping between OpenFlow port names and numbers.  From a
 779    command prompt, "ovs-ofctl show br0" makes such a request and
 780    prints the response for switch br0.
 781
 782    The Interface table in the Open vSwitch database also maps OpenFlow
 783    port names to numbers.  To print the OpenFlow port number
 784    associated with interface eth0, run:
 785
 786        ovs-vsctl get Interface eth0 ofport
 787
 788    You can print the entire mapping with:
 789
 790        ovs-vsctl -- --columns=name,ofport list Interface
 791
 792    but the output mixes together interfaces from all bridges in the
 793    database, so it may be confusing if more than one bridge exists.
 794
 795    In the Open vSwitch database, ofport value -1 means that the
 796    interface could not be created due to an error.  (The Open vSwitch
 797    log should indicate the reason.)  ofport value [] (the empty set)
 798    means that the interface hasn't been created yet.  The latter is
 799    normally an intermittent condition (unless ovs-vswitchd is not
 800    running).
 801
 802 Q: I added some flows with my controller or with ovs-ofctl, but when I
 803    run "ovs-dpctl dump-flows" I don't see them.
 804
 805 A: ovs-dpctl queries a kernel datapath, not an OpenFlow switch.  It
 806    won't display the information that you want.  You want to use
 807    "ovs-ofctl dump-flows" instead.
 808
 809 Q: It looks like each of the interfaces in my bonded port shows up
 810    as an individual OpenFlow port.  Is that right?
 811
 812 A: Yes, Open vSwitch makes individual bond interfaces visible as
 813    OpenFlow ports, rather than the bond as a whole.  The interfaces
 814    are treated together as a bond for only a few purposes:
 815
 816        - Sending a packet to the OFPP_NORMAL port.  (When an OpenFlow
 817          controller is not configured, this happens implicitly to
 818          every packet.)
 819
 820        - The "autopath" Nicira extension action.  However, "autopath"
 821          is deprecated and scheduled for removal in February 2013.
 822
 823        - Mirrors configured for output to a bonded port.
 824
 825    It would make a lot of sense for Open vSwitch to present a bond as
 826    a single OpenFlow port.  If you want to contribute an
 827    implementation of such a feature, please bring it up on the Open
 828    vSwitch development mailing list at dev@openvswitch.org.
 829
 830 Contact
 831 -------
 832
 833 bugs@openvswitch.org
 834 http://openvswitch.org/