# Example: Configuring WRED and Dynamic Queue Thresholds

RED typically operates on fixed-size queues, and you can configure the router to use fixed-size queues. However, by default, the router employs dynamic queue thresholds to provide a good balance between sharing the egress buffer memory between queues and protecting an individual queue’s claim on its fair share of the egress memory. Fixed-size queues become problematic as the number of configured queues scales into the thousands, because allocating disjointed partitions of buffer memory to each queue means the allocations become quite small, and most likely not all queues are simultaneously active.

In general, you use queues as follows:

- Fixed-size queues on core routers and core-facing interfaces where the number of queues is relatively small (tens or hundreds, but not thousands).
- Dynamic queues on edge-facing interfaces where the number of queues is relatively large (thousands).

As shown in Figure 7, queue lengths extend to oversubscribe memory when aggregate memory utilization is low, and contract to strictly partition memory when memory utilization is high. Dynamic thresholding enforces fairness when free buffers are scarce and promotes sharing when buffers are plentiful. Dynamic queue thresholds are discussed in Queuing and Buffer Management Overview. Figure 7 illustrates WRED behavior with dynamic queue thresholding.

To configure WRED to run on queues whose limits dynamically expand and contract, use the percent keyword when you configure thresholds in a drop profile. For example:

host1(config)#drop-profile internetDropProfile host1(config-drop-profile)#average-length-exponent 9 host1(config-drop-profile)#committed-threshold percent 30 90 4 host1(config-drop-profile)#conformed-threshold percent 25 90 5 host1(config-drop-profile)#exceeded-threshold percent 20 90 6

Figure 7: WRED and Dynamic Queue Thresholding

#### Related Documentation

- Configuring WRED
- Dropping Behavior Overview
- RED and WRED Overview