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
  13    environments.  A vswitch forwards traffic between different VMs on
  14    the same physical host and also forwards traffic between VMs and
  15    the physical network.  Open vSwitch supports standard management
  16    interfaces (e.g. sFlow, NetFlow, IPFIX, RSPAN, CLI), and is open to
  17    programmatic extension and control using OpenFlow and the OVSDB
  18    management protocol.
  19
  20    Open vSwitch as designed to be compatible with modern switching
  21    chipsets.  This means that it can be ported to existing high-fanout
  22    switches allowing the same flexible control of the physical
  23    infrastructure as the virtual infrastructure.  It also means that
  24    Open vSwitch will be able to take advantage of on-NIC switching
  25    chipsets as their functionality matures.
  26
  27 Q: What virtualization platforms can use Open vSwitch?
  28
  29 A: Open vSwitch can currently run on any Linux-based virtualization
  30    platform (kernel 2.6.18 and newer), including: KVM, VirtualBox, Xen,
  31    Xen Cloud Platform, XenServer. As of Linux 3.3 it is part of the
  32    mainline kernel.  The bulk of the code is written in platform-
  33    independent C and is easily ported to other environments.  We welcome
  34    inquires about integrating Open vSwitch with other virtualization
  35    platforms.
  36
  37 Q: How can I try Open vSwitch?
  38
  39 A: The Open vSwitch source code can be built on a Linux system.  You can
  40    build and experiment with Open vSwitch on any Linux machine.
  41    Packages for various Linux distributions are available on many
  42    platforms, including: Debian, Ubuntu, Fedora.
  43
  44    You may also download and run a virtualization platform that already
  45    has Open vSwitch integrated.  For example, download a recent ISO for
  46    XenServer or Xen Cloud Platform.  Be aware that the version
  47    integrated with a particular platform may not be the most recent Open
  48    vSwitch release.
  49
  50 Q: Does Open vSwitch only work on Linux?
  51
  52 A: No, Open vSwitch has been ported to a number of different operating
  53    systems and hardware platforms.  Most of the development work occurs
  54    on Linux, but the code should be portable to any POSIX system.  We've
  55    seen Open vSwitch ported to a number of different platforms,
  56    including FreeBSD, Windows, and even non-POSIX embedded systems.
  57
  58    By definition, the Open vSwitch Linux kernel module only works on
  59    Linux and will provide the highest performance.  However, a userspace
  60    datapath is available that should be very portable.
  61
  62 Q: What's involved with porting Open vSwitch to a new platform or
  63    switching ASIC?
  64
  65 A: The PORTING document describes how one would go about porting Open
  66    vSwitch to a new operating system or hardware platform.
  67
  68 Q: Why would I use Open vSwitch instead of the Linux bridge?
  69
  70 A: Open vSwitch is specially designed to make it easier to manage VM
  71    network configuration and monitor state spread across many physical
  72    hosts in dynamic virtualized environments.  Please see WHY-OVS for a
  73    more detailed description of how Open vSwitch relates to the Linux
  74    Bridge.
  75
  76 Q: How is Open vSwitch related to distributed virtual switches like the
  77    VMware vNetwork distributed switch or the Cisco Nexus 1000V?
  78
  79 A: Distributed vswitch applications (e.g., VMware vNetwork distributed
  80    switch, Cisco Nexus 1000V) provide a centralized way to configure and
  81    monitor the network state of VMs that are spread across many physical
  82    hosts.  Open vSwitch is not a distributed vswitch itself, rather it
  83    runs on each physical host and supports remote management in a way
  84    that makes it easier for developers of virtualization/cloud
  85    management platforms to offer distributed vswitch capabilities.
  86
  87    To aid in distribution, Open vSwitch provides two open protocols that
  88    are specially designed for remote management in virtualized network
  89    environments: OpenFlow, which exposes flow-based forwarding state,
  90    and the OVSDB management protocol, which exposes switch port state.
  91    In addition to the switch implementation itself, Open vSwitch
  92    includes tools (ovs-controller, ovs-ofctl, ovs-vsctl) that developers
  93    can script and extend to provide distributed vswitch capabilities
  94    that are closely integrated with their virtualization management
  95    platform.
  96
  97 Q: Why doesn't Open vSwitch support distribution?
  98
  99 A: Open vSwitch is intended to be a useful component for building
 100    flexible network infrastructure. There are many different approaches
 101    to distribution which balance trade-offs between simplicity,
 102    scalability, hardware compatibility, convergence times, logical
 103    forwarding model, etc. The goal of Open vSwitch is to be able to
 104    support all as a primitive building block rather than choose a
 105    particular point in the distributed design space.
 106
 107 Q: How can I contribute to the Open vSwitch Community?
 108
 109 A: You can start by joining the mailing lists and helping to answer
 110    questions.  You can also suggest improvements to documentation.  If
 111    you have a feature or bug you would like to work on, send a mail to
 112    one of the mailing lists:
 113
 114        http://openvswitch.org/mlists/
 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.8
 149        1.10.x     2.6.18 to 3.8
 150        1.11.x     2.6.18 to 3.8
 151
 152    Open vSwitch userspace should also work with the Linux kernel module
 153    built into Linux 3.3 and later.
 154
 155    Open vSwitch userspace is not sensitive to the Linux kernel version.
 156    It should build against almost any kernel, certainly against 2.6.18
 157    and later.
 158
 159 Q: What Linux kernel versions does IPFIX flow monitoring work with?
 160
 161 A: IPFIX flow monitoring requires the Linux kernel module from Open
 162    vSwitch version 1.10.90 or later.
 163
 164 Q: Should userspace or kernel be upgraded first to minimize downtime?
 165
 166    In general, the Open vSwitch userspace should be used with the
 167    kernel version included in the same release or with the version
 168    from upstream Linux.  However, when upgrading between two releases
 169    of Open vSwitch it is best to migrate userspace first to reduce
 170    the possbility of incompatibilities.
 171
 172 Q: What features are not available in the Open vSwitch kernel datapath
 173    that ships as part of the upstream Linux kernel?
 174
 175 A: The kernel module in upstream Linux 3.3 and later does not include
 176    tunnel virtual ports, that is, interfaces with type "gre",
 177    "ipsec_gre", "gre64", "ipsec_gre64", "vxlan", or "lisp".  It is
 178    possible to create tunnels in Linux and attach them to Open vSwitch
 179    as system devices.  However, they cannot be dynamically created
 180    through the OVSDB protocol or set the tunnel ids as a flow action.
 181
 182    Work is in progress in adding tunnel virtual ports to the upstream
 183    Linux version of the Open vSwitch kernel module.  For now, if you
 184    need these features, use the kernel module from the Open vSwitch
 185    distribution instead of the upstream Linux kernel module.
 186
 187    The upstream kernel module does not include patch ports, but this
 188    only matters for Open vSwitch 1.9 and earlier, because Open vSwitch
 189    1.10 and later implement patch ports without using this kernel
 190    feature.
 191
 192 Q: What features are not available when using the userspace datapath?
 193
 194 A: Tunnel virtual ports are not supported, as described in the
 195    previous answer.  It is also not possible to use queue-related
 196    actions.  On Linux kernels before 2.6.39, maximum-sized VLAN packets
 197    may not be transmitted.
 198
 199
 200 Terminology
 201 -----------
 202
 203 Q: I thought Open vSwitch was a virtual Ethernet switch, but the
 204    documentation keeps talking about bridges.  What's a bridge?
 205
 206 A: In networking, the terms "bridge" and "switch" are synonyms.  Open
 207    vSwitch implements an Ethernet switch, which means that it is also
 208    an Ethernet bridge.
 209
 210 Q: What's a VLAN?
 211
 212 A: See the "VLAN" section below.
 213
 214
 215 Basic Configuration
 216 -------------------
 217
 218 Q: How do I configure a port as an access port?
 219
 220 A: Add "tag=VLAN" to your "ovs-vsctl add-port" command.  For example,
 221    the following commands configure br0 with eth0 as a trunk port (the
 222    default) and tap0 as an access port for VLAN 9:
 223
 224        ovs-vsctl add-br br0
 225        ovs-vsctl add-port br0 eth0
 226        ovs-vsctl add-port br0 tap0 tag=9
 227
 228    If you want to configure an already added port as an access port,
 229    use "ovs-vsctl set", e.g.:
 230
 231        ovs-vsctl set port tap0 tag=9
 232
 233 Q: How do I configure a port as a SPAN port, that is, enable mirroring
 234    of all traffic to that port?
 235
 236 A: The following commands configure br0 with eth0 and tap0 as trunk
 237    ports.  All traffic coming in or going out on eth0 or tap0 is also
 238    mirrored to tap1; any traffic arriving on tap1 is dropped:
 239
 240        ovs-vsctl add-br br0
 241        ovs-vsctl add-port br0 eth0
 242        ovs-vsctl add-port br0 tap0
 243        ovs-vsctl add-port br0 tap1 \
 244            -- --id=@p get port tap1 \
 245            -- --id=@m create mirror name=m0 select-all=true output-port=@p \
 246            -- set bridge br0 mirrors=@m
 247
 248    To later disable mirroring, run:
 249
 250        ovs-vsctl clear bridge br0 mirrors
 251
 252 Q: How do I configure a VLAN as an RSPAN VLAN, that is, enable
 253    mirroring of all traffic to that VLAN?
 254
 255 A: The following commands configure br0 with eth0 as a trunk port and
 256    tap0 as an access port for VLAN 10.  All traffic coming in or going
 257    out on tap0, as well as traffic coming in or going out on eth0 in
 258    VLAN 10, is also mirrored to VLAN 15 on eth0.  The original tag for
 259    VLAN 10, in cases where one is present, is dropped as part of
 260    mirroring:
 261
 262        ovs-vsctl add-br br0
 263        ovs-vsctl add-port br0 eth0
 264        ovs-vsctl add-port br0 tap0 tag=10
 265        ovs-vsctl \
 266            -- --id=@m create mirror name=m0 select-all=true select-vlan=10 \
 267                                     output-vlan=15 \
 268            -- set bridge br0 mirrors=@m
 269
 270    To later disable mirroring, run:
 271
 272        ovs-vsctl clear bridge br0 mirrors
 273
 274    Mirroring to a VLAN can disrupt a network that contains unmanaged
 275    switches.  See ovs-vswitchd.conf.db(5) for details.  Mirroring to a
 276    GRE tunnel has fewer caveats than mirroring to a VLAN and should
 277    generally be preferred.
 278
 279 Q: Can I mirror more than one input VLAN to an RSPAN VLAN?
 280
 281 A: Yes, but mirroring to a VLAN strips the original VLAN tag in favor
 282    of the specified output-vlan.  This loss of information may make
 283    the mirrored traffic too hard to interpret.
 284
 285    To mirror multiple VLANs, use the commands above, but specify a
 286    comma-separated list of VLANs as the value for select-vlan.  To
 287    mirror every VLAN, use the commands above, but omit select-vlan and
 288    its value entirely.
 289
 290    When a packet arrives on a VLAN that is used as a mirror output
 291    VLAN, the mirror is disregarded.  Instead, in standalone mode, OVS
 292    floods the packet across all the ports for which the mirror output
 293    VLAN is configured.  (If an OpenFlow controller is in use, then it
 294    can override this behavior through the flow table.)  If OVS is used
 295    as an intermediate switch, rather than an edge switch, this ensures
 296    that the RSPAN traffic is distributed through the network.
 297
 298    Mirroring to a VLAN can disrupt a network that contains unmanaged
 299    switches.  See ovs-vswitchd.conf.db(5) for details.  Mirroring to a
 300    GRE tunnel has fewer caveats than mirroring to a VLAN and should
 301    generally be preferred.
 302
 303 Q: How do I configure mirroring of all traffic to a GRE tunnel?
 304
 305 A: The following commands configure br0 with eth0 and tap0 as trunk
 306    ports.  All traffic coming in or going out on eth0 or tap0 is also
 307    mirrored to gre0, a GRE tunnel to the remote host 192.168.1.10; any
 308    traffic arriving on gre0 is dropped:
 309
 310        ovs-vsctl add-br br0
 311        ovs-vsctl add-port br0 eth0
 312        ovs-vsctl add-port br0 tap0
 313        ovs-vsctl add-port br0 gre0 \
 314            -- set interface gre0 type=gre options:remote_ip=192.168.1.10 \
 315            -- --id=@p get port gre0 \
 316            -- --id=@m create mirror name=m0 select-all=true output-port=@p \
 317            -- set bridge br0 mirrors=@m
 318
 319    To later disable mirroring and destroy the GRE tunnel:
 320
 321        ovs-vsctl clear bridge br0 mirrors
 322        ovs-vcstl del-port br0 gre0
 323
 324 Q: Does Open vSwitch support ERSPAN?
 325
 326 A: No.  ERSPAN is an undocumented proprietary protocol.  As an
 327    alternative, Open vSwitch supports mirroring to a GRE tunnel (see
 328    above).
 329
 330 Q: How do I connect two bridges?
 331
 332 A: First, why do you want to do this?  Two connected bridges are not
 333    much different from a single bridge, so you might as well just have
 334    a single bridge with all your ports on it.
 335
 336    If you still want to connect two bridges, you can use a pair of
 337    patch ports.  The following example creates bridges br0 and br1,
 338    adds eth0 and tap0 to br0, adds tap1 to br1, and then connects br0
 339    and br1 with a pair of patch ports.
 340
 341        ovs-vsctl add-br br0
 342        ovs-vsctl add-port br0 eth0
 343        ovs-vsctl add-port br0 tap0
 344        ovs-vsctl add-br br1
 345        ovs-vsctl add-port br1 tap1
 346        ovs-vsctl \
 347            -- add-port br0 patch0 \
 348            -- set interface patch0 type=patch options:peer=patch1 \
 349            -- add-port br1 patch1 \
 350            -- set interface patch1 type=patch options:peer=patch0
 351
 352    Bridges connected with patch ports are much like a single bridge.
 353    For instance, if the example above also added eth1 to br1, and both
 354    eth0 and eth1 happened to be connected to the same next-hop switch,
 355    then you could loop your network just as you would if you added
 356    eth0 and eth1 to the same bridge (see the "Configuration Problems"
 357    section below for more information).
 358
 359    If you are using Open vSwitch 1.9 or an earlier version, then you
 360    need to be using the kernel module bundled with Open vSwitch rather
 361    than the one that is integrated into Linux 3.3 and later, because
 362    Open vSwitch 1.9 and earlier versions need kernel support for patch
 363    ports.  This also means that in Open vSwitch 1.9 and earlier, patch
 364    ports will not work with the userspace datapath, only with the
 365    kernel module.
 366
 367 Q: Why are there so many different ways to dump flows?
 368
 369 A: Open vSwitch uses different kinds of flows for different purposes:
 370
 371       - OpenFlow flows are the most important kind of flow.  OpenFlow
 372         controllers use these flows to define a switch's policy.
 373         OpenFlow flows support wildcards, priorities, and multiple
 374         tables.
 375
 376         When in-band control is in use, Open vSwitch sets up a few
 377         "hidden" flows, with priority higher than a controller or the
 378         user can configure, that are not visible via OpenFlow.  (See
 379         the "Controller" section of the FAQ for more information
 380         about hidden flows.)
 381
 382       - The Open vSwitch software switch implementation uses a second
 383         kind of flow internally.  These flows, called "exact-match"
 384         or "datapath" or "kernel" flows, do not support wildcards or
 385         priorities and comprise only a single table, which makes them
 386         suitable for caching.   OpenFlow flows and exact-match flows
 387         also support different actions and number ports differently.
 388
 389         Exact-match flows are an implementation detail that is
 390         subject to change in future versions of Open vSwitch.  Even
 391         with the current version of Open vSwitch, hardware switch
 392         implementations do not necessarily use exact-match flows.
 393
 394   Each of the commands for dumping flows has a different purpose:
 395
 396       - "ovs-ofctl dump-flows <br>" dumps OpenFlow flows, excluding
 397         hidden flows.  This is the most commonly useful form of flow
 398         dump.  (Unlike the other commands, this should work with any
 399         OpenFlow switch, not just Open vSwitch.)
 400
 401       - "ovs-appctl bridge/dump-flows <br>" dumps OpenFlow flows,
 402         including hidden flows.  This is occasionally useful for
 403         troubleshooting suspected issues with in-band control.
 404
 405       - "ovs-dpctl dump-flows [dp]" dumps the exact-match flow table
 406         entries for a Linux kernel-based datapath.  In Open vSwitch
 407         1.10 and later, ovs-vswitchd merges multiple switches into a
 408         single datapath, so it will show all the flows on all your
 409         kernel-based switches.  This command can occasionally be
 410         useful for debugging.
 411
 412       - "ovs-appctl dpif/dump-flows <br>", new in Open vSwitch 1.10,
 413         dumps exact-match flows for only the specified bridge,
 414         regardless of the type.
 415
 416
 417 Configuration Problems
 418 ----------------------
 419
 420 Q: I created a bridge and added my Ethernet port to it, using commands
 421    like these:
 422
 423        ovs-vsctl add-br br0
 424        ovs-vsctl add-port br0 eth0
 425
 426    and as soon as I ran the "add-port" command I lost all connectivity
 427    through eth0.  Help!
 428
 429 A: A physical Ethernet device that is part of an Open vSwitch bridge
 430    should not have an IP address.  If one does, then that IP address
 431    will not be fully functional.
 432
 433    You can restore functionality by moving the IP address to an Open
 434    vSwitch "internal" device, such as the network device named after
 435    the bridge itself.  For example, assuming that eth0's IP address is
 436    192.168.128.5, you could run the commands below to fix up the
 437    situation:
 438
 439        ifconfig eth0 0.0.0.0
 440        ifconfig br0 192.168.128.5
 441
 442    (If your only connection to the machine running OVS is through the
 443    IP address in question, then you would want to run all of these
 444    commands on a single command line, or put them into a script.)  If
 445    there were any additional routes assigned to eth0, then you would
 446    also want to use commands to adjust these routes to go through br0.
 447
 448    If you use DHCP to obtain an IP address, then you should kill the
 449    DHCP client that was listening on the physical Ethernet interface
 450    (e.g. eth0) and start one listening on the internal interface
 451    (e.g. br0).  You might still need to manually clear the IP address
 452    from the physical interface (e.g. with "ifconfig eth0 0.0.0.0").
 453
 454    There is no compelling reason why Open vSwitch must work this way.
 455    However, this is the way that the Linux kernel bridge module has
 456    always worked, so it's a model that those accustomed to Linux
 457    bridging are already used to.  Also, the model that most people
 458    expect is not implementable without kernel changes on all the
 459    versions of Linux that Open vSwitch supports.
 460
 461    By the way, this issue is not specific to physical Ethernet
 462    devices.  It applies to all network devices except Open vswitch
 463    "internal" devices.
 464
 465 Q: I created a bridge and added a couple of Ethernet ports to it,
 466    using commands like these:
 467
 468        ovs-vsctl add-br br0
 469        ovs-vsctl add-port br0 eth0
 470        ovs-vsctl add-port br0 eth1
 471
 472    and now my network seems to have melted: connectivity is unreliable
 473    (even connectivity that doesn't go through Open vSwitch), all the
 474    LEDs on my physical switches are blinking, wireshark shows
 475    duplicated packets, and CPU usage is very high.
 476
 477 A: More than likely, you've looped your network.  Probably, eth0 and
 478    eth1 are connected to the same physical Ethernet switch.  This
 479    yields a scenario where OVS receives a broadcast packet on eth0 and
 480    sends it out on eth1, then the physical switch connected to eth1
 481    sends the packet back on eth0, and so on forever.  More complicated
 482    scenarios, involving a loop through multiple switches, are possible
 483    too.
 484
 485    The solution depends on what you are trying to do:
 486
 487        - If you added eth0 and eth1 to get higher bandwidth or higher
 488          reliability between OVS and your physical Ethernet switch,
 489          use a bond.  The following commands create br0 and then add
 490          eth0 and eth1 as a bond:
 491
 492              ovs-vsctl add-br br0
 493              ovs-vsctl add-bond br0 bond0 eth0 eth1
 494
 495          Bonds have tons of configuration options.  Please read the
 496          documentation on the Port table in ovs-vswitchd.conf.db(5)
 497          for all the details.
 498
 499        - Perhaps you don't actually need eth0 and eth1 to be on the
 500          same bridge.  For example, if you simply want to be able to
 501          connect each of them to virtual machines, then you can put
 502          each of them on a bridge of its own:
 503
 504              ovs-vsctl add-br br0
 505              ovs-vsctl add-port br0 eth0
 506
 507              ovs-vsctl add-br br1
 508              ovs-vsctl add-port br1 eth1
 509
 510          and then connect VMs to br0 and br1.  (A potential
 511          disadvantage is that traffic cannot directly pass between br0
 512          and br1.  Instead, it will go out eth0 and come back in eth1,
 513          or vice versa.)
 514
 515        - If you have a redundant or complex network topology and you
 516          want to prevent loops, turn on spanning tree protocol (STP).
 517          The following commands create br0, enable STP, and add eth0
 518          and eth1 to the bridge.  The order is important because you
 519          don't want have to have a loop in your network even
 520          transiently:
 521
 522              ovs-vsctl add-br br0
 523              ovs-vsctl set bridge br0 stp_enable=true
 524              ovs-vsctl add-port br0 eth0
 525              ovs-vsctl add-port br0 eth1
 526
 527          The Open vSwitch implementation of STP is not well tested.
 528          Please report any bugs you observe, but if you'd rather avoid
 529          acting as a beta tester then another option might be your
 530          best shot.
 531
 532 Q: I can't seem to use Open vSwitch in a wireless network.
 533
 534 A: Wireless base stations generally only allow packets with the source
 535    MAC address of NIC that completed the initial handshake.
 536    Therefore, without MAC rewriting, only a single device can
 537    communicate over a single wireless link.
 538
 539    This isn't specific to Open vSwitch, it's enforced by the access
 540    point, so the same problems will show up with the Linux bridge or
 541    any other way to do bridging.
 542
 543 Q: I can't seem to add my PPP interface to an Open vSwitch bridge.
 544
 545 A: PPP most commonly carries IP packets, but Open vSwitch works only
 546    with Ethernet frames.  The correct way to interface PPP to an
 547    Ethernet network is usually to use routing instead of switching.
 548
 549 Q: Is there any documentation on the database tables and fields?
 550
 551 A: Yes.  ovs-vswitchd.conf.db(5) is a comprehensive reference.
 552
 553 Q: When I run ovs-dpctl I no longer see the bridges I created.  Instead,
 554    I only see a datapath called "ovs-system".  How can I see datapath
 555    information about a particular bridge?
 556
 557 A: In version 1.9.0, OVS switched to using a single datapath that is
 558    shared by all bridges of that type.  The "ovs-appctl dpif/*"
 559    commands provide similar functionality that is scoped by the bridge.
 560
 561
 562 Quality of Service (QoS)
 563 ------------------------
 564
 565 Q: How do I configure Quality of Service (QoS)?
 566
 567 A: Suppose that you want to set up bridge br0 connected to physical
 568    Ethernet port eth0 (a 1 Gbps device) and virtual machine interfaces
 569    vif1.0 and vif2.0, and that you want to limit traffic from vif1.0
 570    to eth0 to 10 Mbps and from vif2.0 to eth0 to 20 Mbps.  Then, you
 571    could configure the bridge this way:
 572
 573        ovs-vsctl -- \
 574            add-br br0 -- \
 575            add-port br0 eth0 -- \
 576            add-port br0 vif1.0 -- set interface vif1.0 ofport_request=5 -- \
 577            add-port br0 vif2.0 -- set interface vif2.0 ofport_request=6 -- \
 578            set port eth0 qos=@newqos -- \
 579            --id=@newqos create qos type=linux-htb \
 580                other-config:max-rate=1000000000 \
 581                queues:123=@vif10queue \
 582                queues:234=@vif20queue -- \
 583            --id=@vif10queue create queue other-config:max-rate=10000000 -- \
 584            --id=@vif20queue create queue other-config:max-rate=20000000
 585
 586    At this point, bridge br0 is configured with the ports and eth0 is
 587    configured with the queues that you need for QoS, but nothing is
 588    actually directing packets from vif1.0 or vif2.0 to the queues that
 589    we have set up for them.  That means that all of the packets to
 590    eth0 are going to the "default queue", which is not what we want.
 591
 592    We use OpenFlow to direct packets from vif1.0 and vif2.0 to the
 593    queues reserved for them:
 594
 595        ovs-ofctl add-flow br0 in_port=5,actions=set_queue:123,normal
 596        ovs-ofctl add-flow br0 in_port=6,actions=set_queue:234,normal
 597
 598    Each of the above flows matches on the input port, sets up the
 599    appropriate queue (123 for vif1.0, 234 for vif2.0), and then
 600    executes the "normal" action, which performs the same switching
 601    that Open vSwitch would have done without any OpenFlow flows being
 602    present.  (We know that vif1.0 and vif2.0 have OpenFlow port
 603    numbers 5 and 6, respectively, because we set their ofport_request
 604    columns above.  If we had not done that, then we would have needed
 605    to find out their port numbers before setting up these flows.)
 606
 607    Now traffic going from vif1.0 or vif2.0 to eth0 should be
 608    rate-limited.
 609
 610    By the way, if you delete the bridge created by the above commands,
 611    with:
 612
 613        ovs-vsctl del-br br0
 614
 615    then that will leave one unreferenced QoS record and two
 616    unreferenced Queue records in the Open vSwich database.  One way to
 617    clear them out, assuming you don't have other QoS or Queue records
 618    that you want to keep, is:
 619
 620        ovs-vsctl -- --all destroy QoS -- --all destroy Queue
 621
 622    If you do want to keep some QoS or Queue records, or the Open
 623    vSwitch you are using is older than version 1.8 (which added the
 624    --all option), then you will have to destroy QoS and Queue records
 625    individually.
 626
 627 Q: I configured Quality of Service (QoS) in my OpenFlow network by
 628    adding records to the QoS and Queue table, but the results aren't
 629    what I expect.
 630
 631 A: Did you install OpenFlow flows that use your queues?  This is the
 632    primary way to tell Open vSwitch which queues you want to use.  If
 633    you don't do this, then the default queue will be used, which will
 634    probably not have the effect you want.
 635
 636    Refer to the previous question for an example.
 637
 638 Q: I configured QoS, correctly, but my measurements show that it isn't
 639    working as well as I expect.
 640
 641 A: With the Linux kernel, the Open vSwitch implementation of QoS has
 642    two aspects:
 643
 644        - Open vSwitch configures a subset of Linux kernel QoS
 645          features, according to what is in OVSDB.  It is possible that
 646          this code has bugs.  If you believe that this is so, then you
 647          can configure the Linux traffic control (QoS) stack directly
 648          with the "tc" program.  If you get better results that way,
 649          you can send a detailed bug report to bugs@openvswitch.org.
 650
 651          It is certain that Open vSwitch cannot configure every Linux
 652          kernel QoS feature.  If you need some feature that OVS cannot
 653          configure, then you can also use "tc" directly (or add that
 654          feature to OVS).
 655
 656        - The Open vSwitch implementation of OpenFlow allows flows to
 657          be directed to particular queues.  This is pretty simple and
 658          unlikely to have serious bugs at this point.
 659
 660    However, most problems with QoS on Linux are not bugs in Open
 661    vSwitch at all.  They tend to be either configuration errors
 662    (please see the earlier questions in this section) or issues with
 663    the traffic control (QoS) stack in Linux.  The Open vSwitch
 664    developers are not experts on Linux traffic control.  We suggest
 665    that, if you believe you are encountering a problem with Linux
 666    traffic control, that you consult the tc manpages (e.g. tc(8),
 667    tc-htb(8), tc-hfsc(8)), web resources (e.g. http://lartc.org/), or
 668    mailing lists (e.g. http://vger.kernel.org/vger-lists.html#netdev).
 669
 670
 671 VLANs
 672 -----
 673
 674 Q: What's a VLAN?
 675
 676 A: At the simplest level, a VLAN (short for "virtual LAN") is a way to
 677    partition a single switch into multiple switches.  Suppose, for
 678    example, that you have two groups of machines, group A and group B.
 679    You want the machines in group A to be able to talk to each other,
 680    and you want the machine in group B to be able to talk to each
 681    other, but you don't want the machines in group A to be able to
 682    talk to the machines in group B.  You can do this with two
 683    switches, by plugging the machines in group A into one switch and
 684    the machines in group B into the other switch.
 685
 686    If you only have one switch, then you can use VLANs to do the same
 687    thing, by configuring the ports for machines in group A as VLAN
 688    "access ports" for one VLAN and the ports for group B as "access
 689    ports" for a different VLAN.  The switch will only forward packets
 690    between ports that are assigned to the same VLAN, so this
 691    effectively subdivides your single switch into two independent
 692    switches, one for each group of machines.
 693
 694    So far we haven't said anything about VLAN headers.  With access
 695    ports, like we've described so far, no VLAN header is present in
 696    the Ethernet frame.  This means that the machines (or switches)
 697    connected to access ports need not be aware that VLANs are
 698    involved, just like in the case where we use two different physical
 699    switches.
 700
 701    Now suppose that you have a whole bunch of switches in your
 702    network, instead of just one, and that some machines in group A are
 703    connected directly to both switches 1 and 2.  To allow these
 704    machines to talk to each other, you could add an access port for
 705    group A's VLAN to switch 1 and another to switch 2, and then
 706    connect an Ethernet cable between those ports.  That works fine,
 707    but it doesn't scale well as the number of switches and the number
 708    of VLANs increases, because you use up a lot of valuable switch
 709    ports just connecting together your VLANs.
 710
 711    This is where VLAN headers come in.  Instead of using one cable and
 712    two ports per VLAN to connect a pair of switches, we configure a
 713    port on each switch as a VLAN "trunk port".  Packets sent and
 714    received on a trunk port carry a VLAN header that says what VLAN
 715    the packet belongs to, so that only two ports total are required to
 716    connect the switches, regardless of the number of VLANs in use.
 717    Normally, only switches (either physical or virtual) are connected
 718    to a trunk port, not individual hosts, because individual hosts
 719    don't expect to see a VLAN header in the traffic that they receive.
 720
 721    None of the above discussion says anything about particular VLAN
 722    numbers.  This is because VLAN numbers are completely arbitrary.
 723    One must only ensure that a given VLAN is numbered consistently
 724    throughout a network and that different VLANs are given different
 725    numbers.  (That said, VLAN 0 is usually synonymous with a packet
 726    that has no VLAN header, and VLAN 4095 is reserved.)
 727
 728 Q: VLANs don't work.
 729
 730 A: Many drivers in Linux kernels before version 3.3 had VLAN-related
 731    bugs.  If you are having problems with VLANs that you suspect to be
 732    driver related, then you have several options:
 733
 734        - Upgrade to Linux 3.3 or later.
 735
 736        - Build and install a fixed version of the particular driver
 737          that is causing trouble, if one is available.
 738
 739        - Use a NIC whose driver does not have VLAN problems.
 740
 741        - Use "VLAN splinters", a feature in Open vSwitch 1.4 and later
 742          that works around bugs in kernel drivers.  To enable VLAN
 743          splinters on interface eth0, use the command:
 744
 745            ovs-vsctl set interface eth0 other-config:enable-vlan-splinters=true
 746
 747          For VLAN splinters to be effective, Open vSwitch must know
 748          which VLANs are in use.  See the "VLAN splinters" section in
 749          the Interface table in ovs-vswitchd.conf.db(5) for details on
 750          how Open vSwitch infers in-use VLANs.
 751
 752          VLAN splinters increase memory use and reduce performance, so
 753          use them only if needed.
 754
 755        - Apply the "vlan workaround" patch from the XenServer kernel
 756          patch queue, build Open vSwitch against this patched kernel,
 757          and then use ovs-vlan-bug-workaround(8) to enable the VLAN
 758          workaround for each interface whose driver is buggy.
 759
 760          (This is a nontrivial exercise, so this option is included
 761          only for completeness.)
 762
 763    It is not always easy to tell whether a Linux kernel driver has
 764    buggy VLAN support.  The ovs-vlan-test(8) and ovs-test(8) utilities
 765    can help you test.  See their manpages for details.  Of the two
 766    utilities, ovs-test(8) is newer and more thorough, but
 767    ovs-vlan-test(8) may be easier to use.
 768
 769 Q: VLANs still don't work.  I've tested the driver so I know that it's OK.
 770
 771 A: Do you have VLANs enabled on the physical switch that OVS is
 772    attached to?  Make sure that the port is configured to trunk the
 773    VLAN or VLANs that you are using with OVS.
 774
 775 Q: Outgoing VLAN-tagged traffic goes through OVS to my physical switch
 776    and to its destination host, but OVS seems to drop incoming return
 777    traffic.
 778
 779 A: It's possible that you have the VLAN configured on your physical
 780    switch as the "native" VLAN.  In this mode, the switch treats
 781    incoming packets either tagged with the native VLAN or untagged as
 782    part of the native VLAN.  It may also send outgoing packets in the
 783    native VLAN without a VLAN tag.
 784
 785    If this is the case, you have two choices:
 786
 787        - Change the physical switch port configuration to tag packets
 788          it forwards to OVS with the native VLAN instead of forwarding
 789          them untagged.
 790
 791        - Change the OVS configuration for the physical port to a
 792          native VLAN mode.  For example, the following sets up a
 793          bridge with port eth0 in "native-tagged" mode in VLAN 9:
 794
 795              ovs-vsctl add-br br0
 796              ovs-vsctl add-port br0 eth0 tag=9 vlan_mode=native-tagged
 797
 798          In this situation, "native-untagged" mode will probably work
 799          equally well.  Refer to the documentation for the Port table
 800          in ovs-vswitchd.conf.db(5) for more information.
 801
 802 Q: I added a pair of VMs on different VLANs, like this:
 803
 804        ovs-vsctl add-br br0
 805        ovs-vsctl add-port br0 eth0
 806        ovs-vsctl add-port br0 tap0 tag=9
 807        ovs-vsctl add-port br0 tap1 tag=10
 808
 809     but the VMs can't access each other, the external network, or the
 810     Internet.
 811
 812 A: It is to be expected that the VMs can't access each other.  VLANs
 813    are a means to partition a network.  When you configured tap0 and
 814    tap1 as access ports for different VLANs, you indicated that they
 815    should be isolated from each other.
 816
 817    As for the external network and the Internet, it seems likely that
 818    the machines you are trying to access are not on VLAN 9 (or 10) and
 819    that the Internet is not available on VLAN 9 (or 10).
 820
 821 Q: I added a pair of VMs on the same VLAN, like this:
 822
 823        ovs-vsctl add-br br0
 824        ovs-vsctl add-port br0 eth0
 825        ovs-vsctl add-port br0 tap0 tag=9
 826        ovs-vsctl add-port br0 tap1 tag=9
 827
 828     The VMs can access each other, but not the external network or the
 829     Internet.
 830
 831 A: It seems likely that the machines you are trying to access in the
 832    external network are not on VLAN 9 and that the Internet is not
 833    available on VLAN 9.  Also, ensure VLAN 9 is set up as an allowed
 834    trunk VLAN on the upstream switch port to which eth0 is connected.
 835
 836 Q: Can I configure an IP address on a VLAN?
 837
 838 A: Yes.  Use an "internal port" configured as an access port.  For
 839    example, the following configures IP address 192.168.0.7 on VLAN 9.
 840    That is, OVS will forward packets from eth0 to 192.168.0.7 only if
 841    they have an 802.1Q header with VLAN 9.  Conversely, traffic
 842    forwarded from 192.168.0.7 to eth0 will be tagged with an 802.1Q
 843    header with VLAN 9:
 844
 845        ovs-vsctl add-br br0
 846        ovs-vsctl add-port br0 eth0
 847        ovs-vsctl add-port br0 vlan9 tag=9 -- set interface vlan9 type=internal
 848        ifconfig vlan9 192.168.0.7
 849
 850 Q: My OpenFlow controller doesn't see the VLANs that I expect.
 851
 852 A: The configuration for VLANs in the Open vSwitch database (e.g. via
 853    ovs-vsctl) only affects traffic that goes through Open vSwitch's
 854    implementation of the OpenFlow "normal switching" action.  By
 855    default, when Open vSwitch isn't connected to a controller and
 856    nothing has been manually configured in the flow table, all traffic
 857    goes through the "normal switching" action.  But, if you set up
 858    OpenFlow flows on your own, through a controller or using ovs-ofctl
 859    or through other means, then you have to implement VLAN handling
 860    yourself.
 861
 862    You can use "normal switching" as a component of your OpenFlow
 863    actions, e.g. by putting "normal" into the lists of actions on
 864    ovs-ofctl or by outputting to OFPP_NORMAL from an OpenFlow
 865    controller.  In situations where this is not suitable, you can
 866    implement VLAN handling yourself, e.g.:
 867
 868        - If a packet comes in on an access port, and the flow table
 869          needs to send it out on a trunk port, then the flow can add
 870          the appropriate VLAN tag with the "mod_vlan_vid" action.
 871
 872        - If a packet comes in on a trunk port, and the flow table
 873          needs to send it out on an access port, then the flow can
 874          strip the VLAN tag with the "strip_vlan" action.
 875
 876 Q: I configured ports on a bridge as access ports with different VLAN
 877    tags, like this:
 878
 879        ovs-vsctl add-br br0
 880        ovs-vsctl set-controller br0 tcp:192.168.0.10:6633
 881        ovs-vsctl add-port br0 eth0
 882        ovs-vsctl add-port br0 tap0 tag=9
 883        ovs-vsctl add-port br0 tap1 tag=10
 884
 885    but the VMs running behind tap0 and tap1 can still communicate,
 886    that is, they are not isolated from each other even though they are
 887    on different VLANs.
 888
 889 A: Do you have a controller configured on br0 (as the commands above
 890    do)?  If so, then this is a variant on the previous question, "My
 891    OpenFlow controller doesn't see the VLANs that I expect," and you
 892    can refer to the answer there for more information.
 893
 894
 895 VXLANs
 896 -----
 897
 898 Q: What's a VXLAN?
 899
 900 A: VXLAN stands for Virtual eXtensible Local Area Network, and is a means
 901    to solve the scaling challenges of VLAN networks in a multi-tenant
 902    environment. VXLAN is an overlay network which transports an L2 network
 903    over an existing L3 network. For more information on VXLAN, please see
 904    the IETF draft available here:
 905
 906    http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-03
 907
 908 Q: How much of the VXLAN protocol does Open vSwitch currently support?
 909
 910 A: Open vSwitch currently supports the framing format for packets on the
 911    wire. There is currently no support for the multicast aspects of VXLAN.
 912    To get around the lack of multicast support, it is possible to
 913    pre-provision MAC to IP address mappings either manually or from a
 914    controller.
 915
 916 Q: What destination UDP port does the VXLAN implementation in Open vSwitch
 917    use?
 918
 919 A: By default, Open vSwitch will use the assigned IANA port for VXLAN, which
 920    is 4789. However, it is possible to configure the destination UDP port
 921    manually on a per-VXLAN tunnel basis. An example of this configuration is
 922    provided below.
 923
 924    ovs-vsctl add-br br0
 925    ovs-vsctl add-port br0 vxlan1 -- set interface vxlan1
 926        type=vxlan options:remote_ip=192.168.1.2 options:key=flow
 927        options:dst_port=8472
 928
 929
 930 Using OpenFlow (Manually or Via Controller)
 931 -------------------------------------------
 932
 933 Q: What versions of OpenFlow does Open vSwitch support?
 934
 935 A: Open vSwitch 1.9 and earlier support only OpenFlow 1.0 (plus
 936    extensions that bring in many of the features from later versions
 937    of OpenFlow).
 938
 939    Open vSwitch versions 1.10 and later will have experimental support
 940    for OpenFlow 1.2 and 1.3.  On these versions of Open vSwitch, the
 941    following command enables OpenFlow 1.0, 1.2, and 1.3 on bridge br0:
 942
 943        ovs-vsctl set bridge br0 protocols=OpenFlow10,OpenFlow12,OpenFlow13
 944
 945    Support for OpenFlow 1.1 is incomplete enough that it cannot yet be
 946    enabled, even experimentally.
 947
 948    Support for OpenFlow 1.2 and 1.3 is still incomplete.  Work to be
 949    done is tracked in OPENFLOW-1.1+ in the Open vSwitch source tree
 950    (also via http://openvswitch.org/development/openflow-1-x-plan/).
 951    When support for a given OpenFlow version is solidly implemented,
 952    Open vSwitch will enable that version by default.
 953
 954 Q: I'm getting "error type 45250 code 0".  What's that?
 955
 956 A: This is a Open vSwitch extension to OpenFlow error codes.  Open
 957    vSwitch uses this extension when it must report an error to an
 958    OpenFlow controller but no standard OpenFlow error code is
 959    suitable.
 960
 961    Open vSwitch logs the errors that it sends to controllers, so the
 962    easiest thing to do is probably to look at the ovs-vswitchd log to
 963    find out what the error was.
 964
 965    If you want to dissect the extended error message yourself, the
 966    format is documented in include/openflow/nicira-ext.h in the Open
 967    vSwitch source distribution.  The extended error codes are
 968    documented in lib/ofp-errors.h.
 969
 970 Q1: Some of the traffic that I'd expect my OpenFlow controller to see
 971     doesn't actually appear through the OpenFlow connection, even
 972     though I know that it's going through.
 973 Q2: Some of the OpenFlow flows that my controller sets up don't seem
 974     to apply to certain traffic, especially traffic between OVS and
 975     the controller itself.
 976
 977 A: By default, Open vSwitch assumes that OpenFlow controllers are
 978    connected "in-band", that is, that the controllers are actually
 979    part of the network that is being controlled.  In in-band mode,
 980    Open vSwitch sets up special "hidden" flows to make sure that
 981    traffic can make it back and forth between OVS and the controllers.
 982    These hidden flows are higher priority than any flows that can be
 983    set up through OpenFlow, and they are not visible through normal
 984    OpenFlow flow table dumps.
 985
 986    Usually, the hidden flows are desirable and helpful, but
 987    occasionally they can cause unexpected behavior.  You can view the
 988    full OpenFlow flow table, including hidden flows, on bridge br0
 989    with the command:
 990
 991        ovs-appctl bridge/dump-flows br0
 992
 993    to help you debug.  The hidden flows are those with priorities
 994    greater than 65535 (the maximum priority that can be set with
 995    OpenFlow).
 996
 997    The DESIGN file at the top level of the Open vSwitch source
 998    distribution describes the in-band model in detail.
 999
1000    If your controllers are not actually in-band (e.g. they are on
1001    localhost via 127.0.0.1, or on a separate network), then you should
1002    configure your controllers in "out-of-band" mode.  If you have one
1003    controller on bridge br0, then you can configure out-of-band mode
1004    on it with:
1005
1006        ovs-vsctl set controller br0 connection-mode=out-of-band
1007
1008 Q: I configured all my controllers for out-of-band control mode but
1009    "ovs-appctl bridge/dump-flows" still shows some hidden flows.
1010
1011 A: You probably have a remote manager configured (e.g. with "ovs-vsctl
1012    set-manager").  By default, Open vSwitch assumes that managers need
1013    in-band rules set up on every bridge.  You can disable these rules
1014    on bridge br0 with:
1015
1016        ovs-vsctl set bridge br0 other-config:disable-in-band=true
1017
1018    This actually disables in-band control entirely for the bridge, as
1019    if all the bridge's controllers were configured for out-of-band
1020    control.
1021
1022 Q: My OpenFlow controller doesn't see the VLANs that I expect.
1023
1024 A: See answer under "VLANs", above.
1025
1026 Q: I ran "ovs-ofctl add-flow br0 nw_dst=192.168.0.1,actions=drop"
1027    but I got a funny message like this:
1028
1029        ofp_util|INFO|normalization changed ofp_match, details:
1030        ofp_util|INFO| pre: nw_dst=192.168.0.1
1031        ofp_util|INFO|post:
1032
1033    and when I ran "ovs-ofctl dump-flows br0" I saw that my nw_dst
1034    match had disappeared, so that the flow ends up matching every
1035    packet.
1036
1037 A: The term "normalization" in the log message means that a flow
1038    cannot match on an L3 field without saying what L3 protocol is in
1039    use.  The "ovs-ofctl" command above didn't specify an L3 protocol,
1040    so the L3 field match was dropped.
1041
1042    In this case, the L3 protocol could be IP or ARP.  A correct
1043    command for each possibility is, respectively:
1044
1045        ovs-ofctl add-flow br0 ip,nw_dst=192.168.0.1,actions=drop
1046
1047    and
1048
1049        ovs-ofctl add-flow br0 arp,nw_dst=192.168.0.1,actions=drop
1050
1051    Similarly, a flow cannot match on an L4 field without saying what
1052    L4 protocol is in use.  For example, the flow match "tp_src=1234"
1053    is, by itself, meaningless and will be ignored.  Instead, to match
1054    TCP source port 1234, write "tcp,tp_src=1234", or to match UDP
1055    source port 1234, write "udp,tp_src=1234".
1056
1057 Q: How can I figure out the OpenFlow port number for a given port?
1058
1059 A: The OFPT_FEATURES_REQUEST message requests an OpenFlow switch to
1060    respond with an OFPT_FEATURES_REPLY that, among other information,
1061    includes a mapping between OpenFlow port names and numbers.  From a
1062    command prompt, "ovs-ofctl show br0" makes such a request and
1063    prints the response for switch br0.
1064
1065    The Interface table in the Open vSwitch database also maps OpenFlow
1066    port names to numbers.  To print the OpenFlow port number
1067    associated with interface eth0, run:
1068
1069        ovs-vsctl get Interface eth0 ofport
1070
1071    You can print the entire mapping with:
1072
1073        ovs-vsctl -- --columns=name,ofport list Interface
1074
1075    but the output mixes together interfaces from all bridges in the
1076    database, so it may be confusing if more than one bridge exists.
1077
1078    In the Open vSwitch database, ofport value -1 means that the
1079    interface could not be created due to an error.  (The Open vSwitch
1080    log should indicate the reason.)  ofport value [] (the empty set)
1081    means that the interface hasn't been created yet.  The latter is
1082    normally an intermittent condition (unless ovs-vswitchd is not
1083    running).
1084
1085 Q: I added some flows with my controller or with ovs-ofctl, but when I
1086    run "ovs-dpctl dump-flows" I don't see them.
1087
1088 A: ovs-dpctl queries a kernel datapath, not an OpenFlow switch.  It
1089    won't display the information that you want.  You want to use
1090    "ovs-ofctl dump-flows" instead.
1091
1092 Q: It looks like each of the interfaces in my bonded port shows up
1093    as an individual OpenFlow port.  Is that right?
1094
1095 A: Yes, Open vSwitch makes individual bond interfaces visible as
1096    OpenFlow ports, rather than the bond as a whole.  The interfaces
1097    are treated together as a bond for only a few purposes:
1098
1099        - Sending a packet to the OFPP_NORMAL port.  (When an OpenFlow
1100          controller is not configured, this happens implicitly to
1101          every packet.)
1102
1103        - Mirrors configured for output to a bonded port.
1104
1105    It would make a lot of sense for Open vSwitch to present a bond as
1106    a single OpenFlow port.  If you want to contribute an
1107    implementation of such a feature, please bring it up on the Open
1108    vSwitch development mailing list at dev@openvswitch.org.
1109
1110 Q: I have a sophisticated network setup involving Open vSwitch, VMs or
1111    multiple hosts, and other components.  The behavior isn't what I
1112    expect.  Help!
1113
1114 A: To debug network behavior problems, trace the path of a packet,
1115    hop-by-hop, from its origin in one host to a remote host.  If
1116    that's correct, then trace the path of the response packet back to
1117    the origin.
1118
1119    Usually a simple ICMP echo request and reply ("ping") packet is
1120    good enough.  Start by initiating an ongoing "ping" from the origin
1121    host to a remote host.  If you are tracking down a connectivity
1122    problem, the "ping" will not display any successful output, but
1123    packets are still being sent.  (In this case the packets being sent
1124    are likely ARP rather than ICMP.)
1125
1126    Tools available for tracing include the following:
1127
1128        - "tcpdump" and "wireshark" for observing hops across network
1129          devices, such as Open vSwitch internal devices and physical
1130          wires.
1131
1132        - "ovs-appctl dpif/dump-flows <br>" in Open vSwitch 1.10 and
1133          later or "ovs-dpctl dump-flows <br>" in earlier versions.
1134          These tools allow one to observe the actions being taken on
1135          packets in ongoing flows.
1136
1137          See ovs-vswitchd(8) for "ovs-appctl dpif/dump-flows"
1138          documentation, ovs-dpctl(8) for "ovs-dpctl dump-flows"
1139          documentation, and "Why are there so many different ways to
1140          dump flows?" above for some background.
1141
1142        - "ovs-appctl ofproto/trace" to observe the logic behind how
1143          ovs-vswitchd treats packets.  See ovs-vswitchd(8) for
1144          documentation.  You can out more details about a given flow
1145          that "ovs-dpctl dump-flows" displays, by cutting and pasting
1146          a flow from the output into an "ovs-appctl ofproto/trace"
1147          command.
1148
1149        - SPAN, RSPAN, and ERSPAN features of physical switches, to
1150          observe what goes on at these physical hops.
1151
1152    Starting at the origin of a given packet, observe the packet at
1153    each hop in turn.  For example, in one plausible scenario, you
1154    might:
1155
1156        1. "tcpdump" the "eth" interface through which an ARP egresses
1157           a VM, from inside the VM.
1158
1159        2. "tcpdump" the "vif" or "tap" interface through which the ARP
1160           ingresses the host machine.
1161
1162        3. Use "ovs-dpctl dump-flows" to spot the ARP flow and observe
1163           the host interface through which the ARP egresses the
1164           physical machine.  You may need to use "ovs-dpctl show" to
1165           interpret the port numbers.  If the output seems surprising,
1166           you can use "ovs-appctl ofproto/trace" to observe details of
1167           how ovs-vswitchd determined the actions in the "ovs-dpctl
1168           dump-flows" output.
1169
1170        4. "tcpdump" the "eth" interface through which the ARP egresses
1171           the physical machine.
1172
1173        5. "tcpdump" the "eth" interface through which the ARP
1174           ingresses the physical machine, at the remote host that
1175           receives the ARP.
1176
1177        6. Use "ovs-dpctl dump-flows" to spot the ARP flow on the
1178           remote host that receives the ARP and observe the VM "vif"
1179           or "tap" interface to which the flow is directed.  Again,
1180           "ovs-dpctl show" and "ovs-appctl ofproto/trace" might help.
1181
1182        7. "tcpdump" the "vif" or "tap" interface to which the ARP is
1183           directed.
1184
1185        8. "tcpdump" the "eth" interface through which the ARP
1186           ingresses a VM, from inside the VM.
1187
1188    It is likely that during one of these steps you will figure out the
1189    problem.  If not, then follow the ARP reply back to the origin, in
1190    reverse.
1191
1192 Q: How do I make a flow drop packets?
1193
1194 A: An empty set of actions causes a packet to be dropped.  You can
1195    specify an empty set of actions with "actions=" on the ovs-ofctl
1196    command line.  For example:
1197
1198        ovs-ofctl add-flow br0 priority=65535,actions=
1199
1200    would cause every packet entering switch br0 to be dropped.
1201
1202    You can write "drop" explicitly if you like.  The effect is the
1203    same.  Thus, the following command also causes every packet
1204    entering switch br0 to be dropped:
1205
1206        ovs-ofctl add-flow br0 priority=65535,actions=drop
1207
1208
1209 Contact
1210 -------
1211
1212 bugs@openvswitch.org
1213 http://openvswitch.org/