Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

QoS policy - check my math :)

All,

I created the following policy:

policy-map DR

class BRANCHES

bandwidth percent 12

random-detect

police 17408000 conform-action transmit exceed-action drop

class DRTRAFFIC

bandwidth percent 60

class DALLAS

bandwidth percent 3

police 3072000 conform-action transmit exceed-action drop

class class-default

fair-queue

random-detect

This is on 100Mb connection between two locations. I want Branches to get 12mb minimum and police at 17Mb. The DR site I want to guarantee 60Mb, and the Dallas location I want to guarantee 3Mb but no more than 3Mb. Does the above look like it would work?

Thanks,

John

HTH, John *** Please rate all useful posts ***
2 ACCEPTED SOLUTIONS

Accepted Solutions
Super Bronze

Re: QoS policy - check my math :)

The bandwidth statement guarantees a minimum, i.e. you shouldn't need to police or shape unless you really need to also cap the bandwidth.

Yes, shape should work in lieu of police.

Super Bronze

Re: QoS policy - check my math :)

What I'm suggesting, if you provide minimum bandwidth guarantees for all traffic that needs it, you shouldn't need to cap any traffic. The whole idea of providing traffic minimum bandwidth guarantees is so they continue to work as needed even when the link is saturated.

I often work with WAN links that run VoIP, vidconferencing, mission critical business apps, normal business apps and system backups. Such links might run at 100% utilization (generally due to system backups) for hours (and during normal business hours), yet QoS allows all the other apps to function as if the backup wasn't running.

If your QoS can insure traffic does obtain the proportion of bandwidth the application needs when there's congestion, there generally little need to cap bandwidth for any traffic.

So you might try:

policy-map TOGO

class SENDDALLAS

bandwidth percent 1

class BRANCHES

bandwidth percent 7

class DRTRAFFIC

bandwidth percent 30

class class-default

bandwidth percent 10

(NB: if your wondering about the reduced percentages, it's the ratios that are really used [they set flow weights], and it also avoids busting the reserved bandwidth setting [remaining percent is another nicer option - if supported by the IOS] along with be easier to use on other bandwidth capacity links.)

[edit]

PS:

BTW, with QoS link "saturation" often isn't the issue it is without QoS.

11 REPLIES
Hall of Fame Super Silver

Re: QoS policy - check my math :)

Hello John,

I've never combined police action with bandwidth action on same policy-map.

I would police on ingress LAN interfaces if really needed with different policy-maps applied inbound on those interfaces.

On outgoing "WAN" interface I would apply a scheduler.

this would provide the advantage of an easier reading of sh policy-map interface type x/y or equivalent SNMP MIB variables.

CBWFQ is elastic in nature and allows unused resources to be used by other traffic classes.

So I don't usually consider to police on outbound interface.

You could for example use a priority command for DR traffic just to make an example, to be sure it will not compete with other traffic classes when the link is fully used.

Edit:

I've realized that I didn't answered your question about the math.

From this point of view it looks like correct (not sure if rates may have to be multiple of 64 kbps or other constraints but these are platform dependent).

Hope to help

Giuseppe

Re: QoS policy - check my math :)

Thanks Giuseppe. So I should police inbound on the LAN side on both sides of the link to the max bandwidth that I want to allow, and then use RED or something like that on the outside to match the transmitted traffic?

HTH, John *** Please rate all useful posts ***
Super Bronze

Re: QoS policy - check my math :)

Would it work as intended? Possibly not because on many platforms/IOSs, FQ within class-default can disturb other class bandwidth allocations. This can be addressed by not using FQ within class-default or using 12.4(20)T or later HQF QoS.

Otherwise, like Giuseppe, I would recommend against using a policer. If you guarantee class minimums, why cap a class if the bandwidth is otherwise available and not being used? If you do need to cap traffic, I often prefer a shaper. Also, if your IOS supports it, you might see if the policer supports percentages rather than absolute values.

Re: QoS policy - check my math :)

Joseph,

If I want to guarantee the traffic for a minimum, should I shape instead of the policing, and would shape work in the same policy map?

Thanks,

John

HTH, John *** Please rate all useful posts ***

Re: QoS policy - check my math :)

Does this one look better?

policy-map TOGO

class SENDDALLAS

shape average 3072000

class BRANCHES

shape average 17408000

class DRTRAFFIC

priority percent 60

class class-default

policy-map MARKTRAFFIC

class DALLAS

set dscp af23

int fa0/0.175

service input MARKTRAFFIC

int fa0/1

service output TOGO

Thanks!

HTH, John *** Please rate all useful posts ***
Super Bronze

Re: QoS policy - check my math :)

No, for a several reasons. You should still use the bandwidth statement to define the minimum bandwidth. Removing the FQ statement within class-default, on many platforms, it's still FQ. I'm not too keen placing DR traffic into LLQ.

Re: QoS policy - check my math :)

How would you treat the DR traffic? I need to keep the DR traffic from saturating the link, but at the same time I need to make sure it gets a minimum to replicate correctly. This is a continuation of what you helped me with a couple of weeks ago.

Thanks,

John

HTH, John *** Please rate all useful posts ***
Super Bronze

Re: QoS policy - check my math :)

The minimum bandwidth for correct replication is guaranteed by the class bandwidth.

As to also keeping such replication traffic from saturating the link, that could be done using a policer or shaper, as you've been thinking, but the better alternative is to guarantee other traffic the bandwidth it needs.

If we guarantee DR traffic 60% and guarantee other traffic the other 40%, DR can "saturate" the link in that it might use 100%, yet this should only be seen if other traffic doesn't want that bandwidth. If other traffic does want bandwidth, DR will be pushed aside such that other traffic gets its guaranteed 40%. If other traffic wants more than its guarantee, it can have it, again provided DR isn't using it. So you might also see other traffic "saturate" the link, again though, only if DR isn't demanding any bandwidth.

What you commonly see with bandwidth intensive traffic vs. non-bandwidth intensive, is bandwidth intensive traffic getting more than its guarantee. It is, again though, because the other traffic doesn't want its guaranteed bandwidth.

If all traffic types (classes) wanted to "saturate" the link, you should see each running at its guaranteed proportion of bandwidth.

Re: QoS policy - check my math :)

Joseph,

So, bear with me, if I'm reading this right, I should keep the bandwidth statements for the minimums, shape to the maximums, and just shape to a maximum for DR?

Would this work:

policy-map TOGO

class SENDDALLAS

bandwidth 2048

shape average 3072000

class BRANCHES

bandwidth 15360

shape average 17408000

class DRTRAFFIC

shape average 76800000

bandwidth 61440000

class class-default

Would the above be better? Would the above would set aside the traffic for the branches and have them work correctly, but not saturate the link, and the DR traffic "should" continue working normally? I'm still setting aside 60Mb for DR traffic.

Thanks for sticking with me on this Joseph. =)

John

HTH, John *** Please rate all useful posts ***
Super Bronze

Re: QoS policy - check my math :)

What I'm suggesting, if you provide minimum bandwidth guarantees for all traffic that needs it, you shouldn't need to cap any traffic. The whole idea of providing traffic minimum bandwidth guarantees is so they continue to work as needed even when the link is saturated.

I often work with WAN links that run VoIP, vidconferencing, mission critical business apps, normal business apps and system backups. Such links might run at 100% utilization (generally due to system backups) for hours (and during normal business hours), yet QoS allows all the other apps to function as if the backup wasn't running.

If your QoS can insure traffic does obtain the proportion of bandwidth the application needs when there's congestion, there generally little need to cap bandwidth for any traffic.

So you might try:

policy-map TOGO

class SENDDALLAS

bandwidth percent 1

class BRANCHES

bandwidth percent 7

class DRTRAFFIC

bandwidth percent 30

class class-default

bandwidth percent 10

(NB: if your wondering about the reduced percentages, it's the ratios that are really used [they set flow weights], and it also avoids busting the reserved bandwidth setting [remaining percent is another nicer option - if supported by the IOS] along with be easier to use on other bandwidth capacity links.)

[edit]

PS:

BTW, with QoS link "saturation" often isn't the issue it is without QoS.

Super Bronze

Re: QoS policy - check my math :)

The bandwidth statement guarantees a minimum, i.e. you shouldn't need to police or shape unless you really need to also cap the bandwidth.

Yes, shape should work in lieu of police.

321
Views
14
Helpful
11
Replies
CreatePlease to create content