X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=vswitchd%2Fvswitch.xml;h=b9d8aaa9f3249d3a5f53e9366b2f0e72e4f47271;hb=92467099ee05b930b060d34d05b81bb1322e6fbf;hp=da3652b95a06a329681b0aaadba648f96b315dfa;hpb=1a048029a0902439c3f17c49a7f71e4d09fecf70;p=openvswitch
diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml
index da3652b9..b9d8aaa9 100644
--- a/vswitchd/vswitch.xml
+++ b/vswitchd/vswitch.xml
@@ -25,14 +25,27 @@
- Key-value pairs that identify this Open vSwitch's role in
- external systems. The currently defined key-value pairs are:
+ Key-value pairs for use by external frameworks that integrate
+ with Open vSwitch, rather than by Open vSwitch itself. System
+ integrators should either use the Open vSwitch development
+ mailing list to coordinate on common key-value definitions, or
+ choose key names that are likely to be unique. The currently
+ defined common key-value pairs are:
- system-uuid
- - A universally unique identifier for the Open vSwitch's
- physical host. The form of the identifier depends on the
- type of the host. On a Citrix XenServer, this is the host
- UUID displayed by, e.g.,
xe host-list
.
+ system-type
+ - An identifier for the switch type, such as
+
XenServer
or KVM
.
+ system-version
+ - The version of the switch software, such as
+
5.6.0
on XenServer.
+ system-id
+ - A unique identifier for the Open vSwitch's physical host.
+ The form of the identifier depends on the type of the host.
+ On a Citrix XenServer, this will likely be the same as
+
xs-system-uuid
.
+ xs-system-uuid
+ - The Citrix XenServer universally unique identifier for the
+ physical host as displayed by
xe host-list
.
@@ -130,6 +143,38 @@
will be used.
+
+ When a controller is configured, it is, ordinarily, responsible
+ for setting up all flows on the 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. This setting
+ determines the switch's response to such a situation. It may be set
+ to one of the following:
+
+ standalone
+ - If no message is received from the controller for three
+ times the inactivity probe interval
+ (see
), then Open vSwitch
+ will take over responsibility for setting up flows. In
+ this mode, Open vSwitch causes the bridge to act like an
+ ordinary MAC-learning switch. Open vSwitch will continue
+ to retry connecting to the controller in the background
+ and, when the connection succeeds, it will discontinue its
+ standalone behavior.
+ secure
+ - Open vSwitch will not set up flows on its own when the
+ controller connection fails or when no controllers are
+ defined. The bridge will continue to retry connecting to
+ any defined controllers forever.
+
+
+ If this value is unset, the default is implementation-specific.
+ When more than one controller is configured,
+ is considered only when none of the
+ configured controllers can be contacted.
+
+
Reports the OpenFlow datapath ID in use. Exactly 16 hex
digits. (Setting this column will have no useful effect. Set
@@ -146,14 +191,20 @@
- Key-value pairs that identify this bridge's role in external systems.
- The currently defined key-value pairs are:
+ Key-value pairs for use by external frameworks that integrate
+ with Open vSwitch, rather than by Open vSwitch itself. System
+ integrators should either use the Open vSwitch development
+ mailing list to coordinate on common key-value definitions, or
+ choose key names that are likely to be unique. The currently
+ defined key-value pairs are:
- network-uuids
+ bridge-id
+ - A unique identifier of the bridge. On Citrix XenServer this
+ will commonly be the same as
xs-network-uuids
.
+ xs-network-uuids
- Semicolon-delimited set of universally unique identifier(s) for
- the network with which this bridge is associated. The form of the
- identifier(s) depends on the type of the host. On a Citrix
- XenServer host, the network identifiers are RFC 4122 UUIDs as
+ the network with which this bridge is associated on a Citrix
+ XenServer host. The network identifiers are RFC 4122 UUIDs as
displayed by, e.g.,
xe network-list
.
@@ -300,13 +351,21 @@
- Key-value pairs that identify this port's role in external systems. No
- key-value pairs native to are currently defined.
- For fake bridges (see the column), external
- IDs for the fake bridge are defined here by prefixing a
- key
- with fake-bridge-
,
- e.g. fake-bridge-network-uuids
.
+
+ Key-value pairs for use by external frameworks that integrate with
+ Open vSwitch, rather than by Open vSwitch itself. System integrators
+ should either use the Open vSwitch development mailing list to
+ coordinate on common key-value definitions, or choose key names that
+ are likely to be unique.
+
+
+ No key-value pairs native to are currently
+ defined. For fake bridges (see the
+ column), external IDs for the fake bridge are defined here by
+ prefixing a key with fake-bridge-
,
+ e.g. fake-bridge-xs-network-uuids
.
+
@@ -394,15 +453,15 @@
tap
A TUN/TAP device managed by Open vSwitch.
gre
- An Ethernet over RFC 1702 Generic Routing Encapsulation over IPv4
+ An Ethernet over RFC 2890 Generic Routing Encapsulation over IPv4
tunnel. Each tunnel must be uniquely identified by the
combination of remote_ip
, local_ip
, and
in_key
. Note that if two ports are defined that are
the same except one has an optional identifier and the other does
not, the more specific one is matched first. in_key
is considered more specific than local_ip
if a port
- defines one and another port defines the other. The arguments
- are:
+ defines one and another port defines the other. The following
+ options may be specified in the column:
remote_ip
- Required. The tunnel endpoint.
@@ -429,7 +488,7 @@
either be a 32-bit number or the word flow
. If
flow
is specified then the key may be set using
the set_tunnel
Nicira OpenFlow vendor extension (0
- is used in the absense of an action). The ovs-ofctl manual
+ is used in the absence of an action). The ovs-ofctl manual
page contains additional information about the Nicira OpenFlow
vendor extensions. Default is no key.
@@ -457,9 +516,69 @@
csum
- - Optional. Compute GRE checksums for outgoing packets and
- require checksums for incoming packets. Default is enabled,
- set to
false
to disable.
+ - Optional. Compute GRE checksums on outgoing packets.
+ Checksums present on incoming packets will be validated
+ regardless of this setting. Note that GRE checksums
+ impose a significant performance penalty as they cover the
+ entire packet. As the contents of the packet is typically
+ covered by L3 and L4 checksums, this additional checksum only
+ adds value for the GRE and encapsulated Ethernet headers.
+ Default is disabled, set to
true
to enable.
+
+
+ pmtud
+ - Optional. Enable tunnel path MTU discovery. If enabled
+ ``ICMP destination unreachable - fragmentation'' needed
+ messages will be generated for IPv4 packets with the DF bit set
+ and IPv6 packets above the minimum MTU if the packet size
+ exceeds the path MTU minus the size of the tunnel headers. It
+ also forces the encapsulating packet DF bit to be set (it is
+ always set if the inner packet implies path MTU discovery).
+ Note that this option causes behavior that is typically
+ reserved for routers and therefore is not entirely in
+ compliance with the IEEE 802.1D specification for bridges.
+ Default is enabled, set to
false
to disable.
+
+
+ capwap
+ Ethernet tunneling over the UDP transport portion of CAPWAP
+ (RFC 5415). This allows interoperability with certain switches
+ where GRE is not available. Note that only the tunneling component
+ of the protocol is implemented. Due to the non-standard use of
+ CAPWAP, UDP ports 58881 and 58882 are used as the source and
+ destinations ports respectivedly. Each tunnel must be uniquely
+ identified by the combination of remote_ip
and
+ local_ip
. If two ports are defined that are the same
+ except one includes local_ip
and the other does not,
+ the more specific one is matched first. CAPWAP support is not
+ available on all platforms. Currently it is only supported in the
+ Linux kernel module with kernel versions >= 2.6.25. The following
+ options may be specified in the column:
+
+ remote_ip
+ - Required. The tunnel endpoint.
+
+
+ local_ip
+ - Optional. The destination IP that received packets must
+ match. Default is to match all addresses.
+
+
+ tos
+ - Optional. The value of the ToS bits to be set on the
+ encapsulating packet. It may also be the word
+
inherit
, in which case the ToS will be copied from
+ the inner packet if it is IPv4 or IPv6 (otherwise it will be
+ 0). Note that the ECN fields are always inherited. Default is
+ 0.
+
+
+ ttl
+ - Optional. The TTL to be set on the encapsulating packet.
+ It may also be the word
inherit
, in which case the
+ TTL will be copied from the inner packet if it is IPv4 or IPv6
+ (otherwise it will be the system default, typically 64).
+ Default is the system default TTL.
pmtud
@@ -477,11 +596,23 @@
patch
- A pair of virtual devices that act as a patch cable. A
- peer
argument is required that indicates the name
- of the other side of the patch. Since a patch must work in
- pairs, a second patch interface must be declared with the
- name
and peer
arguments reversed.
+
+
+ A pair of virtual devices that act as a patch cable. The column must have the following key-value pair:
+
+
+ peer
+ -
+ The
of the for
+ the other side of the patch. The named 's own peer
option must specify
+ this 's name. That is, the two patch
+ interfaces must have reversed and
+ peer
values.
+
+
+
@@ -489,6 +620,20 @@
Configuration options whose interpretation varies based on
.
+
+
+
+ Key-value pairs that report port status. Supported status
+ values are type
-dependent.
+
+ The only currently defined key-value pair is:
+
+ source_ip
+ - The source IP address used for an IPv4 tunnel end-point,
+ such as
gre
or capwap
. Not
+ supported by all implementations.
+
+
@@ -515,29 +660,42 @@
- Key-value pairs that identify this interface's role in external
- systems. All of the currently defined key-value pairs specifically
+ Key-value pairs for use by external frameworks that integrate
+ with Open vSwitch, rather than by Open vSwitch itself. System
+ integrators should either use the Open vSwitch development
+ mailing list to coordinate on common key-value definitions, or
+ choose key names that are likely to be unique. The currently
+ defined common key-value pairs are:
+
+ attached-mac
+ -
+ The MAC address programmed into the ``virtual hardware'' for this
+ interface, in the form
+ xx:xx:xx:xx:xx:xx.
+ For Citrix XenServer, this is the value of the
MAC
+ field in the VIF record for this interface.
+ iface-id
+ - A system-unique identifier for the interface. On XenServer,
+ this will commonly be the same as
xs-vif-uuid
.
+
+
+ Additionally the following key-value pairs specifically
apply to an interface that represents a virtual Ethernet interface
connected to a virtual machine. These key-value pairs should not be
present for other types of interfaces. Keys whose names end
in -uuid
have values that uniquely identify the entity
in question. For a Citrix XenServer hypervisor, these values are
UUIDs in RFC 4122 format. Other hypervisors may use other
- formats.
- The currently defined key-value pairs are:
+ formats.
+
+ The currently defined key-value pairs for XenServer are:
- vif-uuid
+ xs-vif-uuid
- The virtual interface associated with this interface.
- network-uuid
+ xs-network-uuid
- The virtual network to which this interface is attached.
- vm-uuid
+ xs-vm-uuid
- The VM to which this interface belongs.
- vif-mac
- - The MAC address programmed into the "virtual hardware" for this
- interface, in the
- form xx:xx:xx:xx:xx:xx.
- For Citrix XenServer, this is the value of the
MAC
- field in the VIF record for this interface.
@@ -617,7 +775,12 @@
defined types are listed below:
linux-htb
- - Linux ``hierarchy token bucket'' classifier.
+ -
+ Linux ``hierarchy token bucket'' classifier. See tc-htb(8) (also at
+
http://linux.die.net/man/8/tc-htb
) and the HTB manual
+ (http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm
)
+ for information on how this classifier works and how to configure it.
+
@@ -644,6 +807,14 @@
Mbps.
+
+
+ Key-value pairs for use by external frameworks that integrate with Open
+ vSwitch, rather than by Open vSwitch itself. System integrators should
+ either use the Open vSwitch development mailing list to coordinate on
+ common key-value definitions, or choose key names that are likely to be
+ unique. No common key-value pairs are currently defined.
+
@@ -685,6 +856,14 @@
values are unimportant; only relative ordering matters.
+
+
+ Key-value pairs for use by external frameworks that integrate with Open
+ vSwitch, rather than by Open vSwitch itself. System integrators should
+ either use the Open vSwitch development mailing list to coordinate on
+ common key-value definitions, or choose key names that are likely to be
+ unique. No common key-value pairs are currently defined.
+
@@ -766,31 +945,95 @@
in the appropriate table or tables.
+
+
+
+ Key-value pairs for use by external frameworks that integrate with Open
+ vSwitch, rather than by Open vSwitch itself. System integrators should
+ either use the Open vSwitch development mailing list to coordinate on
+ common key-value definitions, or choose key names that are likely to be
+ unique. No common key-value pairs are currently defined.
+
+
An OpenFlow controller.
- Open vSwitch permits a bridge to have any number of OpenFlow
- controllers. When multiple controllers are configured, Open vSwitch
- connects to all of them simultaneously. OpenFlow 1.0 does not specify
- how multiple controllers coordinate in interacting with a single switch,
- so more than one controller should be specified only if the controllers
- are themselves designed to coordinate with each other.
+
+ Open vSwitch supports two kinds of OpenFlow controllers:
+
+
+
+ - Primary controllers
+ -
+
+ This is the kind of controller envisioned by the OpenFlow 1.0
+ specification. Usually, a primary controller implements a network
+ policy by taking charge of the switch's flow table.
+
+
+
+ Open vSwitch initiates and maintains persistent connections to
+ primary controllers, retrying the connection each time it fails or
+ drops. The column in the
+ table applies to primary controllers.
+
+
+
+ Open vSwitch permits a bridge to have any number of primary
+ controllers. When multiple controllers are configured, Open
+ vSwitch connects to all of them simultaneously. Because
+ OpenFlow 1.0 does not specify how multiple controllers
+ coordinate in interacting with a single switch, more than
+ one primary controller should be specified only if the
+ controllers are themselves designed to coordinate with each
+ other. (The Nicira-defined NXT_ROLE
OpenFlow
+ vendor extension may be useful for this.)
+
+
+ - Service controllers
+ -
+
+ These kinds of OpenFlow controller connections are intended for
+ occasional support and maintenance use, e.g. with
+ ovs-ofctl
. Usually a service controller connects only
+ briefly to inspect or modify some of a switch's state.
+
+
+
+ Open vSwitch listens for incoming connections from service
+ controllers. The service controllers initiate and, if necessary,
+ maintain the connections from their end. The column in the table does
+ not apply to service controllers.
+
+
+
+ Open vSwitch supports configuring any number of service controllers.
+
+
+
+
+
+ The determines the type of controller.
+
- Connection method for controller.
- The following connection methods are currently
- supported:
+ Connection method for controller.
+
+ The following connection methods are currently supported for primary
+ controllers:
+
ssl:ip
[:port
]
-
The specified SSL port (default: 6633) on the host at
- the given ip, which must be expressed as an IP address
- (not a DNS name). The
- column in the must point to a valid
- SSL configuration when this form is used.
+ the given ip, which must be expressed as an IP address
+ (not a DNS name). The
+ column in the table must point to a
+ valid SSL configuration when this form is used.
SSL support is an optional feature that is not always built as
part of Open vSwitch.
@@ -815,8 +1058,35 @@
used only for bootstrapping the OpenFlow PKI at initial switch
setup; ovs-vswitchd
does not use it at all.
- none
- - Disables the controller.
+
+
+ The following connection methods are currently supported for service
+ controllers:
+
+
+ pssl:
[port][:ip
]
+ -
+
+ Listens for SSL connections on the specified TCP port
+ (default: 6633). If ip, which must be expressed as an
+ IP address (not a DNS name), is specified, then connections are
+ restricted to the specified local IP address.
+
+
+ The column in the table must point to a valid SSL
+ configuration when this form is used.
+
+ SSL support is an optional feature that is not always built as
+ part of Open vSwitch.
+
+ ptcp:
[port][:ip
]
+ -
+ Listens for connections on the specified TCP port
+ (default: 6633). If ip, which must be expressed as an
+ IP address (not a DNS name), is specified, then connections are
+ restricted to the specified local IP address.
+
When multiple controllers are configured for a single bridge, the
values must be unique. Duplicate
@@ -869,43 +1139,6 @@
assumes the connection has been broken and attempts to reconnect.
Default is implementation-specific.
-
-
- When a controller is configured, it is, ordinarily, responsible
- for setting up all flows on the 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. This setting
- determines the switch's response to such a situation. It may be set
- to one of the following:
-
- standalone
- - If no message is received from the controller for three
- times the inactivity probe interval
- (see
), then Open vSwitch
- will take over responsibility for setting up flows. In
- this mode, Open vSwitch causes the bridge to act like an
- ordinary MAC-learning switch. Open vSwitch will continue
- to retry connecting to the controller in the background
- and, when the connection succeeds, it will discontinue its
- standalone behavior.
- secure
- - Open vSwitch will not set up flows on its own when the
- controller connection fails. It will continue retry
- connecting to the controller forever.
-
-
- If this value is unset, the default is implementation-specific.
- When more than one controller is configured,
- is considered only when none of the
- configured controllers can be contacted. At that point, the bridge
- enters secure mode if any of the controllers'
- is set to secure
. Otherwise,
- it enters standalone mode if at least one
- is set to standalone
. If none of the
- values are set, the default is
- implementation-defined.
-
@@ -990,6 +1223,16 @@
this network has no gateway.
+
+
+
+ Key-value pairs for use by external frameworks that integrate with Open
+ vSwitch, rather than by Open vSwitch itself. System integrators should
+ either use the Open vSwitch development mailing list to coordinate on
+ common key-value definitions, or choose key names that are likely to be
+ unique. No common key-value pairs are currently defined.
+
+
@@ -1031,6 +1274,14 @@
disambiguate the traffic.
When this option is enabled, a maximum of 508 ports are supported.
+
+
+ Key-value pairs for use by external frameworks that integrate with Open
+ vSwitch, rather than by Open vSwitch itself. System integrators should
+ either use the Open vSwitch development mailing list to coordinate on
+ common key-value definitions, or choose key names that are likely to be
+ unique. No common key-value pairs are currently defined.
+
@@ -1063,6 +1314,14 @@
SSL connection to a man-in-the-middle attack obtaining the initial
CA certificate. It may still be useful for bootstrapping.
+
+
+ Key-value pairs for use by external frameworks that integrate with Open
+ vSwitch, rather than by Open vSwitch itself. System integrators should
+ either use the Open vSwitch development mailing list to coordinate on
+ common key-value definitions, or choose key names that are likely to be
+ unique. No common key-value pairs are currently defined.
+
@@ -1097,6 +1356,14 @@
sFlow targets in the form
ip:port
.
+
+
+ Key-value pairs for use by external frameworks that integrate with Open
+ vSwitch, rather than by Open vSwitch itself. System integrators should
+ either use the Open vSwitch development mailing list to coordinate on
+ common key-value definitions, or choose key names that are likely to be
+ unique. No common key-value pairs are currently defined.
+