Traffic Shaping on a Cisco Router 2800-Series

[Matthias39299]

Hi everybody!

I'm trying to shape traffic on a Cisco Router 2800 to (temporarily) replace our PacketShaper (EOL) until we have a new solution. 

At the moment, I'm trying to test this situation with 2 Clients.

CIR = 20Mbps

Client 1 should have guaranteed bandwidth 10Mbps

Client 2 should also have guaranteed bandwidth 10Mbps

The goal is, when only one Client is accessing the Bandwidth, he should be able to get the full Bandwidth 20Mbps

How do I configure the policy-map?

For now, it looks like this:

policy-map SHAPING

  class cmPOOL1

     shape average 10000000

  class cmPOOL2

     shape average 10000000

A speed test is limiting the bandwidth to max. 10Mbps - what I want to achieve.

But like I described above, when only 1 Client is active - he should be able to get the full bandwidth..(20Mbps)

How do I configure the Bc and Be value? 

Is shaping the right option, or does police command do the job?

Some help would be really appreciated since I'm very new in the world of Networks.

Thank you very much,

Matthias

[Georg Pauwen]

Hello,

you could use 'priority percent' instead, which will give the full bandwidth to any of the two clients when there is no congestion:

policy-map SHAPING

class cmPOOL1

priority percent 50

class cmPOOL2

priority percent 50

[Georg Pauwen]

Actually, in theory, the shaping should only occur in case of congestion. If either client does not use the available bandwidth, it should be available for the other client. Does the configuration you have not work as expected ?

Cisco recommends not to alter the bc and be values, and just use the defaults, which should work fine in the majority of cases...

[paul driver · Accepted solution]

Hello
The below policy will provide you with a maximum guaranteed LLQ of 10 mb for each class at times of congestion and if either isnt beign use then the other policy won’t take more BW.

policy-map Shaping_Child
class cmPOOL1
priority 10240
class cmPOOL2
priority 10240
class class-default
fair-queue

policy-map Shaping_Parent
class class-default
shape average 20480000
service-policy Shaping_Child

[Matthias39299]

Hi @paul driver , 

Thank you very much!

I just tested your configuration example with Parent- and Child-Policy and it works fine!! 

Let's take this example one step further.

What if I have more than 2 Clients with different requirements:

Let's say:

Client 1: MIN Guaranteed Bandwidth 6Mbps - MAX Bandwidth 10Mbps (if available / free)

Client 2: MIN Guaranteed Bandwidth 10Mbps - MAX Bandwidth 20Mbps 

Client 3: MIN Guaranteed Bandwidth 2Mpbs - MAX Bandwidth 3Mbps 

Client 4: MIN Guaranteed Bandwidth 1Mpbs - MAX Bandwidth 8Mbps 

.

.

and so on.. 

policy-map Shaping_Child

  class cmPOOL1

    priority 6144

  class cmPOOL2

    priority 10240

  class cmPOOL3

    priority 2048

  class cmPOOL4

    priority 1024

  class class-default

  fair-queue

How do I configure the Shaping_Parent now, if every client has a different value in maximum Bandwidth?

Thank's for your help!

Kind regards,

Matthias

[Joseph W. Doherty]

LLQ can also have an explicit policer. So you would add an explicit policer with the "max" allowed value in each class. However, as in my posting, in response to Paul, the implicit policer triggers when the parent's bandwidth is exceeded. I.e. you might obtain the results you desire when only one class is using the link.

What was recommended for your OP, indeed satisfies your requirements, but then you didn't mention how to share bandwidth between classes, when the class wasn't all or nothing for its bandwidth demand. For such, especially with your latest variation, that might only be satisfied using bandwidth statements containing either explicit shapers or policers, e.g.:

policy-map parent
class-default
shape average 20000000 !or less to allow for average L2 overhead
service policy child

policy-map child
class cmPOOL1
bandwidth 6000
police (or shape) 10000
class cmPOOL2
bandwidth 10000
police (or shape) 20000 !perhaps optional, as this is the same as the parent's max
class cmPOOL3
bandwidth 2000
police (or shape) 3000
class cmPOOL4
bandwidth 1000
police (or shape) 8000
class class-default
bandwidth 1000 !since your classes don't sum to 20, this keeps the ratios accurate
police (or shape) 1 !as less then 1000, your other classes can use this excess, proportionally

[Joseph W. Doherty]

The "key" to the solution, as already noted by others, is to have a parent shaper, that restricts overall bandwidth to your link's CIR, and a child policy that manages the bandwidth as desired.

The reason I'm adding this posting, I would suggest not to use LLQ for your two clients, as LLQ will drop all excess, not queue it. So instead, I suggest using the "ordinary" bandwidth command. Also, the way LLQ is being suggested, there's only one global physical queue (for all defined LLQ classes), so if there's congestion, packet delivery, between the two clients will be FIFO, but if you use the bandwidth command, the classes will be dequeued 50/50, packet delivery for each client would be a little more averaged out, i.e. not as erratic.  Also, with the bandwidth command, since excess packets will be queued, you can use FQ within the class.

Additionally, you can consider having one class use the default class, assuming you won't have any other traffic, or you could keep both client's to their own classes, and allocate a minimum of bandwidth for the default class (BTW, you always have a default class, whether explicitly defined, or not).

Lastly, I suspect many Cisco shaper's don't account for L2 overhead, but your link vendor may. If so, you'll want to shape slower than the nominal bandwidth (normally in the range of 10 to 20%, I generally use 15%).

E.g. #1
policy-map parent
class-default
shape average 20000000 !or less to allow for average L2 overhead
service policy child#

policy-map child1
class client1
bandwidth percent 50
fair-queue !optional, but recommended
class class-default
bandwidth percent 50
fair-queue !optional, but recommended

policy-map child2
class client1
bandwidth percent 48 !class-default requires 1%, allocation 48/48 maintains 50:50 or 1:1 ratio
fair-queue !optional, but recommended
class client2
bandwidth percent 48
fair-queue !optional, but recommended
class class-default
bandwidth percent 2
fair-queue !optional, but recommended

[paul driver]

Hello Joesph
Interested you your QOS example and the explanation pertaining to the use of BW % instead of using priority queue logic of LLQ, I was aware of the FIFO logic in LLQ but my thinking is the granularity of having separate LLq would have been applicable in this case so if any class exceeded its own allocation then the other class isnt affected by the other
Now my assumption at this time is the BW commands dont provide the same functionality?

[Joseph W. Doherty]

Either approach, when the shaper begins to queue traffic, would insure either client would obtain 50% of the bandwidth. The biggest difference, as noted, would be when using LLQ excess packets would be immediately discarded, but with bandwidth statements, the excess packets would be queued. Of course, only so many packets will be queued, and if you exceed the queue limit, those packets also get immediately discarded.

The second difference is, with bandwidth statements, you can dequeue packets from both classes, also 50/50, or use unused bandwidth.

One "correction" to my prior posting, although same level (as found in the later LLQ implementations) LLQ works from a single FIFO queue, since excess packets are discarded, the FIFO queue wouldn't have anything to dequeue. That said, the dual LLQ classes could have some undesired (?) behavior.

For example, if client 1 is offering a 90% load, while client 2 is offering 10% or less. Since this (logically) shouldn't cause the shaper to queue traffic, all that traffic is transmitted (much as we expect, beyond the fact that the implicit policer, for client 1, isn't policing [that's what we desire, although might seem contrary to how one might expect the policy to work]).

Now let's say client 2 increases its offered load to 20%. Then the offered load exceeds 100%, so implicit policers should police. Client 2's is under 50%, so no policing there, but client 1's, still at 90% offered, should be policed so that only 50% gets through (which also may be very adverse to client 1's traffic, at that time). However, the combined egress is only 50% and 20%, so you're not taking advantage of 30% being unused by client 2 traffic. The bandwidth statement would use this bandwidth. I.e. client 1 should get 80% egress while client 2 should continue to get 20%. Also, if client 2 offers more, it should get it from client 1 until it too reaches 50%.

[amir.glibic]

Hi @Joseph W. Doherty ,

I stumbled upon this thread and I've tested your proposed configuration regarding the parent/child policy.

Unfortunately it seems not to work - or I am doing something wrong. You described here:

"class class-default
bandwidth 1000 !since your classes don't sum to 20, this keeps the ratios accurate
police (or shape) 1 !as less then 1000, your other classes can use this excess, proportionally"

In my case, I can't add anything below the cumulative bandwidth, in my case like this:

policy-map PARENT
class class-default
shape average 25000000
service-policy TestA

policy-map TestA
class add1
bandwidth 6000
shape average 10000000
class add2
bandwidth 10000
shape average 20000000
class class-default

So according to your description, I should assign the remaining 9M to the-class default, so that it sums up to 25M (defined in PARENT). But if I try to add this, the router rejects the command:

Router(config-pmap-c)#shape average 9000000
Shape class class-default CIR requested 9000 (kbps) Required bandwidth 16000 (kbps)

But if I add the 16M that are required at least according to the router message, then these 16M are the real "peak size" for clients in add1, instead of the maximum of 10M. So if Matthias would assign this the way you proposed and has a few more clients, which sum up to ~50M in total, then a client that should have a maximum of 3M (Client3) would theoretically be also able to peak up to 50M.

If I use "bandwidth x" instead of the "shape average x", then no limitation is active at all. I get the full possible bandwidth (for my test the router is connected to a 100M line, that should use only 25M of it - but it bursts up to 80M (rest is used by other devices)).

I'm not sure if this is even possible, at least I can't find any solution to this scenario that would satisfy all the requirements that Matthias has...

[Joseph W. Doherty]

"So according to your description, I should assign the remaining 9M to the-class default, so that it sums up to 25M (defined in PARENT). But if I try to add this, the router rejects the command:

Router(config-pmap-c)#shape average 9000000
Shape class class-default CIR requested 9000 (kbps) Required bandwidth 16000 (kbps)"

No, I don't believe I wrote that, i.e. using a child class shaper to sum to parent's shaper, but perhaps I was misunderstood (fault could be mine, I may have been unclear).

What I wrote was, in my example with multiple classes, adding a bandwidth statement, to an explicitly defined class default, insures class ratios were kept as specified by the class bandwidth statements. If you don't define an explicit class default, the other classes may obtain unused bandwidth from other classes, including class-default, but depending how the IOS allocates that bandwidth, the defined proportions might not be provided.

Consider the policies from which you pulled my description, where the offered traffic is 20 Mbps for only two classes, cmPOOL3 and cmPOOL4, defined as (w/o policers or shapers):
class cmPOOL3
bandwidth 2000
class cmPOOL4
bandwidth 1000
How do those two classes divide the 20 Mbps?

From the way they are defined, I would expect them to split the 20 Mbps 2:1, but this assumes this is true regardless how other class bandwidths are defined (actually probably true in any case), but what if other class bandwidths are not defined? If other class bandwidths are undefined, possibly bandwidth is allocated to one class more than the other (again, probably not), but I recall (?) when all defined, (somewhere) it's documented unused bandwidth is proportionally (by just the active class allocations) is divided (again, probably not), but declaring all class allocations, and explicitly avoiding using the implicit class default, help insures expected results regardless of "internal" default operations which may change between IOS releases.

That's why I suggested/recommended what I did. If still unclear, please let me know.

So, in your example, what I would suggest/recommend is:

policy-map TestA
class add1
bandwidth 6000
shape average 10000000
class add2
bandwidth 10000
shape average 20000000
class class-default
bandwidth 9000

Shapers (or policers) for any of the classes, should be (as far as I know - although child class shaper support various much on IOS release - something I didn't mention before) independent on the class bandwidth allocation. What your example shows, perhaps shows a special restriction for class-default, which has other restrictions, such as (I believe - at least since HQF) requiring a minimum allocation of 1%, even if not explicitly defined.  (Also, it might be specific to specific IOS versions.)

Further, where you note you're able to obtain 100 Mbps, using an interface egress policy of:
policy-map PARENT
class class-default
shape average 25000000
service-policy TestA
interface x
service-policy output PARENT
would, I would say, be a bug!

However, if you're using:
policy-map TestA
class add1
bandwidth 6000
shape average 10000000
class add2
bandwidth 10000
shape average 20000000
class class-default
interface x
service-policy output TestA
bandwidth # !optional
class-default traffic should be able to obtain 100 Mbps.

Oh, your post also gets into "peak" bandwidths - that's a whole subject in itself, where I've seen Cisco documentation be inconsistent and the usual implementation doesn't work as I believe it should.

"I'm not sure if this is even possible, at least I can't find any solution to this scenario that would satisfy all the requirements that Matthias has..."

That's true because his requirements, are not fully defined (probably because he doesn't know what he doesn't know), but what I recommended, I believe probably comes closest to what he seems he likely wants to accomplish.

Further, a traffic management appliance, like PacketShaper's, can do (interesting/nice) things/tricks not supported on a Cisco router.

Another issue to using all LLQ classes, as a solution, I didn't earlier mention, suppose you eventually need to prioritize traffic like VoIP, what do you do then?

Again, if any of this reply is unclear, or you have the questions, feel free to post them, if not here, perhaps on a new thread.

[amir.glibic]

Hi Joseph,

you may be right - I've just checked one of our ISR4331, there it is possible to add the bandwidth 1 under the class default, which is not possible on our old 2800. So your assumption regarding IOS/model may be right.

I just need to test this with an ISR, unfortunately I have none on spare.

I'll try to check this in the next few days.

[Joseph W. Doherty]

An "old" 2800, eh? If it's running an IOS version before HQF (12.4(20)T), there are some major differences.