ASA 5505 QoS latency...

[Dustin Barnett]

I am working with a single T1 connection, and I have configured policing rules to police any user at 500000. This seems to be working well, the problem is that whenever something is being downloaded, latency is terrible, even though I am watching the ASDM bandwidth graph and it appears to be limiting the connection to 500000!

This causes problems because we have a lot of workstations that access a remote network through an ipsec tunnel using both RDP and 2X connections, and it is very noticiable when something is being downloaded/uploaded to the internet. . I've added those ports as priority, but it doesn't seem to help. Is the problem that we just need more bandwidth, or would shaping help?

Here is the configuration:

access-list outside_mpc extended permit ip any any time-range Daily_0600-1900
access-list outside_mpc_3 extended permit tcp any 192.168.50.0 255.255.255.0 eq www

class-map rdp-priority
match port tcp eq 3389
class-map 2X-80-priority
match access-list outside_mpc_3
class-map outside-class
match access-list outside_mpc
!
!
policy-map outside-policy
class rdp-priority
  priority
class 2X-80-priority
  priority
class outside-class
  police input 500000 1500
  police output 500000 1500
policy-map global-policy
class netflow
  flow-export event-type all destination exchange
!
service-policy global-policy global
service-policy outside-policy interface outside

[Marcin Latosiewicz · Accepted solution]

Dustin,

First of all I would monitor if you latency is related to drops in QoS or come for a different place (an example you would be ingress buffer on physical interface filling up).

Monitoring "show service-policy" during high drop period would be the way to go.

What I would suggest overall is not to police by use traffic shaping (hierarchical QoS)

An example is here:

http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/conns_qos.html#wp1074879

Which should be more appropriate in your scenario.

As for the parameters to use, well there will be a bit of experimenting.

Marcin

[Dustin Barnett]

Thanks, I'll look into traffic shaping and go from there.

[Dustin Barnett]

Hi Marcin,

I have been reading about hierarchical priority queuing, and I've noticed that IPsec over TCP is not supported. What will this mean, since we have an IPsec tunnel that we want to give traffic priority on?

[Marcin Latosiewicz]

Dustin,

Well indeed option are slim as far as CLASSIFICATION goes, you cannot do anything decent to IPsec over TCP (but that's a rare deployment, are you actually using it? cTCP or Transport - IPsec over TCP it's called).

The first restriction is specifying this option "match tunnel-group Tunnel-Group-1"

You will either need to perform DSCP tagging/coloring before traffic gets into the tunnel or not use shaping if you need to police inside the tunnel.

What could otherwise work for you is a combination of traffic shaping and policing.

Something like this.

Defining traffic including traffic over FAKE_VPN tunnel.

class-map VOIP
 match rtp 16384 16383
class-map FAKE_VPN
 match flow ip destination-address
 match tunnel-group FAKE_VPN

Now creating child policy for VOIP.

policy-map VOIP
 class VOIP
  priority

And applying it into the big policy like so.

policy-map MIXED_POLICY
 class FAKE_VPN
  police output 512000
 class class-default
  shape average 1024000
  service-policy VOIP

And than of course:

service-policy MIXED_POLICY interface outside
priority-queue outside

Just a thought ;-)

Marcin