xenserver: use ovs-vsctl for VIF VLANs instead of separate state files

[openvswitch] / vswitchd / ovs-vswitchd.conf.5.in

diff --git a/vswitchd/ovs-vswitchd.conf.5.in b/vswitchd/ovs-vswitchd.conf.5.in
index 0dbf94dc267b1330c9ab96647587ef3de13b6748..e7a1739711da8d84db41b5dd2e517f5ed4f51841 100644 (file)
--- a/vswitchd/ovs-vswitchd.conf.5.in
+++ b/vswitchd/ovs-vswitchd.conf.5.in
@@ -266,6 +266,22 @@ a trunk port, the frame's VLAN tag will be set to \fIvid\fR, replacing
 any existing tag; when it is sent out an implicit VLAN port, the frame
 will not be tagged.  This type of mirroring may be referred to as
 RSPAN.
 any existing tag; when it is sent out an implicit VLAN port, the frame
 will not be tagged.  This type of mirroring may be referred to as
 RSPAN.

+.IP
+Please note that mirroring to a VLAN can disrupt a network that
+contains unmanaged switches.  Consider an unmanaged physical switch
+with two ports: port 1, connected to an end host, and port 2,
+connected to an Open vSwitch configured to mirror received packets
+into VLAN 123 on port 2.  Suppose that the end host sends a packet on
+port 1 that the physical switch forwards to port 2.  The Open vSwitch
+forwards this packet to its destination and then reflects it back on
+port 2 in VLAN 123.  This reflected packet causes the unmanaged
+physical switch to replace the MAC learning table entry, which
+correctly pointed to port 1, with one that incorrectly points to port
+2.  Afterward, the physical switch will direct packets destined for
+the end host to the Open vSwitch on port 2, instead of to the end host
+on port 1, disrupting connectivity.  If mirroring to a VLAN is desired
+in this scenario, then the physical switch must be replaced by one
+that learns Ethernet addresses on a per-VLAN basis.

 .ST "Example"
 The following \fBovs\-vswitchd\fR configuration copies all frames received
 on \fBeth1\fR or \fBeth2\fR to \fBeth3\fR.
 .ST "Example"
 The following \fBovs\-vswitchd\fR configuration copies all frames received
 on \fBeth1\fR or \fBeth2\fR to \fBeth3\fR.


@@ -507,7 +523,8 @@ the connection to the controller stays down long enough, no packets
 can pass through the switch at all.
 .IP
 The first of these that is set takes effect.
 can pass through the switch at all.
 .IP
 The first of these that is set takes effect.

-If the value is \fBstandalone\fR, \fBovs\-vswitchd\fR will take over
+If the value is \fBstandalone\fR, or if neither of these settings
+is set, \fBovs\-vswitchd\fR will take over

 responsibility for setting up
 flows when no message has been received from the controller for three
 times the inactivity probe interval (see above).  In this mode,
 responsibility for setting up
 flows when no message has been received from the controller for three
 times the inactivity probe interval (see above).  In this mode,


@@ -516,9 +533,8 @@ MAC-learning switch.  \fBovs\-vswitchd\fR will continue to retry connecting
 to the controller in the background and, when the connection succeeds,
 it discontinues its standalone behavior.
 .IP
 to the controller in the background and, when the connection succeeds,
 it discontinues its standalone behavior.
 .IP

-If this option is set to \fBsecure\fR, or if neither of these settings
-is set, \fBovs\-vswitchd\fR will not set up flows on its own when the
-controller connection fails.
+If this option is set to \fBsecure\fR, \fBovs\-vswitchd\fR will not
+set up flows on its own when the controller connection fails.

 .IP "\fBbridge.\fIname\fB.controller.max-backoff=\fIsecs\fR"
 Sets the maximum time between attempts to connect to the controller to
 \fIsecs\fR, which must be at least 1.  The actual interval between
 .IP "\fBbridge.\fIname\fB.controller.max-backoff=\fIsecs\fR"
 Sets the maximum time between attempts to connect to the controller to
 \fIsecs\fR, which must be at least 1.  The actual interval between


@@ -530,6 +546,19 @@ These settings configure how the switch applies a ``token
 bucket'' to limit the rate at which packets in unknown flows are
 forwarded to the OpenFlow controller for flow-setup processing.  This
 feature prevents a single bridge from overwhelming a controller.
 bucket'' to limit the rate at which packets in unknown flows are
 forwarded to the OpenFlow controller for flow-setup processing.  This
 feature prevents a single bridge from overwhelming a controller.

+.PP
+In addition, when a high rate triggers rate-limiting,
+\fBovs\-vswitchd\fR queues controller packets for each port and
+transmits them to the controller at the configured rate.  The number
+of queued packets is limited by a ``burst size'' parameter.  The
+packet queue is shared fairly among the ports on a bridge.
+.PP
+\fBovs\-vswitchd\fR maintains two such packet rate-limiters per
+bridge.  One of these applies to packets sent up to the controller
+because they do not correspond to any flow.  The other applies to
+packets sent up to the controller by request through flow actions.
+When both rate-limiters are filled with packets, the actual rate that
+packets are sent to the controller is up to twice the specified rate.

 .IP "\fBbridge.\fIname\fB.controller.rate-limit=\fIrate\fR"
 .IQ "\fBmgmt.rate-limit=\fIrate\fR"
 Limits the maximum rate at which packets will be forwarded to the
 .IP "\fBbridge.\fIname\fB.controller.rate-limit=\fIrate\fR"
 .IQ "\fBmgmt.rate-limit=\fIrate\fR"
 Limits the maximum rate at which packets will be forwarded to the