+### Q: I want to add thousands of ports to an Open vSwitch bridge, but
+ it takes too long (minutes or hours) to do it with ovs-vsctl. How
+ can I do it faster?
+
+A: If you add them one at a time with ovs-vsctl, it can take a long
+ time to add thousands of ports to an Open vSwitch bridge. This is
+ because every invocation of ovs-vsctl first reads the current
+ configuration from OVSDB. As the number of ports grows, this
+ starts to take an appreciable amount of time, and when it is
+ repeated thousands of times the total time becomes significant.
+
+ The solution is to add the ports in one invocation of ovs-vsctl (or
+ a small number of them). For example, using bash:
+
+ ovs-vsctl add-br br0
+ cmds=; for i in {1..5000}; do cmds+=" -- add-port br0 p$i"; done
+ ovs-vsctl $cmds
+
+ takes seconds, not minutes or hours, in the OVS sandbox environment.
+
+### Q: I created a bridge named br0. My bridge shows up in "ovs-vsctl
+ show", but "ovs-ofctl show br0" just prints "br0 is not a bridge
+ or a socket".
+
+A: Open vSwitch wasn't able to create the bridge. Check the
+ ovs-vswitchd log for details (Debian and Red Hat packaging for Open
+ vSwitch put it in /var/log/openvswitch/ovs-vswitchd.log).
+
+ In general, the Open vSwitch database reflects the desired
+ configuration state. ovs-vswitchd monitors the database and, when
+ it changes, reconfigures the system to reflect the new desired
+ state. This normally happens very quickly. Thus, a discrepancy
+ between the database and the actual state indicates that
+ ovs-vswitchd could not implement the configuration, and so one
+ should check the log to find out why. (Another possible cause is
+ that ovs-vswitchd is not running. This will make "ovs-vsctl"
+ commands hang, if they change the configuration, unless one
+ specifies "--no-wait".)
+
+### Q: I have a bridge br0. I added a new port vif1.0, and it shows
+ up in "ovs-vsctl show", but "ovs-vsctl list port" says that it has
+ OpenFlow port ("ofport") -1, and "ovs-ofctl show br0" doesn't show
+ vif1.0 at all.
+
+A: Open vSwitch wasn't able to create the port. Check the
+ ovs-vswitchd log for details (Debian and Red Hat packaging for Open
+ vSwitch put it in /var/log/openvswitch/ovs-vswitchd.log). Please
+ see the previous question for more information.
+
+ You may want to upgrade to Open vSwitch 2.3 (or later), in which
+ ovs-vsctl will immediately report when there is an issue creating a
+ port.
+
+### Q: I created a tap device tap0, configured an IP address on it, and
+ added it to a bridge, like this:
+
+ tunctl -t tap0
+ ifconfig tap0 192.168.0.123
+ ovs-vsctl add-br br0
+ ovs-vsctl add-port br0 tap0
+
+ I expected that I could then use this IP address to contact other
+ hosts on the network, but it doesn't work. Why not?
+
+A: The short answer is that this is a misuse of a "tap" device. Use
+ an "internal" device implemented by Open vSwitch, which works
+ differently and is designed for this use. To solve this problem
+ with an internal device, instead run:
+
+ ovs-vsctl add-br br0
+ ovs-vsctl add-port br0 int0 -- set Interface int0 type=internal
+ ifconfig int0 192.168.0.123
+
+ Even more simply, you can take advantage of the internal port that
+ every bridge has under the name of the bridge:
+
+ ovs-vsctl add-br br0
+ ifconfig br0 192.168.0.123
+
+ In more detail, a "tap" device is an interface between the Linux
+ (or *BSD) network stack and a user program that opens it as a
+ socket. When the "tap" device transmits a packet, it appears in
+ the socket opened by the userspace program. Conversely, when the
+ userspace program writes to the "tap" socket, the kernel TCP/IP
+ stack processes the packet as if it had been received by the "tap"
+ device.
+
+ Consider the configuration above. Given this configuration, if you
+ "ping" an IP address in the 192.168.0.x subnet, the Linux kernel
+ routing stack will transmit an ARP on the tap0 device. Open
+ vSwitch userspace treats "tap" devices just like any other network
+ device; that is, it doesn't open them as "tap" sockets. That means
+ that the ARP packet will simply get dropped.
+
+ You might wonder why the Open vSwitch kernel module doesn't
+ intercept the ARP packet and bridge it. After all, Open vSwitch
+ intercepts packets on other devices. The answer is that Open
+ vSwitch only intercepts *received* packets, but this is a packet
+ being transmitted. The same thing happens for all other types of
+ network devices, except for Open vSwitch "internal" ports. If you,
+ for example, add a physical Ethernet port to an OVS bridge,
+ configure an IP address on a physical Ethernet port, and then issue
+ a "ping" to an address in that subnet, the same thing happens: an
+ ARP gets transmitted on the physical Ethernet port and Open vSwitch
+ never sees it. (You should not do that, as documented at the
+ beginning of this section.)
+
+ It can make sense to add a "tap" device to an Open vSwitch bridge,
+ if some userspace program (other than Open vSwitch) has opened the
+ tap socket. This is the case, for example, if the "tap" device was
+ created by KVM (or QEMU) to simulate a virtual NIC. In such a
+ case, when OVS bridges a packet to the "tap" device, the kernel
+ forwards that packet to KVM in userspace, which passes it along to
+ the VM, and in the other direction, when the VM sends a packet, KVM
+ writes it to the "tap" socket, which causes OVS to receive it and
+ bridge it to the other OVS ports. Please note that in such a case
+ no IP address is configured on the "tap" device (there is normally
+ an IP address configured in the virtual NIC inside the VM, but this
+ is not visible to the host Linux kernel or to Open vSwitch).
+
+ There is one special case in which Open vSwitch does directly read
+ and write "tap" sockets. This is an implementation detail of the
+ Open vSwitch userspace switch, which implements its "internal"
+ ports as Linux (or *BSD) "tap" sockets. In such a userspace
+ switch, OVS receives packets sent on the "tap" device used to
+ implement an "internal" port by reading the associated "tap"
+ socket, and bridges them to the rest of the switch. In the other
+ direction, OVS transmits packets bridged to the "internal" port by
+ writing them to the "tap" socket, causing them to be processed by
+ the kernel TCP/IP stack as if they had been received on the "tap"
+ device. Users should not need to be concerned with this
+ implementation detail.
+
+ Open vSwitch has a network device type called "tap". This is
+ intended only for implementing "internal" ports in the OVS
+ userspace switch and should not be used otherwise. In particular,
+ users should not configure KVM "tap" devices as type "tap" (use
+ type "system", the default, instead).
+
+