<div dir="ltr">Hi Galo,<div><br></div><div style>Nice write up, I have a couple of questions/comments...</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 19, 2013 at 2:54 PM, Navarro, Galo <span dir="ltr"><<a href="mailto:galo@midokura.jp" target="_blank">galo@midokura.jp</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi devs,<br>
<br>
Find below a proposal for the implementation of Tunnel Health checks.<br>
Thanks in advance for any feedback, new requirements, etc.<br>
<br>
# Use Case<br>
<br>
The goal of this feature is to watch tunnel's health with a double<br>
purpose: first expose problems in the virtual network that might be<br>
caused by the underlying network (as seen in the Netflix POC). Second,<br>
enable corrective actions, both manual via the API and automatic from<br>
inside MM (typically, recreate the tunnel).<br>
<br>
The solution presented here offers a way for each agent to maintain an<br>
updated status of the tunnel between its own local host and all its peer<br>
hosts. By design, this status relationship will not be symmetric because<br>
there is no guarantee that if A can communicate with B, B will also be<br>
able to communicate with A. Therefore, given any pair of nodes, each<br>
will need to watch the connectivity from itself to the other.<br>
<br>
## API changes<br>
<br>
The API changes will be highly conditioned by the desired GUI to display<br>
tunnel health to users. I will make here a proposal that conditioned to<br>
reusing existing data and functionality. But of course let me know if<br>
you envision a different UI and I'll propose a suitable API for it.<br>
<br>
There are already methods to query existing port stats that provide<br>
rxBytes, txBytes, rxPackets, txPackets. These can be used by the backend<br>
to check tunnel's health, and since there are API methods to query this<br>
data it would be possible to offer a simple visualization of the<br>
connectivity status on tunnels. For example, the GUI could show the list<br>
of port stats (all, or filtering only tunnel ports) where the RX and TX<br>
values would clearly indicate whether there is connectivity or not.<br>
<br>
The backend proposal includes maintaining data in Cassandra to flag<br>
broken or suspected-to-be-broken tunnels. This data could be exposed<br>
through an API call such as:<br>
<br>
GET failing nodes<br>
- Returns a Collection<TunnelHealthAlert> where each TunnelHealthAlert<br>
  contains<br>
  - HostId, PeerHostId, TunnelPortId and Counter. Where Counter is the<br>
    number of consecutive checks without Host with id <hostId> receiving<br>
    data from Host with id <PeerHostId>.<br>
  - Only tunnels with >0 errors will be returned, all others can be<br>
    assumed healthy<br>
- If considered useful, the GET could accept optional filters such as<br>
  HostId (show only tunnels from/to <HostId>)<br>
<br>
It'd be convenient to offer users the option to take corrective actions<br>
on tunnels with no connectivity. This would avoid the need to restat MM<br>
as seen in the Netflix PoC. The simplest of these actions would be<br>
offered by an API call:<br>
<br>
POST: request recreation of tunnel betweeh hostId1 and hostId2<br>
- Receives both hostIds as parameters<br>
<br>
Some questions regarding needs for the GUI:<br>
<br>
* Q: Do we want to be able to enable/disable tunnel health checks<br>
  altogether?<br>
* Q: Do we care about zones?<br>
<br>
## Backend changes<br>
<br>
The idea would be to have a component (which I'll call here<br>
TunnelDoc) in each MM agent that monitors the state of its tunnels<br>
FROM the peer to itself. This component will use the metrics published<br>
for each port to evaluate the connectivity from each peer to its own<br>
host.<br>
<br>
Let's say we have two peers A, B connected by a tunnel<br>
<br>
- TunnelPorts become active on each side of the tunnel, the TunnelDoc<br>
  becomes aware of local ports and starts taking care of them.<br>
- Regularly, for each cared-for tunnel the TunnelDoc:<br>
    - Sends a packet to the other peer<br>
    - Logs variation on RX value of the PortStats on the tunnel's local port.<br>
    - If variation = 0, increment a "no-increment" counter<br>
    - If "no-increment" counter > threshold, trigger alert message for<br>
      lack of connectivity on the REVERSE direction of the tunnel (e.g.:<br>
      if the TunnelDoc at A spots no RX, the alert refers to loss of<br>
      connectivity from B to A).<br>
    - Implement whatever corrective measures upon receiving the alert<br>
      (typically, the DatapathController could recreate the tunnel)<br></blockquote><div><br></div><div style><br></div><div style>This is not a lot of extra traffic, but the number of tunnels does grow quadratically with the number of MM agents. I propose a slight variation on the above to avoid sending traffic on non-idle tunnels, along the lines of what is done by IPsec's dead peer detection:</div>
<div style><br></div><div style><a href="http://www.ietf.org/rfc/rfc3706.txt">http://www.ietf.org/rfc/rfc3706.txt</a><br></div><div style><br></div><div style>Basically, from the POV of view of one of the nodes, it looks like this:</div>
<div style><br></div><div style>   * Monitor idleness (by looking at RX as you outline above) and do nothing and consider the tunnel healthy while idleness doesn't go above a certain threshold.</div><div style>   * When the tunnel becomes idle, send an "are-you-there" packet to the Peer (we could just use the tunnel-key for this).</div>
<div style>   * When an "are-you-there" packet is received, reply to it with an Ack.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

The counters described above would be stored in a common data structure<br>
in Cassandra so that API clients could easily retrieve the list of<br>
failing tunnels as described above.<br></blockquote><div><br></div><div><br></div><div style>I wonder why Cassandra and not Zookeeper?</div><div style><br></div><div style>Cheers,</div><div style>G</div><div><br></div><div>
 </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Thanks!<br>
<span class=""><font color="#888888">/g<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">-- Guillermo Ontañón</div>
</div></div>