On Fri, 2004-10-29 at 09:24, KOVACS Krisztian wrote:

  Hi,

2004-10-29, p keltezéssel 14:58-kor jamal ezt írta:

quoted

To take a rough estimate of 5K users, how often do you think
these replay messages will be generated?

Is there a (clever) way to avoid transporting them and still achieve
an accurate failover?

  There is, provided that you do not want replay detection to work after
a failover. The more often you would send sequence number updates the
smaller the possible replay window will be. If you sacrifice scalability
you get more accurate replay detection.

ok. It should still get better in a short period of time though.
Moral in my point is i hope you make it an optional feature.

  To play with numbers: say that you have 5K users, so let's suppose
there are at most 20K IPSEC SAs. If you decide to send an update per
second, that would mean 20K updates/second. If each update message is 20
bytes long, that means that on Ethernet you can transmit all of them in
about 280 packets. 

Are you batching? 
In my count: Assuming 20bytes is in a packet of its own - your numbers
translate to 20Kpps which is > 10Mbps ;-> 
I suppose SAs will be much lower rate. So you need probably a dedicated
100Mbps just for the syncing. I would also say SA updates should be
prioritized over replay messages.

That's not too much. (I suppose the 20K pfkey
messages would be much more of a problem, though...)

Why not use the netlink events (you mention pfkey).

Batching them with a timeout should help.

cheers,
jamal