Latency issues with sustained data transfers over WAN

Unanswered Question

This is kind of a WAN issue and kind of a VPN issue, so hopefully I'm posting this in the right area.

I have two sites:

  • Site A:  Cisco ASA 5510 with 6Mb connection to the Internet
  • Site B:  Cisco 2801 with T1 connection to the internet

Site A and B are connected with a L2L IPSEC VPN.

The problem I'm having is that whenever a sustained data transfer is sent over the VPN (from Site A to B) the bandwidth usage hits the roof and the packet latency jumps from about 8ms to 400ms.

I've read about this sort of thing happening with an inappropriately sized TCP Window, however I don't see any options on the ASA to adjust the TCP Window size.  I kind of think it has something to do with thedisparate Internet connection speeds on both ends but there doesn't seem to be any bandwidth-shaping options for the VPN connection on the ASA.

At Site B I've replace the router (Cisco 1721 with a 2801) and the CSU/DSU WIC in the routers to no avail.

Any ideas or suggestions would be appreciated - Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Edison Ortiz Mon, 07/19/2010 - 11:50
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

Get that old router (1721) to Site A and build a site-to-site tunnel with QoS limiting the speed to 1.5Mbps

Just have the ASA on Site A for general FW duties.



Well, I've made some changes and have had limited success.

First of all, I took the essence of Ortiz's suggestion and reconfigured my network a bit.

The basic structure is now:
Remote site (connected with VPN) --> Internet ---> ASA 5510 ---> Cisco 2801 ---> Internal network

I'd be happy to post a more verbose Visio drawing of this if y'all need a clearer picture.

Now I can now terminate the VPN on the ASA or the 2801.  So while I was doing some research about configuring QoS on the 2801 I found information about configuring QoS on the ASA and I got to wondering "Can I terminate a L2L VPN on a VLAN and then create a QoS policy map to restrict the bandwidth on that VLAN interface?" and it turns out that I can.

So I decided to keep the VPN on the ASA rather than the 2801 and do the VLAN w/ QoS thing I just described:

interface Ethernet0/0.1
vlan 1
nameif vlan_RemoteSiteVPN
security-level 0
ip address

global (vlan_RemoteSiteVPN) 1 interface

class-map RemoteSite_Class-map
match tunnel-group
match flow ip destination-address

policy-map VPN-QoS_RemoteSite
  class RemoteSite_Class-map
  police output 1572500
service-policy VPN-QoS_RemoteSite interface vlan_RemoteSiteVPN

(1572500 is roughly 1.49Mb)

After all of this the VPN works however I still have my original issue where the bandwidth gets saturated and the latecy hits the roof when there's sustained data transfer.

Am I doing something wrong with my policy map on the ASA?  Or am I just better off terminating the VPN the 2801 and QoS'ing from there?


I think I've resolved my issue.

I had to ditch the vlan-config thing.  I'm pretty confident that I could have gotten it to work but applying the policy-map to the outside interface seems to have accomplished the goal without affecting the other traffic that isn't bound for the remote site.

Here's the configuration I settled on:

class-map RemoteSiteVPN_class-map

match tunnel-group

match flow ip destination-address


class RemoteSiteVPN_class-map class-map

police output 1258290 209715

service-policyVPN_QoS interface outside

After applying this config and resetting the VPN connection I copied a file to a server at the remote site and the latency initially jumped up to ~400ms but after about 5 pings or so it settled down to a reasonable level.  I think I just need to fine-tune the "police output" directive and it'll be perfect.

Pavol Golis Mon, 08/30/2010 - 14:13
User Badges:
  • Cisco Employee,

Policing is just one option little but too radical, you got delay as your packets were stuck in queues awaiting transfer. You can try to adjust "queue-limit" of your QoS classes, (lower packets queued = lower waiting time = lower delay)

Correct me if I'm wrong but the "queue-limit" option can only be used with priority-queuing, not policing?  What would be the advantage of priority-queuing?  In my situation there's no voice going over the line; it's all TCP-based data replication from file and database servers.  So It seems that it would be a pain to classify and prioritize all the different types of data from their various ports.  Unless I'm mistaken, policing creates an upper-bound limit on the bandwidth that all data going over the line is subject too.

That said there is a source of data that is sent over the line that is more important than everything else.  Ideally I would like to give that data priority over everything else, but I would still need to shape the bandwidth.  Can policing and priority be used together on the same tunnel-group?


Well I'm still battling this issue.  The policing keeps the link from getting saturated but for some reason my database replication still gets behind if any other data is being pushed over the line.  When the db replication gets behind too much it locks up of our ERP system and then none of the phone reps can take orders.  Obviously this is bad.

The db replication is a block-level, one-way sync so it's not like it's pushing tons of data over the line.

I've tried priority queuing but the replication uses a range of ports (3000-3100) which doesn't seem to be configurable.  Not to mention that you can't match an access-list and a tunnel-group on a class map.

Does anyone have any ideas or suggestions?


This Discussion

Related Content