- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-15-2011 11:26 AM - edited 03-11-2019 01:21 PM
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
Solved! Go to Solution.
- Labels:
-
NGFW Firewalls
Accepted Solutions

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-16-2011 08:19 AM
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

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-16-2011 08:19 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-18-2011 11:34 AM
Thanks, I'll look into traffic shaping and go from there.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-19-2011 08:45 AM
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?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-19-2011 10:18 AM
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
