+ These columns are mutually exclusive. Exactly one of them must be
+ nonempty.
+
+
- Output port for selected packets, if nonempty. Mutually exclusive
- with .
+ Output port for selected packets, if nonempty.
Specifying a port for mirror output reserves that port exclusively
for mirroring. No frames other than those selected for mirroring
will be forwarded to the port, and any frames received on the port
@@ -1119,8 +1663,7 @@
- Output VLAN for selected packets, if nonempty. Mutually exclusive
- with .
+ Output VLAN for selected packets, if nonempty.
The frames will be sent out all ports that trunk
, as well as any ports with implicit VLAN
. When a mirrored frame is sent out a
@@ -1128,6 +1671,37 @@
, replacing any existing tag; when it is
sent out an implicit VLAN port, the frame will not be tagged. This
type of mirroring is sometimes called RSPAN.
+
+ The following destination MAC addresses will not be mirrored to a
+ VLAN to avoid confusing switches that interpret the protocols that
+ they represent:
+
+
+ 01:80:c2:00:00:00
+ - IEEE 802.1D Spanning Tree Protocol (STP).
+
+ 01:80:c2:00:00:01
+ - IEEE Pause frame.
+
+ 01:80:c2:00:00:0x
+ - Other reserved protocols.
+
+ 01:00:0c:cc:cc:cc
+ -
+ Cisco Discovery Protocol (CDP), VLAN Trunking Protocol (VTP),
+ Dynamic Trunking Protocol (DTP), Port Aggregation Protocol (PAgP),
+ and others.
+
+
+ 01:00:0c:cc:cc:cd
+ - Cisco Shared Spanning Tree Protocol PVSTP+.
+
+ 01:00:0c:cd:cd:cd
+ - Cisco STP Uplink Fast.
+
+ 01:00:0c:00:00:00
+ - Cisco Inter Switch Link.
+
Please note: 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,
@@ -1173,7 +1747,7 @@
Open vSwitch supports two kinds of OpenFlow controllers:
-
+
- Primary controllers
-
@@ -1251,23 +1825,6 @@
- The specified TCP port (default: 6633) on the host at
the given ip, which must be expressed as an IP address
(not a DNS name).
- discover
- -
-
Enables controller discovery.
- In controller discovery mode, Open vSwitch broadcasts a DHCP
- request with vendor class identifier OpenFlow
across
- all of the bridge's network devices. It will accept any valid
- DHCP reply that has the same vendor class identifier and includes
- a vendor-specific option with code 1 whose contents are a string
- specifying the location of the controller in the same format as
- .
- The DHCP reply may also, optionally, include a vendor-specific
- option with code 2 whose contents are a string specifying the URI
- to the base of the OpenFlow PKI
- (e.g. http://192.168.0.1/openflow/pki
). This URI is
- used only for bootstrapping the OpenFlow PKI at initial switch
- setup; ovs-vswitchd
does not use it at all.
-
The following connection methods are currently supported for service
@@ -1298,39 +1855,36 @@
restricted to the specified local IP address.
-
When multiple controllers are configured for a single bridge, the
- values must be unique. Duplicate
- values yield unspecified results.
+ When multiple controllers are configured for a single bridge, the
+ values must be unique. Duplicate
+ values yield unspecified results.
- If it is specified, this setting must be one of the following
- strings that describes how Open vSwitch contacts this OpenFlow
- controller over the network:
-
-
- in-band
- - In this mode, this controller's OpenFlow traffic travels over the
- bridge associated with the controller. With this setting, Open
- vSwitch allows traffic to and from the controller regardless of the
- contents of the OpenFlow flow table. (Otherwise, Open vSwitch
- would never be able to connect to the controller, because it did
- not have a flow to enable it.) This is the most common connection
- mode because it is not necessary to maintain two independent
- networks.
- out-of-band
- - In this mode, OpenFlow traffic uses a control network separate
- from the bridge associated with this controller, that is, the
- bridge does not use any of its own network devices to communicate
- with the controller. The control network must be configured
- separately, before or after
ovs-vswitchd
is started.
-
-
+ If it is specified, this setting must be one of the following
+ strings that describes how Open vSwitch contacts this OpenFlow
+ controller over the network:
- If not specified, the default is implementation-specific. If
- is discover
, the connection mode
- is always treated as in-band
regardless of the actual
- setting.
+
+ in-band
+ - In this mode, this controller's OpenFlow traffic travels over the
+ bridge associated with the controller. With this setting, Open
+ vSwitch allows traffic to and from the controller regardless of the
+ contents of the OpenFlow flow table. (Otherwise, Open vSwitch
+ would never be able to connect to the controller, because it did
+ not have a flow to enable it.) This is the most common connection
+ mode because it is not necessary to maintain two independent
+ networks.
+ out-of-band
+ - In this mode, OpenFlow traffic uses a control network separate
+ from the bridge associated with this controller, that is, the
+ bridge does not use any of its own network devices to communicate
+ with the controller. The control network must be configured
+ separately, before or after
ovs-vswitchd
is started.
+
+
+
+ If not specified, the default is implementation-specific.