From: KOVACS Krisztian <hidden@balabit.hu>
To: hadi@cyberus.ca
Cc: netdev@oss.sgi.com, ipsec-tools-devel@lists.sourceforge.net,
vpn-failover@lists.balabit.hu
Subject: Re: [RFC] IPSEC failover and replay detection sequence numbers
Date: Fri, 29 Oct 2004 18:15:47 +0200 [thread overview]
Message-ID: <41826CB3.2080306@balabit.hu> (raw)
In-Reply-To: <1099062095.1023.14.camel@jzny.localdomain>
Hi,
jamal wrote:
> 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.
Definitely.
>> 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?
Of course! I think it is a must, especially if we use such tiny
messages. But this is dependant on the user-space code of course.
> 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.
I think a dedicated 100mbps/1Gbps interface is not a problem anyway...
>>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.
Agreed. However, for the initial tests I chose pfkey because racoon
uses pfkey only, so it would be good enough for me as a prototype. I
think it would not be too much work to implement the netlink interface
as well - with batching included.
--
Regards,
Krisztian KOVACS
next prev parent reply other threads:[~2004-10-29 16:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-29 10:23 [RFC] IPSEC failover and replay detection sequence numbers KOVACS Krisztian
2004-10-29 12:58 ` jamal
2004-10-29 13:24 ` KOVACS Krisztian
2004-10-29 15:01 ` jamal
2004-10-29 16:15 ` KOVACS Krisztian [this message]
2004-11-07 17:42 ` Michael Richardson
2004-11-04 14:01 ` [Vpn-failover] [RFC] IPSEC failover - Netlink part Ulrich Weber
2004-11-04 18:15 ` Patrick McHardy
2004-11-08 10:31 ` Ulrich Weber
2004-11-08 16:10 ` Patrick McHardy
2004-11-09 8:55 ` Ulrich Weber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41826CB3.2080306@balabit.hu \
--to=hidden@balabit.hu \
--cc=hadi@cyberus.ca \
--cc=ipsec-tools-devel@lists.sourceforge.net \
--cc=netdev@oss.sgi.com \
--cc=vpn-failover@lists.balabit.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.