[ovs-dev] [patch_v3] vtep: add source node replication support.

Bruce Davie bdavie at vmware.com
Tue Apr 26 18:41:10 UTC 2016


Darrell,
 I don’t think you can handle the error of unsupported replication mode the way it is described here:

+      <column name="switch_fault_status"
+        key="unsupported_source_node_replication">
+        Indicates that the requested source node replication mode cannot be
+        supported by the physical switch;  this specifically means in this
+        context that the physical switch lacks the capability to support
+        source node replication mode.  This error occurs when a controller
+        attempts to set source node replication mode for one of the logical
+        switches that the physical switch is keeping context for.  If this
+        error occurs, logical switches continue to use service node
+        replication mode.
+      </column>

If a given logical switch spans 2 or more physical switches, and one of them can’t support source mode replication, but the other one can, then you’ll end up with the logical switch in a mixed state, with one switch falling back to service node mode and the other staying in source node mode. At this point I don’t know what happens, but clearly the controller will not be able to report what mode the logical switch is actually in (short of introducing an explicit “mixed mode”).

I propose that the last sentence read: An NVC that observes this error condition should take appropriate action (e.g. reverting the logical switch to service node replication mode).

Regarding the description of the alt_replication_mode column, I think it could be clearer. Suggested wording follows:

 <group title="Per Logical-Switch Alternate Replication Mode">
      <p>
        For handling broadcast, multicast (in default manner) and unknown
        unicast traffic, packets can be sent to all members of a logical
        switch.  There are different modes
        to replicate the packets.  The default mode of replication is to send the
        traffic to a service node, which can be a hypervisor, server or
        appliance, and let the service node handle replication to other
        transport nodes (hypervisors or other VTEP physical
        switches).  This mode is called service node replication.  An alternate
        mode of replication, called source node replication involves the
        source node sending to all other transport nodes. Hypervisors are
        always responsible for doing their own replication for locally
        attached VMs in both modes.
        Service node mode is the default (and was the only option for prior versions of this schema).
        Source node mode is an alternate replication mode that may be configured using this column.
      </p>

      <column name="alt_replication_mode">
        <p>
          This column (if used) configures the alternate replication mode for this
          <ref table="Logical_Switch"/>.  There is one valid value presently,
          <code>source_node</code>.
        </p>

Finally, it’s not strictly necessary to give this group such a long name. It’s a per-logical switch feature by definition (it exists in the table where per logical switch information is configured) so you could shorten the name as follows:

<group title="Alternate Replication Mode”>

(The reason that the tunnel key gets the longwinded treatment is because it can also be configured on a per tunnel basis elsewhere in the schema).

Bruce



More information about the dev mailing list