Ang: RE: [VPN] IPsec performance just 55% of WAN bandwidth

hakan.palm at generic.se hakan.palm at generic.se
Mon Jul 21 04:11:47 EDT 2003


Ryan,

have you tried lowering the MTU? Either using
any of the available utilities or your old friend
regedit.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Interfaces
\[Adapter ID]

Create or edit the DWORD MTU and set it to
something like 1400 or so. Make sure you use
decimal and not hex... >)

HTH

Regards,
/Palm





	rmalayter at bai.org
2003-07-17 20:29
		
	Till:	djdawso at qwest.com @ INTERNET
	Kopia:	vpn at lists.shmoo.com @ INTERNET, (Blank: Hakan Palm/Generic)
	Ärende:	RE: [VPN] IPsec performance just 55% of WAN bandwidth

Thanks for the quick reply... Dana, these are actually Qwest T1s in
downtown Chicago, the Sonicwall end being our financial district offices
and the other being our cage at the Qwest CyberCenter down by McCormick
place.

Zero-data-byte pings average 13.25 ms, which, according to your formula,
should give me a theoretical max throughput of over 10 mbps. The VPN
seems to add only about 3ms of latency versus an open connection, so I
don't think that is the problem: I get the full 3 Mbps bandwidth on an
unencrypted 10ms latency connection.

Besides, don't Windows 2000 and newer have a much better sliding TCP
window size algorithm? I don't think it's a fixed window anymore. I
mean, we routinely see TCP/IP throughput >> 100 Mbps on our gigabit
links, even though latency is nonzero.

Thanks for any further ideas,
	-Ryan-

-----Original Message-----
From: Dana J. Dawson [mailto:djdawso at qwest.com]
Sent: Thursday, July 17, 2003 12:01 PM
To: Ryan Malayter
Cc: vpn at lists.shmoo.com
Subject: Re: [VPN] IPsec performance just 55% of WAN bandwidth


What kind of ping response times are you seeing across the VPN (use the
smallest
ping size you can for this test)?  The reason I ask is that it's
possible you're
seeing a TCP Windowing throughput limitation.  With a TCP window size of
17.5
KBytes (a common MS Windows TCP Window size), a round trip time of
around 83
msecs will limit any single TCP session to 1.68 Mbits/sec.  With the
older 8760
Byte window size (used in older versions of Windows NT), the round trip
time
that limits you to 1.68 Mbits/sec drops to about 42 msec.  If your ping
times
are in this range, then you may be seeing this limit.  If they're
significantly
shorter than this, then this is not the problem.  By the way, the
formula for
computing this is:

    Round_Trip_Time = Window_Size / Max_Throughput

where the Round_Trip_Time is in seconds, Window_Size is in bits (Bytes *
8), and
Max_Throughput is in bits/second.

HTH

Dana

--

Dana J. Dawson                     djdawso at qwest.com
Senior Staff Engineer              CCIE #1937
Qwest Communications               (612) 664-3364
600 Stinson Blvd., Suite 1S        (612) 664-4779 (FAX)
Minneapolis  MN  55413-2620

"Hard is where the money is."



Ryan Malayter wrote:

> We have an IPsec tunnel set up between two sites. The physical layer
> in-between VPN endpoints consists of one 2xT1 multiplexed link,
followed
> by three hops on our ISP's OC-192 backbone. One side has a Sonicwall
> Pro-VX device, the other has a Nokia Checkpoint FW-1 appliance. Both
> have triple-DES hardware assist and are rated at much higher speeds
than
> my link for VPN throughput.
>
> We've tested unencrypted speed, and we get about 2.8 Mbps aggregate
via
> HTTP or FTP over the link. However, when testing both HTTP and FTP
> between two servers via the VPN tunnel, I consistently get just 1.68
> Mbps in wither direction. I have tested multiple servers on both ends,
> at different (low-traffic) times of day.
>
> I'm wondering if this is a packet size or fragementation issue. I
cannot
> seem to find a way to adjust FTP packet size on either end (both are
> Windows 2000 servers). The largest ping I can get through the tunnel
is
>      ping -l -1418
> which I think would be a 1446-byte packet.
>
> Any ideas on how I should proceed diagnosing this performance issue?
> Neither the Sonicwall nor the Nokia device seem to have good
diagnostic
> tools built-in.
>
> Thank you for your help,
>
> Ryan Malayter
> Sr. Network & Database Administrator
> Bank Administration Institute
> Chicago, Illinois, USA
> PGP Key: http://www.malayter.com/pgp-public.txt
> :::::::::::::::::::::::::::::::
> Never argue with idiots. They drag you down to their level,
> and then beat you with experience.
> _______________________________________________
> VPN mailing list
> VPN at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/vpn
>
>

_______________________________________________
VPN mailing list
VPN at lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/vpn






More information about the VPN mailing list