9. Service Ingress QoS Policies
This chapter provides information to configure SAP ingress QoS policies using the CLI.
9.1. Overview of Service Ingress Policy
There is one default service ingress policy. The default policy allocates a single queue and maps all traffic to the “be” (best-effort) FC. The default policies can be copied and modified but they cannot be deleted. The default policies are identified as policy ID 1. The default policies are applied to the appropriate interface, by default. For example, the default SAP-ingress policy is applied to access ingress SAPs. You must explicitly associate other QoS policies. For information about the tasks and commands necessary to access the command line interface and to configure and maintain your 7210 SAS devices, refer to the CLI Usage chapter in the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Basic System Configuration Guide.
In a service ingress QoS policy, a user can define up to eight queues or 16 policers/meters per policy, with up to two queues or two meters per FC.
For VPLS, the following types of forwarding are supported:
- unicast
- multicast
- broadcast
- unknown
Multicast, broadcast, and unknown types are flooded to all destinations within the service while the unicast forwarding type is handled in a point-to-point manner within the service. All these traffic types use the same queue or meter (in other words, a separate queue or meter for multicast, broadcast, and unknown unicast traffic types cannot be defined).
Unicast and multipoint traffic can be defined to use the same queue or meter or different queues or meter per FC. In other words, eight queues and 16 policers are shared by unicast and multicast traffic types and if a user allocates a dedicated multicast queue for BUM traffic, the number of queues available for unicast traffic reduces. Similarly, up to 16 meters can be shared by unicast and multicast traffic types.
9.1.1. Configuration Guidelines for SAP-Ingress Policy
The configuration guidelines for SAP ingress policies are the following.
- The option is available to configure a smaller number of ingress queues or ingress policers per SAP.
- On the 7210 SAS-K 2F1C2T and 7210 SAS-K 2F6C4T, hardware queues are allocated in groups of two, and on the 7210 SAS-K 3SFP+ 8C, hardware queues are allocated in groups of four; these grouped queues are reserved for use by the SAP even if the user specifies an odd value. The 7210 SAS-K 2F1C2T and 7210 SAS-K 2F6C4T support two, four, six, or eight queues per SAP. The 7210 SAS-K 3SFP+ 8C supports four or eight queues per SAP.
- FC-to-queue map can be defined; this allows the user to assign the packets classified into a particular FC to any one of the queues configured for the SAP.
- The option is available to use up to two queues per FC, with one queue for unicast traffic and one queue for BUM traffic, with a maximum of eight queues per access SAP. This option can be used with multipoint services for example, VPLS service. BUM traffic shares a single queue per FC; therefore it is not possible to use individual queue for each of broadcast, unknown-unicast, and multicast traffic. It is possible to define the same queue for unicast and BUM traffic. For example, users can assign two queues per FC, such that unicast traffic uses one of the queues and the BUM traffic uses the other queue. This allows users to have four FCs per SAP with two queues per FC; or the user can have seven FCs per SAP with one queue per FC and the eighth queue being shared by BUM traffic of all the FCs; or a mix and match is allowed. If a multicast queue is not assigned to an FC explicitly, it uses queue 1 (the default queue of the policy).
- The queue parameters such as queue shaper rate (CIR/PIR), CBS and MBS, queue priority, and weight can be defined. The assigned priority and weight are used to determine the priority and weight of the queue in both the CIR and PIR scheduling loop.
- Allow configuration of WRED slopes (per queue) – high-slope and low-slope. Depending on the queue mode and the profile assigned to the packet on SAP ingress classification, one of the configured WRED slopes is used to evaluate if a buffer can be allocated to the packet. In-profile packets use the high-slope and out-of-profile packets use the low-slope.
- Supports Strict priority (SP) scheduling and Weighted-Fair Queuing (WFQ) scheduling for SAP ingress queues. For more information about service ingress scheduling, see the Schedulers.
- The option is available to use up to two policers per FC, with one policer for unicast traffic and one for BUM traffic, with a maximum of up to 16 policers per access SAP. This option can be used with multipoint services for example, VPLS service. BUM traffic shares a single meter per FC; therefore it is not possible to use individual meter for each of broadcast, unknown-unicast, and multicast traffic. It is possible to define the same meter for unicast and BUM traffic. For example, users can assign two meters per FC, such that unicast traffic uses one meter and the BUM traffic uses the other meter. This allows users to have eight FCs per SAP with two meters per FC, or users can have eight FCs per SAP with one meter per FC and the eighth meter being shared by BUM traffic of all the FCs; or a mix and match is allowed. If a multicast meter is not assigned to an FC explicitly, it uses queue 1 (the default queue of the policy).
- The option is available to use a queue or a meter per FC, with up to two queues per FC or two meters per FC or a queue and a meter per FC for a maximum of up to eight queues per access SAP and 16 meters/policers per access SAP. It is allowed to configure queue for unicast traffic and meter for BUM traffic or vice-versa. This option can be used with multipoint services for example, VPLS service. BUM traffic shares a single meter or queue per FC; therefore it is not possible to use individual meter or an individual queue for each of broadcast, unknown-unicast, and multicast traffic. If a multicast meter is not assigned to an FC explicitly, it uses queue 1 (the default queue of the policy).
- The meter parameters such as meter rate (CIR/PIR), CBS and MBS, and meter mode (srTCM, trTCM) can be defined.
- If both IP criteria and MAC criteria are configured in SAP ingress QoS classification then they need resources from two different slices. In other words, the MAC and IP criteria entries cannot be located in the same slice. If resources are not found in two different slices, then the association of the policy fails.
9.1.1.1. Resource Allocation for Service Ingress QoS Classification Policy
The available global pool of ingress internal CAM hardware resources can be allocated as per user needs for use with different features such as SAP ingress QoS policy, ingress ACLs, and so on. SAP ingress QoS can be allocated classification for use from this pool. Resources can be allocated for SAP ingress QoS policy classification IPv4, IPv6, and MAC match criteria, based on the operator needs. Users can modify the resources allocated to scale the number of entries available per match criteria or scale the number of SAPs. The resources from the global ingress internal CAM pool are allocated in slices with a fixed number of entries.
The number of slices to be allotted for a SAP ingress QoS policy is specified using the config system resource-profile ingress-internal-tcam qos-sap-ingress-resource CLI command.
The user can specify a limit for the amount of resources required for SAP ingress QoS policies and also has the option to limit the amount of resources used per match criteria supported for SAP ingress QoS policies. A given slice can be used for MAC criteria, IP criteria, and IPv6 criteria.
Before associating SAP-ingress policy match criteria with a SAP, resources must be allocated. Until resources are allocated for use, attempts to associate a policy with a SAP fail. When the user allocates resources for use by SAP ingress QoS policies using the config system resource-profile ingress-internal-tcam qos-sap-ingress-resource CLI command, the system allocates resources in slices of 510 entries (192 entries for the 7210 SAS-K 3SFP+ 8C).
The above resources set the maximum limit on the resources available for use by all SAP ingress policies in use simultaneously on the system. The software manages the resource slices allocated to the SAP ingress QoS policy pool and allocates the entries in the slices when a SAP ingress QoS policy is associated with a SAP. The software allocates the resources required by a SAP from the slices depending on whether the SAP-ingress policy uses IP criteria, IPv6 criteria, or MAC criteria, and the number of entries configured in the SAP-ingress policy.
When the user allocates slices of resources using the config system resource-profile ingress-internal-tcam qos-sap-ingress-resource CLI command, the resources are used only for classification entries configured under IPv4 criteria or MAC criteria.
If the user needs to use IPv6 criteria, resources must be allocated using the config system resource-profile ingress-internal-tcam qos-sap-ingress-resource mac-ipv4-ipv6-128-match-enable CLI command. The resources allocated using this command are used for classification entries configured under IPv6 criteria, IPv4 criteria, or MAC criteria. Each IPv6, IPv4, or MAC classification entry consumes two resources from this pool, reducing the number of classification entries that can be accommodated in a single slice to 256 (96 entries for the 7210 SAS-K 3SFP+ 8C.) The user can choose to allocate all the slices allocated for SAP ingress QoS classification for IPv6 criteria or allocate only a portion of it.
The tools dump system-resources CLI command displays the current usage and availability of the resources. One or more entries per slice are reserved for system use.
9.1.1.2. Resource Allocation for SAP Ingress Meters
The FC ingress meter and SAP ingress aggregate meter allocate resources for the common meter resource pool. A single FC ingress meter requires one entry from the pool when the policy is associated with the SAP and a single SAP ingress aggregate meter uses a single entry from the pool when the command to enable SAP aggregate meter functionality is executed under the context of the SAP. An increase in FC ingress meter reduces the number of meters available for SAP ingress aggregate meter. The reverse is also true.
The tools dump system-resources CLI command can be used to display the current utilization of the ingress meter resource pool.
9.1.1.3. Default SAP-Ingress Policy
The default policy 1 maps all traffic to default FC “be” and maps FC “be” to queue 1. Queue 1 is configured with CIR 0 and PIR max. The following is a sample configuration output of a default SAP-ingress policy.
Table 41 lists the SAP-ingress policy defaults.
Table 41: SAP-Ingress Policy Defaults
Field | Default |
description | “Default SAP-ingress QoS policy.” |
scope | template |
queue | 1 |
adaptation-rule | cir closest pir closest |
rate | pir = max, cir= 0 |
cbs | 10KBytes - default |
mbs | 60KBytes - default |
priority | 1 |
weight | 1 |
default-fc | be |
9.1.1.4. Use of Index File by SAP QoS Ingress Policy
The 7210 SAS uses an index file to store the map that indicates the QoS resource allocation to the SAPs. This file is used to ensure that all the SAPs that were created successfully before a reboot can be recreated during a reboot. Without an index file, it is possible that all the SAPs that were configured successfully may fail on a reboot after saving the configuration file. The index file is stored in the flash. During a reboot, if the file is found, the system allocates resources as per the stored map. If the file is not found, the system implements a best-fit algorithm and tries to allocate resources for all the SAPs on a first-come-first-served basis. When the index file is not present it is possible that the saved configuration did not execute successfully after the reboot.
 | Note: The following caveats apply:
|
9.2. Basic Configurations
A basic service ingress QoS policy must conform to the following:
- have a unique service ingress QoS policy ID
- have a QoS policy scope of template or exclusive
- have at least one default unicast FC queue
- (optionally) use multipoint FC queue
- (optionally) use unicast meter and BUM traffic
Configuring and applying QoS policies is optional. If no QoS policy is explicitly applied to a SAP, a default QoS policy is applied.
9.2.1. Service Ingress QoS Policies
To create a service ingress policy, perform the following.
- Define a policy ID value. The system does not dynamically assign a value.
- Define a description that provides a brief overview of policy features.
- Specify a default FC for the policy. All packets received on an ingress SAP using this ingress QoS policy are classified to the default FC.
- Define FC parameters by performing the following.
- Modify the unicast/queue default value to override the default unicast forwarding type queue mapping for fc fc-name.
- Modify the multicast/queue default value to override the default multicast forwarding type queue mapping for fc fc-name.
- Associate a meter for fc fc-name, if desired, for both unicast and BUM traffic types.
- Specify the following classification criteria - IPv4/IPv6 or MAC criteria or both IP and MAC criteria. You can define IPv4/IPv6, MAC-based and MAC and IP based SAP ingress policies to select the appropriate ingress meter and corresponding FC for matched traffic.
- A SAP-ingress policy is created with a template scope. The scope can be modified to exclusive for a special one-time use policy. Otherwise, the template scope enables the policy to be applied to multiple SAPs.
The following is a sample service ingress policy configuration output.
9.2.2. Service Ingress QoS Queues
To create service ingress queue parameters, perform the following.
- Define a new queue ID value. The system will not dynamically assign a value.
- Configure queue parameters. Rate, slope-policy, CBS, MBS, priority, and weight.The following is a sample ingress queue configuration output.A:ALA-7>config>qos# infoecho "QoS Policy Configuration"#--------------------------------------------------sap-ingress 1 createpolicy-name "default"description "Default SAP ingress QoS policy."no ip-mac-matchscope templatequeue 1 createadaptation-rule cir closest pir closestrate cir 0 pir maxslope-policy "default"mbs 60cbs 10priority 1weight 1exit.........#------------------------------------------A:ALA-7>config>qos#
9.2.3. Service Ingress QoS Meters
The following are sample service ingress QoS meters.
9.2.4. SAP Ingress FC Configuration
The following is a sample SAP ingress FC configuration output with unicast queues and multicast queues.
The following is a sample SAP ingress FC configuration output with a mix of unicast queues and meters, and a mix of multicast queues and meters.
9.2.5. Service Ingress dot1p and IP DSCP Criteria
The following is a sample configuration output of dot1p classification policy and IP DSCP classification policy used for ingress classification and its association with SAP-ingress policy.
9.2.6. Service Ingress IP Match Criteria
When specifying SAP ingress match criteria, only one match criteria type can be configured in the SAP ingress QoS policy.
The following is a sample ingress IP criteria configuration output.
9.2.7. Service Ingress MAC Match Criteria
To configure service ingress policy MAC criteria, perform the following.
- Define a new entry ID value. Entries must be explicitly created; the system does not dynamically assign entries or a value.
- Associate the FC with a specific MAC criteria entry ID.
- Define a description. The description provides a brief overview of policy features.
The following is a sample ingress MAC criteria configuration output.
9.2.8. Applying Service Ingress Policies
SAP ingress QoS policies are supported only on access SAPs.
9.2.8.1. Epipe Service
The following sample configuration output shows an Epipe service configuration with SAP-ingress policy 100 applied to the SAP.
9.2.8.2. VPLS
The following sample configuration output shows a VPLS service configuration with SAP-ingress policy 100.
9.2.8.3. IES
The following sample configuration output shows an IES service configuration.
9.3. Service Management Tasks
This section describes service management tasks.
9.3.1. Deleting QoS Policies
Every service SAP is associated, by default, with the appropriate ingress policy (policy-id 1). You can replace the default policy with a customer-configured policy, but you cannot entirely remove the policy from the SAP configuration. When you remove a non-default service ingress policy, the association reverts to the default policy-id 1.
A QoS policy cannot be deleted until it is removed from all SAPs where it is applied.
9.3.1.1. Removing a QoS Policy from Service SAPs
The following Epipe service output samples show that the SAP service ingress reverts to policy-id 1 when the non-default policies are removed from the configuration.
9.3.2. Copying and Overwriting QoS Policies
You can copy an existing service ingress policy, rename it with a new policy ID value, or overwrite an existing policy ID. The overwrite option must be specified or an error occurs if the destination policy ID exists.
9.3.3. Removing a Policy from the QoS Configuration
Use the following syntax to remove a policy from the QoS configuration.
9.3.4. Editing QoS Policies
You can change existing QoS policies and entries. The changes are applied immediately to all services where this policy is applied. To prevent configuration errors, copy the policy to a work area, make the edits, and then overwrite the original policy.