[nsp] IPSEC throughput impact?
Steve Francis
sfrancis at fastclick.com
Tue Jul 6 14:51:47 EDT 2004
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
> Streiner, Justin
> Sent: Tuesday, July 06, 2004 10:55 AM
> To: cisco-nsp at puck.nether.net
> Subject: [nsp] IPSEC throughput impact?
>
> The 3 T1s
> are running CEF per-packet load-sharing on both sides and are
> short-haul only, so I feel pretty confident in ruling out RTT
> variance across the 3 circuits interfering with the
> load-sharing and eventual packet reassembly/decryption in this case.
I wouldn't feel so confident of that. IPSec packets have to arrive in
order of sequence number, or they are discarded, and rely on the upper
layer protocol (whatever is encapsulated) to timeout and resend.
I'd guess that is what is happening.
>
> The customer sees throughput of about 2.1 Mb/s across the T1s
> with the VPN traffic routed across them.
>
> When we let the site-to-site traffic flow across the
> Internet, their throughput across the VPN doubles to about 4
> Mb/s. Oddly enough, they don't appear to come close to
> maxing out the T1s during our testing - maybe leaking out at
> 50-60% usage. I can access the test server on their network
> with or without the VPN, and when I access it without the
> VPN, the throughput is about 3x higher than when I connect to
> their VPN. This is with the site-to-site traffic going
> across the Internet in both directions.
>
> Beyond the overhead of the encryption itself, and perhaps
> some choke point on the path of the T1s, I'm at a loss to
> explain the large loss of throughput.
>
> I understand the size of the original unencrypted packet will
> factor greatly into the throughput measurements since a large
> original packet may need to be broken up into two IPSEC
> packets upon encryption, and reassembled upon decryption.
>
> The VPN itself is IPSEC-3DES, using the Cisco Unity VPN client.
>
> My question is:
> Has anyone had personal experience with a similar case as far
> what kind of throughput a customer should be able to
> realistically expect over their VPN?
>
> jms
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
More information about the cisco-nsp
mailing list