cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
259
Views
0
Helpful
2
Replies
Highlighted
Beginner

Qos Traffic Question

                  I have a question about using both Qos and traffic shaping. Is it smart to use both?  I  though using the rate limit bypasses the Qos settings which makes it worst on the traffic. Should you just use one?  Does the rate limit take a higher priority then the QoS if it configured like this?


class-map match-any VoIP-Signaling-and-Citrix
match ip dscp af31
match ip dscp cs3
match access-group name CitrixServers
class-map match-any CitrixApps
match access-group name CitrixServers
class-map match-all VoIP-Traffic
match ip dscp ef
class-map match-any VoIP-Signaling
match ip dscp af31
match ip dscp cs3
class-map match-any BillingApps
match access-group name BillingServers
!
!
policy-map MARK-COS2
class VoIP-Signaling
class CitrixApps
  set ip dscp af32
policy-map VoIP-QoS
class VoIP-Traffic
    priority percent 20
class VoIP-Signaling-and-Citrix
    bandwidth remaining percent 40
  service-policy MARK-COS2
class BillingApps
    bandwidth remaining percent 30
  set ip dscp af21
class class-default
    fair-queue
    random-detect dscp-based

interface Serial0/0/0
bandwidth 1536
ip address 10.X.X.X X.X.X.X
ip flow ingress
ip flow egress
rate-limit input access-group 101 200000 37500 37500 conform-action transmit exceed-action drop
encapsulation ppp
tx-ring-limit 1
tx-queue-limit 1
no cdp enable
service-policy output VoIP-QoS
!
ip access-list extended BillingServers
permit ip any host 10.X.X.X
permit ip any host 10.X.X.X
ip access-list extended CitrixServers
permit ip any host 10.X.X.X
permit ip any 10.0.X.X X.X.X.X
permit ip any host 10.X.X.X
!
access-list 101 permit ip host 10.X.X.X
access-list 101 permit ip host 10.X.X.X
access-list 101 permit ip host 10.X.X.X
access-list 101 permit ip host 10.X.X.X
access-list 101 permit ip any host 10.X.X.X
access-list 101 permit ip any host 10.X.X.X
access-list 101 permit ip any host 10.X.X.X

2 REPLIES 2
Highlighted
Participant

hello Jay,

Yes you can use both Qos and shaping traffic.

If you are using qos then it will divide the bandwidth according to its default behavior. But it shaping you will reserve some bandwidth for one queue and others cant have it even there is no traffic.

You can either use share so all the queues can share bandwidth .

In the rate limit you just limiting to cretin Mb and if there is congestion then it will start dropping packets.

Please check this doc for more details.

Please rate if this helps.

thanks

Highlighted
VIP Expert

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

Your rate-limiter is not a shaper.

Unsure all combinations of an interface defined rate-limiter are valid with a service policy, but in this instance it makes sense as this configured rate-limiter only acts upon ingress traffic and your service policy is configured for egress.  I.e. they are not acting on the same traffic.

Yes, using a shaper with QoS often makes much sense.  Using a rate-limiter (or policer) with QoS is often driven more by configuration placement or device limitations.  (Note: rate-limiting can be done upon ingress or egress, a shaper only upon egress; some platforms will support rate-limiting but not shaping.)

In your config snippet, I'm guessing the rate-limiter is trying allow some bandwidth for traffic to hosts other than those listed in ACL 101.  Generally, a better way method than limiting some ingress bandwidth would be to define an egress policy on the other side of your serial link.

The major issues policing ingress traffic, as seen in this example, are non-rate-adaptive traffic can still congest the serial link upstream of the policer, or even if rate-adaptive, it may burst above the rate limits (also creating temporary link congestion).

Content for Community-Ad