From: Alex Wang Date: Fri, 7 Aug 2015 07:21:42 +0000 (-0700) Subject: ovn-controller-vtep: Update related documentation. X-Git-Tag: v2.5.0~573 X-Git-Url: http://git.cascardo.eti.br/?a=commitdiff_plain;h=88058f19ed9aadb1b22d26d93e46b3fd5eb1ad32;p=cascardo%2Fovs.git ovn-controller-vtep: Update related documentation. This commit conducts the following documentation changes: * add a description in ovn-architecture manual for the life cycle about VTEP gateway. * add TODOs related to ovn-controller-vtep. * refine the ovn-sb, ovn-nb schema manual to require logical 'port' type and 'options' configuration. Signed-off-by: Alex Wang Acked-by: Russell Bryant Acked-by: Justin Pettit --- diff --git a/ovn/TODO b/ovn/TODO index 356b3bad2..6f625cea5 100644 --- a/ovn/TODO +++ b/ovn/TODO @@ -80,3 +80,24 @@ So far, both ovn-controller and ovn-controller-vtep only allow chassis to have one tunnel encapsulation entry. We should extend the implementation to support multiple tunnel encapsulations. + +** Update learned MAC addresses from VTEP to OVN + + The VTEP gateway stores all MAC addresses learned from its + physical interfaces in the 'Ucast_Macs_Local' and the + 'Mcast_Macs_Local' tables. ovn-controller-vtep should be + able to update that information back to ovn-sb database, + so that other chassis know where to send packets destined + to the extended external network instead of broadcasting. + +** Translate ovn-sb Multicast_Group table into VTEP config + + The ovn-controller-vtep daemon should be able to translate + the Multicast_Group table entry in ovn-sb database into + Mcast_Macs_Remote table configuration in VTEP database. + +* Use BFD as tunnel monitor. + + Both ovn-controller and ovn-contorller-vtep should use BFD to + monitor the tunnel liveness. Both ovs-vswitchd schema and + VTEP schema supports BFD. \ No newline at end of file diff --git a/ovn/ovn-architecture.7.xml b/ovn/ovn-architecture.7.xml index b4e6d106a..47dfc2a28 100644 --- a/ovn/ovn-architecture.7.xml +++ b/ovn/ovn-architecture.7.xml @@ -817,6 +817,101 @@ +

Life Cycle of a VTEP gateway

+ +

+ A gateway is a chassis that forwards traffic between the OVN-managed + part of a logical network and a physical VLAN, extending a + tunnel-based logical network into a physical network. +

+ +

+ The steps below refer often to details of the OVN and VTEP database + schemas. Please see ovn-sb(5), ovn-nb(5) + and vtep(5), respectively, for the full story on these + databases. +

+ +
    +
  1. + A VTEP gateway's life cycle begins with the administrator registering + the VTEP gateway as a Physical_Switch table entry in the + VTEP database. The ovn-controller-vtep + connected to this VTEP database, will recognize the new VTEP gateway + and create a new Chassis table entry for it in the + OVN_Southbound database. +
    2. + +
  2. + The administrator can then create a new Logical_Switch + table entry, and bind a particular vlan on a VTEP gateway's port to + any VTEP logical switch. Once a VTEP logical switch is bound to + a VTEP gateway, the ovn-controller-vtep will detect + it and add its name to the vtep_logical_switches + column of the Chassis table in the + OVN_Southbound database. Note, the tunnel_key + column of VTEP logical switch is not filled at creation. The + ovn-controller-vtep will set the column when the + correponding vtep logical switch is bound to an OVN logical network. +
    3. + +
  3. + Now, the administrator can use the CMS to add a VTEP logical switch + to the OVN logical network. To do that, the CMS must first create a + new Logical_Port table entry in the + OVN_Northbound database. Then, the type column + of this entry must be set to "vtep". Next, the + vtep-logical-switch and vtep-physical-switch keys + in the options column must also be specified, since + multiple VTEP gateways can attach to the same VTEP logical switch. +
    4. + +
  4. + The newly created logical port in the OVN_Northbound + database and its configuration will be passed down to the + OVN_Southbound database as a new Port_Binding + table entry. The ovn-controller-vtep will recognize the + change and bind the logical port to the corresponding VTEP gateway + chassis. Configuration of binding the same VTEP logical switch to + a different OVN logical networks is not allowed and a warning will be + generated in the log. +
    5. + +
  5. + Beside binding to the VTEP gateway chassis, the + ovn-controller-vtep will update the tunnel_key + column of the VTEP logical switch to the corresponding + Datapath_Binding table entry's tunnel_key for the + bound OVN logical network. +
    6. + +
  6. + Next, the ovn-controller-vtep will keep reacting to the + configuration change in the Port_Binding in the + OVN_Northbound database, and updating the + Ucast_Macs_Remote table in the VTEP database. + This allows the VTEP gateway to understand where to forward the unicast + traffic coming from the extended external network. +
    7. + +
  7. + Eventually, the VTEP gateway's life cycle ends when the administrator + unregisters the VTEP gateway from the VTEP database. + The ovn-controller-vtep will recognize the event and + remove all related configurations (Chassis table entry + and port bindings) in the OVN_Southbound database. +
    8. + +
  8. + When the ovn-controller-vtep is terminated, all related + configurations in the OVN_Southbound database and + the VTEP database will be cleaned, including + Chassis table entries for all registered VTEP gateways + and their port bindings, and all Ucast_Macs_Remote table + entries and the Logical_Switch tunnel keys. +
    9. +
+

Design Decisions

Tunnel Encapsulations

diff --git a/ovn/ovn-nb.xml b/ovn/ovn-nb.xml index ba1cec1a3..701466b05 100644 --- a/ovn/ovn-nb.xml +++ b/ovn/ovn-nb.xml @@ -111,32 +111,60 @@

Specify a type for this logical port. Logical ports can be used to model - other types of connectivity into an OVN logical switch. Leaving this column - blank maintains the default logical port behavior. + other types of connectivity into an OVN logical switch. Leaving this + column blank maintains the default logical port behavior, which is + for a VM (or VIF) interface. The following other types are defined:

-

- When this column is set to localnet, this logical port - represents a connection to a locally accessible network from each - ovn-controller instance. A logical switch can only have a - single localnet port attached and at most one regular - logical port. This is used to model direct connectivity to an existing - network. -

+
+
localnet
+
A connection to a locally accessible network from each + ovn-controller instance. A logical switch can only + have a single localnet port attached and at most one + regular logical port. This is used to model direct connectivity + to an existing network.
+
+ +
+
vtep
+
A port to a logical switch on a VTEP gateway. In order + to get this port correctly recognized by the OVN controller, the + :vtep-physical-switch + and :vtep-logical-switch + must also be defined.
+

This column provides key/value settings specific to the logical port - . + . The following options are defined:

-

- When is set to localnet, you must set - the option network_name. ovn-controller uses - local configuration to determine exactly how to connect to this locally - accessible network. -

+
+
network_name
+
+ Must be set when is localnet. + ovn-controller uses local configuration to determine + exactly how to connect to this locally accessible network. +
+
+ +
+
vtep-physical-switch
+
+ The name of the VTEP gateway. Must be set when + is vtep. +
+
+ +
+
vtep-logical-switch
+
+ A logical switch name connected by the VTEP gateway. Must be + set when is vtep. +
+
@@ -279,7 +307,6 @@

The action to take when the ACL rule matches:

-
  • allow: Forward the packet. diff --git a/ovn/ovn-sb.xml b/ovn/ovn-sb.xml index 74631f93e..c1932ad2d 100644 --- a/ovn/ovn-sb.xml +++ b/ovn/ovn-sb.xml @@ -10,8 +10,8 @@ The OVN Southbound database sits at the center of the OVN architecture. It is the one component that speaks both southbound directly to all the hypervisors and gateways, via - ovn-controller, and northbound to the Cloud Management - System, via ovn-northd: + ovn-controller/ovn-controller-vtep, and + northbound to the Cloud Management System, via ovn-northd:

    Database Structure

    @@ -115,13 +115,14 @@
    external_ids: map of string-string pairs
    Key-value pairs for use by the software that manages the OVN Southbound - database rather than by ovn-controller. In particular, - ovn-northd can use key-value pairs in this column to relate - entities in the southbound database to higher-level entities (such as - entities in the OVN Northbound database). Individual key-value pairs in - this column may be documented in some cases to aid in understanding and - troubleshooting, but the reader should not mistake such documentation as - comprehensive. + database rather than by + ovn-controller/ovn-controller-vtep. In + particular, ovn-northd can use key-value pairs in this + column to relate entities in the southbound database to higher-level + entities (such as entities in the OVN Northbound database). Individual + key-value pairs in this column may be documented in some cases to aid + in understanding and troubleshooting, but the reader should not mistake + such documentation as comprehensive.
    @@ -129,8 +130,9 @@

    Each row in this table represents a hypervisor or gateway (a chassis) in the physical network (PN). Each chassis, via - ovn-controller, adds and updates its own row, and keeps a - copy of the remaining rows to determine how to reach other hypervisors. + ovn-controller/ovn-controller-vtep, adds + and updates its own row, and keeps a copy of the remaining rows to + determine how to reach other hypervisors.

    @@ -167,12 +169,19 @@ A gateway is a chassis that forwards traffic between the OVN-managed part of a logical network and a physical VLAN, extending a tunnel-based logical network into a physical network. Gateways are - typically dedicated nodes that do not host VMs. + typically dedicated nodes that do not host VMs and will be controlled + by ovn-controller-vtep.

    - Stores all vtep logical switch names connected by this gateway - chassis. + Stores all VTEP logical switch names connected by this gateway + chassis. The table entry with + :vtep-physical-switch + equal , and + :vtep-logical-switch + value in + , will be + associated with this . @@ -182,9 +191,10 @@ The column in the table refers to rows in this table to identify how OVN may transmit logical dataplane packets to this chassis. - Each chassis, via ovn-controller(8), adds and updates - its own rows and keeps a copy of the remaining rows to determine - how to reach other chassis. + Each chassis, via ovn-controller(8) or + ovn-controller-vtep(8), adds and updates its own rows + and keeps a copy of the remaining rows to determine how to reach + other chassis.

    @@ -927,12 +937,13 @@

    - ovn-controller populates the chassis column - for the records that identify the logical ports that are located on its - hypervisor, which ovn-controller in turn finds out by - monitoring the local hypervisor's Open_vSwitch database, which - identifies logical ports via the conventions described in - IntegrationGuide.md. + ovn-controller/ovn-controller-vtep + populates the chassis column for the records that + identify the logical ports that are located on its hypervisor/gateway, + which ovn-controller/ovn-controller-vtep in + turn finds out by monitoring the local hypervisor's Open_vSwitch + database, which identifies logical ports via the conventions described + in IntegrationGuide.md.

    @@ -941,8 +952,9 @@ (This is not critical because resources hosted on the chassis are equally unreachable regardless of whether their rows are present.) To handle the case where a VM is shut down abruptly on one chassis, then brought up - again on a different one, ovn-controller must overwrite the - chassis column with new information. + again on a different one, + ovn-controller/ovn-controller-vtep must + overwrite the chassis column with new information.

    @@ -959,48 +971,78 @@

    A type for this logical port. Logical ports can be used to model - other types of connectivity into an OVN logical switch. Leaving this column - blank maintains the default logical port behavior. + other types of connectivity into an OVN logical switch. Leaving this + column blank maintains the default logical port behavior, which + is for a VM (or VIF) interface. The following other types are defined:

    -

    - When this column is set to localnet, this logical port - represents a connection to a locally accessible network from each - ovn-controller instance. A logical switch can only have a single - localnet port attached and at most one regular logical - port. This is used to model direct connectivity to an existing - network. -

    +
    +
    localnet
    +
    A connection to a locally accessible network from each + ovn-controller instance. A logical switch can only + have a single localnet port attached and at most one + regular logical port. This is used to model direct connectivity + to an existing network.
    +
    + +
    +
    vtep
    +
    A port to a logical switch on a VTEP gateway chassis. In order + to get this port correctly recognized by the OVN controller, the + :vtep-physical-switch + and :vtep-logical-switch + must also be defined.
    +

    This column provides key/value settings specific to the logical port - . + . The following options are defined:

    -

    - When is set to localnet, you must set - the option network_name. ovn-controller uses - the configuration entry ovn-bridge-mappings to determine - how to connect to this network. ovn-bridge-mappings is a - list of network names mapped to a local OVS bridge that provides access - to that network. An example of configuring - ovn-bridge-mappings would be: -

    +
    +
    network_name
    +
    + Must be set when is localnet. + ovn-controller uses the configuration entry + ovn-bridge-mappings to determine how to connect to + this network. ovn-bridge-mappings is a list of + network names mapped to a local OVS bridge that provides access + to that network. An example of configuring + ovn-bridge-mappings would be: -

    - $ ovs-vsctl set open - . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1 -

    +

    + $ ovs-vsctl set open + . external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1 +

    -

    - Also note that when a logical switch has a localnet port - attached, every chassis that may have a local vif attached to that - logical switch must have a bridge mapping configured to reach that - localnet. Traffic that arrives on a localnet - port is never forwarded over a tunnel to another chassis. -

    +

    + Also note that when a logical switch has a localnet + port attached, every chassis that may have a local vif attached + to that logical switch must have a bridge mapping configured to + reach that localnet. Traffic that arrives on a + localnet port is never forwarded over a tunnel to + another chassis. +

    +
    +
    + +
    +
    vtep-physical-switch
    +
    + The name of the VTEP gateway. Must be set when + is vtep. +
    +
    + +
    +
    vtep-logical-switch
    +
    + A logical switch name connected by the VTEP gateway. Must be + set when is vtep. +
    +
    @@ -1034,7 +1076,7 @@ The physical location of the logical port. To successfully identify a chassis, this column must be a record. This is - populated by ovn-controller. + populated by ovn-controller/ovn-controller-vtep.