X-Git-Url: http://git.cascardo.eti.br/?p=cascardo%2Fovs.git;a=blobdiff_plain;f=vtep%2Fvtep.xml;h=b1befce63a6879fd111a799ed52210354c6eedd5;hp=0450999b63d73ce9f3bd9fd53dbde2f22f723686;hb=1f661ac7b8e8dbf809d987391c0196e396107650;hpb=07bb41a92032ede0c7a4f95fb030958a16284aa8 diff --git a/vtep/vtep.xml b/vtep/vtep.xml index 0450999b6..b1befce63 100644 --- a/vtep/vtep.xml +++ b/vtep/vtep.xml @@ -5,7 +5,7 @@ physical ports into logical switches maintained by a network virtualization controller such as NSX.

- +

Glossary:

@@ -29,7 +29,7 @@
Virtual Routing and Forwarding instance.
-
+ Top-level configuration for a hardware VTEP. There must be @@ -238,7 +238,7 @@

+ type='{"type": "integer"}'> The Differentiated Service Code Point (DSCP) is specified using 6 bits in the Type of Service (TOS) field in the IP header. DSCP provides a mechanism to classify the network traffic and provide Quality of @@ -287,7 +287,7 @@ Symbolic name for the switch, such as its hostname. - + An extended description for the switch, such as its switch login banner. @@ -310,6 +310,28 @@ requested by the NVC due to lack of resources. + + Indicates that the switch has been unable to create the logical router + interfaces requested by the NVC due to conflicting configurations or a + lack of hardware resources. + + + + Indicates that the switch has been unable to create the static routes + requested by the NVC due to conflicting configurations or a lack of + hardware resources. + + + + Indicates that the switch has been unable to create the logical router + requested by the NVC due to conflicting configurations or a lack of + hardware resources. + + + + Indicates that the switch does not support logical routing. + + Indicates that an error has occurred in the switch but that no more specific information is available. @@ -357,7 +379,7 @@

- In most cases the BFD peer of a hardware VTEP will be an Open vSwitch + In many cases the BFD peer of a hardware VTEP will be an Open vSwitch instance. The Open vSwitch implementation of BFD aims to comply faithfully with the requirements put forth in RFC 5880. Open vSwitch does not implement the optional Authentication or ``Echo Mode'' @@ -413,8 +435,8 @@

- True to enable BFD on this tunnel. - The default is False. + True to enable BFD on this . If not + specified, BFD will not be enabled by default. An alternate receive interval, in milliseconds, that must be greater - than or equal to . The - implementation switches from to when there is no obvious incoming - data traffic at the interface, to reduce the CPU and bandwidth cost - of monitoring an idle interface. This feature may be disabled by - setting a value of 0. This feature is reset whenever or - changes. + than or equal to . The + implementation should switch from + to when there is no obvious + incoming data traffic at the tunnel, to reduce the CPU and bandwidth + cost of monitoring an idle tunnel. This feature may be disabled by + setting a value of 0. This feature is reset whenever + or + changes. - True to consider the interface capable of packet I/O as long as it - continues to receive any packets (not just BFD packets). This - prevents link congestion that causes consecutive BFD control packets - to be lost from marking the interface down. + When true, traffic received on the + is used to indicate the capability of packet I/O. + BFD control packets are still transmitted and received. At least one + BFD control packet must be received every + 100 * amount of time. + Otherwise, even if traffic is received, the + will be false. @@ -468,59 +493,58 @@ - -

- The VTEP sets key-value pairs in the - column to report the status of BFD on this tunnel. When BFD is - not enabled, with , the - HSC clears all key-value pairs from . -

+ +

+ The VTEP sets key-value pairs in the + column to report the status of BFD on this tunnel. When BFD is + not enabled, with , the + HSC clears all key-value pairs from . +

- - Set to true if the BFD session has been successfully - enabled. Set to false if the VTEP cannot support BFD or has - insufficient resources to enable BFD on this tunnel. The NVC - will disable the BFD monitoring on the other side of the tunnel - once this value is set to false. - + + Set to true if the BFD session has been successfully enabled. + Set to false if the VTEP cannot support BFD or has insufficient + resources to enable BFD on this tunnel. The NVC will disable + the BFD monitoring on the other side of the tunnel once this + value is set to false. + - - Reports the state of the BFD session. The BFD session is fully - healthy and negotiated if UP. - + Reports the state of the BFD session. The BFD session is fully + healthy and negotiated if UP. +
- - Reports whether the BFD session believes this tunnel - may be used to forward traffic. Typically this means the local session - is signaling UP, and the remote system isn't signaling a - problem such as concatenated path down. - + + Reports whether the BFD session believes this + may be used to forward traffic. Typically this means the local session + is signaling UP, and the remote system isn't signaling a + problem such as concatenated path down. + - - In case of a problem, set to an error message that reports what the - local BFD session thinks is wrong. The error messages are defined - in section 4.1 of [RFC 5880]. - + + A diagnostic code specifying the local system's reason for the + last change in session state. The error messages are defined in + section 4.1 of [RFC 5880]. + - - Reports the state of the remote endpoint's BFD session. - + Reports the state of the remote endpoint's BFD session. +
- - In case of a problem, set to an error message that reports what the - remote endpoint's BFD session thinks is wrong. The error messages - are defined in section 4.1 of [RFC 5880]. - + + A diagnostic code specifying the remote system's reason for the + last change in session state. The error messages are defined in + section 4.1 of [RFC 5880]. + - - A short message providing further information about the BFD status - (possibly including reasons why BFD could not be enabled). - + + A short message providing further information about the BFD status + (possibly including reasons why BFD could not be enabled). +
@@ -532,7 +556,25 @@ Identifies how VLANs on the physical port are bound to logical switches. If, for example, the map contains a (VLAN, logical switch) pair, a packet that arrives on the port in the VLAN is considered to belong to the - paired logical switch. + paired logical switch. A value of zero in the VLAN field means + that untagged traffic on the physical port is mapped to the + logical switch. + + + +

+ Attach Access Control Lists (ACLs) to the physical port. The + column consists of a map of VLAN tags to s. If the value of + the VLAN tag in the map is 0, this means that the ACL is + associated with the entire physical port. Non-zero values mean + that the ACL is to be applied only on packets carrying that VLAN + tag value. Switches will not necessarily support matching on the + VLAN tag for all ACLs, and unsupported ACL bindings will cause + errors to be reported. The binding of an ACL to a specific + VLAN and the binding of an ACL to the entire physical port + should not be combined on a single physical port. That is, a + mix of zero and non-zero keys in the map is not recommended. +

@@ -541,7 +583,8 @@ column with a mapping for every VLAN that is bound in . An implementation that does not support such statistics or only partially supports them would not populate this column - or partially populate it, respectively. + or partially populate it, respectively. A value of zero in the + VLAN field refers to untagged traffic on the physical port. @@ -568,6 +611,12 @@ because of a conflict with local configuration.

+ +

+ Indicates that an error has occurred in associating an ACL + with a port. +

+

Indicates that an error has occurred on the port but that no @@ -662,9 +711,10 @@

- For vxlan_over_ipv4 encapsulation, this column - is the VXLAN VNI that identifies a logical switch. It must - be in the range 0 to 16,777,215. + For vxlan_over_ipv4 encapsulation, when the tunnel key + per model is in use, this column is the + VXLAN VNI that identifies a logical switch. It must be in the range + 0 to 16,777,215.

@@ -673,7 +723,7 @@ Symbolic name for the logical switch. - + An extended description for the logical switch, such as its switch login banner. @@ -710,7 +760,7 @@ - +

Mapping of unicast MAC addresses to tunnels (physical locators). This table is written by the NVC, so it contains the @@ -754,7 +804,7 @@

- A MAC address that has been learned by the VTEP. + A MAC address that has been learned by the VTEP.

The keyword unknown-dst is used as a special @@ -833,10 +883,10 @@

A logical router, or VRF. A logical router may be connected to one or more - logical switches. Subnet addresses and interface addresses may be configured on the + logical switches. Subnet addresses and interface addresses may be configured on the interfaces.

- + Maps from an IPv4 or IPv6 address prefix in CIDR notation to a logical switch. Multiple prefixes may map to the same switch. By @@ -851,6 +901,15 @@ One or more static routes, mapping IP prefixes to next hop IP addresses. + + Maps ACLs to logical router interfaces. The router interfaces + are indicated using IP address notation, and must be the same + interfaces created in the + column. For example, an ACL could be associated with the logical + router interface with an address of 192.68.1.1 as defined in the + example above. + + Symbolic name for the logical router. @@ -860,6 +919,28 @@ An extended description for the logical router. + + +

+ An entry in this column indicates to the NVC that the HSC has + encountered a fault in configuring state related to the + logical router. +

+ +

+ Indicates that an error has occurred in associating an ACL + with a logical router port. +

+
+ +

+ Indicates that an error has occurred in configuring the + logical router but that no + more specific information is available. +

+
+
+
@@ -925,7 +1006,7 @@ table="Physical_Locator"/> records.''

- +
@@ -935,24 +1016,17 @@

- For the vxlan_over_ipv4 encapsulation, the only - encapsulation defined so far, all endpoints associated with a given must use a common tunnel key, which is carried - in the column of . -

- -

- For some encapsulations yet to be defined, we expect to identify both an endpoint and a tunnel key. - When the first such encapsulation is defined, we expect to add a - ``tunnel_key'' column to to allow the - tunnel key to be defined. -

- -

- See the ``Per Logical-Switch Tunnel Key'' section in the table for further discussion of the model. + The vxlan_over_ipv4 encapsulation, the only encapsulation + defined so far, can use either tunnel key model described in the ``Per + Logical-Switch Tunnel Key'' section in the + table. When the tunnel key per model is in + use, the column in the + table is filled with a VNI and the column in this table is empty; in the + key-per-tunnel model, the opposite is true. The former model is older, + and thus likely to be more widely supported. See the ``Per + Logical-Switch Tunnel Key'' section in the + table for further discussion of the model.

@@ -971,6 +1045,228 @@

-
+ +

+ This column is used only in the tunnel key per + model (see + above). +

+ +

+ For vxlan_over_ipv4 encapsulation, when the + model is in + use, this column is the VXLAN VNI. It must be in the range 0 to + 16,777,215. +

+
+ + +

+ Describes the individual entries that comprise an Access Control List. +

+

+ Each entry in the table is a single rule to match on certain + header fields. While there are a large number of fields that can + be matched on, most hardware cannot match on arbitrary + combinations of fields. It is common to match on either L2 + fields (described below in the L2 group of columns) or L3/L4 fields + (the L3/L4 group of columns) but not both. The hardware switch + controller may log an error if an ACL entry requires it to match + on an incompatible mixture of fields. +

+ +

+ The sequence number for the ACL entry for the purpose of + ordering entries in an ACL. Lower numbered entries are matched + before higher numbered entries. +

+
+ + +

+ Source MAC address, in the form + xx:xx:xx:xx:xx:xx +

+
+ +

+ Destination MAC address, in the form + xx:xx:xx:xx:xx:xx +

+
+ +

+ Ethertype in hexadecimal, in the form + 0xAAAA +

+
+
+ + +

+ Source IP address, in the form + xx.xx.xx.xx for IPv4 or appropriate + colon-separated hexadecimal notation for IPv6. +

+
+ +

+ Mask that determines which bits of source_ip to match on, in the form + xx.xx.xx.xx for IPv4 or appropriate + colon-separated hexadecimal notation for IPv6. +

+
+ +

+ Destination IP address, in the form + xx.xx.xx.xx for IPv4 or appropriate + colon-separated hexadecimal notation for IPv6. +

+
+ +

+ Mask that determines which bits of dest_ip to match on, in the form + xx.xx.xx.xx for IPv4 or appropriate + colon-separated hexadecimal notation for IPv6. +

+
+ +

+ Protocol number in the IPv4 header, or value of the "next + header" field in the IPv6 header. +

+
+ +

+ Lower end of the range of source port values. The value + specified is included in the range. +

+
+ +

+ Upper end of the range of source port values. The value + specified is included in the range. +

+
+ +

+ Lower end of the range of destination port values. The value + specified is included in the range. +

+
+ +

+ Upper end of the range of destination port values. The value + specified is included in the range. +

+
+ +

+ Integer representing the value of TCP flags to match. For + example, the SYN flag is the second least significant bit in + the TCP flags. Hence a value of 2 would indicate that the "SYN" + flag should be set (assuming an appropriate mask). +

+
+ +

+ Integer representing the mask to apply when matching TCP + flags. For example, a value of 2 would imply that the "SYN" + flag should be matched and all other flags ignored. +

+
+ +

+ ICMP type to be matched. +

+
+ +

+ ICMP code to be matched. +

+
+
+ +

+ Direction of traffic to match on the specified port, either + "ingress" (toward the logical switch or router) or "egress" + (leaving the logical switch or router). +

+
+ +

+ Action to take for this rule, either "permit" or "deny". +

+
+ +

+ An entry in this column indicates to the NVC that the ACL + could not be configured as requested. The switch must clear this column when the error + has been cleared. +

+ +

+ Indicates that an ACL entry requested by + the controller could not be instantiated by the switch, + e.g. because it requires an unsupported combination of + fields to be matched. +

+
+ +

+ Indicates that an error has occurred in configuring the ACL + entry but no + more specific information is available. +

+
+
+
+ +

+ Access Control List table. Each ACL is constructed as a set of + entries from the table. Packets that + are not matched by any entry in the ACL are allowed by default. +

+ +

+ A set of references to entries in the table. +

+
+ +

+ A human readable name for the ACL, which may (for example) be displayed on + the switch CLI. +

+
+ +

+ An entry in this column indicates to the NVC that the ACL + could not be configured as requested. The switch must clear this column when the error + has been cleared. +

+ +

+ Indicates that an ACL requested by + the controller could not be instantiated by the switch, + e.g., because it requires an unsupported combination of + fields to be matched. +

+
+ +

+ Indicates that an ACL requested by + the controller could not be instantiated by the switch due + to a shortage of resources (e.g. TCAM space). +

+
+ +

+ Indicates that an error has occurred in configuring the ACL + but no + more specific information is available. +

+
+
+