Hi all, <div><br></div><div>I agree that the results will need to be stored in Cassandra, for what Galo said, the metrics are there and the GUI already knows how to get them. </div><div><br></div><div>About this 'are you there' problem. I wonder if we could use zookeeper's ephemeral nodes. This nodes exist in zookeeper as long as the session who created them still exists. We could create a znode for every tunnel, tied to the session. If a tunnel disappears or stops working the ephemeral node disappears (don't know how, we should see the details here). There could be some watchers set in place to notify the responsible for the tunnel recreation. </div>
<div><br><br><div class="gmail_quote">On Tue, Feb 19, 2013 at 5:27 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Just to clarify after talking w. Guillermo:<br>
<br>
Even though we don't need to active listen for an ACK received (for<br>
the reasons explained before), we do need to implement a mechanism to<br>
receive and reply to "are-you-there" messages received on one side of<br>
the tunnel.<br>
<span class="HOEnZb"><font color="#888888"><br>
/g<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 19 February 2013 16:50, Navarro, Galo <<a href="mailto:galo@midokura.jp">galo@midokura.jp</a>> wrote:<br>
> On 19 February 2013 16:31, Guillermo Ontañón <<a href="mailto:guillermo@midokura.jp">guillermo@midokura.jp</a>> wrote:<br>
>> On Tue, Feb 19, 2013 at 4:21 PM, Navarro, Galo <<a href="mailto:galo@midokura.jp">galo@midokura.jp</a>> wrote:<br>
>>><br>
>>> Hi Guillermo, thanks for the quick feedback! Some comments below<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<br>
>>> >> 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<br>
>>> >> (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>
>>><br>
>>> > This is not a lot of extra traffic, but the number of tunnels does grow<br>
>>> > quadratically with the number of MM agents. I propose a slight variation<br>
>>> > on<br>
>>> > the above to avoid sending traffic on non-idle tunnels, along the lines<br>
>>> > of<br>
>>> > what is done by IPsec's dead peer detection:<br>
>>> ><br>
>>> > <a href="http://www.ietf.org/rfc/rfc3706.txt" target="_blank">http://www.ietf.org/rfc/rfc3706.txt</a><br>
>>> ><br>
>>> > Basically, from the POV of view of one of the nodes, it looks like this:<br>
>>> ><br>
>>> >    * Monitor idleness (by looking at RX as you outline above) and do<br>
>>> > nothing<br>
>>> > and consider the tunnel healthy while idleness doesn't go above a<br>
>>> > certain<br>
>>> > threshold.<br>
>>> >    * When the tunnel becomes idle, send an "are-you-there" packet to the<br>
>>> > Peer (we could just use the tunnel-key for this).<br>
>>> >    * When an "are-you-there" packet is received, reply to it with an<br>
>>> > Ack.<br>
>>><br>
>>> This is definitely better. I messed up copypastes badly but the idea<br>
>>> was basically what you explain, the "send packet to another peer"<br>
>>> would be conditioned to several cycles without increment on the<br>
>>> "no-data-increment" counter.<br>
>><br>
>><br>
>><br>
>> But I think that for this to work you need the 'ack' reply, would it be<br>
>> included? Otherwise a host may be receiving traffic (non-idle) but not<br>
>> sending, and would never send any 'are-you-there' packets to the other side<br>
>> because its RX is increasing.<br>
><br>
> But note that A is only monitoring *incoming* connectivity (B->A).<br>
> This is because once the packet leaves A it's agent can tell that<br>
> something is broken in the line, but not in what direction (is PING<br>
> lost bc. A->B is cut, or ACK lost because B->A is cut?). We need to<br>
> report health of each direction.<br>
><br>
> So, A doesn't care about A->B. It only asserts that data is arriving<br>
> from B. With this in mind, once A's agent sends the "are-you-there"<br>
> message it doesn't really need to pay attention to the ACK.<br>
><br>
> From the other side, B will do the same in reverse. If the<br>
> "are-you-there" never arrives because A->B is broken, B will notice<br>
> the static rx count and start a health check of the A->B direction.<br>
><br>
> Does that make sense?<br>
> /g<br>
</div></div></blockquote></div><br></div>