QoS question
Pasted below is the config from a device I am working on. I see cir is 256000, and what I believe to be burst rates of 8000 and 8000. I believe this means there are two "bit buckets" but I am not sure how they work. What I am trying to understand is if how the two 8000 numbers relate to the CIR of 256000. And the exceed-actions and viloate-actions work. I know one is for bursting, but I do not really see an example that relates to this on Cicos's site. Can any one elaborate on this for me?
ROUTER#show policy-map TEST_MAP
Policy Map TEST_MAP
Class TEST_MAP
police cir 256000 bc 8000 be 8000 <<<<<<<<<<<<<<<<<<<<<<<<<<<
conform-action transmit
exceed-action drop
violate-action drop
ROUTER#show policy-map interface Serial0
Serial0
Service-policy output: TEST_MAP
Class-map: TEST_MAP (match-all)
32365 packets, 3252186 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: access-group 111
police:
cir 256000 bps, bc 8000 bytes, be 1500 bytes
conformed 29233 packets, 2958994 bytes; actions:
transmit
exceeded 64 packets, 8772 bytes; actions:
drop
violated 2747 packets, 265802 bytes; actions:
drop
conformed 0 bps, exceed 0 bps, violate 0 bps
Class-map: class-default (match-any)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any
ROUTER#show policy-map TEST_MAP
Policy Map TEST_MAP
Class TEST_MAP
police cir 256000 bc 8000 be 8000 <<<<<<<<<<<<<<<<<<<<<<<<<<<
conform-action transmit
exceed-action drop
violate-action drop
ROUTER#show policy-map interface Serial0
Serial0
Service-policy output: TEST_MAP
Class-map: TEST_MAP (match-all)
32365 packets, 3252186 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: access-group 111
police:
cir 256000 bps, bc 8000 bytes, be 1500 bytes
conformed 29233 packets, 2958994 bytes; actions:
transmit
exceeded 64 packets, 8772 bytes; actions:
drop
violated 2747 packets, 265802 bytes; actions:
drop
conformed 0 bps, exceed 0 bps, violate 0 bps
Class-map: class-default (match-any)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any
encrypt the encryption, never mind my brain hurts.
Comments
-
jason_lunde Member Posts: 567I cannot explain it much better than this doc:
CISCO EXPLANATION ABOUT TOKEN BUCKET ALGORITHM
Basically you are creating two buckets, a conform bucket and an exceed bucket, both 8000 bytes. You committed information rate is in bps, so 256000 bps. You use this in your token bucket calculations (Tc = Bc/CIR (in seconds)) So like in their example, using your CIR, if you have an 8000 byte bucket and receive a 4500 byte packet you would take your committed bucket (8000-4500=3500 >0) So you would use your conform action. If your next packet arrived .1 seconds later you would take that calculation (0.1 * 256000)/8 = 3200. So 3200 is added back to the committed bucket (3500 + 3200= 6700). If the next packet is over 6700, than the exceeded bucket can be checked in the same manner. If it is greater than 0 when taken from the exceeded bucket, the exceed action is taken. HTH's and is accurate...If I am off I am sure someone can correct me -
networker050184 Mod Posts: 11,962 Modjason_lunde wrote: »I cannot explain it much better than this doc:
CISCO EXPLANATION ABOUT TOKEN BUCKET ALGORITHM
Basically you are creating two buckets, a conform bucket and an exceed bucket, both 8000 bytes. You committed information rate is in bps, so 256000 bps. You use this in your token bucket calculations (Tc = Bc/CIR (in seconds)) So like in their example, using your CIR, if you have an 8000 byte bucket and receive a 4500 byte packet you would take your committed bucket (8000-4500=3500 >0) So you would use your conform action. If your next packet arrived .1 seconds later you would take that calculation (0.1 * 256000)/8 = 3200. So 3200 is added back to the committed bucket (3500 + 3200= 6700). If the next packet is over 6700, than the exceeded bucket can be checked in the same manner. If it is greater than 0 when taken from the exceeded bucket, the exceed action is taken. HTH's and is accurate...If I am off I am sure someone can correct me
Great link, explains it very well. The only thing I will say about your explanation is there is no Tc used in policing, only in shaping.An expert is a man who has made all the mistakes which can be made. -
Forsaken_GA Member Posts: 4,024To elaborate on the other two actions....
Basically, the work it works is like this -
If your traffic is at or below your commit rate, your traffic is conforming, and the conform action is applied.
If your traffic is between your commit rate and your burst rate, then your traffic is exceeding, and the exceed action is applied. If you traffic is over your burst rate, it's violating, and the violate action is performed. The choices are basically transmit (send it on through), drop it, or remark it and then transmit it. If the traffic is remarked, it'll usually be to a lower preference, which means it may not get the type of service it was originally marked for and makes it more likely to be dropped sometime later in the transmit path.
In useful terms, if you're a provider, you will accept the committed rate as is, you'll usually remark the burst traffic to a lower preference, but still allow it to be sent (because dropping traffic when you absolutely don't have to tends to piss customers off), and you'll drop the violate traffic because your customer is just being an abuseful prick at that point.
That is, of course, just a general guideline, the specifics of the situation should be considered on a link to link basis, if you're overprovisioned, you can be a little more forgiving of burst traffic, if you're woefully oversubscribed, you have to be more militant about enforcing CIR's -
jason_lunde Member Posts: 567Forsaken_GA wrote: »To elaborate on the other two actions....
Basically, the work it works is like this -
If your traffic is at or below your commit rate, your traffic is conforming, and the conform action is applied.
If your traffic is between your commit rate and your burst rate, then your traffic is exceeding, and the exceed action is applied. If you traffic is over your burst rate, it's violating, and the violate action is performed. The choices are basically transmit (send it on through), drop it, or remark it and then transmit it. If the traffic is remarked, it'll usually be to a lower preference, which means it may not get the type of service it was originally marked for and makes it more likely to be dropped sometime later in the transmit path.
In useful terms, if you're a provider, you will accept the committed rate as is, you'll usually remark the burst traffic to a lower preference, but still allow it to be sent (because dropping traffic when you absolutely don't have to tends to piss customers off), and you'll drop the violate traffic because your customer is just being an abuseful prick at that point.
That is, of course, just a general guideline, the specifics of the situation should be considered on a link to link basis, if you're overprovisioned, you can be a little more forgiving of burst traffic, if you're woefully oversubscribed, you have to be more militant about enforcing CIR's
Definitely....I remember trainsignal's ONT videos on this explaining it very well. He had like a chart with 2 lines...bc and be. If the traffic ended up under bc it was conforming...if it was between bc and be it was exceeding, and above be was violating. Might be worth a watch. -
liven Member Posts: 918Thanks everyone.
Everyone's explanation pretty much confirms that I understand it. But it really helps to hear others explain it.
Thanks againencrypt the encryption, never mind my brain hurts.