9
9
Q: What is Open vSwitch?
11
11
A: Open vSwitch is a production quality open source software switch
12
designed to be used as a vswitch in virtualized server environments. A
13
vswitch forwards traffic between different VMs on the same physical host
14
and also forwards traffic between VMs and the physical network. Open
15
vSwitch supports standard management interfaces (e.g. sFlow, NetFlow,
16
RSPAN, CLI), and is open to programmatic extension and control using
17
OpenFlow and the OVSDB management protocol.
12
designed to be used as a vswitch in virtualized server
13
environments. A vswitch forwards traffic between different VMs on
14
the same physical host and also forwards traffic between VMs and
15
the physical network. Open vSwitch supports standard management
16
interfaces (e.g. sFlow, NetFlow, IPFIX, RSPAN, CLI), and is open to
17
programmatic extension and control using OpenFlow and the OVSDB
19
20
Open vSwitch as designed to be compatible with modern switching
20
21
chipsets. This means that it can be ported to existing high-fanout
321
328
alternative, Open vSwitch supports mirroring to a GRE tunnel (see
331
Q: How do I connect two bridges?
333
A: First, why do you want to do this? Two connected bridges are not
334
much different from a single bridge, so you might as well just have
335
a single bridge with all your ports on it.
337
If you still want to connect two bridges, you can use a pair of
338
patch ports. The following example creates bridges br0 and br1,
339
adds eth0 and tap0 to br0, adds tap1 to br1, and then connects br0
340
and br1 with a pair of patch ports.
343
ovs-vsctl add-port br0 eth0
344
ovs-vsctl add-port br0 tap0
346
ovs-vsctl add-port br1 tap1
348
-- add-port br0 patch0 \
349
-- set interface patch0 type=patch options:peer=patch1 \
350
-- add-port br1 patch1 \
351
-- set interface patch1 type=patch options:peer=patch0
353
Bridges connected with patch ports are much like a single bridge.
354
For instance, if the example above also added eth1 to br1, and both
355
eth0 and eth1 happened to be connected to the same next-hop switch,
356
then you could loop your network just as you would if you added
357
eth0 and eth1 to the same bridge (see the "Configuration Problems"
358
section below for more information).
360
If you are using Open vSwitch 1.9 or an earlier version, then you
361
need to be using the kernel module bundled with Open vSwitch rather
362
than the one that is integrated into Linux 3.3 and later, because
363
Open vSwitch 1.9 and earlier versions need kernel support for patch
364
ports. This also means that in Open vSwitch 1.9 and earlier, patch
365
ports will not work with the userspace datapath, only with the
324
368
Q: Why are there so many different ways to dump flows?
326
370
A: Open vSwitch uses different kinds of flows for different purposes:
770
819
the machines you are trying to access are not on VLAN 9 (or 10) and
771
820
that the Internet is not available on VLAN 9 (or 10).
822
Q: I added a pair of VMs on the same VLAN, like this:
825
ovs-vsctl add-port br0 eth0
826
ovs-vsctl add-port br0 tap0 tag=9
827
ovs-vsctl add-port br0 tap1 tag=9
829
The VMs can access each other, but not the external network or the
832
A: It seems likely that the machines you are trying to access in the
833
external network are not on VLAN 9 and that the Internet is not
834
available on VLAN 9. Also, ensure VLAN 9 is set up as an allowed
835
trunk VLAN on the upstream switch port to which eth0 is connected.
773
837
Q: Can I configure an IP address on a VLAN?
775
839
A: Yes. Use an "internal port" configured as an access port. For
799
863
You can use "normal switching" as a component of your OpenFlow
800
864
actions, e.g. by putting "normal" into the lists of actions on
801
865
ovs-ofctl or by outputting to OFPP_NORMAL from an OpenFlow
802
controller. This will only be suitable for some situations,
866
controller. In situations where this is not suitable, you can
867
implement VLAN handling yourself, e.g.:
869
- If a packet comes in on an access port, and the flow table
870
needs to send it out on a trunk port, then the flow can add
871
the appropriate VLAN tag with the "mod_vlan_vid" action.
873
- If a packet comes in on a trunk port, and the flow table
874
needs to send it out on an access port, then the flow can
875
strip the VLAN tag with the "strip_vlan" action.
805
877
Q: I configured ports on a bridge as access ports with different VLAN
865
937
extensions that bring in many of the features from later versions
868
Open vSwitch versions 1.10 and later will have experimental support
869
for OpenFlow 1.2 and 1.3. On these versions of Open vSwitch, the
870
following command enables OpenFlow 1.0, 1.2, and 1.3 on bridge br0:
872
ovs-vsctl set bridge br0 protocols=openflow10,openflow12,openflow13
874
Support for OpenFlow 1.1 is incomplete enough that it cannot yet be
875
enabled, even experimentally.
877
Support for OpenFlow 1.2 and 1.3 is still incomplete. Work to be
878
done is tracked in OPENFLOW-1.1+ in the Open vSwitch source tree
940
Open vSwitch 1.10 and later have experimental support for OpenFlow
941
1.2 and 1.3. On these versions of Open vSwitch, the following
942
command enables OpenFlow 1.0, 1.2, and 1.3 on bridge br0:
944
ovs-vsctl set bridge br0 protocols=OpenFlow10,OpenFlow12,OpenFlow13
946
Open vSwitch version 1.12 and later will have experimental support
947
for OpenFlow 1.1, 1.2, and 1.3. On these versions of Open vSwitch,
948
the following command enables OpenFlow 1.0, 1.1, 1.2, and 1.3 on
951
ovs-vsctl set bridge br0 protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13
953
Use the -O option to enable support for later versions of OpenFlow
954
in ovs-ofctl. For example:
956
ovs-ofctl -O OpenFlow13 dump-flows br0
958
Support for OpenFlow 1.1, 1.2, and 1.3 is still incomplete. Work
959
to be done is tracked in OPENFLOW-1.1+ in the Open vSwitch sources
879
960
(also via http://openvswitch.org/development/openflow-1-x-plan/).
880
961
When support for a given OpenFlow version is solidly implemented,
881
962
Open vSwitch will enable that version by default.
1039
1117
implementation of such a feature, please bring it up on the Open
1040
1118
vSwitch development mailing list at dev@openvswitch.org.
1120
Q: I have a sophisticated network setup involving Open vSwitch, VMs or
1121
multiple hosts, and other components. The behavior isn't what I
1124
A: To debug network behavior problems, trace the path of a packet,
1125
hop-by-hop, from its origin in one host to a remote host. If
1126
that's correct, then trace the path of the response packet back to
1129
Usually a simple ICMP echo request and reply ("ping") packet is
1130
good enough. Start by initiating an ongoing "ping" from the origin
1131
host to a remote host. If you are tracking down a connectivity
1132
problem, the "ping" will not display any successful output, but
1133
packets are still being sent. (In this case the packets being sent
1134
are likely ARP rather than ICMP.)
1136
Tools available for tracing include the following:
1138
- "tcpdump" and "wireshark" for observing hops across network
1139
devices, such as Open vSwitch internal devices and physical
1142
- "ovs-appctl dpif/dump-flows <br>" in Open vSwitch 1.10 and
1143
later or "ovs-dpctl dump-flows <br>" in earlier versions.
1144
These tools allow one to observe the actions being taken on
1145
packets in ongoing flows.
1147
See ovs-vswitchd(8) for "ovs-appctl dpif/dump-flows"
1148
documentation, ovs-dpctl(8) for "ovs-dpctl dump-flows"
1149
documentation, and "Why are there so many different ways to
1150
dump flows?" above for some background.
1152
- "ovs-appctl ofproto/trace" to observe the logic behind how
1153
ovs-vswitchd treats packets. See ovs-vswitchd(8) for
1154
documentation. You can out more details about a given flow
1155
that "ovs-dpctl dump-flows" displays, by cutting and pasting
1156
a flow from the output into an "ovs-appctl ofproto/trace"
1159
- SPAN, RSPAN, and ERSPAN features of physical switches, to
1160
observe what goes on at these physical hops.
1162
Starting at the origin of a given packet, observe the packet at
1163
each hop in turn. For example, in one plausible scenario, you
1166
1. "tcpdump" the "eth" interface through which an ARP egresses
1167
a VM, from inside the VM.
1169
2. "tcpdump" the "vif" or "tap" interface through which the ARP
1170
ingresses the host machine.
1172
3. Use "ovs-dpctl dump-flows" to spot the ARP flow and observe
1173
the host interface through which the ARP egresses the
1174
physical machine. You may need to use "ovs-dpctl show" to
1175
interpret the port numbers. If the output seems surprising,
1176
you can use "ovs-appctl ofproto/trace" to observe details of
1177
how ovs-vswitchd determined the actions in the "ovs-dpctl
1180
4. "tcpdump" the "eth" interface through which the ARP egresses
1181
the physical machine.
1183
5. "tcpdump" the "eth" interface through which the ARP
1184
ingresses the physical machine, at the remote host that
1187
6. Use "ovs-dpctl dump-flows" to spot the ARP flow on the
1188
remote host that receives the ARP and observe the VM "vif"
1189
or "tap" interface to which the flow is directed. Again,
1190
"ovs-dpctl show" and "ovs-appctl ofproto/trace" might help.
1192
7. "tcpdump" the "vif" or "tap" interface to which the ARP is
1195
8. "tcpdump" the "eth" interface through which the ARP
1196
ingresses a VM, from inside the VM.
1198
It is likely that during one of these steps you will figure out the
1199
problem. If not, then follow the ARP reply back to the origin, in
1202
Q: How do I make a flow drop packets?
1204
A: An empty set of actions causes a packet to be dropped. You can
1205
specify an empty set of actions with "actions=" on the ovs-ofctl
1206
command line. For example:
1208
ovs-ofctl add-flow br0 priority=65535,actions=
1210
would cause every packet entering switch br0 to be dropped.
1212
You can write "drop" explicitly if you like. The effect is the
1213
same. Thus, the following command also causes every packet
1214
entering switch br0 to be dropped:
1216
ovs-ofctl add-flow br0 priority=65535,actions=drop
added
removed
FAQ
