Solved: QoS policy - check my math :)

John Blakley · ‎10-21-2009

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 ***

Joseph W. Doherty · ‎10-21-2009

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.

View solution in original post

Joseph W. Doherty · ‎10-21-2009

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.

View solution in original post

Giuseppe Larosa · ‎10-21-2009

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

John Blakley · ‎10-21-2009

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 ***

Joseph W. Doherty · ‎10-21-2009

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.

John Blakley · ‎10-21-2009

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 ***

John Blakley · ‎10-21-2009

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 ***

Joseph W. Doherty · ‎10-21-2009

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.

John Blakley · ‎10-21-2009

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 ***

Joseph W. Doherty · ‎10-21-2009

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.

John Blakley · ‎10-21-2009

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 ***

Joseph W. Doherty · ‎10-21-2009

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.

Joseph W. Doherty · ‎10-21-2009

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.