Ethernet Sub-Interfaces do not have a way to get the state of congestion that their underlying physical, or "main," interface may be experiencing. Due to this reason, a queuing policy applied directly to a subinterface would have no way to know when the link is congested, and thus would
never trigger. As such, Cisco IOS does not allow direct application of a policy-map that uses any sort of queuing policies directly to sub-interfaces. A way to overcome this limitation is to apply a policy that shapes the rate of the subinterface to create artificial congestion. This type of configuration is referred to as HQF, or Hierarchical Queuing Framework.
The logic of CBWFQ is that during congestion, a class with a bandwidth reservation of ClassBandwidth will have at least a ClassBandwidth/ InterfaceBandwidth share of the total interface bandwidth. CBWFQ reservation only becomes active when congestion occurs.
The CLI will not allow you to assign a service-policy with CBWFQ weights unless the interface is using FIFO queuing, which implies that CBWFQ is not compatible with any of the legacy queuing methods, such as custom queueing or priority queueing. These must be disabled explicitly before applying the service policy.
Each class configured with a bandwidth statement under the policy-map has its own dedicated FIFO queue in the interface’s CBWFQ conversation pool. The depth of each FIFO queue can be changed on a per-class basis with the queue-limit command. The overall WFQ settings, such as the CDT and the total queue size, can be set using the queue-limit under class-default, and the hold-queue <number> out command at the interface level.
As soon as the bandwidth keyword is specified under any user-defined class, the interface queue turns into CBWFQ. This means that any unmatched flows that fall back into class-default are scheduled using dynamic WFQ weights. This means that automatic classification occurs, along with precedence-based weight assignment and sharing of the single buffer space of WFQ. This behavior is default, even if you did not configure fair-queue under the class-default. If you want to disable fair-queue for unclassified packets, an explicit bandwidth value for the class-default can be configured, which turns it into a single FIFO queue.
Moreover, if you do not define any classes other than class-default, and class default has a bandwidth value defined, the entire interface queue essentially becomes a FIFO queue.
policy-map TEST
class class-default
bandwidth 96
Bandwidth Reservations and CBWFQ
It is not possible to mix the bandwidth and bandwidth percent commands in the same policy map; the units must be the same among classes.
MQC LLQ and Remaining Bandwidth Reservations
To prevent starvation of other queues, the packets de-queued from the LLQ conversation are metered using a simple token bucket, with a configurable rate and burst size. Packets that exceed the token bucket are dropped (policed) during times of congestion; if there is no congestion, exceeding traffic is not dropped, but it is simply not prioritized. Multiple classes inside a single policy-map can use the priority keyword, but only a single priority queue exists. This design of multiple priority classes is used to ensure that one priority flow does not starve another priority flow.
When the LLQ priority reservation is configured, the CBWFQ algorithm subtracts the reserved bandwidth of the priority queue from the interface’s available bandwidth or from the available rate based on the shaping policy. The remaining bandwidth can be used to create a relative bandwidth reservation for other classes in the CBWFQ.
bandwidth remaining percent
MQC WRED
CBWFQ supports three drop policies: classic tail-drop, which is the default for user-defined classes, Congestive Discard for WFQ, and Random Early Detection (RED).
When you apply the random-detect command under a user-defined class, it automatically removes the MQC LLQ and Remaining Bandwidth Reservations (pending update) command and enforces RED as the drop policy. When using RED with CBWFQ, each flow is considered an individual FIFO queue. This is similar to legacy flow-based WRED; the big improvement is the ability to use random drop per flow, not per whole queue.
MQC Dynamic Flows and WRED
There are two ways to enable WRED within class-default. The first is to configure a bandwidth reservation statement (turning the class’s queue into a FIFO queue) and then enabling RED, and the second is to enable RED with WFQ. The second case
activates RED dropping to replace Congestive Discard Threshold-based drops for dynamic flows.
MQC WRED with ECN
TCP Explicit Congestion Notification (ECN), similar to BECN and FECN in Frame Relay, is used to signal the forthcoming of network congestion for TCP flows. Originally, TCP detected network congestion based on packet loss, timeouts, and duplicate acknowledgments. This was usually the result of full queues and unconditional packet drops. TCP ECN allows the network to signal the receiver of the flow that the network is close to dropping packets. It’s then up to the TCP receiver to decide how to react to this notification; it usually signals the sender to slow the sending rate. The overall effect of TCP ECN is better performance, compared to simple packet drops and slow start, because it allows the sender to respond faster than slow start would and results in less time spent on the recovery from a packet loss.
TCP ECN works together with RED by changing the exceed action from random drop to ECN marking. Instead of randomly dropping a packet when the average queue depth grows above the minimum threshold, RED marks packet with the special ECN flag.
!
ip tcp ecn
!
policy-map AAA
class BBB
random-detect
random-detect ecn
No comments:
Post a Comment