Tokens
are filled into the bucket at the committed rate; that is, if the committed rate is 1 MB, this is the number of
tokens inserted into the bucket. Think of it as advance token deposit or token repository. The depth of the
bucket is the burst size. When traffic arrives at the bucket and sufficient tokens are available, the traffic is said
to conform, and the corresponding number of tokens are removed from the bucket (tokens spent are gone). If
sufficient tokens are not available (repository is empty), the traffic is said to exceed.
Configuring Committed Access Rate (CAR)
Example 7-8 shows how CAR can be used to limit the rate for specific types of protocols to ensure sufficient
capacity for other traffic, including mission-critical applications. Two access lists are created to classify the web
and ICMP traffic, so that they can be handled separately by CAR. Note that multiple rate-limit statements can be
configured in each direction, and they will be processed top down. The following example shows outbound rate
limiting. Inbound rate limiting can also be added.
Example 7-8. Configuring CAR
Code View:
Router(config)# access-list 101 permit tcp any any eq www
Router(config)# access-list 102 permit icmp any any
Router(config)# interface
Router(config-if)# rate-limit output access-group 101 10000000 24000 32000 conformaction
set-prec-transmit 5 exceed-action set-prec-transmit 0
Router(config-if)# rate-limit output access-group 102 50000 25000 30000 conformaction
set-prec-transmit 0 exceed-action drop
Router(config-if)# rate-limit output 4000000 16000 24000 conform-action continue
exceed-action drop
Let's look more closely at the steps involved in Example 7-8:
The first rate-limit policy dictates that all World Wide Web traffic is sent.
Pages:
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376