• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Cisco p2p vpn limited bwidth

M

manilapoo

Junior Member
This is my first experience with site to site VPNs so bear with me on the details.

What the company is experiencing is about 500kbps maximum throughput from site to site VPN. One site has load balanced dual T1s connected to a Cisco 1760 as the border router. after this router is a IPS device and firewall filtering traffic and then a Cisco 3640 router as the VPN headend.

On the remote site is a cisco 2620 with a T1 connection along with a PIX 506E.

We are using hash MD5, 3DES and a pre-shared key to authenticate/encrypt. We have had the users at the remote site complain a few times, but only recently have I installed PRTG and actually watched the bandwidth usage. I went to dslreports and ran a speed test at each site to confirm the T1 speed and both sites were able to exceed 1300kbps on the test, however, when we transfer files or do anything over the VPN tunnel we are only able to get a measly 500kpbs max.

There doesn't seem to be any items in the VPN config as they are rather simple defining the enryption and the pre-shared key.

I have no clue what is capping this. Can anyone offer any suggestions?

 
first, check the processors on the routers involved in the tunnel. I hope the 1760 isn't a vpn endpoint.

Then it's that's not it it's highly likely that you have a fragmentation problem.

see here for an important feature called "pre-fragmentation for VPNs"

Basically your performance gets robbed because IP sec is applied to a packet resulting in it being too big for the wire (MTU), router then fragments it. This is bad. You always want to fragment the packet and THEN apply the encryptiong/tunnel.

http://www.cisco.com/en/US/products/sw/...cts_feature_guide09186a0080115533.html
 
agreed...large packets may need fragmentation because of ipsec. if this is done before encryption, you should have no problems.

if the encrypted packet is fragmented, the fragments need to be reassembled before decryption. This burdens the CPU and could be causing your slowness.

Try using GRE MTU so that fragmentation occurs before the encryption.

 
show proc cpu will tell you what the processor is up to. Run your test for about 5-10 minutes and keep checking the CPU. It will also tell you what process is using how much.

there may even be some counters to look for with show crypto
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top