X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=vswitchd%2Fvswitch.xml;h=465f27dd1b2a0df279f98a42f45298f687f82ad8;hb=142181fcd734a2afff9fe13e54fe51c7a2c824d2;hp=500a0f967768a27b4b9573ecd72062b2b9cc3a8e;hpb=76ce9432393df462e2030036021ea60096a734d4;p=openvswitch diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml index 500a0f96..465f27dd 100644 --- a/vswitchd/vswitch.xml +++ b/vswitchd/vswitch.xml @@ -15,12 +15,6 @@ Set of bridges managed by the daemon. - - Default OpenFlow set used by bridges. May be - overridden on a per-bridge basis by the column in . - - Remote database clients to which the Open vSwitch's database server should connect or to which it should listen. @@ -31,8 +25,12 @@ - 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 @@ -56,6 +54,34 @@ after it finishes applying a set of configuration changes. + + + Describes functionality supported by the hardware and software platform + on which this Open vSwitch is based. Clients should not modify this + column. See the description for defined + capability categories and the meaning of associated + records. + + + +

+ Key-value pairs that report statistics about a running Open_vSwitch + daemon. The current implementation updates these counters + periodically. In the future, we plan to, instead, update them only + when they are queried (e.g. using an OVSDB select + operation) and perhaps at other times, but not on any regular + periodic basis.

+

+ The currently defined key-value pairs are listed below. Some Open + vSwitch implementations may not support some statistics, in which + case those key-value pairs are omitted.

+
+
load-average
+
+ System load average multiplied by 100 and rounded to the nearest + integer.
+
+ @@ -104,15 +130,47 @@ - OpenFlow controller set. If unset, defaults to the set of - controllers specified by in the - table. If the default is also unset, then no OpenFlow - controllers will be used. + OpenFlow controller set. If unset, then no OpenFlow controllers + 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. + Reports the OpenFlow datapath ID in use. Exactly 16 hex + digits. (Setting this column will have no useful effect. Set + :other-config + instead.) @@ -124,8 +182,12 @@ - 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 common key-value pairs are:
network-uuids
Semicolon-delimited set of universally unique identifier(s) for @@ -180,37 +242,48 @@

A bridge port must be configured for VLANs in one of two mutually exclusive ways:

    -
  • A ``trunk port'' has an empty value for - and a possibly non-empty - value.
    • +
  • A ``trunk port'' has an empty value for . Its value may be + empty or non-empty.
  • An ``implicitly tagged VLAN port'' or ``access port'' - has an nonempty value for and an empty - value.
    • + has an nonempty value for . Its + value must be empty.
If and are both nonempty, the configuration is ill-formed.

-

If nonempty, this port's implicitly tagged VLAN. Frames - arriving on trunk ports will be forwarded to this port only - if they are tagged with the given VLAN. Frames arriving on - other VLAN ports will be forwarded to this port only if they - have the same value. Frames forwarded - to this port will not have an 802.1Q header.

-

When a frame with a 802.1Q header that indicates a nonzero VLAN is - received on an implicit VLAN port, it is discarded.

-

Must be empty if this is a trunk port.

+

+ If this is an access port (see above), the port's implicitly + tagged VLAN. Must be empty if this is a trunk port. +

+

+ Frames arriving on trunk ports will be forwarded to this + port only if they are tagged with the given VLAN (or, if + is 0, then if they lack a VLAN header). + Frames arriving on other access ports will be forwarded to + this port only if they have the same + value. Frames forwarded to this port will not have an + 802.1Q header. +

+

+ When a frame with a 802.1Q header that indicates a nonzero + VLAN is received on an access port, it is discarded. +

-

The 802.1Q VLAN(s) that this port trunks. If the column is - empty, then the port trunks all VLANs as well as packets that - have no VLAN header. Otherwise, only frames that have an - 802.1Q header with one of the specified VLANs are accepted. - If 0 is included, then frames without an 802.1Q - header are also accepted.

-

Must be empty unless this is a trunk port.

+

+ If this is a trunk port (see above), the 802.1Q VLAN(s) that + this port trunks; if it is empty, then the port trunks all + VLANs. Must be empty if this is an access port. +

+

+ Frames arriving on trunk ports are dropped if they are not + in one of the specified VLANs. For this purpose, packets + that have no VLAN header are treated as part of VLAN 0. +

@@ -250,6 +323,10 @@ + + Quality of Service configuration for this port. + + The MAC address to use for this port for the purpose of choosing the bridge's MAC address. This column does not necessarily reflect the @@ -263,13 +340,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-network-uuids. +

@@ -364,8 +449,8 @@ 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.
@@ -440,11 +525,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. +
+
+
@@ -478,15 +575,23 @@ -

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. +

+

+ All of the currently defined 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.

+ formats. +

The currently defined key-value pairs are:

vif-uuid
@@ -503,9 +608,169 @@ field in the VIF record for this interface.
 + + +

+ Key-value pairs that report interface statistics. The current + implementation updates these counters periodically. In the future, + we plan to, instead, update them when an interface is created, when + they are queried (e.g. using an OVSDB select operation), + and just before an interface is deleted due to virtual interface + hot-unplug or VM shutdown, and perhaps at other times, but not on any + regular periodic basis.

+

+ The currently defined key-value pairs are listed below. These are + the same statistics reported by OpenFlow in its struct + ofp_port_stats structure. If an interface does not support a + given statistic, then that pair is omitted.

+ + + +

Quality of Service (QoS) configuration for each Port that + references it.

+ + +

The type of QoS to implement. The column in the table + identifies the types that a switch actually supports. The currently + defined types are listed below:

+
+
linux-htb
+
Linux ``hierarchy token bucket'' classifier.
+
+ + + +

A map from queue numbers to records. The + supported range of queue numbers depend on . The + queue numbers are the same as the queue_id used in + OpenFlow in struct ofp_action_enqueue and other + structures. Queue 0 is used by OpenFlow output actions that do not + specify a specific queue.

+ + + +

Key-value pairs for configuring QoS features that depend on + .

+

The linux-htb class supports the following key-value + pairs:

+
+
max-rate
+
Maximum rate shared by all queued traffic, in bit/s. + Optional. If not specified, for physical interfaces, the + default is the link rate. For other interfaces or if the + link rate cannot be determined, the default is currently 100 + 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. + +
+ + +

A configuration for a port output queue, used in configuring Quality of + Service (QoS) features. May be referenced by column in table.

+ + +

Key-value pairs for configuring the output queue. The supported + key-value pairs and their meanings depend on the + of the records that reference this row.

+

The key-value pairs defined for of min-rate are:

+
+
min-rate
+
Minimum guaranteed bandwidth, in bit/s. Required.
+
+

The key-value pairs defined for of linux-htb are:

+
+
min-rate
+
Minimum guaranteed bandwidth, in bit/s. Required.
+
max-rate
+
Maximum allowed bandwidth, in bit/s. Optional. If specified, the + queue's rate will not be allowed to exceed the specified value, even + if excess bandwidth is available. If unspecified, defaults to no + limit.
+
burst
+
Burst size, in bits. This is the maximum amount of ``credits'' + that a queue can accumulate while it is idle. Optional. Details of + the linux-htb implementation require a minimum burst + size, so a too-small burst will be silently + ignored.
+
priority
+
A nonnegative 32-bit integer. Defaults to 0 if + unspecified. A queue with a smaller priority + will receive all the excess bandwidth that it can use before + a queue with a larger value receives any. Specific priority + 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. + +
+

A port mirror within a .

A port mirror configures a bridge to send selected frames to special @@ -585,31 +850,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.

@@ -634,8 +963,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 @@ -688,43 +1044,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.

- @@ -809,6 +1128,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. + +
@@ -850,6 +1179,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. +
@@ -882,6 +1219,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. +
@@ -889,10 +1234,11 @@ of switches.

- IP address to report as ``agent address'' to collectors. If not - specified, defaults to the in - the collector's . If neither is specified, - sFlow is disabled. + Name of the network device whose IP address should be reported as the + ``agent address'' to collectors. If not specified, the IP address + defaults to the in the + collector's . If an agent IP address cannot be + determined either way, sFlow is disabled. @@ -915,5 +1261,55 @@ 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. + +
+ + +

Records in this table describe functionality supported by the hardware + and software platform on which this Open vSwitch is based. Clients + should not modify this table.

+ +

A record in this table is meaningful only if it is referenced by the + column in the + table. The key used to reference it, called + the record's ``category,'' determines the meanings of the + column. The following general forms of + categories are currently defined:

+ +
+
qos-type
+
type is supported as the value for + in the table. +
+
+ + +

Key-value pairs that describe capabilities. The meaning of the pairs + depends on the category key that the column in the table + uses to reference this record, as described above.

+ +

The presence of a record for category qos-type + indicates that the switch supports type as the value of + the column in the + table. The following key-value pairs are defined to further describe + QoS capabilities:

+ +
+
n-queues
+
Number of supported queues, as a positive integer. Keys in the + column for + records whose value + equals type must range between 0 and this value minus one, + inclusive.
+
+