ovn: Document limitation in the L3HA plan

The intergateway monitoring covers host failure well, but it doesn't cover path failure which is a more complicated problem. By this change I don't mean we should implement something to cover path failure right away, but that we should keep the limitation in mind. Signed-off-by: Miguel Angel Ajo <[email protected]> Signed-off-by: Ben Pfaff <[email protected]>
zhuomingliang · May 1, 2017 · 712eb1b · 712eb1b
1 parent 74c760c
commit 712eb1b
Show file tree

Hide file tree

Showing 2 changed files with 9 additions and 0 deletions.
diff --git a/AUTHORS.rst b/AUTHORS.rst
@@ -215,6 +215,7 @@ Mehak Mahajan                   [email protected]
 Michael Arnaldi                 [email protected]
 Michal Weglicki                 [email protected]
 Mickey Spiegel                  [email protected]
+Miguel Angel Ajo                [email protected]
 Mijo Safradin                   [email protected]
 Mika Vaisanen                   [email protected]
 Minoru TAKAHASHI                [email protected]

diff --git a/Documentation/topics/high-availability.rst b/Documentation/topics/high-availability.rst
@@ -288,6 +288,14 @@ which are alive, and therefore whether or not that gateway happens to be the
 leader.  If leading, the gateway forwards traffic normally, otherwise it drops
 all traffic.
 
+We should note that this method works well under the assumption that there
+are no inter-gateway connectivity failures, in such case this method would fail
+to elect a single master. The simplest example is two gateways which stop seeing
+each other but can still reach the hypervisors. Protocols like VRRP or CARP
+have the same issue. A mitigation for this type of failure mode could be
+achieved by having all network elements (hypervisors and gateways) periodically
+share their link status to other endpoints.
+
 Gateway Leadership Resignation
 ++++++++++++++++++++++++++++++