02-16-2006 07:43 AM - edited 03-03-2019 11:46 AM
Hi guys, recently I've setup some test environment to simulate how the QoS can be apply in order to policing the traffic the way I want it to be. But I don't know what I done wrong, the end result doesn't seems satisfying.
Here's the scenario. RouterA connect to the server segment (FTP, HTTP etc etc), RouterB have one back-to-back cable connecting to RouterA to simulate a WAN environment and the clockrate is set at 128000. Now I want to limit the traffic to FTP for just 32k, below is my configuration.
***************************************************************
!
class-map match-all FOR_FTP
match access-group name FTP
!
!
policy-map MY-POLICY
class FOR_FTP
bandwidth 32
shape average 32000
class class-default
fair-queue
!
!
interface Serial0
bandwidth 128
ip address 10.1.1.1 255.255.255.0
service-policy output MY-POLICY
clockrate 128000
!
ip access-list extended FTP
permit ip any 172.16.1.0 0.0.0.255
!
**************************************************************
I've check the access-list, it match and then show the policy-map, and the traffic shaping is active. But when I use the STG to query the router for both 1.3.6.1.2.1.2.2.1.10.1 (input traffic) and 1.3.6.1.2.1.2.2.1.16.1 (output traffic), the graph just aint right, there's time the traffic hovering around 90kb and sometimes over 100kb. What's wrong with the configuration? I thought I configured that the traffic who match the "FTP" access-list will be shape average to only 32kbps maximum?
Any input over here? My customer just won't accept the result if he want to shape it to 32k while the graph shows more than that...sigh..
02-16-2006 03:42 PM
Could you provide a bit more info ?
I presume this service-policy is applied on Router A's WAN interface to B, right ?
Your ACL seems to match a destination adderss of 172.16.1.0/24. Is that correct ? What address range is your server in ?
Paresh
02-16-2006 10:40 PM
to be sure, I did tried to enable the service-policy at both end, means I limit the output for both RouterA and RouterB...
172.16.1.x is the RouterB end, they tried to access to some other segment, the configuration I shown in the first post is checked in for RouterA, so the destination is going to 172.16.1.x, the access-list counter is increasing and sometimes the traffic is shaped. But the graph shown is just not right, any idea?
02-16-2006 11:48 PM
Ok, could you try this instead:
class-map match-all FOR_FTP
match protocol ftp
!
!
policy-map MY-POLICY
class FOR_FTP
bandwidth 32
shape average 32000
class class-default
fair-queue
!
!
interface Serial0
bandwidth 128
ip address 10.1.1.1 255.255.255.0
service-policy output MY-POLICY
clockrate 128000
Try this and see how you go...
The thing to make sure when you do this test is that there is no non-FTP traffic on the link. This is because your MIBs are polling total interface traffic. A good way of verifying how much traffic is matching the FOR_FTP class is to use 'show policy-map interface serial0' and view the bit-rate there.
Hope that helps - pls rate the post if it does.
Paresh
02-21-2006 12:43 AM
hi Paresh,
the method you suggested work perfectly, the graph was shape at 32k nicely, and the otherway I've tried also proved working, before this the access-list FTP is to match from source to destination, but when I match it with tcp host to host, it works as well.
to be firm, if under the policy-map MY-POLICY, since I guaranteed the bandwidth for FTP to 32k, and I've a default-class. If now I change the config as follow:
policy-map MY-POLICY
class FOR_FTP
bandwidth 32
shape peak 32000 64000
class class-default
fair-queue
would that means that if there's no traffic that chucks up the link, the bandwidth guaranteed for FTP is 32k but it is able to burst up to 64k? will it be able to use the full 128k link if at the same times there's no traffic through?
and if I tried to flood the link with some other traffic (e.g. web application), how to ensure that my FTP traffic still getting at least 32k guaranteed, I've done some "show policy-map int serialx" and here's the result
i. With bandwidht32 while shape peak 32000 64000
*********************************************************************************
DC#sh policy-map int s0/0
Serial0/0
Service-policy output: SHAPE_FTP
Class-map: FOR_FTP (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group name FTP
Queueing
Output Queue: Conversation 265
Bandwidth 32 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
64000/32000 16000 64000 64000 2000 16000
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 0 0 0 0 no
Class-map: class-default (match-any)
31 packets, 1431 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 256
(total queued/total drops/no-buffer drops) 0/0/0
DC#
**********************************************************************************
How to intepret the Target/Average Rate actually? Target rate is the burst rate? and when can we know actually the traffic is bursting, means occupying more than the minimum guarantee bandwidth? Appreciate your view
02-21-2006 02:08 AM
Hi,
To answer your first question, 'shape peak 32000 64000' will result in setting a CIR of 32k and a Bc of 64k. That means a Tc of 2 seconds. Firstly, it's not a good idea to use such a high Tc value. Secondly, the Bc parameter specifies the committed burst and not an excess rate. With a shape statement such as this, your router will be shaping this class out at twice the configured CIR since the Be will default to be the same as the Bc. When using 'shape peak', the router will always try to shape out at 2*32k = 64k. The use of 'bandwidth 32' will ensure that you get at least 32k at all times - this is guaranteed.
To ensure that your FTP is getting a minimum of 32k, check the output of 'show policy-map int' while you are passing traffic through it. The counters will update in real time.
The Target/Average rate follows from my first explanation - the CIR is 32k but since you are using 'shape peak' with default Be, the target shaping rate is twice the CIR, 64k.
To check if the traffic is bursting, you have to once again check the output of 'show policy-map int' while you are passing traffic through it. The counters will update in real time.
Ensure that you configure 'load-interval 30' under the interface where you have applied the service policy to get more accurate bit rates.
Pls remember to rate the posts if you have found them useful
Paresh
02-22-2006 12:50 AM
may be I'm a little slow in picking up new things, I'm still obsess with those Bc, Be stuffs...but from what I've read in the Cisco qos document, if the configuration as follow:
**************************
policy-map SHAPE_FTP
class FOR_FTP
bandwidth 32
shape peak 48000
class class-default
fair-queue
**************************
it means that the guaranteed minimum bw is 32k eventhough the link is congested, but if the link is not congested by other type of traffic, then it'll be able to burst up to 48k only aint it? But when I show the policy-map of these, the Target Rate is 96000 and the average rate is 48000. How to explain this?
Let's be straight to the point, if I want it to have minimum bw of 32k, but only able to go up to 48k when the link is not congested (i didn't want it to utilize the full 128k link eventhough no one is using it). How should the policy like?
As I understand, Bc is Sustained Rate, and Be is Excess Rate, why when the Be = Bc, then the router will try to shape out at 2*CIR? Really really appreciate if you could help me to clear these confusion...thanks a million, u been a real helpful chap
02-22-2006 01:07 AM
If i can get the "show policy-map" result as the attached text, does that means my traffic get a guaranteed 32k of bw no matter how congested the link is, and able to burst to 64000 (under sustained rate section) when it is possible? to achieve this result i do as follows:
**************************
policy-map SHAPE_FTP
class FOR_FTP
bandwidth 32
shape peak 32000 64000 0
class class-default
fair-queue
**************************
02-22-2006 02:09 AM
Hi Mate,
In regards to your question about the target rate, you are seeing the result of the default Be that I alluded to earlier.
Now, if you aim is to:
- guarantee 32k of bandwidth to FTP traffic no matter how congestion the interface is
--- AND ---
- allow the FTP traffic to burst up to 64k when there is no congestion on the link
Then, the following policy will accomplish this:
policy-map SHAPE_FTP
class FOR_FTP
bandwidth 32
shape average 64000
class class-default
fair-queue
Pls try that out and you will see that it does exactly what you want.
Hope that helps - pls rate the post if it does.
Paresh
02-22-2006 02:11 AM
Just another note: the difference between the policy I just posted and what you had is that my policy will result in a lower Bc than what you had, and that is a good thing, as it will help to reduce jitter.
Hope that helps - pls rate the post if it does.
Paresh
02-22-2006 07:10 PM
Paresh,
refer to the config above, I tried it lots of times and this is what I've read from Cisco QoS document. But the weird thing is, althought we're saying that we guaranteed minimum of 32k, and allow it to burst to 64k, fine...
but do a "show policy-map" it shows a target rate of 128000, and an average rate of 64000. Bc (Sustained) is 8000 while Be (Excess) is 8000 as well. I'm not trying to be paranoid but I want to know why it shows it that way since when people question you, better be prepare than sorry...
simple, why target rate higher than the max. traffic I've let it burst?
02-22-2006 06:59 AM
hi,
first of all i do not understand the statment
"bandwith 32" - this is if u want to guarantee 32 kb/s - not to limit.
if this does not work, try the following:
policy-map my-policy
class FOR_FTP
police cir 32000 bc 12032
conform-action transmit
exceed-action drop
02-22-2006 12:57 PM
To rabeder,
I'm not sure what you don't understand about 'bandwidth 32' - this is simply the CBWFQ guarantee of 32k for the traffic class.
The config you have supplied does not quite meet the requirements of the original poster. He wanted a guarantee of 32k with the ability to get up to 64k. With your config, you will apply a hard limit of 32k, dropping everything above it. That does not meet the stated requirements.
Hope that helps - pls rate the post if it does.
Paresh
02-23-2006 12:15 AM
After much simulation, I came out with some conclusion, I guess perhaps its me that doesn't really know how QoS works and to be honest, I'm totally lost.
******************************
policy-map SHAPE_FTP
class FOR_FTP
bandwidth 32
shape peak 64000
class class-default
fair-queue
this will let the FTP traffic consume up the whole 128k leased-line while no other traffic passing through. Show policy-map having a result as follows:
Target Rate - 128000
Average Rate - 64000
Bc - 8000
Be - 8000
Interval - 125ms
if according to Cisco QoS document, configuration like this will guarantee minimum 32k and let it burst to 64k max eventhough there's no other traffic, but after I tested, it'll consumed the whole 128k LL. Sigh...
******************************
******************************
policy-map SHAPE_FTP
class FOR_FTP
bandwidth 32
shape peak 32000 64000 0
class class-default
fair-queue
I'll configure it this way as I thought I'll let it burst to 64k and no further, and this prove to be a little more accurate when you show the policy-map, result as follow:
Target Rate - 32000
Average Rate - 32000
Bc - 64000
Be - 0
Interval - 2000ms
From what I intepret, it should means that average & target rate is always at 32k, but it is able to sustain up to 64k when there's some free resource. The graph at least is withstand around 60-70k but you can see irregular burst in between since the burst interval is 2seconds.
******************************
anyone willing to shed some light to me? I've spend quite some time but just can't get the result I want
02-23-2006 02:18 AM
Hi,
I'm not sure if you read my last couple of posts. I think that you are not quite understanding the operation of the 'shape peak' command. Let me try and explain:
- the 'shape peak' command results in the router attempting to transmit (Bc+Be) bits at every Tc interval. The token bucket is replenished with (Bc+be) bits every interval. Since the Be is the same as Bc by default, you end up with a rate that is twice the CIR that you have configured
- the 'shape average' command results in the router replenishing the token bucket with Bc bits every Tc interval. If there are periods where the class is idle, the token bucket can fill up to (Bc+Be) and the router will be able to transmit (Bc+Be) bits in the next interval that a packet arrives.
Now, if you try the following configuration:
policy-map SHAPE_FTP
class FOR_FTP
bandwidth 32
shape average 64000
class class-default
fair-queue
Pls note very carefully that I am using the 'shape average' command, not the 'shape peak' command.
YOu will see that the above configuration results in a target and average rate equal to 64000. Note that this does NOT mean that your router will always transmit at 64k. It will only do that when bandwidth is available.
Pls try and go through what I have written and try it out on your router. If you still have questions, let me know.
Hope that helps - pls rate the post if it does.
Paresh
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide