Q: What is Open vSwitch?
A: Open vSwitch is a production quality open source software switch
- designed to be used as a vswitch in virtualized server environments. A
- vswitch forwards traffic between different VMs on the same physical host
- and also forwards traffic between VMs and the physical network. Open
- vSwitch supports standard management interfaces (e.g. sFlow, NetFlow,
- RSPAN, CLI), and is open to programmatic extension and control using
- OpenFlow and the OVSDB management protocol.
+ designed to be used as a vswitch in virtualized server
+ environments. A vswitch forwards traffic between different VMs on
+ the same physical host and also forwards traffic between VMs and
+ the physical network. Open vSwitch supports standard management
+ interfaces (e.g. sFlow, NetFlow, IPFIX, RSPAN, CLI), and is open to
+ programmatic extension and control using OpenFlow and the OVSDB
+ management protocol.
Open vSwitch as designed to be compatible with modern switching
chipsets. This means that it can be ported to existing high-fanout
http://openvswitch.org/mlists/
-
Releases
--------
LTS release, we will provide an updated release that includes the
fix. Releases that are not LTS may not be fixed and may just be
supplanted by the next major release. The current LTS release is
- 1.4.x.
+ 1.9.x.
Q: What Linux kernel versions does each Open vSwitch release work with?
It should build against almost any kernel, certainly against 2.6.18
and later.
+Q: What Linux kernel versions does IPFIX flow monitoring work with?
+
+A: IPFIX flow monitoring requires the Linux kernel module from Open
+ vSwitch version 1.10.90 or later.
+
Q: Should userspace or kernel be upgraded first to minimize downtime?
In general, the Open vSwitch userspace should be used with the
A: The kernel module in upstream Linux 3.3 and later does not include
tunnel virtual ports, that is, interfaces with type "gre",
- "ipsec_gre", "gre64", "ipsec_gre64", "vxlan", or "capwap". It is
+ "ipsec_gre", "gre64", "ipsec_gre64", "vxlan", or "lisp". It is
possible to create tunnels in Linux and attach them to Open vSwitch
as system devices. However, they cannot be dynamically created
through the OVSDB protocol or set the tunnel ids as a flow action.
alternative, Open vSwitch supports mirroring to a GRE tunnel (see
above).
+Q: How do I connect two bridges?
+
+A: First, why do you want to do this? Two connected bridges are not
+ much different from a single bridge, so you might as well just have
+ a single bridge with all your ports on it.
+
+ If you still want to connect two bridges, you can use a pair of
+ patch ports. The following example creates bridges br0 and br1,
+ adds eth0 and tap0 to br0, adds tap1 to br1, and then connects br0
+ and br1 with a pair of patch ports.
+
+ ovs-vsctl add-br br0
+ ovs-vsctl add-port br0 eth0
+ ovs-vsctl add-port br0 tap0
+ ovs-vsctl add-br br1
+ ovs-vsctl add-port br1 tap1
+ ovs-vsctl \
+ -- add-port br0 patch0 \
+ -- set interface patch0 type=patch options:peer=patch1 \
+ -- add-port br1 patch1 \
+ -- set interface patch1 type=patch options:peer=patch0
+
+ Bridges connected with patch ports are much like a single bridge.
+ For instance, if the example above also added eth1 to br1, and both
+ eth0 and eth1 happened to be connected to the same next-hop switch,
+ then you could loop your network just as you would if you added
+ eth0 and eth1 to the same bridge (see the "Configuration Problems"
+ section below for more information).
+
+ If you are using Open vSwitch 1.9 or an earlier version, then you
+ need to be using the kernel module bundled with Open vSwitch rather
+ than the one that is integrated into Linux 3.3 and later, because
+ Open vSwitch 1.9 and earlier versions need kernel support for patch
+ ports. This also means that in Open vSwitch 1.9 and earlier, patch
+ ports will not work with the userspace datapath, only with the
+ kernel module.
+
Q: Why are there so many different ways to dump flows?
A: Open vSwitch uses different kinds of flows for different purposes:
ovs-vsctl -- --all destroy QoS -- --all destroy Queue
+ If you do want to keep some QoS or Queue records, or the Open
+ vSwitch you are using is older than version 1.8 (which added the
+ --all option), then you will have to destroy QoS and Queue records
+ individually.
+
Q: I configured Quality of Service (QoS) in my OpenFlow network by
adding records to the QoS and Queue table, but the results aren't
what I expect.
the machines you are trying to access are not on VLAN 9 (or 10) and
that the Internet is not available on VLAN 9 (or 10).
+Q: I added a pair of VMs on the same VLAN, like this:
+
+ ovs-vsctl add-br br0
+ ovs-vsctl add-port br0 eth0
+ ovs-vsctl add-port br0 tap0 tag=9
+ ovs-vsctl add-port br0 tap1 tag=9
+
+ The VMs can access each other, but not the external network or the
+ Internet.
+
+A: It seems likely that the machines you are trying to access in the
+ external network are not on VLAN 9 and that the Internet is not
+ available on VLAN 9. Also, ensure VLAN 9 is set up as an allowed
+ trunk VLAN on the upstream switch port to which eth0 is connected.
+
Q: Can I configure an IP address on a VLAN?
A: Yes. Use an "internal port" configured as an access port. For
can refer to the answer there for more information.
-Controllers
------------
+VXLANs
+-----
+
+Q: What's a VXLAN?
+
+A: VXLAN stands for Virtual eXtensible Local Area Network, and is a means
+ to solve the scaling challenges of VLAN networks in a multi-tenant
+ environment. VXLAN is an overlay network which transports an L2 network
+ over an existing L3 network. For more information on VXLAN, please see
+ the IETF draft available here:
+
+ http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-03
+
+Q: How much of the VXLAN protocol does Open vSwitch currently support?
+
+A: Open vSwitch currently supports the framing format for packets on the
+ wire. There is currently no support for the multicast aspects of VXLAN.
+ To get around the lack of multicast support, it is possible to
+ pre-provision MAC to IP address mappings either manually or from a
+ controller.
+
+Q: What destination UDP port does the VXLAN implementation in Open vSwitch
+ use?
+
+A: By default, Open vSwitch will use the assigned IANA port for VXLAN, which
+ is 4789. However, it is possible to configure the destination UDP port
+ manually on a per-VXLAN tunnel basis. An example of this configuration is
+ provided below.
+
+ ovs-vsctl add-br br0
+ ovs-vsctl add-port br0 vxlan1 -- set interface vxlan1
+ type=vxlan options:remote_ip=192.168.1.2 options:key=flow
+ options:dst_port=8472
+
+
+Using OpenFlow (Manually or Via Controller)
+-------------------------------------------
Q: What versions of OpenFlow does Open vSwitch support?
for OpenFlow 1.2 and 1.3. On these versions of Open vSwitch, the
following command enables OpenFlow 1.0, 1.2, and 1.3 on bridge br0:
- ovs-vsctl set bridge br0 protocols=openflow10,openflow12,openflow13
+ ovs-vsctl set bridge br0 protocols=OpenFlow10,OpenFlow12,OpenFlow13
+
+ Use the -O option to enable support for later versions of OpenFlow
+ in ovs-ofctl. For example:
+
+ ovs-ofctl -O OpenFlow13 dump-flows br0
Support for OpenFlow 1.1 is incomplete enough that it cannot yet be
enabled, even experimentally.
problem. If not, then follow the ARP reply back to the origin, in
reverse.
+Q: How do I make a flow drop packets?
+
+A: An empty set of actions causes a packet to be dropped. You can
+ specify an empty set of actions with "actions=" on the ovs-ofctl
+ command line. For example:
+
+ ovs-ofctl add-flow br0 priority=65535,actions=
+
+ would cause every packet entering switch br0 to be dropped.
+
+ You can write "drop" explicitly if you like. The effect is the
+ same. Thus, the following command also causes every packet
+ entering switch br0 to be dropped:
+
+ ovs-ofctl add-flow br0 priority=65535,actions=drop
+
+
Contact
-------
git://git.onelab.eu / sliver-openvswitch.git / blobdiff