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

.\" -*- nroff -*-
.de TQ
.  br
.  ns
.  TP "\\$1"
..
.de IQ
.  br
.  ns
.  IP "\\$1"
..
.de ST
.  PP
.  RS -0.15in
.  I "\\$1"
.  RE
.  PP
..
.TH ovs\-vswitchd.conf 5 "April 2009" "Open vSwitch" "Open vSwitch Manual"
.
.SH NAME
ovs\-vswitchd.conf \- configuration file for \fBovs\-vswitchd\fR
.
.SH DESCRIPTION
This manual page describes the syntax for the configuration file used 
by \fBovs\-vswitchd\fR(8), the virtual switch daemon.
.PP
The configuration file is based on key-value pairs, which are given
one per line in the form \fIkey\fB=\fIvalue\fR.  Each \fIkey\fR
consists of one or more parts separated by dots,
e.g. \fIpart1\fB.\fIpart2\fB.\fIpart3\fR.  Each \fIpart\fR may consist
only of the English letters, digits, and the special characters
\fB_-@$:+\fR.  White space within \fIvalue\fR  and at the beginning of a
line is significant, but is otherwise ignored.
.PP
If a single key is specified more than once, that key has multiple
values, one value for each time the key is specified.  The ordering of
key-value pairs, and the ordering of multiple values for a single key,
within a configuration file is not significant.
.PP
Blank lines, lines that consist only of white space, and lines that
begin with \fB#\fR (optionally preceded by white space) are ignored.
Keep in mind that programs that modify the configuration file, such as 
\fBovs\-brcompatd\fR and \fBovs-cfg-mod\fR, may alter the order of
elements and 
strip comments and blank lines.
.PP
The following subsections describe how key-value pairs are used to
configure \fBovs\-vswitchd\fR.
.SS "Bridge Configuration"
A bridge (switch) with a given \fIname\fR is configured by specifying
the names of its network devices as values for key
\fBbridge.\fIname\fB.port\fR.  (The specified \fIname\fR may not begin
with \fBdp\fR or \fBnl:\fR followed by a digit.)
.PP
The names given on \fBbridge.\fIname\fB.port\fR must be the names of
existing network devices, except for ``internal ports.''  An internal
port is a simulated network device that receives traffic only
through the virtual switch and switches any traffic sent it through
virtual switch.  An internal port may configured with an IP address,
etc. using the usual system tools (e.g. \fBifconfig\fR, \fBip\fR).  To
designate network device \fInetdev\fR as an internal port, add
\fBiface.\fInetdev\fB.internal=true\fR to the configuration file.
\fBovs\-vswitchd\fR will honor this configuration setting by automatically
creating the named internal port.
.PP
A bridge with a given \fIname\fR always has an internal port with the
same \fIname\fR, called the ``local port.''  This network device may
be included
in the bridge, by specifying it as one of the values for key
\fBbridge.\fIname\fB.port\fR, or it may be omitted.  If it is
included, then its MAC address is by default the lowest-numbered MAC
address among the other bridge ports, ignoring other internal ports
and bridge ports that are
used as port mirroring destinations (see \fBPort Mirroring\fR, below).
For this purpose, the MAC of a bonded port (see \fBNetwork Device
Bonding\fR, below) is by default the MAC of its slave whose name is first in
alphabetical order.
There are two ways to modify this algorithm for selecting the MAC
address of the local port:
.IP \(bu
To use a specific MAC address for the local port, set
\fBbridge.\fIname\fB.mac\fR to a MAC address in the format
\fIxx\fB:\fIxx\fB:\fIxx\fB:\fIxx\fB:\fIxx\fB:\fIxx\fR, where each
\fIx\fR is a hex digit.
.IP \(bu
To override the MAC of a port for the purpose of this algorithm, set
\fBport.\fIport\fB.mac\fR to a MAC address in the format described
above.
.PP
If no valid MAC address can be determined
either of these ways, then a MAC address is randomly generated.
.PP
The following syntax defines a bridge named \fBmybr\fR, configured
with network devices \fBeth0\fR, \fBeth1\fR, and \fBeth2\fR:
.RS
.nf

bridge.mybr.port=eth0
bridge.mybr.port=eth1
bridge.mybr.port=eth2

.fi
.RE
.SS "802.1Q VLAN support"
A bridge port may be configured either as a trunk port or as belonging
to a single, untagged VLAN.  These two options are mutually exclusive,
and a port must be configured in one way or the other.
.ST "Trunk Ports"
By default, bridge ports are trunk ports that carry all VLANs.  To
limit the VLANs that a trunk port carries, define
\fBvlan.\fIport\fB.trunks\fR to one or more integers between 0 and
4095 designating VLANs.  Only frames that have an 802.1Q header with
one of the listed VLANs are accepted on a trunk port.  If 0 is
included in the list, then frames without an 802.1Q header are also
accepted.  Other frames are discarded.
.PP
The following syntax makes network device \fBeth0\fR a trunk port that
carries VLANs 1, 2, and 3:
.PP
.RS
.nf

vlan.eth0.trunks=1
vlan.eth0.trunks=2
vlan.eth0.trunks=3
        
.fi
.RE
.ST "Untagged VLAN Ports"
A bridge port may be configured with an implicit, untagged VLAN.  
Define key
\fBvlan.\fIport\fB.tag\fR to an integer value \fIvid\fR between 0 and
4095, inclusive, to designate the named \fIport\fR as a member
of 802.1Q VLAN \fIvid\fR.  When \fIport\fR is assigned a VLAN tag this
way, frames arriving on trunk ports will be forwarded to \fIport\fR
only if they are tagged with VLAN \fIvid\fR, and frames arriving on
other VLAN ports will be forwarded to \fIport\fR only if their
\fIvid\fR values are equal.  Frames forwarded to \fIport\fR will not
have an 802.1Q header.
.PP
When \fIvid\fR is 0, frames arriving on trunk ports without an 802.1Q
VLAN header will also be forwarded to \fIport\fR.
.PP
When a frame with a 802.1Q header that indicates a nonzero VLAN is
received on an implicit VLAN port, it is discarded.
.PP
The following syntax makes network device \fBeth0\fR a member of VLAN
101:
.PP
.RS
.nf

vlan.eth0.tag=101
        
.fi
.RE
.SS "Network Device Bonding"
Bonding allows multiple ``slave'' network devices to be treated as if
they were a single virtual ``bonded'' network device.  It is useful for
load balancing and fail-over.
.PP
\fBovs\-vswitchd\fR supports ``source load balancing'' (SLB) bonding, which
assigns flows to slaves based on source MAC address, with periodic
rebalancing as traffic patterns change.  This form of bonding does not
require 802.3ad or other special support from the upstream switch to
which the slave devices are connected.
.PP
To configure bonding, create a virtual bonding device by specifying
the slave network device names as values for
\fBbonding.\fIname\fB.slave\fR, then specify \fIname\fR as a bridge
port.  The chosen \fIname\fR should not be the name of any real
network device on the host system.
.PP
By default, bonding interfaces are enabled or disabled immediately
when a carrier is detected or dropped on the underlying network
device.  To insert a delay when carrier comes up or goes down before
enabling or disabling an interface, set the value of
\fBbonding.\fIname\fB.updelay\fR or
\fBbonding.\fIname\fB.downdelay\fR, respectively, to a positive
integer, interpreted in milliseconds.
The \fBupdelay\fR setting is honored only when at least one bonded
interface is already enabled.  When no interfaces are enabled, then
the first bond interface to come up is enabled immediately.  The
\fBdowndelay\fR setting is always honored.
.PP
The following syntax bonds \fBeth0\fR and \fBeth1\fR into a bonding
device named \fBbond0\fR, which is added to bridge \fBmybr\fR along
with physical network devices \fBeth2\fR and \fBeth3\fR:
.PP
.RS
.nf

bridge.mybr.port=bond0
bridge.mybr.port=eth2
bridge.mybr.port=eth3

bonding.bond0.slave=eth0
bonding.bond0.slave=eth1
        
.fi
.RE
.SS "Port Mirroring (SPAN and RSPAN)"
\fBovs\-vswitchd\fR may be configured to send selected frames to special
``mirrored'' ports, in addition to their normal destinations.  Mirroring
traffic may also be referred to as SPAN or RSPAN, depending on the
mechanism used for delivery.
.PP
Up to 32 instances of port mirroring may be configured on a given
bridge.  Each must be given a name that is unique within the bridge.
The keys associated with port mirroring instance \fIpmname\fR for
bridge \fIbrname\fR begin with \fBmirror.\fIbrname\fB.\fIpmname\fR.
.PP
The selection of the frames to mirror and the form in which they
should be output is configured separately for each port mirroring
instances, through a subsection of
\fBmirror.\fIbrname\fB.\fIpmname\fR, named \fBselect\fR, and
\fBoutput\fR, respectively.
.ST "Selecting Frames to Mirror"
The values for the following keys, if specified, limit the frames that
are chosen for mirroring.  If none of these keys is specified, then
all frames received by the bridge are mirrored.  If more than one of
these keys is specified, then a frame must meet all specified criteria
to be mirrored.
.TP
\fBmirror.\fIbrname\fB.\fIpmname\fB.select.src-port=\fIport\fR
.TQ
\fBmirror.\fIbrname\fB.\fIpmname\fB.select.dst-port=\fIport\fR
.TQ
\fBmirror.\fIbrname\fB.\fIpmname\fB.select.port=\fIport\fR
Frame received on \fIport\fR, output to \fIport\fR, or either received
on or output to \fIport\fR, respectively.  \fIport\fR must be part of
the bridge \fIbrname\fR; that is, it must be listed on
\fBbridge.\fIbrname\fB.port\fR.
.TP
\fBmirror.\fIbrname\fB.\fIpmname\fB.select.vlan=\fIvid\fR
.
\fIvid\fR must be an integer between 0 and 4095, inclusive.  A nonzero
\fIvid\fR selects frames that belong to VLAN \fIvid\fR, that is,
frames that arrived on a trunk port tagged with VLAN \fIvid\fR or on a
port that is configured as part of VLAN \fIvid\fR (see \fB802.1Q VLAN
tagging\fR, above).  A \fIvid\fR of zero selects frames that do not
belong to a VLAN, that is, frames that arrived on a trunk port without
a VLAN tag or tagged with VLAN 0.
.ST "Mirror Output"
The values of the following keys determine how frames selected for
mirroring are output.  Only one of the keys may be specified.
.TP
\fBmirror.\fIbrname\fB.\fIpmname\fB.output.port=\fIport\fR
.
Causes the selected frames to be sent out \fIport\fR, which must be
part of the bridge \fIbrname\fR; that is, it must be listed on
\fBbridge.\fIbrname\fB.port\fR.
.IP
Specifying a \fIport\fR in this way reserves that port exclusively for
mirroring.  No frames other than those selected for mirroring will be
forwarded to \fIport\fR, and any frames received on \fIport\fR will be
discarded.  This type of mirroring may be referred to as SPAN.
.TP
\fBmirror.\fIbrname\fB.\fIpmname\fB.output.vlan=\fIvid\fR
.
Causes the selected frames to be sent on the VLAN numbered \fIvid\fR,
which must be an integer between 0 and 4095, inclusive.  The frames
will be sent out all ports that trunk VLAN \fIvid\fR, as well as any
ports with implicit VLAN \fIvid\fR.  When a mirrored frame is sent out
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.
.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.  In addition,
learning should be disabled on the VLAN containing mirrored traffic.
If this is not done then the intermediate switch will learn the MAC
address of each end host from the mirrored traffic.  If packets being
sent to that end host are also mirrored, then they will be dropped
since the switch will attempt to send them out the input port.
Disabling learning for the VLAN will cause the switch to correctly
send the packet out all ports configured for that VLAN.
.ST "Example"
The following \fBovs\-vswitchd\fR configuration copies all frames received
on \fBeth1\fR or \fBeth2\fR to \fBeth3\fR.
.PP
.RS
.nf

bridge.mybr.port=eth1
bridge.mybr.port=eth2
bridge.mybr.port=eth3

mirror.mybr.a.select.src-port=eth1
mirror.mybr.a.select.src-port=eth2
mirror.mybr.a.output.port=eth3
        
.fi
.RE
.SS "Port Rate-Limiting"
Traffic policing and shaping are configured on physical ports.  Policing
defines a hard limit at which traffic that exceeds the specified rate is
dropped.  Shaping uses queues to delay packets so that egress traffic
leaves at the specified rate.

.ST "Ingress Policing"
The rate at which traffic is allowed to enter through a port may be 
configured with ingress policing.  Note that "ingress" is from the 
perspective of \fBovs\-vswitchd\fR.  If configured on a physical port, 
then it limits the rate at which traffic is allowed into the system from 
the outside.  If configured on a virtual interface that is connected to 
a virtual machine, then it limits the rate at which the guest is able to 
transmit.

The rate is specified in kilobits (1000 bits) per second with a maximum 
burst size specified in kilobits (1000 bits).  The burst size should be at 
least the size of the interface's MTU.  

A port may be configured to enforce ingress policing by defining the
key \fBport.\fIname\fB.ingress.policing-rate\fR with an integer
indicating the rate.  The port \fIname\fR will only allow traffic to be
received at the rate specified in kilobits per second.  If the rate is zero 
or the key is not defined, then ingress policing is disabled.

If ingress policing is enabled, then the burst rate may be set by defining 
the key \fBport.\fIname\fB.ingress.policing-burst\fR with an integer 
indicating the burst rate in kilobits.  If the key is not supplied or is 
zero, then the default burst is 10 kilobits.

.PP
The following syntax limits port \fBeth1\fR to receiving traffic at
\fB512\fR kilobits per second with a burst of \fB20\fR kilobits:
.PP
.RS
.nf

port.eth1.ingress.policing-rate=512
port.eth1.ingress.policing-burst=20

.fi
.SS "NetFlow v5 Flow Logging"
NetFlow is a protocol that exports a number of details about terminating 
IP flows, such as the principals involved and duration.  A bridge may be 
configured to send NetFlow v5 records to NetFlow collectors when flows 
end.  To enable, define the key \fBnetflow.\fIbridge\fB.host\fR for each 
collector in the form \fIip\fB:\fIport\fR.  Records from \fIbridge\fR 
will be sent to each \fIip\fR on UDP \fIport\fR.  The \fIip\fR must
be specified numerically, not as a DNS name.

The NetFlow messages will use the datapath index for the engine type and id.  
This can be overridden with the \fBnetflow.\fIbridge\fB.engine-type\fR and 
\fBnetflow.\fIbridge\fB.engine-id\fR, respectively.  Each takes a value
between 0 and 255, inclusive. 

Many NetFlow collectors do not expect multiple virtual switches to be
sending messages from the same host, and they do not store the engine
information which could be used to disambiguate the traffic.  To prevent
flows from multiple switches appearing as if they came on the interface,
add \fBnetflow.\fIbridge\fB.add-id-to-iface=true\fR to the configuration
file.  This will place the least significant 7 bits of the engine id
into the most significant bits of the ingress and egress interface fields 
of flow records.  By default, this behavior is disabled.

The following syntax sends NetFlow records for \fBmybr\fR to the NetFlow
collector \fBnflow.example.com\fR on UDP port \fB9995\fR:
.PP
.RS
.nf

netflow.mybr.host=nflow.example.com:9995

.fi
.RE
.SS "Remote Management"
A \fBovs\-vswitchd\fR instance may be remotely managed by a controller that
supports the OpenFlow Management Protocol, such as NOX.  This
functionality is enabled by setting the key \fBmgmt.controller\fR to one 
of the following values:
.
.IP "\fBssl:\fIip\fR[\fB:\fIport\fR]"
The specified SSL \fIport\fR (default: 6633) on the host at the given
\fIip\fR, which must be expressed as an IP address (not a DNS name).
SSL must be configured when this form is used (see \fBSSL
Configuration\fR, below).
.
.IP "\fBtcp:\fIip\fR[\fB:\fIport\fR]"
The specified TCP \fIport\fR (default: 6633) on the host at the given
\fIip\fR, which must be expressed as an IP address (not a DNS name).
.PP
The maximum time between attempts to connect to the controller may be
specified in integral seconds with the \fBmgmt.max-backoff\fR key.  The
default maximum backoff is 8 seconds, and the minimum value is 1
second.

An inactivity probe may be configured with the \fBmgmt.inactivity-probe\fR
key.  If \fBovs\-vswitchd\fR does not communicate with the controller for the
specified number of seconds, it will send a probe.  If a response is not
received for an additional amount of that time, \fBovs\-vswitchd\fR assumes
the connection has been broken and attempts to reconnect.  The default
and minimum values are both 5 seconds.

A management id may be specified with the \fBmgmt.id\fR key.  It takes
an id in the form of exactly 12 hexadecimal digits.  If one is not
specified, a random id is generated each time \fBovs\-vswitchd\fR is started.
.fi
.RE
.SS "OpenFlow Controller Connectivity"
\fBovs\-vswitchd\fR can perform all configured bridging and switching
locally, or it can be configured to connect a given bridge to an
external OpenFlow controller, such as NOX.  Its behavior depends on
the \fBbridge.\fIname\fB.controller\fR setting:
.
.TP
\fI\[la]unset\[ra]\fR
When the key is not set, the behavior depends on whether remote 
management is configured.  If management is configured, then the switch 
will connect to the controller specified on \fBmgmt.controller\fR.  If 
management is not configured, the switch will perform all configured 
bridging and switching locally.
.
.TP
\fI\[la]empty\[ra]\fR
Setting an empty string value disables controller connectivity.  The
switch will perform all configured bridging and switching locally.
.
.TP
\fBdiscover\fR
Use controller discovery to find the local OpenFlow controller.
Refer to \fBsecchan\fR(8) for information on how to configure a DHCP
server to support controller discovery.  The following additional
options control the discovery process:
.
.RS
.TP
\fBbridge.\fIname\fB.controller.accept-regex=\fIregex\fR
A POSIX extended regular expression against which the discovered
controller location is validated.  Only controllers whose names match
the regular expression will be accepted.
.IP
The default regular expression is \fBssl:.*\fR, meaning that only SSL
controller connections will be accepted, when SSL is configured (see
\fBSSL Configuration\fR), and \fB.*\fR otherwise, meaning that any
controller will be accepted.
.IP
The regular expression is implicitly anchored at the beginning of the
controller location string, as if it begins with \fB^\fR.
.TP
\fBbridge.\fIname\fB.controller.update-resolv.conf=\fBtrue\fR|\fBfalse\fR
By default, or if this is set to \fBtrue\fR, \fBovs\-vswitchd\fR overwrites
the system's \fB/etc/resolv.conf\fR with domain information and DNS
servers obtained via DHCP.  If this setting is \fBfalse\fR,
\fBovs\-vswitchd\fR will not modify \fB/etc/resolv.conf\fR.
.IP
\fBovs\-vswitchd\fR will only modify \fBresolv.conf\fR if the DHCP response
that it receives specifies one or more DNS servers.
.RE
.
.TP
\fBssl:\fIip\fR[\fB:\fIport\fR]
The specified SSL \fIport\fR (default: 6633) on the host at the given
\fIip\fR, which must be expressed as an IP address (not a DNS name).
SSL must be configured when this form is used (see \fBSSL
Configuration\fR, below).
.
.TP
\fBtcp:\fIip\fR[\fB:\fIport\fR]
The specified TCP \fIport\fR (default: 6633) on the host at the given
\fIip\fR, which must be expressed as an IP address (not a DNS name).
.
.TP
\fBunix:\fIfile\fR
The Unix domain server socket named \fIfile\fR.
.PP
The datapath ID used by the bridge to identify itself to the remote
controller may be specified as \fBbridge.\fIname\fB.datapath-id\fR,
in the form of exactly 12 hexadecimal digits.  If the datapath ID
is not specified, then it defaults to the bridge's MAC address (see
\fBBridge Configuration\fR, above, for information on how the bridge's
MAC address is chosen).
.ST "Local Port Network Configuration"
When an external controller is configured, but controller discovery is
not in use, the following additional settings are honored:
.TP
\fBbridge.\fIname\fB.controller.in-band=\fBtrue\fR|\fBfalse\fR
By default, or if this is set to \fBtrue\fR, \fBovs\-vswitchd\fR connects
to the controller in-band.  If this is set to \fBfalse\fR,
\fBovs\-vswitchd\fR connects to the controller out-of-band.  Refer to
\fBsecchan\fR(8) for a description of in-band and out-of-band control.
.IP "\fBbridge.\fIname\fB.controller.ip=\fIip\fR"
If specified, the IP address to configure on the bridge's local port.
.IP "\fBbridge.\fIname\fB.controller.netmask=\fInetmask\fR"
When an IP is specified, the corresponding netmask.  The default is
255.255.255.0 for a Class C IP address, 255.255.0.0 for Class B, and
255.0.0.0 for Class A.
.IP "\fBbridge.\fIname\fB.controller.gateway=\fIip\fR"
When an IP is specified, the corresponding IP gateway.  There is no
default gateway.
.ST "Controller Failure Settings"
The following additional settings take effect when any remote
controller is configured:
.IP "\fBbridge.\fIname\fB.controller.inactivity-probe=\fIsecs\fR"
This optional setting may be set to \fIsecs\fR, a number of seconds.
The minimum value of \fIsecs\fR is 5 seconds.  The default is taken
from \fBmgmt.inactivity-probe\fR (see above).
.IP
When the virtual switch is connected to the controller, it waits for a
message to be received from the controller for \fIsecs\fR seconds
before it sends a inactivity probe to the controller.  After sending
the inactivity probe, if no response is received for an additional
\fIsecs\fR seconds, the secure channel assumes that the connection has
been broken and attempts to reconnect.
.IP
Changing the inactivity probe interval also changes the interval
before entering standalone mode (see below).
.IP "\fBbridge.\fIname\fB.controller.fail-mode=\fBstandalone\fR|\fBsecure\fR"
.IQ "\fBmgmt.fail-mode=standalone\fR|\fBsecure\fR"
When a controller is configured, it is, ordinarily, responsible for
setting up all flows on the virtual switch.  Thus, if the connection to
the controller fails, no new network connections can be set up.  If
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.
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,
\fBovs\-vswitchd\fR causes the datapath to act like an ordinary
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
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
connection attempts starts at 1 second and doubles on each failing
attempt until it reaches the maximum.  The default maximum backoff
time is taken from \fBmgmt.max-backoff\fR.
.ST "Controller Rate-Limiting"
These settings configure how the virtual 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.
.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
OpenFlow controller to \fIrate\fR packets per second.  A rate specified
explicitly for \fIname\fR overrides a value configured using the
\fBmgmt.rate-limit\fR key.
.IP
If neither one of these settings is set, then the bridge does not
limit the rate at which packets are forwarded to the controller.
.IP "\fBbridge.\fIname\fB.controller.burst-limit=\fIburst\fR"
.IQ "\fBmgmt.burst-limit=\fIburst\fR"
Sets the maximum number of unused packet credits that the bridge will
allow to accumulate during the time in which no packets are being
forwarded to the OpenFlow controller to \fIburst\fR (measured in
packets).  The default \fIburst\fR is one-quarter of the \fIrate\fR
specified in the rate-limit setting.
.IP
A burst specified explicitly for \fIname\fR overrides a value configured 
using the \fBmgmt.burst-limit\fR key.  This option takes effect only 
when a rate-limit is specified.
.ST "Remote Command Execution Settings"
These settings configure the commands that remote OpenFlow connections
are allowed to invoke using (e.g.) \fBovs\-ofctl execute\fR.  To be
permitted, a command name must be whitelisted and must not be
blacklisted.  When the whitelist and blacklist permit a command name,
\fBovs\-vswitchd\fR looks for a program with the same name as the command
in the commands directory (see below).  Other directories are not
searched.
.IP "\fBbridge.\fIname\fB.controller.commands.acl=\fIglob\fR"
Whitelists commands whose names match shell glob pattern \fIglob\fR,
allowing those commands to be invoked by the remote controller.
.IP
By default, no commands are whitelisted, so this setting is mandatory
if any remote command execution is to be allowed.
.IP "\fBbridge.\fIname\fB.controller.commands.acl=\fB!\fR\fIglob\fR"
Blacklists commands whose names match shell glob pattern \fIglob\fR,
prohibiting those commands from being invoked by the remote
controller.  Command names that include characters other than upper-
and lower-case English letters, digits, and the underscore and hyphen
characters are blacklisted unconditionally.
.IP "\fBbridge.\fIname\fB.controller.commands.dir=\fIdirectory\fR"
Sets the directory searched for remote command execution to
\fIdirectory\fR.  The default directory is
\fB@pkgdatadir@/commands\fR.
.SS "SSL Configuration"
When \fBovs\-vswitchd\fR is configured to connect over SSL for management or
for controller connectivity, the following settings are required:
.TP
\fBssl.private-key=\fIprivkey.pem\fR
Specifies a PEM file containing the private key used as the virtual
switch's identity for SSL connections to the controller.
.TP
\fBssl.certificate=\fIcert.pem\fR
Specifies a PEM file containing a certificate, signed by the
certificate authority (CA) used by the controller and manager, that
certifies the virtual switch's private key, identifying a trustworthy
switch.
.TP
\fBssl.ca-cert=\fIcacert.pem\fR
Specifies a PEM file containing the CA certificate used to verify that
the virtual switch is connected to a trustworthy controller.
.PP
These files are read only once, at \fBovs\-vswitchd\fR startup time.  If
their contents change, \fBovs\-vswitchd\fR must be killed and restarted.
.PP
These SSL settings apply to all SSL connections made by the virtual
switch.
.ST "CA Certificate Bootstrap"
Ordinarily, all of the files named in the SSL configuration must exist
when \fBovs\-vswitchd\fR starts.  However, if \fBssl.bootstrap-ca-cert\fR
is set to \fBtrue\fR, then \fBovs\-vswitchd\fR will attempt to obtain the
CA certificate from the controller on its first SSL connection and
save it to the named PEM file.  If it is successful, it will
immediately drop the connection and reconnect, and from then on all
SSL connections must be authenticated by a certificate signed by the
CA certificate thus obtained.
.PP
\fBThis option exposes the SSL connection to a man-in-the-middle
attack obtaining the initial CA certificate\fR, but it may be useful
for bootstrapping.
.PP
This option is only useful if the controller sends its CA certificate
as part of the SSL certificate chain.  The SSL protocol does not
require the controller to send the CA certificate, but
\fBcontroller\fR(8) can be configured to do so with the
\fB--peer-ca-cert\fR option.
.SS "OpenFlow Management Connections"
By default, each bridge \fIname\fR listens for OpenFlow management
connections on a Unix domain socket named
\fB@RUNDIR@/\fIname\fB.mgmt\fR.  This socket can be used to perform
local OpenFlow monitoring and administration, e.g., \fBovs\-ofctl dump-flows
unix:@RUNDIR@/\fIname\fB.mgmt\fR to display the flows currently set up
in bridge \fIname\fR.
.PP
If \fBbridge.\fIname\fB.openflow.listeners\fR is set to one or more
values, \fBovs\-vswitchd\fR instead listens on the specified connection
methods.  Acceptable connection methods include:
.RS
.IP "\fBpunix:\fIfile\fR"
Listens for connections on the Unix domain server socket named \fIfile\fR.
.IP "\fBpssl:\fR[\fIport\fR]"
Listens for SSL connections on \fIport\fR (default: 6633).  SSL must
be configured when this form is used (see \fBSSL Configuration\fR,
above).
.IP "\fBptcp:\fR[\fIport\fR]"
Listens for TCP connections on \fIport\fR (default: 6633).
.RE
To entirely disable listening for management connections, set
\fBbridge.\fIname\fB.openflow.listeners\fR to the single value
\fBnone\fR.

.SS "OpenFlow Controller Connection Snooping"
By default, each bridge \fIname\fR listens for OpenFlow controller
connection snooping connections on a Unix domain socket named
\fB@RUNDIR@/\fIname\fB.snoop\fR.  A client that connects to this
socket, e.g., \fBovs\-ofctl monitor unix:@RUNDIR@/\fIname\fB.snoop\fR, will
receive a copy of every OpenFlow message sent by the switch to the
controller, or vice versa, on the primary OpenFlow controller
connection.
.PP
If \fBbridge.\fIname\fB.openflow.snoops\fR is set to one or more
values, \fBovs\-vswitchd\fR instead listens on the specified connection
methods.  The acceptable connection methods are the same as for
OpenFlow management connections (see above).
.PP
To entirely disable controller connection snooping, set
\fBbridge.\fIname\fB.openflow.snoops\fR to the single value
\fBnone\fR.
.SH "SEE ALSO"
.BR ovs\-brcompatd (8),
.BR ovs\-cfg\-mod (8),
.BR ovs\-vswitchd (8)