http://openvswitch.org/mlists/
-
Releases
--------
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.
- "ovs-dpctl dump-flows [dp]" dumps the exact-match flow table
entries for a Linux kernel-based datapath. In Open vSwitch
- 1.10 and later, ovs-vswitchd later merges multiple switches
- into a single datapath, so it will show all the flows on all
- your kernel-based switches. This command can occasionally be
+ 1.10 and later, ovs-vswitchd merges multiple switches into a
+ single datapath, so it will show all the flows on all your
+ kernel-based switches. This command can occasionally be
useful for debugging.
- "ovs-appctl dpif/dump-flows <br>", new in Open vSwitch 1.10,
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.
You can use "normal switching" as a component of your OpenFlow
actions, e.g. by putting "normal" into the lists of actions on
ovs-ofctl or by outputting to OFPP_NORMAL from an OpenFlow
- controller. This will only be suitable for some situations,
- though.
+ controller. In situations where this is not suitable, you can
+ implement VLAN handling yourself, e.g.:
+
+ - If a packet comes in on an access port, and the flow table
+ needs to send it out on a trunk port, then the flow can add
+ the appropriate VLAN tag with the "mod_vlan_vid" action.
+
+ - If a packet comes in on a trunk port, and the flow table
+ needs to send it out on an access port, then the flow can
+ strip the VLAN tag with the "strip_vlan" action.
Q: I configured ports on a bridge as access ports with different VLAN
tags, like this:
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
Support for OpenFlow 1.1 is incomplete enough that it cannot yet be
enabled, even experimentally.
controller is not configured, this happens implicitly to
every packet.)
- - The "autopath" Nicira extension action. However, "autopath"
- is deprecated and scheduled for removal in February 2013.
-
- Mirrors configured for output to a bonded port.
It would make a lot of sense for Open vSwitch to present a bond as
implementation of such a feature, please bring it up on the Open
vSwitch development mailing list at dev@openvswitch.org.
+Q: I have a sophisticated network setup involving Open vSwitch, VMs or
+ multiple hosts, and other components. The behavior isn't what I
+ expect. Help!
+
+A: To debug network behavior problems, trace the path of a packet,
+ hop-by-hop, from its origin in one host to a remote host. If
+ that's correct, then trace the path of the response packet back to
+ the origin.
+
+ Usually a simple ICMP echo request and reply ("ping") packet is
+ good enough. Start by initiating an ongoing "ping" from the origin
+ host to a remote host. If you are tracking down a connectivity
+ problem, the "ping" will not display any successful output, but
+ packets are still being sent. (In this case the packets being sent
+ are likely ARP rather than ICMP.)
+
+ Tools available for tracing include the following:
+
+ - "tcpdump" and "wireshark" for observing hops across network
+ devices, such as Open vSwitch internal devices and physical
+ wires.
+
+ - "ovs-appctl dpif/dump-flows <br>" in Open vSwitch 1.10 and
+ later or "ovs-dpctl dump-flows <br>" in earlier versions.
+ These tools allow one to observe the actions being taken on
+ packets in ongoing flows.
+
+ See ovs-vswitchd(8) for "ovs-appctl dpif/dump-flows"
+ documentation, ovs-dpctl(8) for "ovs-dpctl dump-flows"
+ documentation, and "Why are there so many different ways to
+ dump flows?" above for some background.
+
+ - "ovs-appctl ofproto/trace" to observe the logic behind how
+ ovs-vswitchd treats packets. See ovs-vswitchd(8) for
+ documentation. You can out more details about a given flow
+ that "ovs-dpctl dump-flows" displays, by cutting and pasting
+ a flow from the output into an "ovs-appctl ofproto/trace"
+ command.
+
+ - SPAN, RSPAN, and ERSPAN features of physical switches, to
+ observe what goes on at these physical hops.
+
+ Starting at the origin of a given packet, observe the packet at
+ each hop in turn. For example, in one plausible scenario, you
+ might:
+
+ 1. "tcpdump" the "eth" interface through which an ARP egresses
+ a VM, from inside the VM.
+
+ 2. "tcpdump" the "vif" or "tap" interface through which the ARP
+ ingresses the host machine.
+
+ 3. Use "ovs-dpctl dump-flows" to spot the ARP flow and observe
+ the host interface through which the ARP egresses the
+ physical machine. You may need to use "ovs-dpctl show" to
+ interpret the port numbers. If the output seems surprising,
+ you can use "ovs-appctl ofproto/trace" to observe details of
+ how ovs-vswitchd determined the actions in the "ovs-dpctl
+ dump-flows" output.
+
+ 4. "tcpdump" the "eth" interface through which the ARP egresses
+ the physical machine.
+
+ 5. "tcpdump" the "eth" interface through which the ARP
+ ingresses the physical machine, at the remote host that
+ receives the ARP.
+
+ 6. Use "ovs-dpctl dump-flows" to spot the ARP flow on the
+ remote host that receives the ARP and observe the VM "vif"
+ or "tap" interface to which the flow is directed. Again,
+ "ovs-dpctl show" and "ovs-appctl ofproto/trace" might help.
+
+ 7. "tcpdump" the "vif" or "tap" interface to which the ARP is
+ directed.
+
+ 8. "tcpdump" the "eth" interface through which the ARP
+ ingresses a VM, from inside the VM.
+
+ It is likely that during one of these steps you will figure out the
+ problem. If not, then follow the ARP reply back to the origin, in
+ reverse.
+
Contact
-------
git://git.onelab.eu / sliver-openvswitch.git / blobdiff