The fabric queue selection mechanism is known as fabric QoS. Three queues are defined: a high-priority port for internal control traffic and classified high-priority traffic, a low-priority port for assured-forwarding (AF) traffic, and a best effort port (BE) for low-priority traffic. Each port is assigned 1023 queues. The queues map to a physical egress interface and are assigned when the interface is created. The associated quanta for each of the queues are derived from the bandwidth of the physical or logical interfaces in relative terms to the other interfaces present on that line card or PLIM.

Note	By default, internal control traffic is placed in the high-priority queue.

If an ingress QoS policy is configured classifying certain traffic as being priority, then the priority traffic is placed into the high-priority queue together with the internal control traffic. All other traffic is placed in the best-effort queue.

The user can configure a fabric QoS policy that defines the relative MDRR bandwidths associated with the AF and BE ports. This is applied to the secure domain router (SDR) (this may be the whole router if no individual service domain routers are configured) and affects all fabricq ASICs in the logical router.

Of the four levels of priority—HP1, HP2, AF, and BE—AF is unused. From Release 6.6.1 onwards, support for AF is enabled. The enhancement allows for AF and BE traffic to be supported, even while prioritizing traffic for BE. This provides better quality of service whenever there is a fabric congestion.

A maximum of three classes can be specified within the policy. A class known as class-default is automatically created and equates to the BE port or queues. The name of this class cannot be altered. Any name may be applied to the classes that equate to the priority and AF ports or queues.

Within the fabric QoS policy, the only applicable actions are to assign priority to the priority class and bandwidth remaining percent to the AF and BE classes. The bandwidth remaining percent for the BE class does not need to be specified. It receives all remaining capacity after the appropriate weight has been allocated to the AF class. The user may wish to specifically enter configuration values for the default class just for clarity.

Fabric QoS policy class maps are restricted to matching a subset of these classification options:

• precedence

• dscp

• qos-group

• discard-class

• mpls experimental topmost

  Note	To match on qos-group or discard-class , an ingress QoS policy must be applied, setting the required values for qos-group or discard-class . Both of these variables have local significance only and are not recognized outside of the router.

The fabricq queue selection mechanism is known as Fabric QoS. To provide class of service to the traffic under fabric congestion scenarios, configure Fabric QoS. The platform-independent user interface allows you to configure an MQC policy on the switch fabric queues. This policy is global for all line cards on the router.

Be careful when applying ingress QoS policies when they must interact with a fabric QoS policy. The fabric QoS policy overrides any traffic classification conducted by the ingress policy when determining which traffic should be placed in the priority, AF, or BE queues within the fabricq ASIC. In addition, the fabric QoS policy is used to determine which traffic is placed in the priority queue within the ingressq ASIC fabric queues and the switch fabric ASICs (S2 and S3 stages) rather than any priority marking set by the ingress QoS policy. The priority marking performed by the ingress QoS policy is still used when determining packet scheduling in the shape queues within the ingressq ASIC.

For example, if an ingress QoS policy were to classify and mark particular traffic types as being priority and a fabric QoS policy were to be applied either marking alternative traffic as being priority or not setting priority at all, then the ingress policy priority statement is effectively ignored in the fabricq, the S2 ASICs, and the S3 ASICs. Use caution to ensure that there is no conflict between the ingress QoS policy and the fabric QoS policy.

A very simplistic illustration would be if an ingress QoS policy uses a class-map to exclude MPLS experimental 3 from the priority class, but the fabric QoS policy places MPLS experimental 3 traffic in the priority class. In this case, the MPLS experimental 3 traffic is placed in the high-priority S2 and S3 queues and the fabricq high-priority port or queues.

If the ingress QoS policy remarks certain traffic with values that the fabric QoS policy class-maps are to match on, then the remarked traffic is matched and placed in the appropriate port or queues. This provides the ability for the ingress QoS policy and the fabric QoS policy to complement each other, rather than potentially conflicting.

As noted above, fabric QoS is constrained to a subset of the possible match criteria that can be used in its class maps. If the ingress QoS policy were to set a qos-group marking for all traffic that should be placed in the priority queue and another qos-group marking for all traffic to be placed in the AF class, then if the fabric QoS policy class maps matches on the qos-group values, the policy is honored end to end. This approach enables multiple ingress QoS policies to interact in the expected manner with a fabric QoS policy.

It is important to remember that if an ingress QoS policy is applied to an interface and the fabric QoS policy has been applied to the router, then the ingress MSC RX PSE is required to perform two classification cycles. This has an impact on the forwarding capacity of the line card or PLIM, reducing the performance to about 62.5 Mpps.

You can choose not to apply a specific fabric QoS policy, giving the ingress QoS policy the decision on which traffic is placed in the high-priority queues but removing the ability to differentiate between AF and BE classes in the fabricq ASIC.