FAQ

   1                  Open vSwitch <http://openvswitch.org>
   2
   3 Frequently Asked Questions
   4 ==========================
   5
   6 Configuration Problems
   7 ----------------------
   8
   9 Q: I created a bridge and added my Ethernet port to it, using commands
  10    like these:
  11
  12        ovs-vsctl add-br br0
  13        ovs-vsctl add-port br0 eth0
  14
  15    and as soon as I ran the "add-port" command I lost all connectivity
  16    through eth0.  Help!
  17
  18 A: A physical Ethernet device that is part of an Open vSwitch bridge
  19    should not have an IP address.  If one does, then that IP address
  20    will not be fully functional.
  21
  22    You can restore functionality by moving the IP address to an Open
  23    vSwitch "internal" device, such as the network device named after
  24    the bridge itself.  For example, assuming that eth0's IP address is
  25    192.168.128.5, you could run the commands below to fix up the
  26    situation:
  27
  28        ifconfig eth0 0.0.0.0
  29        ifconfig br0 192.168.128.5
  30
  31    (If your only connection to the machine running OVS is through the
  32    IP address in question, then you would want to run all of these
  33    commands on a single command line, or put them into a script.)  If
  34    there were any additional routes assigned to eth0, then you would
  35    also want to use commands to adjust these routes to go through br0.
  36
  37    If you use DHCP to obtain an IP address, then you should kill the
  38    DHCP client that was listening on the physical Ethernet interface
  39    (e.g. eth0) and start one listening on the internal interface
  40    (e.g. br0).  You might still need to manually clear the IP address
  41    from the physical interface (e.g. with "ifconfig eth0 0.0.0.0").
  42
  43    There is no compelling reason why Open vSwitch must work this way.
  44    However, this is the way that the Linux kernel bridge module has
  45    always worked, so it's a model that those accustomed to Linux
  46    bridging are already used to.  Also, the model that most people
  47    expect is not implementable without kernel changes on all the
  48    versions of Linux that Open vSwitch supports.
  49
  50    By the way, this issue is not specific to physical Ethernet
  51    devices.  It applies to all network devices except Open vswitch
  52    "internal" devices.
  53
  54 Q: I created a bridge and added a couple of Ethernet ports to it,
  55    using commands like these:
  56
  57        ovs-vsctl add-br br0
  58        ovs-vsctl add-port br0 eth0
  59        ovs-vsctl add-port br0 eth1
  60
  61    and now my network seems to have melted: connectivity is unreliable
  62    (even connectivity that doesn't go through Open vSwitch), all the
  63    LEDs on my physical switches are blinking, wireshark shows
  64    duplicated packets, and CPU usage is very high.
  65
  66 A: More than likely, you've looped your network.  Probably, eth0 and
  67    eth1 are connected to the same physical Ethernet switch.  This
  68    yields a scenario where OVS receives a broadcast packet on eth0 and
  69    sends it out on eth1, then the physical switch connected to eth1
  70    sends the packet back on eth0, and so on forever.  More complicated
  71    scenarios, involving a loop through multiple switches, are possible
  72    too.
  73
  74    The solution depends on what you are trying to do:
  75
  76        - If you added eth0 and eth1 to get higher bandwidth or higher
  77          reliability between OVS and your physical Ethernet switch,
  78          use a bond.  The following commands create br0 and then add
  79          eth0 and eth1 as a bond:
  80
  81              ovs-vsctl add-br br0
  82              ovs-vsctl add-bond br0 bond0 eth0 eth1
  83
  84          Bonds have tons of configuration options.  Please read the
  85          documentation on the Port table in ovs-vswitchd.conf.db(5)
  86          for all the details.
  87
  88        - Perhaps you don't actually need eth0 and eth1 to be on the
  89          same bridge.  For example, if you simply want to be able to
  90          connect each of them to virtual machines, then you can put
  91          each of them on a bridge of its own:
  92
  93              ovs-vsctl add-br br0
  94              ovs-vsctl add-port br0 eth0
  95
  96              ovs-vsctl add-br br1
  97              ovs-vsctl add-port br1 eth1
  98
  99          and then connect VMs to br0 and br1.  (A potential
 100          disadvantage is that traffic cannot directly pass between br0
 101          and br1.  Instead, it will go out eth0 and come back in eth1,
 102          or vice versa.)
 103
 104        - If you have a redundant or complex network topology and you
 105          want to prevent loops, turn on spanning tree protocol (STP).
 106          The following commands create br0, enable STP, and add eth0
 107          and eth1 to the bridge.  The order is important because you
 108          don't want have to have a loop in your network even
 109          transiently:
 110
 111              ovs-vsctl add-br br0
 112              ovs-vsctl set bridge br0 stp_enable=true
 113              ovs-vsctl add-port br0 eth0
 114              ovs-vsctl add-port br0 eth1
 115
 116          The Open vSwitch implementation of STP is not well tested.
 117          Please report any bugs you observe, but if you'd rather avoid
 118          acting as a beta tester then another option might be your
 119          best shot.
 120
 121 Q: I can't seem to use Open vSwitch in a wireless network.
 122
 123 A: Wireless base stations generally only allow packets with the source
 124    MAC address of NIC that completed the initial handshake.
 125    Therefore, without MAC rewriting, only a single device can
 126    communicate over a single wireless link.
 127
 128    This isn't specific to Open vSwitch, it's enforced by the access
 129    point, so the same problems will show up with the Linux bridge or
 130    any other way to do bridging.
 131
 132
 133 VLANs
 134 -----
 135
 136 Q: VLANs don't work.
 137
 138 A: Many drivers in Linux kernels before version 3.3 had VLAN-related
 139    bugs.  If you are having problems with VLANs that you suspect to be
 140    driver related, then you have several options:
 141
 142        - Upgrade to Linux 3.3 or later.
 143
 144        - Build and install a fixed version of the particular driver
 145          that is causing trouble, if one is available.
 146
 147        - Use a NIC whose driver does not have VLAN problems.
 148
 149        - Use "VLAN splinters", a feature in Open vSwitch 1.4 and later
 150          that works around bugs in kernel drivers.  To enable VLAN
 151          splinters on interface eth0, use the command:
 152
 153              ovs-vsctl set interface eth0 other-config:enable-vlan-splinters=true
 154
 155          For VLAN splinters to be effective, Open vSwitch must know
 156          which VLANs are in use.  See the "VLAN splinters" section in
 157          the Interface table in ovs-vswitchd.conf.db(5) for details on
 158          how Open vSwitch infers in-use VLANs.
 159
 160          VLAN splinters increase memory use and reduce performance, so
 161          use them only if needed.
 162
 163        - Apply the "vlan workaround" patch from the XenServer kernel
 164          patch queue, build Open vSwitch against this patched kernel,
 165          and then use ovs-vlan-bug-workaround(8) to enable the VLAN
 166          workaround for each interface whose driver is buggy.
 167
 168          (This is a nontrivial exercise, so this option is included
 169          only for completeness.)
 170
 171    It is not always easy to tell whether a Linux kernel driver has
 172    buggy VLAN support.  The ovs-vlan-test(8) and ovs-test(8) utilities
 173    can help you test.  See their manpages for details.  Of the two
 174    utilities, ovs-test(8) is newer and more thorough, but
 175    ovs-vlan-test(8) may be easier to use.
 176
 177 Q: VLANs still don't work.  I've tested the driver so I know that it's OK.
 178
 179 A: Do you have VLANs enabled on the physical switch that OVS is
 180    attached to?  Make sure that the port is configured to trunk the
 181    VLAN or VLANs that you are using with OVS.
 182
 183 Q: Outgoing VLAN-tagged traffic goes through OVS to my physical switch
 184    and to its destination host, but OVS seems to drop incoming return
 185    traffic.
 186
 187 A: It's possible that you have the VLAN configured on your physical
 188    switch as the "native" VLAN.  In this mode, the switch treats
 189    incoming packets either tagged with the native VLAN or untagged as
 190    part of the native VLAN.  It may also send outgoing packets in the
 191    native VLAN without a VLAN tag.
 192
 193    If this is the case, you have two choices:
 194
 195        - Change the physical switch port configuration to tag packets
 196          it forwards to OVS with the native VLAN instead of forwarding
 197          them untagged.
 198
 199        - Change the OVS configuration for the physical port to a
 200          native VLAN mode.  For example, the following sets up a
 201          bridge with port eth0 in "native-tagged" mode in VLAN 9:
 202
 203              ovs-vsctl add-br br0
 204              ovs-vsctl add-port br0 eth0 tag=9 vlan_mode=native-tagged
 205
 206          In this situation, "native-untagged" mode will probably work
 207          equally well.  Refer to the documentation for the Port table
 208          in ovs-vswitchd.conf.db(5) for more information.
 209
 210 Q: Can I configure an IP address on a VLAN?
 211
 212 A: Yes.  Use an "internal port" configured as an access port.  For
 213    example, the following configures IP address 192.168.0.7 on VLAN 9.
 214    That is, OVS will forward packets from eth0 to 192.168.0.7 only if
 215    they have an 802.1Q header with VLAN 9.  Conversely, traffic
 216    forwarded from 192.168.0.7 to eth0 will be tagged with an 802.1Q
 217    header with VLAN 9:
 218
 219        ovs-vsctl add-br br0
 220        ovs-vsctl add-port br0 eth0
 221        ovs-vsctl add-port br0 vlan9 tag=9 -- set interface vlan9 type=internal
 222        ifconfig vlan9 192.168.0.7
 223
 224 Q: My OpenFlow controller doesn't see the VLANs that I expect.
 225
 226 A: The configuration for VLANs in the Open vSwitch database (e.g. via
 227    ovs-vsctl) only affects traffic that goes through Open vSwitch's
 228    implementation of the OpenFlow "normal switching" action.  By
 229    default, when Open vSwitch isn't connected to a controller and
 230    nothing has been manually configured in the flow table, all traffic
 231    goes through the "normal switching" action.  But, if you set up
 232    OpenFlow flows on your own, through a controller or using ovs-ofctl
 233    or through other means, then you have to implement VLAN handling
 234    yourself.
 235
 236    You can use "normal switching" as a component of your OpenFlow
 237    actions, e.g. by putting "normal" into the lists of actions on
 238    ovs-ofctl or by outputting to OFPP_NORMAL from an OpenFlow
 239    controller.  This will only be suitable for some situations,
 240    though.
 241
 242
 243 Controllers
 244 -----------
 245
 246 Q: I'm getting "error type 45250 code 0".  What's that?
 247
 248 A: This is a Open vSwitch extension to OpenFlow error codes.  Open
 249    vSwitch uses this extension when it must report an error to an
 250    OpenFlow controller but no standard OpenFlow error code is
 251    suitable.
 252
 253    Open vSwitch logs the errors that it sends to controllers, so the
 254    easiest thing to do is probably to look at the ovs-vswitchd log to
 255    find out what the error was.
 256
 257    If you want to dissect the extended error message yourself, the
 258    format is documented in include/openflow/nicira-ext.h in the Open
 259    vSwitch source distribution.  The extended error codes are
 260    documented in lib/ofp-errors.h.
 261
 262 Q1: Some of the traffic that I'd expect my OpenFlow controller to see
 263     doesn't actually appear through the OpenFlow connection, even
 264     though I know that it's going through.
 265 Q2: Some of the OpenFlow flows that my controller sets up don't seem
 266     to apply to certain traffic, especially traffic between OVS and
 267     the controller itself.
 268
 269 A: By default, Open vSwitch assumes that OpenFlow controllers are
 270    connected "in-band", that is, that the controllers are actually
 271    part of the network that is being controlled.  In in-band mode,
 272    Open vSwitch sets up special "hidden" flows to make sure that
 273    traffic can make it back and forth between OVS and the controllers.
 274    These hidden flows are higher priority than any flows that can be
 275    set up through OpenFlow, and they are not visible through normal
 276    OpenFlow flow table dumps.
 277
 278    Usually, the hidden flows are desirable and helpful, but
 279    occasionally they can cause unexpected behavior.  You can view the
 280    full OpenFlow flow table, including hidden flows, on bridge br0
 281    with the command:
 282
 283        ovs-appctl bridge/dump-flows br0
 284
 285    to help you debug.  The hidden flows are those with priorities
 286    greater than 65535 (the maximum priority that can be set with
 287    OpenFlow).
 288
 289    The DESIGN file at the top level of the Open vSwitch source
 290    distribution describes the in-band model in detail.
 291
 292    If your controllers are not actually in-band (e.g. they are on
 293    localhost via 127.0.0.1, or on a separate network), then you should
 294    configure your controllers in "out-of-band" mode.  If you have one
 295    controller on bridge br0, then you can configure out-of-band mode
 296    on it with:
 297
 298        ovs-vsctl set controller br0 connection-mode=out-of-band
 299
 300 Q: I configured all my controllers for out-of-band control mode but
 301    "ovs-appctl bridge/dump-flows" still shows some hidden flows.
 302
 303 A: You probably have a remote manager configured (e.g. with "ovs-vsctl
 304    set-manager").  By default, Open vSwitch assumes that managers need
 305    in-band rules set up on every bridge.  You can disable these rules
 306    on bridge br0 with:
 307
 308        ovs-vsctl set bridge br0 other-config:disable-in-band=true
 309
 310    This actually disables in-band control entirely for the bridge, as
 311    if all the bridge's controllers were configured for out-of-band
 312    control.
 313
 314 Q: My OpenFlow controller doesn't see the VLANs that I expect.
 315
 316 A: See answer under "VLANs", above.
 317
 318 Contact
 319 -------
 320
 321 bugs@openvswitch.org
 322 http://openvswitch.org/