Thanks for the reply Willi,<br><br>What I have seen is that replay IPsec SA counters are increased by a big number so there are no troubles with the IPsec SA counters. That's good!.. but....<br><br>But, imagine the following scenario: SG1 is  overloaded (big amounts of IKE_SA connections). If the SG1 crashes just after he has answered some IKE request and didn't have the time to synchonize this information to other members in the cluster (SG2); then SG2 must close those IKE_SAs due to unsynchronization of IKE_SA counters. I'm I right? The good point here is that just those IKE_SA message replies that couldn't be synchronized with SG2, are those which will be terminated. The rest of IKE_SA will continue working.<br>

<br>Another subject that I'm working on: IKEv2/IPsec Traffic Management.<br><br>If we focus in a different problem, we can propose to manage some IKEv2/IPsec traffic from SG1 to SG2 by using Redirect Mechanism and adding a kind of transfer of IKEv2/IPsec context between gateways as well. Of course, this is a much more research subject than an email for the "User-mailinglist" of strongSwan, but I thinks this is still interesting. ISPs will face the problem of peer mobility (mobility in terms of Access Network, not just IP as MOBIKE already does) and I was thinking in a solution to IPsec traffic management. <br>

<br>Regards<br>Daniel P<br>
<br><br><div class="gmail_quote">2012/6/29 Martin Willi <span dir="ltr"><<a href="mailto:martin@strongswan.org" target="_blank">martin@strongswan.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Daniel,<br>
<div class="im"><br>
> Is this the new feature of High Availability for IPsec RFC-6311 ?<br>
<br>
</div>Our HA solution works different and is not based on RFC 6311. In fact,<br>
we don't need any additional protocol support in IKEv2 between server<br>
and client, all the synchronization is done between the cluster nodes<br>
directly.<br>
<div class="im"><br>
> Does this patch generate IKE exchanges to increases IPsec Counters?<br>
<br>
</div>We use ClusterIP to keep the sequence counters up to date, no IKE<br>
exchange is involved. This has the big advantage that it works with any<br>
IKEv2 client.<br>
<div class="im"><br>
> I thought that the first patches didn't increase the IPsec replay<br>
> counters. Is this a new feature in ha3.3? Or since when did you<br>
> developed this capability?<br>
<br>
</div>One issue that might arise with the ClusterIP sequence update is that we<br>
might miss some packets due to packet loss. This can be problematic for<br>
outgoing packets, as the peer might reject a few packets after failover,<br>
breaking connections.<br>
<br>
As a work-around, I've implemented a "failover advance" mechanism with<br>
these last two commits: After a failover, we advance the replay counter<br>
for outgoing messages by a certain window. This will make sure we don't<br>
use sequence numbers for packets already processed by the responder.<br>
Doesn't change anything fundamental, but certainly can improve<br>
connection reliability after a failover.<br>
<br>
Regards<br>
<span class="HOEnZb"><font color="#888888">Martin<br>
<br>
</font></span></blockquote></div><br>