MQC and Rate Limiting

iproute

Greetings QoS gurus.

I have an interesting scenario. Thought I might post it here see what you folks think.

The challenge is that I have a new 1Gbps circuit, where bursting above 700Mbps (95th percentile) will incur additional charges. What I'd like to do is limit utilization to 650Mbps or so until such a time where additional charges are authorized. That covers both ingress and egress.

Limiting Input on Circuit:
The biggest source of ingress data for the interface on this new circuit will be a single source, which is controlled by me. So my thought was to integrate a rate limit into the existing MQC policy on that source. Here's what I have so far.

policy-map pm
 class limit-data (class matches an access-list, non-matching traffic passed to the next class)
    police <value tbd> conform-action transmit exceed-action drop 
 class class1
  priority percent <value>
 class class2
  bandwidth remaining percent <value>
 class class3
  bandwidth remaining percent <value>
 class class-default
  bandwidth remaining percent <value>

This seems problematic to me, because by putting the rate-limit at the top, my impression is that it's going to affect the actual available bandwidth for classes 1-3, and default. If I put the limit-data class lower in the PM, then anything matching higher classes won't be rate limited. Is the impression I noted above accurate or off base? Any recommendations for how to manage this?

Limiting Output on Circuit:
We're looking at largely the same scenario as the first part, except that we're working with the affected interface directly and we want to rate limit ALL outbound traffic (until such a time where additional charges are authorized, where we could change the egress policy-map). How does one do that though and continue to queue data differently according to class-based configurations?

QoS is not my strongest area, so any help would be greatly appreciated.

Thanks in advance.

networker050184

Well, first off limiting input on your end of the circuit is kind of pointless. The traffic has already passed across the circuit and been counted by the provider at that point. Limiting output on the other end is the only real option here. That may not be feasible depending on the type of circuit though.

What you are looking for on the egress is a nested policy-map. Something like below (forgive syntax errors, doing this off the top of my head).

policy-map Parent
class class-default shape <rate>
service-policy Child

policy-map Child
class class1
priority <rate>
class class2
bandwidth <rate>
(and so on for each class)

interface GigabitEthernet0
service-policy out Parent

iproute

Thanks for the quick reply. I'll poke around and see what I can come up with for an egress/limited policy based on your feedback.

Regarding ingress, let me add a bit more clarity to the rough explanation above. In the diagram below, interface Y is where the 700Mbps/1Gbps (burst) circumstance is in effect. The X interface (which is under my control) is where nearly all ingress traffic is sourced for the Y interface. By limiting the output on X for the networks behind Y, I can have some measure of control over what ingresses on Y.

[Router A][X]---{WAN}---[Y][Router B]

policy-map pm
 class limit-data (class matches an access-list, non-matching traffic passed to the next class)
    police <value tbd> conform-action transmit exceed-action drop 
 class class1
  priority percent <value>
 class class2
  bandwidth remaining percent <value>
 class class3
  bandwidth remaining percent <value>
 class class-default
  bandwidth remaining percent <value>

This is what I had come up with in attempting to rate limit traffic leaving X and headed for Y.

networker050184

So if you control router A and B all you have to do is limit egress on both and not worry about ingress.

I personally would not go with the approach you are attempting. I'd use the nested approach in my example. Firstly because you won't start using your queuing until your interface is congested. Since it's a 1G interface on a 700Mbps circuit you will already be using above the 700Mbps by the time that happens. So you want the parent policy to limit everything to 700Mbps where your queuing in the child class can start kicking in. The parent policy is in effect making it a 700Mbps traffic rate that you want.

iproute

Thanks. Super valuable feedback. I've got this working on interface Y (egress) in my lab.

The only wrench I'll throw in the works is that interface X doesn't only communicate with interface Y, so forcing output to be only 700Mbps on X would not be ideal. Forcing it to be 700Mbps for traffic headed to Y and uncapped for all other traffic would be ideal. Maybe I'm wanting to have my cake and eat it too .

networker050184

You can do a nested policy in a class other than class-default so you can make a class for each site it connects to with a sub policy nested within. Or do a normal policy with only a nested policy in the X->Y class.

iproute

Perfect. Thanks again for your help!