projects / mirror_ovs.git / blame
| Commit | Line | Data |
|---|---|---|
| edde4861 SF |
1 | .. |
| 2 | Licensed under the Apache License, Version 2.0 (the "License"); you may | |
| 3 | not use this file except in compliance with the License. You may obtain | |
| 4 | a copy of the License at | |
| 5 | ||
| 6 | http://www.apache.org/licenses/LICENSE-2.0 | |
| 7 | ||
| 8 | Unless required by applicable law or agreed to in writing, software | |
| 9 | distributed under the License is distributed on an "AS IS" BASIS, WITHOUT | |
| 10 | WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the | |
| 11 | License for the specific language governing permissions and limitations | |
| 12 | under the License. | |
| 13 | ||
| 14 | Convention for heading levels in Open vSwitch documentation: | |
| 15 | ||
| 16 | ======= Heading 0 (reserved for the title in a document) | |
| 17 | ------- Heading 1 | |
| 18 | ~~~~~~~ Heading 2 | |
| 19 | +++++++ Heading 3 | |
| 20 | ''''''' Heading 4 | |
| 21 | ||
| 22 | Avoid deeper levels because they do not render well. | |
| 23 | ||
| 24 | ========================== | |
| 25 | Frequently Asked Questions | |
| 26 | ========================== | |
| 27 | ||
| 28 | General | |
| 29 | ------- | |
| 30 | ||
| 31 | Q: What is Open vSwitch? | |
| 32 | ||
| 33 | A: Open vSwitch is a production quality open source software switch | |
| 34 | designed to be used as a vswitch in virtualized server environments. A | |
| 35 | vswitch forwards traffic between different VMs on the same physical host | |
| 36 | and also forwards traffic between VMs and the physical network. Open | |
| 37 | vSwitch supports standard management interfaces (e.g. sFlow, NetFlow, | |
| 38 | IPFIX, RSPAN, CLI), and is open to programmatic extension and control using | |
| 39 | OpenFlow and the OVSDB management protocol. | |
| 40 | ||
| 41 | Open vSwitch as designed to be compatible with modern switching chipsets. | |
| 42 | This means that it can be ported to existing high-fanout switches allowing | |
| 43 | the same flexible control of the physical infrastructure as the virtual | |
| 44 | infrastructure. It also means that Open vSwitch will be able to take | |
| 45 | advantage of on-NIC switching chipsets as their functionality matures. | |
| 46 | ||
| 47 | Q: What virtualization platforms can use Open vSwitch? | |
| 48 | ||
| 49 | A: Open vSwitch can currently run on any Linux-based virtualization | |
| 50 | platform (kernel 3.10 and newer), including: KVM, VirtualBox, Xen, Xen | |
| 51 | Cloud Platform, XenServer. As of Linux 3.3 it is part of the mainline | |
| 52 | kernel. The bulk of the code is written in platform- independent C and is | |
| 53 | easily ported to other environments. We welcome inquires about integrating | |
| 54 | Open vSwitch with other virtualization platforms. | |
| 55 | ||
| 56 | Q: How can I try Open vSwitch? | |
| 57 | ||
| 58 | A: The Open vSwitch source code can be built on a Linux system. You can | |
| 59 | build and experiment with Open vSwitch on any Linux machine. Packages for | |
| 60 | various Linux distributions are available on many platforms, including: | |
| 61 | Debian, Ubuntu, Fedora. | |
| 62 | ||
| 63 | You may also download and run a virtualization platform that already has | |
| 64 | Open vSwitch integrated. For example, download a recent ISO for XenServer | |
| 65 | or Xen Cloud Platform. Be aware that the version integrated with a | |
| 66 | particular platform may not be the most recent Open vSwitch release. | |
| 67 | ||
| 68 | Q: Does Open vSwitch only work on Linux? | |
| 69 | ||
| 70 | A: No, Open vSwitch has been ported to a number of different operating | |
| 71 | systems and hardware platforms. Most of the development work occurs on | |
| 72 | Linux, but the code should be portable to any POSIX system. We've seen | |
| 73 | Open vSwitch ported to a number of different platforms, including FreeBSD, | |
| 74 | Windows, and even non-POSIX embedded systems. | |
| 75 | ||
| 76 | By definition, the Open vSwitch Linux kernel module only works on Linux and | |
| 77 | will provide the highest performance. However, a userspace datapath is | |
| 78 | available that should be very portable. | |
| 79 | ||
| 80 | Q: What's involved with porting Open vSwitch to a new platform or switching ASIC? | |
| 81 | ||
| 82 | A: The `porting document <PORTING.rst>`__ describes how one would go about | |
| 83 | porting Open vSwitch to a new operating system or hardware platform. | |
| 84 | ||
| 85 | Q: Why would I use Open vSwitch instead of the Linux bridge? | |
| 86 | ||
| 87 | A: Open vSwitch is specially designed to make it easier to manage VM | |
| 88 | network configuration and monitor state spread across many physical hosts | |
| 89 | in dynamic virtualized environments. Refer to `WHY-OVS <WHY-OVS.rst>`__ | |
| 90 | for a more detailed description of how Open vSwitch relates to the Linux | |
| 91 | Bridge. | |
| 92 | ||
| 93 | Q: How is Open vSwitch related to distributed virtual switches like the VMware | |
| 94 | vNetwork distributed switch or the Cisco Nexus 1000V? | |
| 95 | ||
| 96 | A: Distributed vswitch applications (e.g., VMware vNetwork distributed | |
| 97 | switch, Cisco Nexus 1000V) provide a centralized way to configure and | |
| 98 | monitor the network state of VMs that are spread across many physical | |
| 99 | hosts. Open vSwitch is not a distributed vswitch itself, rather it runs on | |
| 100 | each physical host and supports remote management in a way that makes it | |
| 101 | easier for developers of virtualization/cloud management platforms to offer | |
| 102 | distributed vswitch capabilities. | |
| 103 | ||
| 104 | To aid in distribution, Open vSwitch provides two open protocols that are | |
| 105 | specially designed for remote management in virtualized network | |
| 106 | environments: OpenFlow, which exposes flow-based forwarding state, and the | |
| 107 | OVSDB management protocol, which exposes switch port state. In addition to | |
| 108 | the switch implementation itself, Open vSwitch includes tools (ovs-ofctl, | |
| 109 | ovs-vsctl) that developers can script and extend to provide distributed | |
| 110 | vswitch capabilities that are closely integrated with their virtualization | |
| 111 | management platform. | |
| 112 | ||
| 113 | Q: Why doesn't Open vSwitch support distribution? | |
| 114 | ||
| 115 | A: Open vSwitch is intended to be a useful component for building flexible | |
| 116 | network infrastructure. There are many different approaches to distribution | |
| 117 | which balance trade-offs between simplicity, scalability, hardware | |
| 118 | compatibility, convergence times, logical forwarding model, etc. The goal | |
| 119 | of Open vSwitch is to be able to support all as a primitive building block | |
| 120 | rather than choose a particular point in the distributed design space. | |
| 121 | ||
| 122 | Q: How can I contribute to the Open vSwitch Community? | |
| 123 | ||
| 124 | A: You can start by joining the mailing lists and helping to answer | |
| 125 | questions. You can also suggest improvements to documentation. If you | |
| 126 | have a feature or bug you would like to work on, send a mail to `one of the | |
| 8bb0434a | 127 | mailing lists <http://openvswitch.org/mlists/>`__. |
| edde4861 SF |
128 | |
| 129 | Q: Why can I no longer connect to my OpenFlow controller or OVSDB manager? | |
| 130 | ||
| 131 | A: Starting in OVS 2.4, we switched the default ports to the IANA-specified | |
| 132 | port numbers for OpenFlow (6633->6653) and OVSDB (6632->6640). We | |
| 133 | recommend using these port numbers, but if you cannot, all the programs | |
| 134 | allow overriding the default port. See the appropriate man page. | |
| 135 | ||
| 136 | Releases | |
| 137 | -------- | |
| 138 | ||
| 139 | Q: What does it mean for an Open vSwitch release to be LTS (long-term support)? | |
| 140 | ||
| 141 | A: All official releases have been through a comprehensive testing process | |
| 142 | and are suitable for production use. Planned releases occur twice a year. | |
| 143 | If a significant bug is identified in an LTS release, we will provide an | |
| 144 | updated release that includes the fix. Releases that are not LTS may not | |
| 145 | be fixed and may just be supplanted by the next major release. The current | |
| 7169d4fd | 146 | LTS release is 2.5.x. |
| edde4861 | 147 | |
| 8bb0434a | 148 | For more information on the Open vSwitch release process, refer to `release |
| f8e5a539 | 149 | process <Documentation/release-process.rst>`__. |
| edde4861 SF |
150 | |
| 151 | Q: What Linux kernel versions does each Open vSwitch release work with? | |
| 152 | ||
| 153 | A: The following table lists the Linux kernel versions against which the | |
| 154 | given versions of the Open vSwitch kernel module will successfully build. | |
| 155 | The Linux kernel versions are upstream kernel versions, so Linux kernels | |
| 156 | modified from the upstream sources may not build in some cases even if they | |
| 157 | are based on a supported version. This is most notably true of Red Hat | |
| 158 | Enterprise Linux (RHEL) kernels, which are extensively modified from | |
| 159 | upstream. | |
| 160 | ||
| 161 | ============ ============== | |
| 162 | Open vSwitch Linux kernel | |
| 163 | ============ ============== | |
| 164 | 1.4.x 2.6.18 to 3.2 | |
| 165 | 1.5.x 2.6.18 to 3.2 | |
| 166 | 1.6.x 2.6.18 to 3.2 | |
| 167 | 1.7.x 2.6.18 to 3.3 | |
| 168 | 1.8.x 2.6.18 to 3.4 | |
| 169 | 1.9.x 2.6.18 to 3.8 | |
| 170 | 1.10.x 2.6.18 to 3.8 | |
| 171 | 1.11.x 2.6.18 to 3.8 | |
| 172 | 2.0.x 2.6.32 to 3.10 | |
| 173 | 2.1.x 2.6.32 to 3.11 | |
| 174 | 2.3.x 2.6.32 to 3.14 | |
| 175 | 2.4.x 2.6.32 to 4.0 | |
| 176 | 2.5.x 2.6.32 to 4.3 | |
| 177 | 2.6.x 3.10 to 4.7 | |
| 178 | ============ ============== | |
| 179 | ||
| 180 | Open vSwitch userspace should also work with the Linux kernel module built | |
| 181 | into Linux 3.3 and later. | |
| 182 | ||
| 183 | Open vSwitch userspace is not sensitive to the Linux kernel version. It | |
| 184 | should build against almost any kernel, certainly against 2.6.32 and later. | |
| 185 | ||
| 186 | Q: Are all features available with all datapaths? | |
| 187 | ||
| 188 | A: Open vSwitch supports different datapaths on different platforms. Each | |
| 189 | datapath has a different feature set: the following tables try to summarize | |
| 190 | the status. | |
| 191 | ||
| 192 | Supported datapaths: | |
| 193 | ||
| 194 | Linux upstream | |
| 195 | The datapath implemented by the kernel module shipped with Linux | |
| 196 | upstream. Since features have been gradually introduced into the kernel, | |
| 197 | the table mentions the first Linux release whose OVS module supports the | |
| 198 | feature. | |
| 199 | ||
| 200 | Linux OVS tree | |
| 201 | The datapath implemented by the Linux kernel module distributed with the | |
| 202 | OVS source tree. | |
| 203 | ||
| 204 | Userspace | |
| 205 | Also known as DPDK, dpif-netdev or dummy datapath. It is the only | |
| 206 | datapath that works on NetBSD, FreeBSD and Mac OSX. | |
| 207 | ||
| 208 | Hyper-V | |
| 209 | Also known as the Windows datapath. | |
| 210 | ||
| 211 | The following table lists the datapath supported features from an Open | |
| 212 | vSwitch user's perspective. | |
| 213 | ||
| 214 | ===================== ============== ============== ========= ======= | |
| 215 | Feature Linux upstream Linux OVS tree Userspace Hyper-V | |
| 216 | ===================== ============== ============== ========= ======= | |
| 217 | NAT 4.6 YES NO NO | |
| 218 | Connection tracking 4.3 YES PARTIAL PARTIAL | |
| 219 | Tunnel - LISP NO YES NO NO | |
| 220 | Tunnel - STT NO YES NO YES | |
| 221 | Tunnel - GRE 3.11 YES YES YES | |
| 222 | Tunnel - VXLAN 3.12 YES YES YES | |
| 223 | Tunnel - Geneve 3.18 YES YES YES | |
| 224 | Tunnel - GRE-IPv6 NO NO YES NO | |
| 225 | Tunnel - VXLAN-IPv6 4.3 YES YES NO | |
| 226 | Tunnel - Geneve-IPv6 4.4 YES YES NO | |
| 227 | QoS - Policing YES YES YES NO | |
| 228 | QoS - Shaping YES YES NO NO | |
| 229 | sFlow YES YES YES NO | |
| 230 | IPFIX 3.10 YES YES NO | |
| 231 | Set action YES YES YES PARTIAL | |
| 232 | NIC Bonding YES YES YES NO | |
| 233 | Multiple VTEPs YES YES YES NO | |
| 234 | ===================== ============== ============== ========= ======= | |
| 235 | ||
| 236 | Do note, however: | |
| 237 | ||
| 238 | * Only a limited set of flow fields is modifiable via the set action by the | |
| 239 | Hyper-V datapath. | |
| 240 | * The Hyper-V datapath only supports one physical NIC per datapath. This is | |
| 241 | why bonding is not supported. | |
| 242 | * The Hyper-V datapath can have at most one IP address configured as a | |
| 243 | tunnel endpoint. | |
| 244 | ||
| 245 | The following table lists features that do not *directly* impact an Open | |
| 246 | vSwitch user, e.g. because their absence can be hidden by the ofproto layer | |
| 247 | (usually this comes with a performance penalty). | |
| 248 | ||
| 249 | ===================== ============== ============== ========= ======= | |
| 250 | Feature Linux upstream Linux OVS tree Userspace Hyper-V | |
| 251 | ===================== ============== ============== ========= ======= | |
| 252 | SCTP flows 3.12 YES YES YES | |
| 253 | MPLS 3.19 YES YES YES | |
| 254 | UFID 4.0 YES YES NO | |
| 255 | Megaflows 3.12 YES YES NO | |
| 256 | Masked set action 4.0 YES YES NO | |
| 257 | Recirculation 3.19 YES YES YES | |
| 258 | TCP flags matching 3.13 YES YES NO | |
| 259 | Validate flow actions YES YES N/A NO | |
| 260 | Multiple datapaths YES YES YES NO | |
| 261 | Tunnel TSO - STT N/A YES NO YES | |
| 262 | ===================== ============== ============== ========= ======= | |
| 263 | ||
| 264 | Q: What DPDK version does each Open vSwitch release work with? | |
| 265 | ||
| 266 | A: The following table lists the DPDK version against which the given | |
| 267 | versions of Open vSwitch will successfully build. | |
| 268 | ||
| 269 | ============ ===== | |
| 270 | Open vSwitch DPDK | |
| 271 | ============ ===== | |
| 272 | 2.2.x 1.6 | |
| 273 | 2.3.x 1.6 | |
| 274 | 2.4.x 2.0 | |
| 275 | 2.5.x 2.2 | |
| 276 | 2.6.x 16.07 | |
| 277 | ============ ===== | |
| 278 | ||
| dc76953f | 279 | Q: I get an error like this when I configure Open vSwitch:: |
| edde4861 SF |
280 | |
| 281 | configure: error: Linux kernel in <dir> is version <x>, but | |
| 282 | version newer than <y> is not supported (please refer to the | |
| 283 | FAQ for advice) | |
| 284 | ||
| 285 | What should I do? | |
| 286 | ||
| 287 | A: You have the following options: | |
| 288 | ||
| 289 | - Use the Linux kernel module supplied with the kernel that you are using. | |
| 290 | (See also the following FAQ.) | |
| 291 | ||
| 292 | - If there is a newer released version of Open vSwitch, consider building | |
| 293 | that one, because it may support the kernel that you are building | |
| 294 | against. (To find out, consult the table in the previous FAQ.) | |
| 295 | ||
| 296 | - The Open vSwitch "master" branch may support the kernel that you are | |
| 297 | using, so consider building the kernel module from "master". | |
| 298 | ||
| 299 | All versions of Open vSwitch userspace are compatible with all versions of | |
| 300 | the Open vSwitch kernel module, so you do not have to use the kernel module | |
| 301 | from one source along with the userspace programs from the same source. | |
| 302 | ||
| 303 | Q: What features are not available in the Open vSwitch kernel datapath that | |
| 304 | ships as part of the upstream Linux kernel? | |
| 305 | ||
| 306 | A: The kernel module in upstream Linux does not include support for LISP. | |
| 307 | Work is in progress to add support for LISP to the upstream Linux version | |
| 308 | of the Open vSwitch kernel module. For now, if you need this feature, use | |
| 309 | the kernel module from the Open vSwitch distribution instead of the | |
| 310 | upstream Linux kernel module. | |
| 311 | ||
| 312 | Certain features require kernel support to function or to have reasonable | |
| 313 | performance. If the ovs-vswitchd log file indicates that a feature is not | |
| 314 | supported, consider upgrading to a newer upstream Linux release or using | |
| 315 | the kernel module paired with the userspace distribution. | |
| 316 | ||
| 317 | Q: Why do tunnels not work when using a kernel module other than the one | |
| 318 | packaged with Open vSwitch? | |
| 319 | ||
| 320 | A: Support for tunnels was added to the upstream Linux kernel module after | |
| 321 | the rest of Open vSwitch. As a result, some kernels may contain support for | |
| 322 | Open vSwitch but not tunnels. The minimum kernel version that supports each | |
| 323 | tunnel protocol is: | |
| 324 | ||
| 325 | ======== ============ | |
| 326 | Protocol Linux Kernel | |
| 327 | ======== ============ | |
| 328 | GRE 3.11 | |
| 329 | VXLAN 3.12 | |
| 330 | Geneve 3.18 | |
| 331 | LISP not upstream | |
| 332 | STT not upstream | |
| 333 | ======== ============ | |
| 334 | ||
| 335 | If you are using a version of the kernel that is older than the one listed | |
| 336 | above, it is still possible to use that tunnel protocol. However, you must | |
| 337 | compile and install the kernel module included with the Open vSwitch | |
| 338 | distribution rather than the one on your machine. If problems persist after | |
| 339 | doing this, check to make sure that the module that is loaded is the one | |
| 340 | you expect. | |
| 341 | ||
| 342 | Q: Why are UDP tunnel checksums not computed for VXLAN or Geneve? | |
| 343 | ||
| 344 | A: Generating outer UDP checksums requires kernel support that was not part | |
| 345 | of the initial implementation of these protocols. If using the upstream | |
| 346 | Linux Open vSwitch module, you must use kernel 4.0 or newer. The | |
| 347 | out-of-tree modules from Open vSwitch release 2.4 and later support UDP | |
| 348 | checksums. | |
| 349 | ||
| 350 | Q: What features are not available when using the userspace datapath? | |
| 351 | ||
| 352 | A: Tunnel virtual ports are not supported, as described in the previous | |
| 353 | answer. It is also not possible to use queue-related actions. On Linux | |
| 354 | kernels before 2.6.39, maximum-sized VLAN packets may not be transmitted. | |
| 355 | ||
| 356 | Q: Should userspace or kernel be upgraded first to minimize downtime? | |
| 357 | ||
| 358 | A. In general, the Open vSwitch userspace should be used with the kernel | |
| 359 | version included in the same release or with the version from upstream | |
| 360 | Linux. However, when upgrading between two releases of Open vSwitch it is | |
| 361 | best to migrate userspace first to reduce the possibility of | |
| 362 | incompatibilities. | |
| 363 | ||
| 364 | Q: What happened to the bridge compatibility feature? | |
| 365 | ||
| 366 | A: Bridge compatibility was a feature of Open vSwitch 1.9 and earlier. | |
| 367 | When it was enabled, Open vSwitch imitated the interface of the Linux | |
| 368 | kernel "bridge" module. This allowed users to drop Open vSwitch into | |
| 369 | environments designed to use the Linux kernel bridge module without | |
| 370 | adapting the environment to use Open vSwitch. | |
| 371 | ||
| 372 | Open vSwitch 1.10 and later do not support bridge compatibility. The | |
| 373 | feature was dropped because version 1.10 adopted a new internal | |
| 374 | architecture that made bridge compatibility difficult to maintain. Now | |
| 375 | that many environments use OVS directly, it would be rarely useful in any | |
| 376 | case. | |
| 377 | ||
| 378 | To use bridge compatibility, install OVS 1.9 or earlier, including the | |
| 379 | accompanying kernel modules (both the main and bridge compatibility | |
| 380 | modules), following the instructions that come with the release. Be sure | |
| 381 | to start the ovs-brcompatd daemon. | |
| 382 | ||
| 383 | Terminology | |
| 384 | ----------- | |
| 385 | ||
| 386 | Q: I thought Open vSwitch was a virtual Ethernet switch, but the documentation | |
| 387 | keeps talking about bridges. What's a bridge? | |
| 388 | ||
| 389 | A: In networking, the terms "bridge" and "switch" are synonyms. Open | |
| 390 | vSwitch implements an Ethernet switch, which means that it is also an | |
| 391 | Ethernet bridge. | |
| 392 | ||
| 393 | Q: What's a VLAN? | |
| 394 | ||
| 395 | A: See the "VLAN" section below. | |
| 396 | ||
| 397 | Basic Configuration | |
| 398 | ------------------- | |
| 399 | ||
| 400 | Q: How do I configure a port as an access port? | |
| 401 | ||
| 402 | A. Add ``tag=VLAN`` to your ``ovs-vsctl add-port`` command. For example, | |
| 403 | the following commands configure br0 with eth0 as a trunk port (the | |
| 404 | default) and tap0 as an access port for VLAN 9: | |
| 405 | ||
| 406 | :: | |
| 407 | ||
| 408 | $ ovs-vsctl add-br br0 | |
| 409 | $ ovs-vsctl add-port br0 eth0 | |
| 410 | $ ovs-vsctl add-port br0 tap0 tag=9 | |
| 411 | ||
| 412 | If you want to configure an already added port as an access port, use | |
| 413 | ``ovs-vsctl set``, e.g.: | |
| 414 | ||
| 415 | :: | |
| 416 | ||
| 417 | $ ovs-vsctl set port tap0 tag=9 | |
| 418 | ||
| 419 | Q: How do I configure a port as a SPAN port, that is, enable mirroring of all | |
| 420 | traffic to that port? | |
| 421 | ||
| 422 | A. The following commands configure br0 with eth0 and tap0 as trunk ports. | |
| 423 | All traffic coming in or going out on eth0 or tap0 is also mirrored to | |
| 424 | tap1; any traffic arriving on tap1 is dropped: | |
| 425 | ||
| 426 | :: | |
| 427 | ||
| 428 | $ ovs-vsctl add-br br0 | |
| 429 | $ ovs-vsctl add-port br0 eth0 | |
| 430 | $ ovs-vsctl add-port br0 tap0 | |
| 431 | $ ovs-vsctl add-port br0 tap1 \ | |
| 432 | -- --id=@p get port tap1 \ | |
| 433 | -- --id=@m create mirror name=m0 select-all=true output-port=@p \ | |
| 434 | -- set bridge br0 mirrors=@m | |
| 435 | ||
| 436 | To later disable mirroring, run: | |
| 437 | ||
| 438 | :: | |
| 439 | ||
| 440 | $ ovs-vsctl clear bridge br0 mirrors | |
| 441 | ||
| 442 | Q: Does Open vSwitch support configuring a port in promiscuous mode? | |
| 443 | ||
| 444 | A: Yes. How you configure it depends on what you mean by "promiscuous | |
| 445 | mode": | |
| 446 | ||
| 447 | - Conventionally, "promiscuous mode" is a feature of a network interface | |
| 448 | card. Ordinarily, a NIC passes to the CPU only the packets actually | |
| 449 | destined to its host machine. It discards the rest to avoid wasting | |
| 450 | memory and CPU cycles. When promiscuous mode is enabled, however, it | |
| 451 | passes every packet to the CPU. On an old-style shared-media or | |
| 452 | hub-based network, this allows the host to spy on all packets on the | |
| 453 | network. But in the switched networks that are almost everywhere these | |
| 454 | days, promiscuous mode doesn't have much effect, because few packets not | |
| 455 | destined to a host are delivered to the host's NIC. | |
| 456 | ||
| 457 | This form of promiscuous mode is configured in the guest OS of the VMs on | |
| 458 | your bridge, e.g. with "ifconfig". | |
| 459 | ||
| 460 | - The VMware vSwitch uses a different definition of "promiscuous mode". | |
| 461 | When you configure promiscuous mode on a VMware vNIC, the vSwitch sends a | |
| 462 | copy of every packet received by the vSwitch to that vNIC. That has a | |
| 463 | much bigger effect than just enabling promiscuous mode in a guest OS. | |
| 464 | Rather than getting a few stray packets for which the switch does not yet | |
| 465 | know the correct destination, the vNIC gets every packet. The effect is | |
| 466 | similar to replacing the vSwitch by a virtual hub. | |
| 467 | ||
| 468 | This "promiscuous mode" is what switches normally call "port mirroring" | |
| 469 | or "SPAN". For information on how to configure SPAN, see "How do I | |
| 470 | configure a port as a SPAN port, that is, enable mirroring of all traffic | |
| 471 | to that port?" | |
| 472 | ||
| 473 | Q: How do I configure a DPDK port as an access port? | |
| 474 | ||
| 475 | A: Firstly, you must have a DPDK-enabled version of Open vSwitch. | |
| 476 | ||
| 477 | If your version is DPDK-enabled it will support the other-config:dpdk-init | |
| 478 | configuration in the database and will display lines with "EAL:..." during | |
| 479 | startup when other_config:dpdk-init is set to 'true'. | |
| 480 | ||
| 481 | Secondly, when adding a DPDK port, unlike a system port, the type for the | |
| dc76953f | 482 | interface must be specified. For example:: |
| edde4861 SF |
483 | |
| 484 | $ ovs-vsctl add-br br0 | |
| 485 | $ ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk | |
| 486 | ||
| 487 | Finally, it is required that DPDK port names begin with ``dpdk``. | |
| 488 | ||
| 795752a3 | 489 | Refer to the `DPDK installation guide`_ for more information on enabling |
| edde4861 SF |
490 | and using DPDK with Open vSwitch. |
| 491 | ||
| 492 | Q: How do I configure a VLAN as an RSPAN VLAN, that is, enable mirroring of all | |
| 493 | traffic to that VLAN? | |
| 494 | ||
| 495 | A: The following commands configure br0 with eth0 as a trunk port and tap0 | |
| 496 | as an access port for VLAN 10. All traffic coming in or going out on tap0, | |
| 497 | as well as traffic coming in or going out on eth0 in VLAN 10, is also | |
| 498 | mirrored to VLAN 15 on eth0. The original tag for VLAN 10, in cases where | |
| 499 | one is present, is dropped as part of mirroring: | |
| 500 | ||
| 501 | :: | |
| 502 | ||
| 503 | $ ovs-vsctl add-br br0 | |
| 504 | $ ovs-vsctl add-port br0 eth0 | |
| 505 | $ ovs-vsctl add-port br0 tap0 tag=10 | |
| 506 | $ ovs-vsctl \ | |
| 507 | -- --id=@m create mirror name=m0 select-all=true select-vlan=10 \ | |
| 508 | output-vlan=15 \ | |
| 509 | -- set bridge br0 mirrors=@m | |
| 510 | ||
| 511 | To later disable mirroring, run: | |
| 512 | ||
| 513 | :: | |
| 514 | ||
| 515 | $ ovs-vsctl clear bridge br0 mirrors | |
| 516 | ||
| 517 | Mirroring to a VLAN can disrupt a network that contains unmanaged switches. | |
| 518 | See ovs-vswitchd.conf.db(5) for details. Mirroring to a GRE tunnel has | |
| 519 | fewer caveats than mirroring to a VLAN and should generally be preferred. | |
| 520 | ||
| 521 | Q: Can I mirror more than one input VLAN to an RSPAN VLAN? | |
| 522 | ||
| 523 | A: Yes, but mirroring to a VLAN strips the original VLAN tag in favor of | |
| 524 | the specified output-vlan. This loss of information may make the mirrored | |
| 525 | traffic too hard to interpret. | |
| 526 | ||
| 527 | To mirror multiple VLANs, use the commands above, but specify a | |
| 528 | comma-separated list of VLANs as the value for select-vlan. To mirror | |
| 529 | every VLAN, use the commands above, but omit select-vlan and its value | |
| 530 | entirely. | |
| 531 | ||
| 532 | When a packet arrives on a VLAN that is used as a mirror output VLAN, the | |
| 533 | mirror is disregarded. Instead, in standalone mode, OVS floods the packet | |
| 534 | across all the ports for which the mirror output VLAN is configured. (If | |
| 535 | an OpenFlow controller is in use, then it can override this behavior | |
| 536 | through the flow table.) If OVS is used as an intermediate switch, rather | |
| 537 | than an edge switch, this ensures that the RSPAN traffic is distributed | |
| 538 | through the network. | |
| 539 | ||
| 540 | Mirroring to a VLAN can disrupt a network that contains unmanaged switches. | |
| 541 | See ovs-vswitchd.conf.db(5) for details. Mirroring to a GRE tunnel has | |
| 542 | fewer caveats than mirroring to a VLAN and should generally be preferred. | |
| 543 | ||
| 544 | Q: How do I configure mirroring of all traffic to a GRE tunnel? | |
| 545 | ||
| 546 | A: The following commands configure br0 with eth0 and tap0 as trunk ports. | |
| 547 | All traffic coming in or going out on eth0 or tap0 is also mirrored to | |
| 548 | gre0, a GRE tunnel to the remote host 192.168.1.10; any traffic arriving on | |
| dc76953f | 549 | gre0 is dropped:: |
| edde4861 SF |
550 | |
| 551 | $ ovs-vsctl add-br br0 | |
| 552 | $ ovs-vsctl add-port br0 eth0 | |
| 553 | $ ovs-vsctl add-port br0 tap0 | |
| 554 | $ ovs-vsctl add-port br0 gre0 \ | |
| 555 | -- set interface gre0 type=gre options:remote_ip=192.168.1.10 \ | |
| 556 | -- --id=@p get port gre0 \ | |
| 557 | -- --id=@m create mirror name=m0 select-all=true output-port=@p \ | |
| 558 | -- set bridge br0 mirrors=@m | |
| 559 | ||
| dc76953f | 560 | To later disable mirroring and destroy the GRE tunnel:: |
| edde4861 SF |
561 | |
| 562 | $ ovs-vsctl clear bridge br0 mirrors | |
| 563 | $ ovs-vsctl del-port br0 gre0 | |
| 564 | ||
| 565 | Q: Does Open vSwitch support ERSPAN? | |
| 566 | ||
| 567 | A: No. As an alternative, Open vSwitch supports mirroring to a GRE tunnel | |
| 568 | (see above). | |
| 569 | ||
| 570 | Q: How do I connect two bridges? | |
| 571 | ||
| 572 | A: First, why do you want to do this? Two connected bridges are not much | |
| 573 | different from a single bridge, so you might as well just have a single | |
| 574 | bridge with all your ports on it. | |
| 575 | ||
| 576 | If you still want to connect two bridges, you can use a pair of patch | |
| 577 | ports. The following example creates bridges br0 and br1, adds eth0 and | |
| 578 | tap0 to br0, adds tap1 to br1, and then connects br0 and br1 with a pair of | |
| 579 | patch ports. | |
| 580 | ||
| 581 | :: | |
| 582 | ||
| 583 | $ ovs-vsctl add-br br0 | |
| 584 | $ ovs-vsctl add-port br0 eth0 | |
| 585 | $ ovs-vsctl add-port br0 tap0 | |
| 586 | $ ovs-vsctl add-br br1 | |
| 587 | $ ovs-vsctl add-port br1 tap1 | |
| 588 | $ ovs-vsctl \ | |
| 589 | -- add-port br0 patch0 \ | |
| 590 | -- set interface patch0 type=patch options:peer=patch1 \ | |
| 591 | -- add-port br1 patch1 \ | |
| 592 | -- set interface patch1 type=patch options:peer=patch0 | |
| 593 | ||
| 594 | Bridges connected with patch ports are much like a single bridge. For | |
| 595 | instance, if the example above also added eth1 to br1, and both eth0 and | |
| 596 | eth1 happened to be connected to the same next-hop switch, then you could | |
| 597 | loop your network just as you would if you added eth0 and eth1 to the same | |
| 598 | bridge (see the "Configuration Problems" section below for more | |
| 599 | information). | |
| 600 | ||
| 601 | If you are using Open vSwitch 1.9 or an earlier version, then you need to | |
| 602 | be using the kernel module bundled with Open vSwitch rather than the one | |
| 603 | that is integrated into Linux 3.3 and later, because Open vSwitch 1.9 and | |
| 604 | earlier versions need kernel support for patch ports. This also means that | |
| 605 | in Open vSwitch 1.9 and earlier, patch ports will not work with the | |
| 606 | userspace datapath, only with the kernel module. | |
| 607 | ||
| 608 | Q: How do I configure a bridge without an OpenFlow local port? (Local port in | |
| 609 | the sense of OFPP_LOCAL) | |
| 610 | ||
| 611 | A: Open vSwitch does not support such a configuration. Bridges always have | |
| 612 | their local ports. | |
| 613 | ||
| 614 | Implementation Details | |
| 615 | ---------------------- | |
| 616 | ||
| 617 | Q: I hear OVS has a couple of kinds of flows. Can you tell me about them? | |
| 618 | ||
| 619 | A: Open vSwitch uses different kinds of flows for different purposes: | |
| 620 | ||
| 621 | - OpenFlow flows are the most important kind of flow. OpenFlow controllers | |
| 622 | use these flows to define a switch's policy. OpenFlow flows support | |
| 623 | wildcards, priorities, and multiple tables. | |
| 624 | ||
| 625 | When in-band control is in use, Open vSwitch sets up a few "hidden" | |
| 626 | flows, with priority higher than a controller or the user can configure, | |
| 627 | that are not visible via OpenFlow. (See the "Controller" section of the | |
| 628 | FAQ for more information about hidden flows.) | |
| 629 | ||
| 630 | - The Open vSwitch software switch implementation uses a second kind of | |
| 631 | flow internally. These flows, called "datapath" or "kernel" flows, do | |
| 632 | not support priorities and comprise only a single table, which makes them | |
| 633 | suitable for caching. (Like OpenFlow flows, datapath flows do support | |
| 634 | wildcarding, in Open vSwitch 1.11 and later.) OpenFlow flows and | |
| 635 | datapath flows also support different actions and number ports | |
| 636 | differently. | |
| 637 | ||
| 638 | Datapath flows are an implementation detail that is subject to change in | |
| 639 | future versions of Open vSwitch. Even with the current version of Open | |
| 640 | vSwitch, hardware switch implementations do not necessarily use this | |
| 641 | architecture. | |
| 642 | ||
| 643 | Users and controllers directly control only the OpenFlow flow table. Open | |
| 644 | vSwitch manages the datapath flow table itself, so users should not normally be | |
| 645 | concerned with it. | |
| 646 | ||
| 647 | Q: Why are there so many different ways to dump flows? | |
| 648 | ||
| 649 | A: Open vSwitch has two kinds of flows (see the previous question), so it | |
| 650 | has commands with different purposes for dumping each kind of flow: | |
| 651 | ||
| 652 | - ``ovs-ofctl dump-flows <br>`` dumps OpenFlow flows, excluding hidden | |
| 653 | flows. This is the most commonly useful form of flow dump. (Unlike the | |
| 654 | other commands, this should work with any OpenFlow switch, not just Open | |
| 655 | vSwitch.) | |
| 656 | ||
| 657 | - ``ovs-appctl bridge/dump-flows <br>`` dumps OpenFlow flows, including | |
| 658 | hidden flows. This is occasionally useful for troubleshooting suspected | |
| 659 | issues with in-band control. | |
| 660 | ||
| 661 | - ``ovs-dpctl dump-flows [dp]`` dumps the datapath flow table entries for a | |
| 662 | Linux kernel-based datapath. In Open vSwitch 1.10 and later, | |
| 663 | ovs-vswitchd merges multiple switches into a single datapath, so it will | |
| 664 | show all the flows on all your kernel-based switches. This command can | |
| 665 | occasionally be useful for debugging. | |
| 666 | ||
| 667 | - ``ovs-appctl dpif/dump-flows <br>``, new in Open vSwitch 1.10, dumps | |
| 668 | datapath flows for only the specified bridge, regardless of the type. | |
| 669 | ||
| 670 | Q: How does multicast snooping works with VLANs? | |
| 671 | ||
| 672 | A: Open vSwitch maintains snooping tables for each VLAN. | |
| 673 | ||
| 674 | Q: Can OVS populate the kernel flow table in advance instead of in reaction to | |
| 675 | packets? | |
| 676 | ||
| 677 | A: No. There are several reasons: | |
| 678 | ||
| 679 | - Kernel flows are not as sophisticated as OpenFlow flows, which means that | |
| 680 | some OpenFlow policies could require a large number of kernel flows. The | |
| 681 | "conjunctive match" feature is an extreme example: the number of kernel | |
| 682 | flows it requires is the product of the number of flows in each | |
| 683 | dimension. | |
| 684 | ||
| 685 | - With multiple OpenFlow flow tables and simple sets of actions, the number | |
| 686 | of kernel flows required can be as large as the product of the number of | |
| 687 | flows in each dimension. With more sophisticated actions, the number of | |
| 688 | kernel flows could be even larger. | |
| 689 | ||
| 690 | - Open vSwitch is designed so that any version of OVS userspace | |
| 691 | interoperates with any version of the OVS kernel module. This forward | |
| 692 | and backward compatibility requires that userspace observe how the kernel | |
| 693 | module parses received packets. This is only possible in a | |
| 694 | straightforward way when userspace adds kernel flows in reaction to | |
| 695 | received packets. | |
| 696 | ||
| 697 | For more relevant information on the architecture of Open vSwitch, please | |
| 698 | read "The Design and Implementation of Open vSwitch", published in USENIX | |
| 699 | NSDI 2015. | |
| 700 | ||
| 701 | Performance | |
| 702 | ----------- | |
| 703 | ||
| 704 | Q: I just upgraded and I see a performance drop. Why? | |
| 705 | ||
| 706 | A: The OVS kernel datapath may have been updated to a newer version than | |
| 707 | the OVS userspace components. Sometimes new versions of OVS kernel module | |
| 708 | add functionality that is backwards compatible with older userspace | |
| 709 | components but may cause a drop in performance with them. Especially, if a | |
| 710 | kernel module from OVS 2.1 or newer is paired with OVS userspace 1.10 or | |
| 711 | older, there will be a performance drop for TCP traffic. | |
| 712 | ||
| 713 | Updating the OVS userspace components to the latest released version should | |
| 714 | fix the performance degradation. | |
| 715 | ||
| 716 | To get the best possible performance and functionality, it is recommended to | |
| 717 | pair the same versions of the kernel module and OVS userspace. | |
| 718 | ||
| 719 | Configuration Problems | |
| 720 | ---------------------- | |
| 721 | ||
| 722 | Q: I created a bridge and added my Ethernet port to it, using commands like | |
| dc76953f | 723 | these:: |
| edde4861 SF |
724 | |
| 725 | ovs-vsctl add-br br0 | |
| 726 | ovs-vsctl add-port br0 eth0 | |
| 727 | ||
| 728 | and as soon as I ran the "add-port" command I lost all connectivity through | |
| 729 | eth0. Help! | |
| 730 | ||
| 731 | A: A physical Ethernet device that is part of an Open vSwitch bridge should | |
| 732 | not have an IP address. If one does, then that IP address will not be | |
| 733 | fully functional. | |
| 734 | ||
| 735 | You can restore functionality by moving the IP address to an Open vSwitch | |
| 736 | "internal" device, such as the network device named after the bridge | |
| 737 | itself. For example, assuming that eth0's IP address is 192.168.128.5, you | |
| dc76953f | 738 | could run the commands below to fix up the situation:: |
| edde4861 SF |
739 | |
| 740 | $ ifconfig eth0 0.0.0.0 | |
| 741 | $ ifconfig br0 192.168.128.5 | |
| 742 | ||
| 743 | (If your only connection to the machine running OVS is through the IP | |
| 744 | address in question, then you would want to run all of these commands on a | |
| 745 | single command line, or put them into a script.) If there were any | |
| 746 | additional routes assigned to eth0, then you would also want to use | |
| 747 | commands to adjust these routes to go through br0. | |
| 748 | ||
| 749 | If you use DHCP to obtain an IP address, then you should kill the DHCP | |
| 750 | client that was listening on the physical Ethernet interface (e.g. eth0) | |
| 751 | and start one listening on the internal interface (e.g. br0). You might | |
| 752 | still need to manually clear the IP address from the physical interface | |
| 753 | (e.g. with "ifconfig eth0 0.0.0.0"). | |
| 754 | ||
| 755 | There is no compelling reason why Open vSwitch must work this way. | |
| 756 | However, this is the way that the Linux kernel bridge module has always | |
| 757 | worked, so it's a model that those accustomed to Linux bridging are already | |
| 758 | used to. Also, the model that most people expect is not implementable | |
| 759 | without kernel changes on all the versions of Linux that Open vSwitch | |
| 760 | supports. | |
| 761 | ||
| 762 | By the way, this issue is not specific to physical Ethernet devices. It | |
| 763 | applies to all network devices except Open vSwitch "internal" devices. | |
| 764 | ||
| 765 | Q: I created a bridge and added a couple of Ethernet ports to it, using | |
| dc76953f | 766 | commands like these:: |
| edde4861 SF |
767 | |
| 768 | $ ovs-vsctl add-br br0 | |
| 769 | $ ovs-vsctl add-port br0 eth0 | |
| 770 | $ ovs-vsctl add-port br0 eth1 | |
| 771 | ||
| 772 | and now my network seems to have melted: connectivity is unreliable (even | |
| 773 | connectivity that doesn't go through Open vSwitch), all the LEDs on my physical | |
| 774 | switches are blinking, wireshark shows duplicated packets, and CPU usage is | |
| 775 | very high. | |
| 776 | ||
| 777 | A: More than likely, you've looped your network. Probably, eth0 and eth1 | |
| 778 | are connected to the same physical Ethernet switch. This yields a scenario | |
| 779 | where OVS receives a broadcast packet on eth0 and sends it out on eth1, | |
| 780 | then the physical switch connected to eth1 sends the packet back on eth0, | |
| 781 | and so on forever. More complicated scenarios, involving a loop through | |
| 782 | multiple switches, are possible too. | |
| 783 | ||
| 784 | The solution depends on what you are trying to do: | |
| 785 | ||
| 786 | - If you added eth0 and eth1 to get higher bandwidth or higher reliability | |
| 787 | between OVS and your physical Ethernet switch, use a bond. The following | |
| dc76953f | 788 | commands create br0 and then add eth0 and eth1 as a bond:: |
| edde4861 SF |
789 | |
| 790 | $ ovs-vsctl add-br br0 | |
| 791 | $ ovs-vsctl add-bond br0 bond0 eth0 eth1 | |
| 792 | ||
| 793 | Bonds have tons of configuration options. Please read the documentation | |
| 794 | on the Port table in ovs-vswitchd.conf.db(5) for all the details. | |
| 795 | ||
| 796 | Configuration for DPDK-enabled interfaces is slightly less | |
| 795752a3 SF |
797 | straightforward. Refer to the `DPDK installation guide`_ for more |
| 798 | information. | |
| edde4861 SF |
799 | |
| 800 | - Perhaps you don't actually need eth0 and eth1 to be on the same bridge. | |
| 801 | For example, if you simply want to be able to connect each of them to | |
| 802 | virtual machines, then you can put each of them on a bridge of its own: | |
| 803 | ||
| 804 | $ ovs-vsctl add-br br0 | |
| 805 | $ ovs-vsctl add-port br0 eth0 | |
| 806 | ||
| 807 | $ ovs-vsctl add-br br1 | |
| 808 | $ ovs-vsctl add-port br1 eth1 | |
| 809 | ||
| 810 | and then connect VMs to br0 and br1. (A potential disadvantage is that | |
| 811 | traffic cannot directly pass between br0 and br1. Instead, it will go | |
| 812 | out eth0 and come back in eth1, or vice versa.) | |
| 813 | ||
| 814 | - If you have a redundant or complex network topology and you want to | |
| 815 | prevent loops, turn on spanning tree protocol (STP). The following | |
| 816 | commands create br0, enable STP, and add eth0 and eth1 to the bridge. | |
| 817 | The order is important because you don't want have to have a loop in your | |
| dc76953f | 818 | network even transiently:: |
| edde4861 SF |
819 | |
| 820 | $ ovs-vsctl add-br br0 | |
| 821 | $ ovs-vsctl set bridge br0 stp_enable=true | |
| 822 | $ ovs-vsctl add-port br0 eth0 | |
| 823 | $ ovs-vsctl add-port br0 eth1 | |
| 824 | ||
| 825 | The Open vSwitch implementation of STP is not well tested. Report any | |
| 826 | bugs you observe, but if you'd rather avoid acting as a beta tester then | |
| 827 | another option might be your best shot. | |
| 828 | ||
| 829 | Q: I can't seem to use Open vSwitch in a wireless network. | |
| 830 | ||
| 831 | A: Wireless base stations generally only allow packets with the source MAC | |
| 832 | address of NIC that completed the initial handshake. Therefore, without | |
| 833 | MAC rewriting, only a single device can communicate over a single wireless | |
| 834 | link. | |
| 835 | ||
| 836 | This isn't specific to Open vSwitch, it's enforced by the access point, so | |
| 837 | the same problems will show up with the Linux bridge or any other way to do | |
| 838 | bridging. | |
| 839 | ||
| 840 | Q: I can't seem to add my PPP interface to an Open vSwitch bridge. | |
| 841 | ||
| 842 | A: PPP most commonly carries IP packets, but Open vSwitch works only with | |
| 843 | Ethernet frames. The correct way to interface PPP to an Ethernet network | |
| 844 | is usually to use routing instead of switching. | |
| 845 | ||
| 846 | Q: Is there any documentation on the database tables and fields? | |
| 847 | ||
| 848 | A: Yes. ovs-vswitchd.conf.db(5) is a comprehensive reference. | |
| 849 | ||
| 850 | Q: When I run ovs-dpctl I no longer see the bridges I created. Instead, I only | |
| 851 | see a datapath called "ovs-system". How can I see datapath information about a | |
| 852 | particular bridge? | |
| 853 | ||
| 854 | A: In version 1.9.0, OVS switched to using a single datapath that is shared | |
| 855 | by all bridges of that type. The ``ovs-appctl dpif/*`` commands provide | |
| 856 | similar functionality that is scoped by the bridge. | |
| 857 | ||
| 858 | Q: I created a GRE port using ovs-vsctl so why can't I send traffic or see the | |
| 859 | port in the datapath? | |
| 860 | ||
| 861 | A: On Linux kernels before 3.11, the OVS GRE module and Linux GRE module | |
| 862 | cannot be loaded at the same time. It is likely that on your system the | |
| 863 | Linux GRE module is already loaded and blocking OVS (to confirm, check | |
| 864 | dmesg for errors regarding GRE registration). To fix this, unload all GRE | |
| 865 | modules that appear in lsmod as well as the OVS kernel module. You can then | |
| 795752a3 SF |
866 | reload the OVS module following the directions in the `general installation |
| 867 | guide`_, which will ensure that dependencies are satisfied. | |
| edde4861 SF |
868 | |
| 869 | Q: Open vSwitch does not seem to obey my packet filter rules. | |
| 870 | ||
| 871 | A: It depends on mechanisms and configurations you want to use. | |
| 872 | ||
| 873 | You cannot usefully use typical packet filters, like iptables, on physical | |
| 874 | Ethernet ports that you add to an Open vSwitch bridge. This is because | |
| 875 | Open vSwitch captures packets from the interface at a layer lower below | |
| 876 | where typical packet-filter implementations install their hooks. (This | |
| 877 | actually applies to any interface of type "system" that you might add to an | |
| 878 | Open vSwitch bridge.) | |
| 879 | ||
| 880 | You can usefully use typical packet filters on Open vSwitch internal ports | |
| 881 | as they are mostly ordinary interfaces from the point of view of packet | |
| 882 | filters. | |
| 883 | ||
| 884 | For example, suppose you create a bridge br0 and add Ethernet port eth0 to | |
| 885 | it. Then you can usefully add iptables rules to affect the internal | |
| 886 | interface br0, but not the physical interface eth0. (br0 is also where you | |
| 887 | would add an IP address, as discussed elsewhere in the FAQ.) | |
| 888 | ||
| 889 | For simple filtering rules, it might be possible to achieve similar results | |
| 0b1545be HZ |
890 | by installing appropriate OpenFlow flows instead. The OVS conntrack |
| 891 | feature (see the "ct" action in ovs-ofctl(8)) can implement a stateful | |
| 892 | firewall. | |
| edde4861 SF |
893 | |
| 894 | If the use of a particular packet filter setup is essential, Open vSwitch | |
| 895 | might not be the best choice for you. On Linux, you might want to consider | |
| 896 | using the Linux Bridge. (This is the only choice if you want to use | |
| 897 | ebtables rules.) On NetBSD, you might want to consider using the bridge(4) | |
| 898 | with BRIDGE_IPF option. | |
| 899 | ||
| 900 | Q: It seems that Open vSwitch does nothing when I removed a port and then | |
| 901 | immediately put it back. For example, consider that p1 is a port of | |
| dc76953f | 902 | ``type=internal``:: |
| edde4861 SF |
903 | |
| 904 | $ ovs-vsctl del-port br0 p1 -- \ | |
| 905 | add-port br0 p1 -- \ | |
| 906 | set interface p1 type=internal | |
| 907 | ||
| 908 | A: It's an expected behaviour. | |
| 909 | ||
| 910 | If del-port and add-port happen in a single OVSDB transaction as your | |
| 911 | example, Open vSwitch always "skips" the intermediate steps. Even if they | |
| 912 | are done in multiple transactions, it's still allowed for Open vSwitch to | |
| 913 | skip the intermediate steps and just implement the overall effect. In both | |
| 914 | cases, your example would be turned into a no-op. | |
| 915 | ||
| 916 | If you want to make Open vSwitch actually destroy and then re-create the | |
| 917 | port for some side effects like resetting kernel setting for the | |
| 918 | corresponding interface, you need to separate operations into multiple | |
| 919 | OVSDB transactions and ensure that at least the first one does not have | |
| 920 | ``--no-wait``. In the following example, the first ovs-vsctl will block | |
| dc76953f | 921 | until Open vSwitch reloads the new configuration and removes the port:: |
| edde4861 SF |
922 | |
| 923 | $ ovs-vsctl del-port br0 p1 | |
| 924 | $ ovs-vsctl add-port br0 p1 -- \ | |
| 925 | set interface p1 type=internal | |
| 926 | ||
| 927 | Q: I want to add thousands of ports to an Open vSwitch bridge, but it takes too | |
| 928 | long (minutes or hours) to do it with ovs-vsctl. How can I do it faster? | |
| 929 | ||
| 930 | A: If you add them one at a time with ovs-vsctl, it can take a long time to | |
| 931 | add thousands of ports to an Open vSwitch bridge. This is because every | |
| 932 | invocation of ovs-vsctl first reads the current configuration from OVSDB. | |
| 933 | As the number of ports grows, this starts to take an appreciable amount of | |
| 934 | time, and when it is repeated thousands of times the total time becomes | |
| 935 | significant. | |
| 936 | ||
| 937 | The solution is to add the ports in one invocation of ovs-vsctl (or a small | |
| dc76953f | 938 | number of them). For example, using bash:: |
| edde4861 SF |
939 | |
| 940 | $ ovs-vsctl add-br br0 | |
| 941 | $ cmds=; for i in {1..5000}; do cmds+=" -- add-port br0 p$i"; done | |
| 942 | $ ovs-vsctl $cmds | |
| 943 | ||
| 944 | takes seconds, not minutes or hours, in the OVS sandbox environment. | |
| 945 | ||
| 946 | Q: I created a bridge named br0. My bridge shows up in "ovs-vsctl show", but | |
| 947 | "ovs-ofctl show br0" just prints "br0 is not a bridge or a socket". | |
| 948 | ||
| 949 | A: Open vSwitch wasn't able to create the bridge. Check the ovs-vswitchd | |
| 950 | log for details (Debian and Red Hat packaging for Open vSwitch put it in | |
| 951 | /var/log/openvswitch/ovs-vswitchd.log). | |
| 952 | ||
| 953 | In general, the Open vSwitch database reflects the desired configuration | |
| 954 | state. ovs-vswitchd monitors the database and, when it changes, | |
| 955 | reconfigures the system to reflect the new desired state. This normally | |
| 956 | happens very quickly. Thus, a discrepancy between the database and the | |
| 957 | actual state indicates that ovs-vswitchd could not implement the | |
| 958 | configuration, and so one should check the log to find out why. (Another | |
| 959 | possible cause is that ovs-vswitchd is not running. This will make | |
| 960 | ovs-vsctl commands hang, if they change the configuration, unless one | |
| 961 | specifies ``--no-wait``.) | |
| 962 | ||
| 963 | Q: I have a bridge br0. I added a new port vif1.0, and it shows up in | |
| 964 | "ovs-vsctl show", but "ovs-vsctl list port" says that it has OpenFlow port | |
| 965 | ("ofport") -1, and "ovs-ofctl show br0" doesn't show vif1.0 at all. | |
| 966 | ||
| 967 | A: Open vSwitch wasn't able to create the port. Check the ovs-vswitchd log | |
| 968 | for details (Debian and Red Hat packaging for Open vSwitch put it in | |
| 969 | /var/log/openvswitch/ovs-vswitchd.log). Please see the previous question | |
| 970 | for more information. | |
| 971 | ||
| 972 | You may want to upgrade to Open vSwitch 2.3 (or later), in which ovs-vsctl | |
| 973 | will immediately report when there is an issue creating a port. | |
| 974 | ||
| 975 | Q: I created a tap device tap0, configured an IP address on it, and added it to | |
| dc76953f | 976 | a bridge, like this:: |
| edde4861 SF |
977 | |
| 978 | $ tunctl -t tap0 | |
| 979 | $ ifconfig tap0 192.168.0.123 | |
| 980 | $ ovs-vsctl add-br br0 | |
| 981 | $ ovs-vsctl add-port br0 tap0 | |
| 982 | ||
| 983 | I expected that I could then use this IP address to contact other hosts on the | |
| 984 | network, but it doesn't work. Why not? | |
| 985 | ||
| 986 | A: The short answer is that this is a misuse of a "tap" device. Use an | |
| 987 | "internal" device implemented by Open vSwitch, which works differently and | |
| 988 | is designed for this use. To solve this problem with an internal device, | |
| dc76953f | 989 | instead run:: |
| edde4861 SF |
990 | |
| 991 | $ ovs-vsctl add-br br0 | |
| 992 | $ ovs-vsctl add-port br0 int0 -- set Interface int0 type=internal | |
| 993 | $ ifconfig int0 192.168.0.123 | |
| 994 | ||
| 995 | Even more simply, you can take advantage of the internal port that every | |
| dc76953f | 996 | bridge has under the name of the bridge:: |
| edde4861 SF |
997 | |
| 998 | $ ovs-vsctl add-br br0 | |
| 999 | $ ifconfig br0 192.168.0.123 | |
| 1000 | ||
| 1001 | In more detail, a "tap" device is an interface between the Linux (or BSD) | |
| 1002 | network stack and a user program that opens it as a socket. When the "tap" | |
| 1003 | device transmits a packet, it appears in the socket opened by the userspace | |
| 1004 | program. Conversely, when the userspace program writes to the "tap" | |
| 1005 | socket, the kernel TCP/IP stack processes the packet as if it had been | |
| 1006 | received by the "tap" device. | |
| 1007 | ||
| 1008 | Consider the configuration above. Given this configuration, if you "ping" | |
| 1009 | an IP address in the 192.168.0.x subnet, the Linux kernel routing stack | |
| 1010 | will transmit an ARP on the tap0 device. Open vSwitch userspace treats | |
| 1011 | "tap" devices just like any other network device; that is, it doesn't open | |
| 1012 | them as "tap" sockets. That means that the ARP packet will simply get | |
| 1013 | dropped. | |
| 1014 | ||
| 1015 | You might wonder why the Open vSwitch kernel module doesn't intercept the | |
| 1016 | ARP packet and bridge it. After all, Open vSwitch intercepts packets on | |
| 1017 | other devices. The answer is that Open vSwitch only intercepts *received* | |
| 1018 | packets, but this is a packet being transmitted. The same thing happens | |
| 1019 | for all other types of network devices, except for Open vSwitch "internal" | |
| 1020 | ports. If you, for example, add a physical Ethernet port to an OVS bridge, | |
| 1021 | configure an IP address on a physical Ethernet port, and then issue a | |
| 1022 | "ping" to an address in that subnet, the same thing happens: an ARP gets | |
| 1023 | transmitted on the physical Ethernet port and Open vSwitch never sees it. | |
| 1024 | (You should not do that, as documented at the beginning of this section.) | |
| 1025 | ||
| 1026 | It can make sense to add a "tap" device to an Open vSwitch bridge, if some | |
| 1027 | userspace program (other than Open vSwitch) has opened the tap socket. | |
| 1028 | This is the case, for example, if the "tap" device was created by KVM (or | |
| 1029 | QEMU) to simulate a virtual NIC. In such a case, when OVS bridges a packet | |
| 1030 | to the "tap" device, the kernel forwards that packet to KVM in userspace, | |
| 1031 | which passes it along to the VM, and in the other direction, when the VM | |
| 1032 | sends a packet, KVM writes it to the "tap" socket, which causes OVS to | |
| 1033 | receive it and bridge it to the other OVS ports. Please note that in such | |
| 1034 | a case no IP address is configured on the "tap" device (there is normally | |
| 1035 | an IP address configured in the virtual NIC inside the VM, but this is not | |
| 1036 | visible to the host Linux kernel or to Open vSwitch). | |
| 1037 | ||
| 1038 | There is one special case in which Open vSwitch does directly read and | |
| 1039 | write "tap" sockets. This is an implementation detail of the Open vSwitch | |
| 1040 | userspace switch, which implements its "internal" ports as Linux (or BSD) | |
| 1041 | "tap" sockets. In such a userspace switch, OVS receives packets sent on | |
| 1042 | the "tap" device used to implement an "internal" port by reading the | |
| 1043 | associated "tap" socket, and bridges them to the rest of the switch. In | |
| 1044 | the other direction, OVS transmits packets bridged to the "internal" port | |
| 1045 | by writing them to the "tap" socket, causing them to be processed by the | |
| 1046 | kernel TCP/IP stack as if they had been received on the "tap" device. | |
| 1047 | Users should not need to be concerned with this implementation detail. | |
| 1048 | ||
| 1049 | Open vSwitch has a network device type called "tap". This is intended only | |
| 1050 | for implementing "internal" ports in the OVS userspace switch and should | |
| 1051 | not be used otherwise. In particular, users should not configure KVM "tap" | |
| 1052 | devices as type "tap" (use type "system", the default, instead). | |
| 1053 | ||
| 1054 | Q: I observe packet loss at the beginning of RFC2544 tests on a server running | |
| 1055 | few hundred container apps bridged to OVS with traffic generated by HW traffic | |
| 1056 | generator. How can I fix this? | |
| 1057 | ||
| 1058 | A: This is expected behavior on virtual switches. RFC2544 tests were | |
| 1059 | designed for hardware switches, which don't have caches on the fastpath | |
| 1060 | that need to be heated. Traffic generators in order to prime the switch | |
| 1061 | use learning phase to heat the caches before sending the actual traffic in | |
| 1062 | test phase. In case of OVS the cache is flushed quickly and to accommodate | |
| 1063 | the traffic generator's delay between learning and test phase, the max-idle | |
| 1064 | timeout settings should be changed to 50000 ms.:: | |
| 1065 | ||
| 1066 | $ ovs-vsctl --no-wait set Open_vSwitch . other_config:max-idle=50000 | |
| 1067 | ||
| 1068 | Q: How can I configure the bridge internal interface MTU? Why does Open vSwitch | |
| 1069 | keep changing internal ports MTU? | |
| 1070 | ||
| 1071 | A: By default Open vSwitch overrides the internal interfaces (e.g. br0) | |
| 1072 | MTU. If you have just an internal interface (e.g. br0) and a physical | |
| 1073 | interface (e.g. eth0), then every change in MTU to eth0 will be reflected | |
| 1074 | to br0. Any manual MTU configuration using `ip` or `ifconfig` on internal | |
| 1075 | interfaces is going to be overridden by Open vSwitch to match the current | |
| 1076 | bridge minimum. | |
| 1077 | ||
| 1078 | Sometimes this behavior is not desirable, for example with tunnels. The | |
| 1079 | MTU of an internal interface can be explicitly set using the following | |
| dc76953f | 1080 | command:: |
| edde4861 SF |
1081 | |
| 1082 | $ ovs-vsctl set int br0 mtu_request=1450 | |
| 1083 | ||
| 1084 | After this, Open vSwitch will configure br0 MTU to 1450. Since this | |
| 1085 | setting is in the database it will be persistent (compared to what happens | |
| 1086 | with `ip` or `ifconfig`). | |
| 1087 | ||
| 1088 | The MTU configuration can be removed to restore the default behavior | |
| dc76953f | 1089 | with:: |
| edde4861 SF |
1090 | |
| 1091 | $ ovs-vsctl set int br0 mtu_request=[] | |
| 1092 | ||
| 1093 | The mtu_request column can be used to configure MTU even for physical | |
| 1094 | interfaces (e.g. eth0). | |
| 1095 | ||
| 1096 | QOS | |
| 1097 | --- | |
| 1098 | ||
| 1099 | Q: Does OVS support Quality of Service (QoS)? | |
| 1100 | ||
| 1101 | A: Yes. For traffic that egresses from a switch, OVS supports traffic | |
| 1102 | shaping; for traffic that ingresses into a switch, OVS support policing. | |
| 1103 | Policing is a simple form of quality-of-service that simply drops packets | |
| 1104 | received in excess of the configured rate. Due to its simplicity, policing | |
| 1105 | is usually less accurate and less effective than egress traffic shaping, | |
| 1106 | which queues packets. | |
| 1107 | ||
| 1108 | Keep in mind that ingress and egress are from the perspective of the | |
| 1109 | switch. That means that egress shaping limits the rate at which traffic is | |
| 1110 | allowed to transmit from a physical interface, but not the rate at which | |
| 1111 | traffic will be received on a virtual machine's VIF. For ingress policing, | |
| 1112 | the behavior is the opposite. | |
| 1113 | ||
| 1114 | Q: How do I configure egress traffic shaping? | |
| 1115 | ||
| 1116 | A: Suppose that you want to set up bridge br0 connected to physical | |
| 1117 | Ethernet port eth0 (a 1 Gbps device) and virtual machine interfaces vif1.0 | |
| 1118 | and vif2.0, and that you want to limit traffic from vif1.0 to eth0 to 10 | |
| 1119 | Mbps and from vif2.0 to eth0 to 20 Mbps. Then, you could configure the | |
| dc76953f | 1120 | bridge this way:: |
| edde4861 SF |
1121 | |
| 1122 | $ ovs-vsctl -- \ | |
| 1123 | add-br br0 -- \ | |
| 1124 | add-port br0 eth0 -- \ | |
| 1125 | add-port br0 vif1.0 -- set interface vif1.0 ofport_request=5 -- \ | |
| 1126 | add-port br0 vif2.0 -- set interface vif2.0 ofport_request=6 -- \ | |
| 1127 | set port eth0 qos=@newqos -- \ | |
| 1128 | --id=@newqos create qos type=linux-htb \ | |
| 1129 | other-config:max-rate=1000000000 \ | |
| 1130 | queues:123=@vif10queue \ | |
| 1131 | queues:234=@vif20queue -- \ | |
| 1132 | --id=@vif10queue create queue other-config:max-rate=10000000 -- \ | |
| 1133 | --id=@vif20queue create queue other-config:max-rate=20000000 | |
| 1134 | ||
| 1135 | At this point, bridge br0 is configured with the ports and eth0 is | |
| 1136 | configured with the queues that you need for QoS, but nothing is actually | |
| 1137 | directing packets from vif1.0 or vif2.0 to the queues that we have set up | |
| 1138 | for them. That means that all of the packets to eth0 are going to the | |
| 1139 | "default queue", which is not what we want. | |
| 1140 | ||
| 1141 | We use OpenFlow to direct packets from vif1.0 and vif2.0 to the queues | |
| dc76953f | 1142 | reserved for them:: |
| edde4861 SF |
1143 | |
| 1144 | $ ovs-ofctl add-flow br0 in_port=5,actions=set_queue:123,normal | |
| 1145 | $ ovs-ofctl add-flow br0 in_port=6,actions=set_queue:234,normal | |
| 1146 | ||
| 1147 | Each of the above flows matches on the input port, sets up the appropriate | |
| 1148 | queue (123 for vif1.0, 234 for vif2.0), and then executes the "normal" | |
| 1149 | action, which performs the same switching that Open vSwitch would have done | |
| 1150 | without any OpenFlow flows being present. (We know that vif1.0 and vif2.0 | |
| 1151 | have OpenFlow port numbers 5 and 6, respectively, because we set their | |
| 1152 | ofport_request columns above. If we had not done that, then we would have | |
| 1153 | needed to find out their port numbers before setting up these flows.) | |
| 1154 | ||
| 1155 | Now traffic going from vif1.0 or vif2.0 to eth0 should be rate-limited. | |
| 1156 | ||
| dc76953f | 1157 | By the way, if you delete the bridge created by the above commands, with:: |
| edde4861 SF |
1158 | |
| 1159 | $ ovs-vsctl del-br br0 | |
| 1160 | ||
| 1161 | then that will leave one unreferenced QoS record and two unreferenced Queue | |
| 1162 | records in the Open vSwich database. One way to clear them out, assuming | |
| dc76953f | 1163 | you don't have other QoS or Queue records that you want to keep, is:: |
| edde4861 SF |
1164 | |
| 1165 | $ ovs-vsctl -- --all destroy QoS -- --all destroy Queue | |
| 1166 | ||
| 1167 | If you do want to keep some QoS or Queue records, or the Open vSwitch you | |
| 1168 | are using is older than version 1.8 (which added the ``--all`` option), | |
| 1169 | then you will have to destroy QoS and Queue records individually. | |
| 1170 | ||
| 1171 | Q: How do I configure ingress policing? | |
| 1172 | ||
| 1173 | A: A policing policy can be configured on an interface to drop packets that | |
| 1174 | arrive at a higher rate than the configured value. For example, the | |
| 1175 | following commands will rate-limit traffic that vif1.0 may generate to | |
| 1176 | 10Mbps: | |
| 1177 | ||
| 1178 | $ ovs-vsctl set interface vif1.0 ingress_policing_rate=10000 | |
| 1179 | $ ovs-vsctl set interface vif1.0 ingress_policing_burst=8000 | |
| 1180 | ||
| 1181 | Traffic policing can interact poorly with some network protocols and can | |
| 1182 | have surprising results. The "Ingress Policing" section of | |
| 1183 | ovs-vswitchd.conf.db(5) discusses the issues in greater detail. | |
| 1184 | ||
| 1185 | Q: I configured Quality of Service (QoS) in my OpenFlow network by adding | |
| 1186 | records to the QoS and Queue table, but the results aren't what I expect. | |
| 1187 | ||
| 1188 | A: Did you install OpenFlow flows that use your queues? This is the | |
| 1189 | primary way to tell Open vSwitch which queues you want to use. If you | |
| 1190 | don't do this, then the default queue will be used, which will probably not | |
| 1191 | have the effect you want. | |
| 1192 | ||
| 1193 | Refer to the previous question for an example. | |
| 1194 | ||
| 1195 | Q: I'd like to take advantage of some QoS feature that Open vSwitch doesn't yet | |
| 1196 | support. How do I do that? | |
| 1197 | ||
| 1198 | A: Open vSwitch does not implement QoS itself. Instead, it can configure | |
| 1199 | some, but not all, of the QoS features built into the Linux kernel. If you | |
| 1200 | need some QoS feature that OVS cannot configure itself, then the first step | |
| 1201 | is to figure out whether Linux QoS supports that feature. If it does, then | |
| 1202 | you can submit a patch to support Open vSwitch configuration for that | |
| 1203 | feature, or you can use "tc" directly to configure the feature in Linux. | |
| 1204 | (If Linux QoS doesn't support the feature you want, then first you have to | |
| 1205 | add that support to Linux.) | |
| 1206 | ||
| 1207 | Q: I configured QoS, correctly, but my measurements show that it isn't working | |
| 1208 | as well as I expect. | |
| 1209 | ||
| 1210 | A: With the Linux kernel, the Open vSwitch implementation of QoS has two | |
| 1211 | aspects: | |
| 1212 | ||
| 1213 | - Open vSwitch configures a subset of Linux kernel QoS features, according | |
| 1214 | to what is in OVSDB. It is possible that this code has bugs. If you | |
| 1215 | believe that this is so, then you can configure the Linux traffic control | |
| 1216 | (QoS) stack directly with the "tc" program. If you get better results | |
| 1217 | that way, you can send a detailed bug report to bugs@openvswitch.org. | |
| 1218 | ||
| 1219 | It is certain that Open vSwitch cannot configure every Linux kernel QoS | |
| 1220 | feature. If you need some feature that OVS cannot configure, then you | |
| 1221 | can also use "tc" directly (or add that feature to OVS). | |
| 1222 | ||
| 1223 | - The Open vSwitch implementation of OpenFlow allows flows to be directed | |
| 1224 | to particular queues. This is pretty simple and unlikely to have serious | |
| 1225 | bugs at this point. | |
| 1226 | ||
| 1227 | However, most problems with QoS on Linux are not bugs in Open vSwitch at | |
| 1228 | all. They tend to be either configuration errors (please see the earlier | |
| 1229 | questions in this section) or issues with the traffic control (QoS) stack | |
| 1230 | in Linux. The Open vSwitch developers are not experts on Linux traffic | |
| 1231 | control. We suggest that, if you believe you are encountering a problem | |
| 1232 | with Linux traffic control, that you consult the tc manpages (e.g. tc(8), | |
| 1233 | tc-htb(8), tc-hfsc(8)), web resources (e.g. http://lartc.org/), or mailing | |
| 1234 | lists (e.g. http://vger.kernel.org/vger-lists.html#netdev). | |
| 1235 | ||
| 1236 | Q: Does Open vSwitch support OpenFlow meters? | |
| 1237 | ||
| 1238 | A: Since version 2.0, Open vSwitch has OpenFlow protocol support for | |
| 1239 | OpenFlow meters. There is no implementation of meters in the Open vSwitch | |
| 1240 | software switch (neither the kernel-based nor userspace switches). | |
| 1241 | ||
| 1242 | VLANs | |
| 1243 | ----- | |
| 1244 | ||
| 1245 | Q: What's a VLAN? | |
| 1246 | ||
| 1247 | A: At the simplest level, a VLAN (short for "virtual LAN") is a way to | |
| 1248 | partition a single switch into multiple switches. Suppose, for example, | |
| 1249 | that you have two groups of machines, group A and group B. You want the | |
| 1250 | machines in group A to be able to talk to each other, and you want the | |
| 1251 | machine in group B to be able to talk to each other, but you don't want the | |
| 1252 | machines in group A to be able to talk to the machines in group B. You can | |
| 1253 | do this with two switches, by plugging the machines in group A into one | |
| 1254 | switch and the machines in group B into the other switch. | |
| 1255 | ||
| 1256 | If you only have one switch, then you can use VLANs to do the same thing, | |
| 1257 | by configuring the ports for machines in group A as VLAN "access ports" for | |
| 1258 | one VLAN and the ports for group B as "access ports" for a different VLAN. | |
| 1259 | The switch will only forward packets between ports that are assigned to the | |
| 1260 | same VLAN, so this effectively subdivides your single switch into two | |
| 1261 | independent switches, one for each group of machines. | |
| 1262 | ||
| 1263 | So far we haven't said anything about VLAN headers. With access ports, | |
| 1264 | like we've described so far, no VLAN header is present in the Ethernet | |
| 1265 | frame. This means that the machines (or switches) connected to access | |
| 1266 | ports need not be aware that VLANs are involved, just like in the case | |
| 1267 | where we use two different physical switches. | |
| 1268 | ||
| 1269 | Now suppose that you have a whole bunch of switches in your network, | |
| 1270 | instead of just one, and that some machines in group A are connected | |
| 1271 | directly to both switches 1 and 2. To allow these machines to talk to each | |
| 1272 | other, you could add an access port for group A's VLAN to switch 1 and | |
| 1273 | another to switch 2, and then connect an Ethernet cable between those | |
| 1274 | ports. That works fine, but it doesn't scale well as the number of | |
| 1275 | switches and the number of VLANs increases, because you use up a lot of | |
| 1276 | valuable switch ports just connecting together your VLANs. | |
| 1277 | ||
| 1278 | This is where VLAN headers come in. Instead of using one cable and two | |
| 1279 | ports per VLAN to connect a pair of switches, we configure a port on each | |
| 1280 | switch as a VLAN "trunk port". Packets sent and received on a trunk port | |
| 1281 | carry a VLAN header that says what VLAN the packet belongs to, so that only | |
| 1282 | two ports total are required to connect the switches, regardless of the | |
| 1283 | number of VLANs in use. Normally, only switches (either physical or | |
| 1284 | virtual) are connected to a trunk port, not individual hosts, because | |
| 1285 | individual hosts don't expect to see a VLAN header in the traffic that they | |
| 1286 | receive. | |
| 1287 | ||
| 1288 | None of the above discussion says anything about particular VLAN numbers. | |
| 1289 | This is because VLAN numbers are completely arbitrary. One must only | |
| 1290 | ensure that a given VLAN is numbered consistently throughout a network and | |
| 1291 | that different VLANs are given different numbers. (That said, VLAN 0 is | |
| 1292 | usually synonymous with a packet that has no VLAN header, and VLAN 4095 is | |
| 1293 | reserved.) | |
| 1294 | ||
| 1295 | Q: VLANs don't work. | |
| 1296 | ||
| 1297 | A: Many drivers in Linux kernels before version 3.3 had VLAN-related bugs. | |
| 1298 | If you are having problems with VLANs that you suspect to be driver | |
| 1299 | related, then you have several options: | |
| 1300 | ||
| 1301 | - Upgrade to Linux 3.3 or later. | |
| 1302 | ||
| 1303 | - Build and install a fixed version of the particular driver that is | |
| 1304 | causing trouble, if one is available. | |
| 1305 | ||
| 1306 | - Use a NIC whose driver does not have VLAN problems. | |
| 1307 | ||
| 1308 | - Use "VLAN splinters", a feature in Open vSwitch 1.4 upto 2.5 that works | |
| 1309 | around bugs in kernel drivers. To enable VLAN splinters on interface | |
| dc76953f | 1310 | eth0, use the command:: |
| edde4861 SF |
1311 | |
| 1312 | $ ovs-vsctl set interface eth0 other-config:enable-vlan-splinters=true | |
| 1313 | ||
| 1314 | For VLAN splinters to be effective, Open vSwitch must know which VLANs | |
| 1315 | are in use. See the "VLAN splinters" section in the Interface table in | |
| 1316 | ovs-vswitchd.conf.db(5) for details on how Open vSwitch infers in-use | |
| 1317 | VLANs. | |
| 1318 | ||
| 1319 | VLAN splinters increase memory use and reduce performance, so use them | |
| 1320 | only if needed. | |
| 1321 | ||
| 1322 | - Apply the "vlan workaround" patch from the XenServer kernel patch queue, | |
| 1323 | build Open vSwitch against this patched kernel, and then use | |
| 1324 | ovs-vlan-bug-workaround(8) to enable the VLAN workaround for each | |
| 1325 | interface whose driver is buggy. | |
| 1326 | ||
| 1327 | (This is a nontrivial exercise, so this option is included only for | |
| 1328 | completeness.) | |
| 1329 | ||
| 1330 | It is not always easy to tell whether a Linux kernel driver has buggy VLAN | |
| 1331 | support. The ovs-vlan-test(8) and ovs-test(8) utilities can help you test. | |
| 1332 | See their manpages for details. Of the two utilities, ovs-test(8) is newer | |
| 1333 | and more thorough, but ovs-vlan-test(8) may be easier to use. | |
| 1334 | ||
| 1335 | Q: VLANs still don't work. I've tested the driver so I know that it's OK. | |
| 1336 | ||
| 1337 | A: Do you have VLANs enabled on the physical switch that OVS is attached | |
| 1338 | to? Make sure that the port is configured to trunk the VLAN or VLANs that | |
| 1339 | you are using with OVS. | |
| 1340 | ||
| 1341 | Q: Outgoing VLAN-tagged traffic goes through OVS to my physical switch | |
| 1342 | and to its destination host, but OVS seems to drop incoming return | |
| 1343 | traffic. | |
| 1344 | ||
| 1345 | A: It's possible that you have the VLAN configured on your physical switch | |
| 1346 | as the "native" VLAN. In this mode, the switch treats incoming packets | |
| 1347 | either tagged with the native VLAN or untagged as part of the native VLAN. | |
| 1348 | It may also send outgoing packets in the native VLAN without a VLAN tag. | |
| 1349 | ||
| 1350 | If this is the case, you have two choices: | |
| 1351 | ||
| 1352 | - Change the physical switch port configuration to tag packets it forwards | |
| 1353 | to OVS with the native VLAN instead of forwarding them untagged. | |
| 1354 | ||
| 1355 | - Change the OVS configuration for the physical port to a native VLAN mode. | |
| 1356 | For example, the following sets up a bridge with port eth0 in | |
| dc76953f | 1357 | "native-tagged" mode in VLAN 9:: |
| edde4861 SF |
1358 | |
| 1359 | $ ovs-vsctl add-br br0 $ ovs-vsctl add-port br0 eth0 tag=9 | |
| 1360 | vlan_mode=native-tagged | |
| 1361 | ||
| 1362 | In this situation, "native-untagged" mode will probably work equally | |
| 1363 | well. Refer to the documentation for the Port table in | |
| 1364 | ovs-vswitchd.conf.db(5) for more information. | |
| 1365 | ||
| dc76953f | 1366 | Q: I added a pair of VMs on different VLANs, like this:: |
| edde4861 SF |
1367 | |
| 1368 | $ ovs-vsctl add-br br0 | |
| 1369 | $ ovs-vsctl add-port br0 eth0 | |
| 1370 | $ ovs-vsctl add-port br0 tap0 tag=9 | |
| 1371 | $ ovs-vsctl add-port br0 tap1 tag=10 | |
| 1372 | ||
| 1373 | but the VMs can't access each other, the external network, or the Internet. | |
| 1374 | ||
| 1375 | A: It is to be expected that the VMs can't access each other. VLANs are a | |
| 1376 | means to partition a network. When you configured tap0 and tap1 as access | |
| 1377 | ports for different VLANs, you indicated that they should be isolated from | |
| 1378 | each other. | |
| 1379 | ||
| 1380 | As for the external network and the Internet, it seems likely that the | |
| 1381 | machines you are trying to access are not on VLAN 9 (or 10) and that the | |
| 1382 | Internet is not available on VLAN 9 (or 10). | |
| 1383 | ||
| dc76953f | 1384 | Q: I added a pair of VMs on the same VLAN, like this:: |
| edde4861 SF |
1385 | |
| 1386 | $ ovs-vsctl add-br br0 | |
| 1387 | $ ovs-vsctl add-port br0 eth0 | |
| 1388 | $ ovs-vsctl add-port br0 tap0 tag=9 | |
| 1389 | $ ovs-vsctl add-port br0 tap1 tag=9 | |
| 1390 | ||
| 1391 | The VMs can access each other, but not the external network or the Internet. | |
| 1392 | ||
| 1393 | A: It seems likely that the machines you are trying to access in the | |
| 1394 | external network are not on VLAN 9 and that the Internet is not available | |
| 1395 | on VLAN 9. Also, ensure VLAN 9 is set up as an allowed trunk VLAN on the | |
| 1396 | upstream switch port to which eth0 is connected. | |
| 1397 | ||
| 1398 | Q: Can I configure an IP address on a VLAN? | |
| 1399 | ||
| 1400 | A: Yes. Use an "internal port" configured as an access port. For example, | |
| 1401 | the following configures IP address 192.168.0.7 on VLAN 9. That is, OVS | |
| 1402 | will forward packets from eth0 to 192.168.0.7 only if they have an 802.1Q | |
| 1403 | header with VLAN 9. Conversely, traffic forwarded from 192.168.0.7 to eth0 | |
| dc76953f | 1404 | will be tagged with an 802.1Q header with VLAN 9:: |
| edde4861 SF |
1405 | |
| 1406 | $ ovs-vsctl add-br br0 | |
| 1407 | $ ovs-vsctl add-port br0 eth0 | |
| 1408 | $ ovs-vsctl add-port br0 vlan9 tag=9 \ | |
| 1409 | -- set interface vlan9 type=internal | |
| 1410 | $ ifconfig vlan9 192.168.0.7 | |
| 1411 | ||
| 1412 | See also the following question. | |
| 1413 | ||
| dc76953f | 1414 | Q: I configured one IP address on VLAN 0 and another on VLAN 9, like this:: |
| edde4861 SF |
1415 | |
| 1416 | $ ovs-vsctl add-br br0 | |
| 1417 | $ ovs-vsctl add-port br0 eth0 | |
| 1418 | $ ifconfig br0 192.168.0.5 | |
| 1419 | $ ovs-vsctl add-port br0 vlan9 tag=9 -- set interface vlan9 type=internal | |
| 1420 | $ ifconfig vlan9 192.168.0.9 | |
| 1421 | ||
| 1422 | but other hosts that are only on VLAN 0 can reach the IP address configured on | |
| 1423 | VLAN 9. What's going on? | |
| 1424 | ||
| 1425 | A: `RFC 1122 section 3.3.4.2 "Multihoming Requirements" | |
| 1426 | <https://tools.ietf.org/html/rfc1122#section-3.3.4.2>`__ describes two | |
| 1427 | approaches to IP address handling in Internet hosts: | |
| 1428 | ||
| 1429 | - In the "Strong ES Model", where an ES is a host ("End System"), an IP | |
| 1430 | address is primarily associated with a particular interface. The host | |
| 1431 | discards packets that arrive on interface A if they are destined for an | |
| 1432 | IP address that is configured on interface B. The host never sends | |
| 1433 | packets from interface A using a source address configured on interface | |
| 1434 | B. | |
| 1435 | ||
| 1436 | - In the "Weak ES Model", an IP address is primarily associated with a | |
| 1437 | host. The host accepts packets that arrive on any interface if they are | |
| 1438 | destined for any of the host's IP addresses, even if the address is | |
| 1439 | configured on some interface other than the one on which it arrived. The | |
| 1440 | host does not restrict itself to sending packets from an IP address | |
| 1441 | associated with the originating interface. | |
| 1442 | ||
| 1443 | Linux uses the weak ES model. That means that when packets destined to the | |
| 1444 | VLAN 9 IP address arrive on eth0 and are bridged to br0, the kernel IP | |
| 1445 | stack accepts them there for the VLAN 9 IP address, even though they were | |
| 1446 | not received on vlan9, the network device for vlan9. | |
| 1447 | ||
| 1448 | To simulate the strong ES model on Linux, one may add iptables rule to | |
| 1449 | filter packets based on source and destination address and adjust ARP | |
| 1450 | configuration with sysctls. | |
| 1451 | ||
| 1452 | BSD uses the strong ES model. | |
| 1453 | ||
| 1454 | Q: My OpenFlow controller doesn't see the VLANs that I expect. | |
| 1455 | ||
| 1456 | A: The configuration for VLANs in the Open vSwitch database (e.g. via | |
| 1457 | ovs-vsctl) only affects traffic that goes through Open vSwitch's | |
| 1458 | implementation of the OpenFlow "normal switching" action. By default, when | |
| 1459 | Open vSwitch isn't connected to a controller and nothing has been manually | |
| 1460 | configured in the flow table, all traffic goes through the "normal | |
| 1461 | switching" action. But, if you set up OpenFlow flows on your own, through | |
| 1462 | a controller or using ovs-ofctl or through other means, then you have to | |
| 1463 | implement VLAN handling yourself. | |
| 1464 | ||
| 1465 | You can use "normal switching" as a component of your OpenFlow actions, | |
| 1466 | e.g. by putting "normal" into the lists of actions on ovs-ofctl or by | |
| 1467 | outputting to OFPP_NORMAL from an OpenFlow controller. In situations where | |
| 1468 | this is not suitable, you can implement VLAN handling yourself, e.g.: | |
| 1469 | ||
| 1470 | - If a packet comes in on an access port, and the flow table needs to send | |
| 1471 | it out on a trunk port, then the flow can add the appropriate VLAN tag | |
| 1472 | with the "mod_vlan_vid" action. | |
| 1473 | ||
| 1474 | - If a packet comes in on a trunk port, and the flow table needs to send it | |
| 1475 | out on an access port, then the flow can strip the VLAN tag with the | |
| 1476 | "strip_vlan" action. | |
| 1477 | ||
| 1478 | Q: I configured ports on a bridge as access ports with different VLAN tags, | |
| dc76953f | 1479 | like this:: |
| edde4861 SF |
1480 | |
| 1481 | $ ovs-vsctl add-br br0 | |
| 1482 | $ ovs-vsctl set-controller br0 tcp:192.168.0.10:6653 | |
| 1483 | $ ovs-vsctl add-port br0 eth0 | |
| 1484 | $ ovs-vsctl add-port br0 tap0 tag=9 | |
| 1485 | $ ovs-vsctl add-port br0 tap1 tag=10 | |
| 1486 | ||
| 1487 | but the VMs running behind tap0 and tap1 can still communicate, that is, they | |
| 1488 | are not isolated from each other even though they are on different VLANs. | |
| 1489 | ||
| 1490 | A: Do you have a controller configured on br0 (as the commands above do)? | |
| 1491 | If so, then this is a variant on the previous question, "My OpenFlow | |
| 1492 | controller doesn't see the VLANs that I expect," and you can refer to the | |
| 1493 | answer there for more information. | |
| 1494 | ||
| 1495 | Q: How MAC learning works with VLANs? | |
| 1496 | ||
| 1497 | A: Open vSwitch implements Independent VLAN Learning (IVL) for | |
| 1498 | ``OFPP_NORMAL`` action, e.g. it logically has separate learning tables for | |
| 1499 | each VLANs. | |
| 1500 | ||
| 1501 | VXLANs | |
| 1502 | ------ | |
| 1503 | ||
| 1504 | Q: What's a VXLAN? | |
| 1505 | ||
| 1506 | A: VXLAN stands for Virtual eXtensible Local Area Network, and is a means | |
| 1507 | to solve the scaling challenges of VLAN networks in a multi-tenant | |
| 1508 | environment. VXLAN is an overlay network which transports an L2 network | |
| 1509 | over an existing L3 network. For more information on VXLAN, please see `RFC | |
| 1510 | 7348 <http://tools.ietf.org/html/rfc7348>`__. | |
| 1511 | ||
| 1512 | Q: How much of the VXLAN protocol does Open vSwitch currently support? | |
| 1513 | ||
| 1514 | A: Open vSwitch currently supports the framing format for packets on the | |
| 1515 | wire. There is currently no support for the multicast aspects of VXLAN. To | |
| 1516 | get around the lack of multicast support, it is possible to pre-provision | |
| 1517 | MAC to IP address mappings either manually or from a controller. | |
| 1518 | ||
| 1519 | Q: What destination UDP port does the VXLAN implementation in Open vSwitch | |
| 1520 | use? | |
| 1521 | ||
| 1522 | A: By default, Open vSwitch will use the assigned IANA port for VXLAN, | |
| 1523 | which is 4789. However, it is possible to configure the destination UDP | |
| 1524 | port manually on a per-VXLAN tunnel basis. An example of this configuration | |
| 1525 | is provided below.:: | |
| 1526 | ||
| 1527 | $ ovs-vsctl add-br br0 | |
| 1528 | $ ovs-vsctl add-port br0 vxlan1 -- set interface vxlan1 type=vxlan \ | |
| 1529 | options:remote_ip=192.168.1.2 options:key=flow options:dst_port=8472 | |
| 1530 | ||
| 1531 | Using OpenFlow | |
| 1532 | -------------- | |
| 1533 | ||
| 1534 | Q: What versions of OpenFlow does Open vSwitch support? | |
| 1535 | ||
| 1536 | A: The following table lists the versions of OpenFlow supported by each | |
| 1537 | version of Open vSwitch: | |
| 1538 | ||
| 1539 | =============== ===== ===== ===== ===== ===== ===== ===== | |
| 1540 | Open vSwitch OF1.0 OF1.1 OF1.2 OF1.3 OF1.4 OF1.5 OF1.6 | |
| 1541 | =============== ===== ===== ===== ===== ===== ===== ===== | |
| 1542 | 1.9 and earlier yes --- --- --- --- --- --- | |
| 1543 | 1.10 yes --- (*) (*) --- --- --- | |
| 1544 | 1.11 yes --- (*) (*) --- --- --- | |
| 1545 | 2.0 yes (*) (*) (*) --- --- --- | |
| 1546 | 2.1 yes (*) (*) (*) --- --- --- | |
| 1547 | 2.2 yes (*) (*) (*) (%) (*) --- | |
| 1548 | 2.3 yes yes yes yes (*) (*) --- | |
| 1549 | 2.4 yes yes yes yes (*) (*) --- | |
| 1550 | 2.5 yes yes yes yes (*) (*) (*) | |
| 1551 | =============== ===== ===== ===== ===== ===== ===== ===== | |
| 1552 | ||
| 1553 | (*) Supported, with one or more missing features. | |
| 1554 | (%) Experimental, unsafe implementation. | |
| 1555 | ||
| 1556 | Open vSwitch 2.3 enables OpenFlow 1.0, 1.1, 1.2, and 1.3 by default in | |
| 1557 | ovs-vswitchd. In Open vSwitch 1.10 through 2.2, OpenFlow 1.1, 1.2, and 1.3 | |
| 1558 | must be enabled manually in ovs-vswitchd. | |
| 1559 | ||
| 1560 | Some versions of OpenFlow are supported with missing features and therefore | |
| 1561 | not enabled by default: OpenFlow 1.4 and 1.5, in Open vSwitch 2.3 and | |
| 1562 | later, as well as OpenFlow 1.6 in Open vSwitch 2.5 and later. Also, the | |
| 1563 | OpenFlow 1.6 specification is still under development and thus subject to | |
| 1564 | change. | |
| 1565 | ||
| 1566 | In any case, the user may override the default: | |
| 1567 | ||
| dc76953f | 1568 | - To enable OpenFlow 1.0, 1.1, 1.2, and 1.3 on bridge br0:: |
| edde4861 SF |
1569 | |
| 1570 | $ ovs-vsctl set bridge br0 \ | |
| 1571 | protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13 | |
| 1572 | ||
| dc76953f | 1573 | - To enable OpenFlow 1.0, 1.1, 1.2, 1.3, 1.4, and 1.5 on bridge br0:: |
| edde4861 SF |
1574 | |
| 1575 | $ ovs-vsctl set bridge br0 \ | |
| 1576 | protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13,OpenFlow14,OpenFlow15 | |
| 1577 | ||
| dc76953f | 1578 | - To enable only OpenFlow 1.0 on bridge br0:: |
| edde4861 SF |
1579 | |
| 1580 | $ ovs-vsctl set bridge br0 protocols=OpenFlow10 | |
| 1581 | ||
| 1582 | All current versions of ovs-ofctl enable only OpenFlow 1.0 by default. Use | |
| 1583 | the -O option to enable support for later versions of OpenFlow in | |
| dc76953f | 1584 | ovs-ofctl. For example:: |
| edde4861 SF |
1585 | |
| 1586 | $ ovs-ofctl -O OpenFlow13 dump-flows br0 | |
| 1587 | ||
| 1588 | (Open vSwitch 2.2 had an experimental implementation of OpenFlow 1.4 that | |
| 1589 | could cause crashes. We don't recommend enabling it.) | |
| 1590 | ||
| 1591 | The `OpenFlow guide <OPENFLOW.rst>`__ tracks support for OpenFlow 1.1 and | |
| 1592 | later features. When support for OpenFlow 1.4 and 1.5 is solidly | |
| 1593 | implemented, Open vSwitch will enable those version by default. | |
| 1594 | ||
| 1595 | Q: Does Open vSwitch support MPLS? | |
| 1596 | ||
| 1597 | A: Before version 1.11, Open vSwitch did not support MPLS. That is, these | |
| 1598 | versions can match on MPLS Ethernet types, but they cannot match, push, or | |
| 1599 | pop MPLS labels, nor can they look past MPLS labels into the encapsulated | |
| 1600 | packet. | |
| 1601 | ||
| 1602 | Open vSwitch versions 1.11, 2.0, and 2.1 have very minimal support for | |
| 1603 | MPLS. With the userspace datapath only, these versions can match, push, or | |
| 1604 | pop a single MPLS label, but they still cannot look past MPLS labels (even | |
| 1605 | after popping them) into the encapsulated packet. Kernel datapath support | |
| 1606 | is unchanged from earlier versions. | |
| 1607 | ||
| 1608 | Open vSwitch version 2.3 can match, push, or pop a single MPLS label and | |
| 1609 | look past the MPLS label into the encapsulated packet. Both userspace and | |
| 1610 | kernel datapaths will be supported, but MPLS processing always happens in | |
| 1611 | userspace either way, so kernel datapath performance will be disappointing. | |
| 1612 | ||
| 1613 | Open vSwitch version 2.4 can match, push, or pop up to 3 MPLS labels and | |
| 1614 | look past the MPLS label into the encapsulated packet. It will have kernel | |
| 1615 | support for MPLS, yielding improved performance. | |
| 1616 | ||
| 1617 | Q: I'm getting "error type 45250 code 0". What's that? | |
| 1618 | ||
| 1619 | A: This is a Open vSwitch extension to OpenFlow error codes. Open vSwitch | |
| 1620 | uses this extension when it must report an error to an OpenFlow controller | |
| 1621 | but no standard OpenFlow error code is suitable. | |
| 1622 | ||
| 1623 | Open vSwitch logs the errors that it sends to controllers, so the easiest | |
| 1624 | thing to do is probably to look at the ovs-vswitchd log to find out what | |
| 1625 | the error was. | |
| 1626 | ||
| 1627 | If you want to dissect the extended error message yourself, the format is | |
| 1628 | documented in include/openflow/nicira-ext.h in the Open vSwitch source | |
| 1629 | distribution. The extended error codes are documented in | |
| 1630 | include/openvswitch/ofp-errors.h. | |
| 1631 | ||
| 1632 | Q: Some of the traffic that I'd expect my OpenFlow controller to see doesn't | |
| 1633 | actually appear through the OpenFlow connection, even though I know that it's | |
| 1634 | going through. | |
| 1635 | ||
| 1636 | A: By default, Open vSwitch assumes that OpenFlow controllers are connected | |
| 1637 | "in-band", that is, that the controllers are actually part of the network | |
| 1638 | that is being controlled. In in-band mode, Open vSwitch sets up special | |
| 1639 | "hidden" flows to make sure that traffic can make it back and forth between | |
| 1640 | OVS and the controllers. These hidden flows are higher priority than any | |
| 1641 | flows that can be set up through OpenFlow, and they are not visible through | |
| 1642 | normal OpenFlow flow table dumps. | |
| 1643 | ||
| 1644 | Usually, the hidden flows are desirable and helpful, but occasionally they | |
| 1645 | can cause unexpected behavior. You can view the full OpenFlow flow table, | |
| dc76953f | 1646 | including hidden flows, on bridge br0 with the command:: |
| edde4861 SF |
1647 | |
| 1648 | $ ovs-appctl bridge/dump-flows br0 | |
| 1649 | ||
| 1650 | to help you debug. The hidden flows are those with priorities | |
| 1651 | greater than 65535 (the maximum priority that can be set with | |
| 1652 | OpenFlow). | |
| 1653 | ||
| 1654 | The DESIGN file at the top level of the Open vSwitch source | |
| 1655 | distribution describes the in-band model in detail. | |
| 1656 | ||
| 1657 | If your controllers are not actually in-band (e.g. they are on | |
| 1658 | localhost via 127.0.0.1, or on a separate network), then you should | |
| 1659 | configure your controllers in "out-of-band" mode. If you have one | |
| 1660 | controller on bridge br0, then you can configure out-of-band mode | |
| dc76953f | 1661 | on it with:: |
| edde4861 SF |
1662 | |
| 1663 | $ ovs-vsctl set controller br0 connection-mode=out-of-band | |
| 1664 | ||
| 1665 | Q: Some of the OpenFlow flows that my controller sets up don't seem to apply to | |
| 1666 | certain traffic, especially traffic between OVS and the controller itself. | |
| 1667 | ||
| 1668 | A: See above. | |
| 1669 | ||
| 1670 | Q: I configured all my controllers for out-of-band control mode but "ovs-appctl | |
| 1671 | bridge/dump-flows" still shows some hidden flows. | |
| 1672 | ||
| 1673 | A: You probably have a remote manager configured (e.g. with "ovs-vsctl | |
| 1674 | set-manager"). By default, Open vSwitch assumes that managers need in-band | |
| 1675 | rules set up on every bridge. You can disable these rules on bridge br0 | |
| dc76953f | 1676 | with:: |
| edde4861 SF |
1677 | |
| 1678 | $ ovs-vsctl set bridge br0 other-config:disable-in-band=true | |
| 1679 | ||
| 1680 | This actually disables in-band control entirely for the bridge, as if all | |
| 1681 | the bridge's controllers were configured for out-of-band control. | |
| 1682 | ||
| 1683 | Q: My OpenFlow controller doesn't see the VLANs that I expect. | |
| 1684 | ||
| 1685 | A: See answer under "VLANs", above. | |
| 1686 | ||
| 1687 | Q: I ran ``ovs-ofctl add-flow br0 nw_dst=192.168.0.1,actions=drop`` but I got a | |
| dc76953f | 1688 | funny message like this:: |
| edde4861 SF |
1689 | |
| 1690 | ofp_util|INFO|normalization changed ofp_match, details: | |
| 1691 | ofp_util|INFO| pre: nw_dst=192.168.0.1 | |
| 1692 | ofp_util|INFO|post: | |
| 1693 | ||
| 1694 | and when I ran ``ovs-ofctl dump-flows br0`` I saw that my nw_dst match had | |
| 1695 | disappeared, so that the flow ends up matching every packet. | |
| 1696 | ||
| 1697 | A: The term "normalization" in the log message means that a flow cannot | |
| 1698 | match on an L3 field without saying what L3 protocol is in use. The | |
| 1699 | "ovs-ofctl" command above didn't specify an L3 protocol, so the L3 field | |
| 1700 | match was dropped. | |
| 1701 | ||
| 1702 | In this case, the L3 protocol could be IP or ARP. A correct command for | |
| dc76953f | 1703 | each possibility is, respectively:: |
| edde4861 SF |
1704 | |
| 1705 | $ ovs-ofctl add-flow br0 ip,nw_dst=192.168.0.1,actions=drop | |
| 1706 | ||
| dc76953f | 1707 | and:: |
| edde4861 SF |
1708 | |
| 1709 | $ ovs-ofctl add-flow br0 arp,nw_dst=192.168.0.1,actions=drop | |
| 1710 | ||
| 1711 | Similarly, a flow cannot match on an L4 field without saying what L4 | |
| 1712 | protocol is in use. For example, the flow match ``tp_src=1234`` is, by | |
| 1713 | itself, meaningless and will be ignored. Instead, to match TCP source port | |
| 1714 | 1234, write ``tcp,tp_src=1234``, or to match UDP source port 1234, write | |
| 1715 | ``udp,tp_src=1234``. | |
| 1716 | ||
| 1717 | Q: How can I figure out the OpenFlow port number for a given port? | |
| 1718 | ||
| 1719 | A: The ``OFPT_FEATURES_REQUEST`` message requests an OpenFlow switch to | |
| 1720 | respond with an ``OFPT_FEATURES_REPLY`` that, among other information, | |
| 1721 | includes a mapping between OpenFlow port names and numbers. From a command | |
| 1722 | prompt, ``ovs-ofctl show br0`` makes such a request and prints the response | |
| 1723 | for switch br0. | |
| 1724 | ||
| 1725 | The Interface table in the Open vSwitch database also maps OpenFlow port | |
| 1726 | names to numbers. To print the OpenFlow port number associated with | |
| dc76953f | 1727 | interface eth0, run:: |
| edde4861 SF |
1728 | |
| 1729 | $ ovs-vsctl get Interface eth0 ofport | |
| 1730 | ||
| dc76953f | 1731 | You can print the entire mapping with:: |
| edde4861 SF |
1732 | |
| 1733 | $ ovs-vsctl -- --columns=name,ofport list Interface | |
| 1734 | ||
| 1735 | but the output mixes together interfaces from all bridges in the database, | |
| 1736 | so it may be confusing if more than one bridge exists. | |
| 1737 | ||
| 1738 | In the Open vSwitch database, ofport value ``-1`` means that the interface | |
| 1739 | could not be created due to an error. (The Open vSwitch log should | |
| 1740 | indicate the reason.) ofport value ``[]`` (the empty set) means that the | |
| 1741 | interface hasn't been created yet. The latter is normally an intermittent | |
| 1742 | condition (unless ovs-vswitchd is not running). | |
| 1743 | ||
| 1744 | Q: I added some flows with my controller or with ovs-ofctl, but when I run | |
| 1745 | "ovs-dpctl dump-flows" I don't see them. | |
| 1746 | ||
| 1747 | A: ovs-dpctl queries a kernel datapath, not an OpenFlow switch. It won't | |
| 1748 | display the information that you want. You want to use ``ovs-ofctl | |
| 1749 | dump-flows`` instead. | |
| 1750 | ||
| 1751 | Q: It looks like each of the interfaces in my bonded port shows up as an | |
| 1752 | individual OpenFlow port. Is that right? | |
| 1753 | ||
| 1754 | A: Yes, Open vSwitch makes individual bond interfaces visible as OpenFlow | |
| 1755 | ports, rather than the bond as a whole. The interfaces are treated | |
| 1756 | together as a bond for only a few purposes: | |
| 1757 | ||
| 1758 | - Sending a packet to the OFPP_NORMAL port. (When an OpenFlow controller | |
| 1759 | is not configured, this happens implicitly to every packet.) | |
| 1760 | ||
| 1761 | - Mirrors configured for output to a bonded port. | |
| 1762 | ||
| 1763 | It would make a lot of sense for Open vSwitch to present a bond as a single | |
| 1764 | OpenFlow port. If you want to contribute an implementation of such a | |
| 1765 | feature, please bring it up on the Open vSwitch development mailing list at | |
| 1766 | dev@openvswitch.org. | |
| 1767 | ||
| 1768 | Q: I have a sophisticated network setup involving Open vSwitch, VMs or multiple | |
| 1769 | hosts, and other components. The behavior isn't what I expect. Help! | |
| 1770 | ||
| 1771 | A: To debug network behavior problems, trace the path of a packet, | |
| 1772 | hop-by-hop, from its origin in one host to a remote host. If that's | |
| 1773 | correct, then trace the path of the response packet back to the origin. | |
| 1774 | ||
| 1775 | The open source tool called ``plotnetcfg`` can help to understand the | |
| 1776 | relationship between the networking devices on a single host. | |
| 1777 | ||
| 1778 | Usually a simple ICMP echo request and reply (``ping``) packet is good | |
| 1779 | enough. Start by initiating an ongoing ``ping`` from the origin host to a | |
| 1780 | remote host. If you are tracking down a connectivity problem, the "ping" | |
| 1781 | will not display any successful output, but packets are still being sent. | |
| 1782 | (In this case the packets being sent are likely ARP rather than ICMP.) | |
| 1783 | ||
| 1784 | Tools available for tracing include the following: | |
| 1785 | ||
| 1786 | - ``tcpdump`` and ``wireshark`` for observing hops across network devices, | |
| 1787 | such as Open vSwitch internal devices and physical wires. | |
| 1788 | ||
| 1789 | - ``ovs-appctl dpif/dump-flows <br>`` in Open vSwitch 1.10 and later or | |
| 1790 | ``ovs-dpctl dump-flows <br>`` in earlier versions. These tools allow one | |
| 1791 | to observe the actions being taken on packets in ongoing flows. | |
| 1792 | ||
| 1793 | See ovs-vswitchd(8) for ``ovs-appctl dpif/dump-flows`` documentation, | |
| 1794 | ovs-dpctl(8) for ``ovs-dpctl dump-flows`` documentation, and "Why are | |
| 1795 | there so many different ways to dump flows?" above for some background. | |
| 1796 | ||
| 1797 | - ``ovs-appctl ofproto/trace`` to observe the logic behind how ovs-vswitchd | |
| 1798 | treats packets. See ovs-vswitchd(8) for documentation. You can out more | |
| 1799 | details about a given flow that ``ovs-dpctl dump-flows`` displays, by | |
| 1800 | cutting and pasting a flow from the output into an ``ovs-appctl | |
| 1801 | ofproto/trace`` command. | |
| 1802 | ||
| 1803 | - SPAN, RSPAN, and ERSPAN features of physical switches, to observe what | |
| 1804 | goes on at these physical hops. | |
| 1805 | ||
| 1806 | Starting at the origin of a given packet, observe the packet at each hop in | |
| 1807 | turn. For example, in one plausible scenario, you might: | |
| 1808 | ||
| 1809 | 1. ``tcpdump`` the ``eth`` interface through which an ARP egresses a VM, | |
| 1810 | from inside the VM. | |
| 1811 | ||
| 1812 | 2. ``tcpdump`` the ``vif`` or ``tap`` interface through which the ARP | |
| 1813 | ingresses the host machine. | |
| 1814 | ||
| 1815 | 3. Use ``ovs-dpctl dump-flows`` to spot the ARP flow and observe the host | |
| 1816 | interface through which the ARP egresses the physical machine. You may | |
| 1817 | need to use ``ovs-dpctl show`` to interpret the port numbers. If the | |
| 1818 | output seems surprising, you can use ``ovs-appctl ofproto/trace`` to | |
| 1819 | observe details of how ovs-vswitchd determined the actions in the | |
| 1820 | ``ovs-dpctl dump-flows`` output. | |
| 1821 | ||
| 1822 | 4. ``tcpdump`` the ``eth`` interface through which the ARP egresses the | |
| 1823 | physical machine. | |
| 1824 | ||
| 1825 | 5. ``tcpdump`` the ``eth`` interface through which the ARP ingresses the | |
| 1826 | physical machine, at the remote host that receives the ARP. | |
| 1827 | ||
| 1828 | 6. Use ``ovs-dpctl dump-flows`` to spot the ARP flow on the remote host | |
| 1829 | remote host that receives the ARP and observe the VM ``vif`` or ``tap`` | |
| 1830 | interface to which the flow is directed. Again, ``ovs-dpctl show`` and | |
| 1831 | ``ovs-appctl ofproto/trace`` might help. | |
| 1832 | ||
| 1833 | 7. ``tcpdump`` the ``vif`` or ``tap`` interface to which the ARP is | |
| 1834 | directed. | |
| 1835 | ||
| 1836 | 8. ``tcpdump`` the ``eth`` interface through which the ARP ingresses a VM, | |
| 1837 | from inside the VM. | |
| 1838 | ||
| 1839 | It is likely that during one of these steps you will figure out the | |
| 1840 | problem. If not, then follow the ARP reply back to the origin, in reverse. | |
| 1841 | ||
| 1842 | Q: How do I make a flow drop packets? | |
| 1843 | ||
| 1844 | A: To drop a packet is to receive it without forwarding it. OpenFlow | |
| 1845 | explicitly specifies forwarding actions. Thus, a flow with an empty set of | |
| 1846 | actions does not forward packets anywhere, causing them to be dropped. You | |
| 1847 | can specify an empty set of actions with ``actions=`` on the ovs-ofctl | |
| dc76953f | 1848 | command line. For example:: |
| edde4861 SF |
1849 | |
| 1850 | $ ovs-ofctl add-flow br0 priority=65535,actions= | |
| 1851 | ||
| 1852 | would cause every packet entering switch br0 to be dropped. | |
| 1853 | ||
| 1854 | You can write "drop" explicitly if you like. The effect is the same. | |
| 1855 | Thus, the following command also causes every packet entering switch br0 to | |
| dc76953f | 1856 | be dropped:: |
| edde4861 SF |
1857 | |
| 1858 | $ ovs-ofctl add-flow br0 priority=65535,actions=drop | |
| 1859 | ||
| 1860 | ``drop`` is not an action, either in OpenFlow or Open vSwitch. Rather, it | |
| 1861 | is only a way to say that there are no actions. | |
| 1862 | ||
| dc76953f | 1863 | Q: I added a flow to send packets out the ingress port, like this:: |
| edde4861 SF |
1864 | |
| 1865 | $ ovs-ofctl add-flow br0 in_port=2,actions=2 | |
| 1866 | ||
| 1867 | but OVS drops the packets instead. | |
| 1868 | ||
| 1869 | A: Yes, OpenFlow requires a switch to ignore attempts to send a packet out | |
| 1870 | its ingress port. The rationale is that dropping these packets makes it | |
| 1871 | harder to loop the network. Sometimes this behavior can even be | |
| 1872 | convenient, e.g. it is often the desired behavior in a flow that forwards a | |
| 1873 | packet to several ports ("floods" the packet). | |
| 1874 | ||
| 1875 | Sometimes one really needs to send a packet out its ingress port | |
| 1876 | ("hairpin"). In this case, output to ``OFPP_IN_PORT``, which in ovs-ofctl | |
| dc76953f | 1877 | syntax is expressed as just ``in_port``, e.g.:: |
| edde4861 SF |
1878 | |
| 1879 | $ ovs-ofctl add-flow br0 in_port=2,actions=in_port | |
| 1880 | ||
| 1881 | This also works in some circumstances where the flow doesn't match on the | |
| 1882 | input port. For example, if you know that your switch has five ports | |
| 1883 | numbered 2 through 6, then the following will send every received packet | |
| dc76953f | 1884 | out every port, even its ingress port:: |
| edde4861 SF |
1885 | |
| 1886 | $ ovs-ofctl add-flow br0 actions=2,3,4,5,6,in_port | |
| 1887 | ||
| dc76953f | 1888 | or, equivalently:: |
| edde4861 SF |
1889 | |
| 1890 | $ ovs-ofctl add-flow br0 actions=all,in_port | |
| 1891 | ||
| 1892 | Sometimes, in complicated flow tables with multiple levels of ``resubmit`` | |
| 1893 | actions, a flow needs to output to a particular port that may or may not be | |
| 1894 | the ingress port. It's difficult to take advantage of ``OFPP_IN_PORT`` in | |
| 1895 | this situation. To help, Open vSwitch provides, as an OpenFlow extension, | |
| 1896 | the ability to modify the in_port field. Whatever value is currently in | |
| 1897 | the in_port field is the port to which outputs will be dropped, as well as | |
| 1898 | the destination for ``OFPP_IN_PORT``. This means that the following will | |
| dc76953f | 1899 | reliably output to port 2 or to ports 2 through 6, respectively:: |
| edde4861 SF |
1900 | |
| 1901 | $ ovs-ofctl add-flow br0 in_port=2,actions=load:0->NXM_OF_IN_PORT[],2 | |
| 1902 | $ ovs-ofctl add-flow br0 actions=load:0->NXM_OF_IN_PORT[],2,3,4,5,6 | |
| 1903 | ||
| 1904 | If the input port is important, then one may save and restore it on the | |
| 1905 | stack: | |
| 1906 | ||
| 1907 | $ ovs-ofctl add-flow br0 actions=push:NXM_OF_IN_PORT[],\ | |
| 1908 | load:0->NXM_OF_IN_PORT[],\ | |
| 1909 | 2,3,4,5,6,\ | |
| 1910 | pop:NXM_OF_IN_PORT[] | |
| 1911 | ||
| 1912 | Q: My bridge br0 has host 192.168.0.1 on port 1 and host 192.168.0.2 on port 2. | |
| 1913 | I set up flows to forward only traffic destined to the other host and drop | |
| dc76953f | 1914 | other traffic, like this:: |
| edde4861 SF |
1915 | |
| 1916 | priority=5,in_port=1,ip,nw_dst=192.168.0.2,actions=2 | |
| 1917 | priority=5,in_port=2,ip,nw_dst=192.168.0.1,actions=1 | |
| 1918 | priority=0,actions=drop | |
| 1919 | ||
| 1920 | But it doesn't work--I don't get any connectivity when I do this. Why? | |
| 1921 | ||
| 1922 | A: These flows drop the ARP packets that IP hosts use to establish IP | |
| 1923 | connectivity over Ethernet. To solve the problem, add flows to allow ARP | |
| dc76953f | 1924 | to pass between the hosts:: |
| edde4861 SF |
1925 | |
| 1926 | priority=5,in_port=1,arp,actions=2 | |
| 1927 | priority=5,in_port=2,arp,actions=1 | |
| 1928 | ||
| 1929 | This issue can manifest other ways, too. The following flows that match on | |
| 1930 | Ethernet addresses instead of IP addresses will also drop ARP packets, | |
| 1931 | because ARP requests are broadcast instead of being directed to a specific | |
| dc76953f | 1932 | host:: |
| edde4861 SF |
1933 | |
| 1934 | priority=5,in_port=1,dl_dst=54:00:00:00:00:02,actions=2 | |
| 1935 | priority=5,in_port=2,dl_dst=54:00:00:00:00:01,actions=1 | |
| 1936 | priority=0,actions=drop | |
| 1937 | ||
| 1938 | The solution already described above will also work in this case. It may | |
| dc76953f | 1939 | be better to add flows to allow all multicast and broadcast traffic:: |
| edde4861 SF |
1940 | |
| 1941 | priority=5,in_port=1,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=2 | |
| 1942 | priority=5,in_port=2,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=1 | |
| 1943 | ||
| 1944 | Q: My bridge disconnects from my controller on add-port/del-port. | |
| 1945 | ||
| 1946 | A: Reconfiguring your bridge can change your bridge's datapath-id because | |
| 1947 | Open vSwitch generates datapath-id from the MAC address of one of its | |
| 1948 | ports. In that case, Open vSwitch disconnects from controllers because | |
| 1949 | there's no graceful way to notify controllers about the change of | |
| 1950 | datapath-id. | |
| 1951 | ||
| 1952 | To avoid the behaviour, you can configure datapath-id manually.:: | |
| 1953 | ||
| 1954 | $ ovs-vsctl set bridge br0 other-config:datapath-id=0123456789abcdef | |
| 1955 | ||
| 1956 | Q: My controller complains that OVS is not buffering packets. | |
| 1957 | What's going on? | |
| 1958 | ||
| 1959 | A: "Packet buffering" is an optional OpenFlow feature, and controllers | |
| 1960 | should detect how many "buffers" an OpenFlow switch implements. It was | |
| 1961 | recently noticed that OVS implementation of the buffering feature was not | |
| 1962 | compliant to OpenFlow specifications. Rather than fix it and risk | |
| 1963 | controller incompatibility, the buffering feature is removed as of OVS 2.7. | |
| 1964 | Controllers are already expected to work properly in cases where the switch | |
| 1965 | can not buffer packets, but sends full packets in "packet-in" messages | |
| 1966 | instead, so this change should not affect existing users. After the change | |
| 1967 | OVS always sends the ``buffer_id`` as ``0xffffffff`` in "packet-in" | |
| 1968 | messages and will send an error response if any other value of this field | |
| 1969 | is included in a "packet-out" or a "flow mod" sent by a controller. | |
| 1970 | ||
| 1971 | Q: How does OVS divide flows among buckets in an OpenFlow "select" group? | |
| 1972 | ||
| 1973 | A: In Open vSwitch 2.3 and earlier, Open vSwitch used the destination | |
| 1974 | Ethernet address to choose a bucket in a select group. | |
| 1975 | ||
| 1976 | Open vSwitch 2.4 and later by default hashes the source and destination | |
| 1977 | Ethernet address, VLAN ID, Ethernet type, IPv4/v6 source and destination | |
| 1978 | address and protocol, and for TCP and SCTP only, the source and destination | |
| 1979 | ports. The hash is "symmetric", meaning that exchanging source and | |
| 1980 | destination addresses does not change the bucket selection. | |
| 1981 | ||
| 1982 | Select groups in Open vSwitch 2.4 and later can be configured to use a | |
| 1983 | different hash function, using a Netronome extension to the OpenFlow 1.5+ | |
| 1984 | group_mod message. For more information, see | |
| 1985 | Documentation/group-selection-method-property.txt in the Open vSwitch | |
| 1986 | source tree. (OpenFlow 1.5 support in Open vSwitch is still experimental.) | |
| 1987 | ||
| 1988 | Q: I added a flow to accept packets on VLAN 123 and output them on VLAN 456, | |
| dc76953f | 1989 | like so:: |
| edde4861 SF |
1990 | |
| 1991 | $ ovs-ofctl add-flow br0 dl_vlan=123,actions=output:1,mod_vlan_vid:456 | |
| 1992 | ||
| 1993 | but the packets are actually being output in VLAN 123. Why? | |
| 1994 | ||
| 1995 | A: OpenFlow actions are executed in the order specified. Thus, the actions | |
| 1996 | above first output the packet, then change its VLAN. Since the output | |
| 1997 | occurs before changing the VLAN, the change in VLAN will have no visible | |
| 1998 | effect. | |
| 1999 | ||
| 2000 | To solve this and similar problems, order actions so that changes to | |
| dc76953f | 2001 | headers happen before output, e.g.:: |
| edde4861 SF |
2002 | |
| 2003 | $ ovs-ofctl add-flow br0 dl_vlan=123,actions=mod_vlan_vid:456,output:1 | |
| 2004 | ||
| 2005 | Q: The "learn" action can't learn the action I want, can you improve it? | |
| 2006 | ||
| 2007 | A: By itself, the "learn" action can only put two kinds of actions into the | |
| 2008 | flows that it creates: "load" and "output" actions. If "learn" is used in | |
| 2009 | isolation, these are severe limits. | |
| 2010 | ||
| 2011 | However, "learn" is not meant to be used in isolation. It is a primitive | |
| 2012 | meant to be used together with other Open vSwitch features to accomplish a | |
| 2013 | task. Its existing features are enough to accomplish most tasks. | |
| 2014 | ||
| 2015 | Here is an outline of a typical pipeline structure that allows for | |
| 2016 | versatile behavior using "learn": | |
| 2017 | ||
| 2018 | - Flows in table A contain a "learn" action, that populates flows in table | |
| 2019 | L, that use a "load" action to populate register R with information about | |
| 2020 | what was learned. | |
| 2021 | ||
| 2022 | - Flows in table B contain two sequential resubmit actions: one to table L | |
| 2023 | and another one to table B+1. | |
| 2024 | ||
| 2025 | - Flows in table B+1 match on register R and act differently depending on | |
| 2026 | what the flows in table L loaded into it. | |
| 2027 | ||
| 2028 | This approach can be used to implement many "learn"-based features. For | |
| 2029 | example: | |
| 2030 | ||
| 2031 | - Resubmit to a table selected based on learned information, e.g. see: | |
| 2032 | http://openvswitch.org/pipermail/discuss/2016-June/021694.html | |
| 2033 | ||
| 2034 | - MAC learning in the middle of a pipeline, as described in `the tutorial | |
| c27b7536 | 2035 | <tutorial/tutorial.rst>`__. |
| edde4861 SF |
2036 | |
| 2037 | - TCP state based firewalling, by learning outgoing connections based on | |
| 2038 | SYN packets and matching them up with incoming packets. | |
| 2039 | ||
| 2040 | - At least some of the features described in T. A. Hoff, "Extending Open | |
| 2041 | vSwitch to Facilitate Creation of Stateful SDN Applications". | |
| 2042 | ||
| 2043 | Development | |
| 2044 | ----------- | |
| 2045 | ||
| 2046 | Q: How do I implement a new OpenFlow message? | |
| 2047 | ||
| 2048 | A: Add your new message to ``enum ofpraw`` and ``enum ofptype`` in | |
| 2049 | ``lib/ofp-msgs.h``, following the existing pattern. Then recompile and fix | |
| 2050 | all of the new warnings, implementing new functionality for the new message | |
| 2051 | as needed. (If you configure with ``--enable-Werror``, as described in the | |
| 795752a3 | 2052 | `general installation guide`_, then it is impossible to miss any warnings.) |
| edde4861 SF |
2053 | |
| 2054 | If you need to add an OpenFlow vendor extension message for a vendor that | |
| 2055 | doesn't yet have any extension messages, then you will also need to edit | |
| 2056 | ``build-aux/extract-ofp-msgs``. | |
| 2057 | ||
| 2058 | Q: How do I add support for a new field or header? | |
| 2059 | ||
| 2060 | A: Add new members for your field to ``struct flow`` in ``lib/flow.h``, and | |
| 2061 | add new enumerations for your new field to ``enum mf_field_id`` in | |
| 2062 | ``lib/meta-flow.h``, following the existing pattern. Also, add support to | |
| 2063 | ``miniflow_extract()`` in ``lib/flow.c`` for extracting your new field from | |
| 2064 | a packet into struct miniflow, and to ``nx_put_raw()`` in | |
| 2065 | ``lib/nx-match.c`` to output your new field in OXM matches. Then recompile | |
| 2066 | and fix all of the new warnings, implementing new functionality for the new | |
| 2067 | field or header as needed. (If you configure with ``--enable-Werror``, as | |
| 795752a3 SF |
2068 | described in the `general installation guide`_, then it is impossible to |
| 2069 | miss any warnings.) | |
| edde4861 SF |
2070 | |
| 2071 | If you want kernel datapath support for your new field, you also need to | |
| 2072 | modify the kernel module for the operating systems you are interested in. | |
| 2073 | This isn't mandatory, since fields understood only by userspace work too | |
| 2074 | (with a performance penalty), so it's reasonable to start development | |
| 2075 | without it. If you implement kernel module support for Linux, then the | |
| 2076 | Linux kernel "netdev" mailing list is the place to submit that support | |
| 2077 | first; please read up on the Linux kernel development process separately. | |
| 2078 | The Windows datapath kernel module support, on the other hand, is | |
| 2079 | maintained within the OVS tree, so patches for that can go directly to | |
| 2080 | ovs-dev. | |
| 2081 | ||
| 2082 | Q: How do I add support for a new OpenFlow action? | |
| 2083 | ||
| 2084 | A: Add your new action to ``enum ofp_raw_action_type`` in | |
| 2085 | ``lib/ofp-actions.c``, following the existing pattern. Then recompile and | |
| 2086 | fix all of the new warnings, implementing new functionality for the new | |
| 2087 | action as needed. (If you configure with ``--enable-Werror``, as described | |
| 795752a3 SF |
2088 | in the `general installation guide`_, then it is impossible to miss any |
| 2089 | warnings.) | |
| edde4861 SF |
2090 | |
| 2091 | If you need to add an OpenFlow vendor extension action for a vendor that | |
| 2092 | doesn't yet have any extension actions, then you will also need to edit | |
| 2093 | ``build-aux/extract-ofp-actions``. | |
| 795752a3 SF |
2094 | |
| 2095 | .. _general installation guide: Documentation/intro/install/general.rst | |
| 2096 | .. _DPDK installation guide: Documentation/intro/install/dpdk.rst |