06-07-2010 01:26 PM - edited 03-04-2019 08:42 AM
I'm sure this will be simple for most of you. I just have never done it. We have an MPLS WAN and we qos various traffic into Normal, Priority, Critical, Video and Voice planes based on default qos markings or ip address.
I have a couple servers that are currently in the Bulk "Normal" ACL. However too often I see them consuming 95% of a t-1 and it concerns me. What I want to do is, in addition to having them in the bulk "normal" plane I want to limit there utilization to a certain percent of the circuit regardless of what else is happening. So, ultimately I want to say, 'you server x.x.x.x you will be in the lowest MPLS QOS plane and no matter what you will not get more than 30% of the circuit'.
The problem traffic is Microsoft SMS and Anti Virus updates.
Here are our current qos config and the associated ACL's.
class-map match-any CLASS-CALL-SIGNALING
match ip dscp cs3
match ip dscp af31
class-map match-any CLASS-VIDEO
match ip dscp af41
class-map match-all CLASS-VOICE
match ip dscp ef
class-map match-all CLASS-PRIORITY-DATA
match not access-group name ACL-BULK-DATA
match ip dscp default
class-map match-any CLASS-CRITICAL-DATA
match access-group name ACL-CRITICAL-DATA
!
!
policy-map QOS-P2P-OUT
class CLASS-VOICE
priority 384
class CLASS-VIDEO
priority 448
class CLASS-CALL-SIGNALING
priority 32
class CLASS-CRITICAL-DATA
set ip dscp cs2
bandwidth remaining percent 10
random-detect dscp-based
class CLASS-PRIORITY-DATA
set ip dscp af11
bandwidth remaining percent 85
random-detect dscp-based
class class-default
bandwidth remaining percent 5
random-detect dscp-based
policy-map QOS-MASERGY-OUT
class CLASS-CRITICAL-DATA
set ip dscp cs2
class CLASS-PRIORITY-DATA
set ip dscp af11
class CLASS-CALL-SIGNALING
set ip dscp ef
***************************************************************************************
ip access-list extended ACL-BULK-DATA
permit ip any host 10.1.12.121
permit ip any host 10.1.12.35
permit ip any host 10.1.12.67
permit ip any host 10.1.12.68
permit ip any host 10.1.12.69
permit ip any host 10.1.12.70
permit ip any host 10.1.30.11
permit tcp any any eq ftp
permit tcp any any eq ftp-data
permit ip any host 10.1.30.93
permit ip any host 10.11.19.30
permit ip any host 10.11.19.31
ip access-list extended ACL-CRITICAL-DATA
permit udp any host 10.1.12.229 eq tftp
permit udp any host 10.1.12.229 eq snmp
permit udp any host 10.1.12.229 eq syslog
permit icmp any host 10.1.12.229
permit udp any any eq tacacs
permit tcp any any eq 22
permit tcp any any eq telnet
permit tcp any host 10.1.20.41 eq 8088
permit tcp any host 10.1.20.41 eq 37350
permit tcp any host 10.1.20.41 eq 38983
permit tcp any host 10.1.20.41 eq 59000
permit tcp any host 10.1.20.41 eq 59003
permit tcp any host 10.1.20.41 eq 59004
permit tcp any host 10.1.20.41 eq 59010
permit tcp any host 10.1.20.41 eq 59011
permit tcp any host 10.1.20.41 eq 59012
permit tcp any host 10.1.20.41 eq 59020
permit tcp any host 10.1.20.41 eq 59021
permit tcp any host 10.1.20.41 eq 65432
Thanks for any advice you have on this issue.
06-07-2010 02:07 PM
Create a class-map that matches an ACL that includes those IP addresses as interesting traffic.
Then attach that class-map to your policy-map with a policing action of 30% of your WAN port.
Regards
Edison
06-07-2010 02:13 PM
I think the approach you are taking now is a good one.
If the service provider has a proper egress queuing mechanism in place the PE facing your remote site should dynamically allocate bandwidth; shrinking the bulk queue as necessary to accommodate priority data traffic.
However if you want to police certain servers in order to protect low bandwidth remote site links the best place may be an ingress policing policy on the remote site CE. This isn’t the most scalable solution because it involves configuration adjustments across all remote site CE’s.
The problem with attempting a CE egress policing policy on your data center site is that a high traffic data center server may need to service several remote sites simultaneously. The policy could create poor service for all, not just the one remote site that has a saturated T1.
As far as setting a percentage that can be done with CBWFQ, but it’s never a hard limit as queues are allocated bandwidth dynamically based on usage across all queues. When I have to get tough with say, an Exchange server that’s abusing the WAN I use a hard policing policy on the interface with the following command in interface config mode.
rate-limit {input | output} {bps | access-group acl-index | [rate-limit] rate-limit-acl-index] | dscp dscp-value | qos-group qos-group-number} burst-normal burst-max conform-action conform-action exceed-action exceed-action
Christopher Gatlin
06-07-2010 02:24 PM
Thanks, Both excellent ideas. I'll work through them and see what results I get.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide