MQC based FRTS + CWFQ .... What is the sequence?

Marcofbbr · ‎04-26-2008

Hi

Considering the attached configuration, what is the order of the operations? Is traffic shaped before or after the CBWFQ guarantees bandwidth?

I have read on my QoS exam student guide that "After the aggregate traffic is shaped, the parent-shape policy map references the child-cbwfq policy map, ..." [Reference: Official Cisco QoS exam Student Guide ver2.2, page 7-57]

I tried to search on cisco site, but is not easy to find. I'm not sure, but this morning I read in the 3700 Documentation, and Shaping is the LAST operation in the sequence.

In my opinion traffic should be processed by CBWFQ and then shaped. In this way, higher priority traffic will be in front of the queue and if traffic exeeds, only low-priority traffic is marked or dropped.

Hope you can help me.

t814687 · ‎04-26-2008

Marco:

The order is the following (release 12.4):

1) Shaping

2) WFQ for shaped traffc

Based on generic logic of nested policies

Traffic Policy as a QoS Policy (Hierarchical Traffic Policies): Example

A traffic policy can be nested within a QoS policy when the service-policy command is used in policy-map class configuration mode. A traffic policy that contains a nested traffic policy is called a hierarchical traffic policy.

A hierarchical traffic policy contains a child policy and a parent policy. The child policy is the previously defined traffic policy that is being associated with the new traffic policy through the use of the service-policy command. The new traffic policy using the preexisting traffic policy is the parent policy. In the example in this section, the traffic policy called child is the child policy and traffic policy called parent is the parent policy.

Hierarchical traffic policies can be attached to subinterfaces, Frame Relay PVCs, and ATM PVCs. A hierarchical traffic policy is particularly beneficial when configuring VIP-based distributed FRF.12 (and higher) PVCs. When hierarchical traffic policies are used, a single traffic policy (with a child and a parent policy) can be used to shape and prioritize PVC traffic. In the following example, the child policy is responsible for prioritizing traffic and the parent policy is responsible for shaping traffic. In this configuration, the parent policy allows packets to be sent from the interface, and the child policy determines the order in which the packets are sent.

Router(config)# policy-map child

Router(config-pmap)# class voice

Router(config-pmap-c)# priority 50

Router(config)# policy-map parent

Router(config-pmap)# class class-default

Router(config-pmap-c)# shape average 10000000

Router(config-pmap-c)# service-policy child

-serg

Joseph W. Doherty · ‎04-27-2008

I recently looked into a similar question of what happens when the shaper cap isn't reached. At least for 12.4(15)T4, the child policy only saw the traffic when the shaper was active. Otherwise, traffic queued in the parent class.

For a policy like yours shaping for frame-relay, there shouldn't be any congestion if you keep within your PVC or far side interface bandwidth limits. I.e. if you're under the shaper's bandwidth, there is no need to send higher priority traffic first since there's no congestion.