Kalyani Garigipati wrote: >> One obvious approach would be not to sync after every exchange >> (that could be a lot of messages), but sync, say, every N seconds >> (say, N=5) in one big batch (for all IKE_SAs that changed in the >> last N seconds). > > <Kalyani> If sync is done in batches and if active device crashes > between the interval sync of the batches, then we again see the same > message Id issue.
Yes; so N can't be very large. > If dpd is enabled then ikev2 counters keep updated frequently. This depends on how often you do DPD... Obviously, you want dead IKE_SAs to go away eventually, but e.g. 30 minute DPD interval would be sufficient for that. If your DPD interval was close to the value of N, that would not work well... but on the other hand, if you have lot of traffic going back and forth, IKEv2 DPD won't get triggered.. > Hence we cannot rule out the possibility of out of sync between > stand by and active device with the above approach. We cannot rule out this possibility with any approach, I think. >> Most of the time, almost all IKE_SAs are just sitting there idle >> (so IKEv2 message ID counters don't change). In case of failure, >> the stand-by device would have out-of-date information for some >> small percentage of IKE_SAs (those whose counters changed since >> last sync) , but that's always going to be the case (for exchanges >> where something more happened just before/during the failure). > > <Kalyani> With HA, we want to ensure the maximum avoidance of out > of sync. In any case of out of sync, the retransmission of messages > should take care of the exchanges. In the worst case the SA will > have to deleted (which is the case Currently now for IKEV2 when > windowing is used and some requests are lost ) Yes. But this worst case cannot be avoided (since the worst case can occur due to other reasons than message IDs) -- it can be just made less likely to happen. >> I haven't done the math, though, so I don't know what value of N >> would result in both acceptable bandwidth and acceptable failure >> rate for the stand-by (depends on how many messages your typical >> IKE_SAs have per hour on average)... > > <Kalyani > we might like the solution to work in all cases of > exchange frequency, hence I think we cannot fix N. I agree; clearly N would be a configurable parameter, not something fixed in some spec. Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
