[no] sap-egress policy-id [create]
config>qos
This command is used to create or edit a service egress QoS policy. The egress policy defines the Service Level Agreement (SLA) for service packets as they egress on the SAP.
Policies in effect are templates that can be applied to multiple services as long as the scope of the policy is template. The queues defined in the policy are not instantiated until a policy is applied to a service.
A sap-egress policy differs from sap-ingress policies in the complexity of the QoS parameters that can be defined. At ingress, policies determine queue mappings based on ingress DSCP and dot1p criteria. Multiple queues can be created per forwarding class and each queue can have different CIR or PIR parameters.
At egress, the policies are much simpler, since the forwarding class and in-profile or out-of-profile determination is done at the original service ingress SAP. Egress SAP QoS policies allow the definition of queues and the mapping of forwarding classes to those queues. Each queue needs to have a relative CIR for determining its allocation of QoS resources during periods of congestion. A PIR can also be defined that forces a hard limit on the packets transmitted through the queue. When the forwarding class is mapped to the queue, a dot1p value can optionally be specified. If specified, and the SAP has a dot1q or qinq encapsulation type, the dot1p value will be used for all packets that egress on that forwarding class. If the SAP is qinq-encapsulated, the qinq-mark-top-only command (under config>service) can be used to specify which qtags will have their dot1p marked or re-marked with the specified dot1p value. If the dot1p value is not specified, a dot1p value of 0 will be used. If the SAP is null-encapsulated, the dot1p value has no meaning.
The ATM access egress shaping configuration in a SAP egress QoS policy is ignored when that policy is assigned to an ATM SAP. The shaping of the egress cell stream is controlled by the atm-td-profile command. If the atm-td-profile is not configured, the default atm-td-profile is in effect. See the atm-td-profile command for more information.
The sap-egress policy with policy-id 1 is the default sap-egress QoS policy and is applied to service egress SAPs when an explicit policy is not specified or removed.
The factory default settings for sap-egress policy-id 1 define a single queue with PIR set to the maximum value and a CIR set to 0. The single queue is the default queue and all forwarding classes will map to it. Packets being tagged according to the defined SAP encapsulation will have the dot1p bits set to 0 for the new tags being added. If the tag already exists and the default sap-egress policy is being used, the dot1p bits are not changed.
If the egress port encapsulation type is qinq, the SAP type is X.Y, and one tag already exists and a new tag must be added, then the new outer tag’s dot1p bits will be set to the inner tag’s dot1p bits value. For all other port types and SAP types, new tags will have a dot1p-bits value of 0 if the default policy is used.
Any changes made to an existing policy, using any of the sub-commands, will be applied immediately to all egress SAPs where this policy is applied. For this reason, when many changes are required on a policy, it is highly recommended that the policy be copied to a work area policy-id. That work-in-progress policy can be modified until complete and then written over the original policy-id. Use the config qos copy command to maintain policies in this manner.
The no form of this command deletes the sap-egress policy. A policy cannot be deleted until it is removed from all service SAPs where it is applied. When a sap-egress policy is removed from a SAP, the SAP will revert to the default sap-egress policy-id 1.
uniquely identifies the policy. The policy-name cannot be used to create the policy, but it can be used to reference a policy that already exists.
keyword used to create a service egress QoS policy
[no] fc fc-name [create]
config>qos>sap-egress
The fc fc-name mode within the SAP egress QoS policy is used to contain the explicitly defined queue mapping and dot1p marking commands for fc-name. When the mapping for fc-name points to the default queue and the dot1p marking is not defined, the mode for fc-name is not displayed in the show configuration or save configuration output unless the detail option is specified.
The no form of the command removes the explicit queue mapping and dot1p marking commands for fc-name. The queue mapping reverts to the default queue for fc-name, and the dot1p marking (if appropriate) uses the default of 0.
n/a
specifies the forwarding class queue mapping or dot1p marking is to be edited. The value given for fc-name must be one of the predefined forwarding classes in the system.
keyword used to create a SAP egress forwarding class policy
packet-byte-offset [add bytes | subtract bytes | none]
no packet-byte-offset
config>qos>sap-egress
config>qos>sap-egress>queue
config>qos>sap-ingress
config>qos>sap-ingress>queue
This command is used to modify the size of the packet that schedulers operate on. Modification only impacts schedulers and queue statistics. The actual packet size is not modified, nor can it be. Only the size used by the schedulers to determine the scheduling is changed. The packet-byte-offset command is meant to be a mechanism that can be used to compensate for downstream encapsulation or header removal. The scheduling rates are affected by the offset, as well as the statistics (accounting) associated with the queue. The packet-byte-offset command does not affect port-level and service-level statistics. It only affects the queue statistics. The network-queue policy applies in both the ingress and egress directions.
The add and subtract keywords are mutually exclusive. Either add, subtract, or none must be specified.
There are three possible modes of packet-byte-offset operation:
no packet-byte-offset — enables legacy behavior so that no modification is performed
packet-byte-offset — automatic adjustment mode. Rates apply to packets based on the received packet size at ingress (this is also known as packet size on the wire, less the Layer 1 headers, the inter-frame GAP and the Preamble) and to the transmitted packet size at egress, which includes 4 bytes of Ethernet FCS. At ingress, all internal headers and associated service headers are discounted during scheduling operation. At egress, 4 bytes are added to accommodate for Ethernet FCS.
packet-byte-offset [add bytes | subtract bytes]— automatic correction followed by addition or subtraction of a specified number of bytes. This command first performs the packet-byte-offset operation as captured above and then adds or subtracts a certain number of bytes. Rates apply to packets based on the size of the packet at the ingress or egress port plus or minus an offset.
Packet byte offset configuration can be applied at the policy level, in which case it applies to all of the queues within the policy, or at the individual queue level so that it applies only to a specific queue.
The no version of this command enables legacy 7705 SAR behavior where the queue rates are relative to the packet size with the internal fabric header added, but without the FCS.
after automatic adjustment for internal headers (for example, added FCS or removal of internal service/overhead), adds the specified number of bytes to each packet associated with the queue for scheduling and accounting purposes. From the queue’s perspective, the packet size is increased by the amount being added to each packet.
after automatic adjustment for internal headers (for example, added FCS or removal of internal service/overhead), subtracts the specified number of bytes from each packet associated with the queue for scheduling and accounting purposes. From the queue’s perspective, the packet size is reduced by the amount being subtracted from each packet.
the packet size is left unchanged
policy-name policy-name
no policy-name
config>qos>sap-egress
This command configures a policy name for the SAP egress policy.
specifies the name for the policy, up to 64 characters
queue queue-id [queue-type] [create]
no queue queue-id
config>qos>sap-egress
This command enables the context to configure a service egress policy queue. Explicit definition of an egress queue’s hardware scheduler status is supported. A single egress queue allows support for multiple forwarding classes.
The default behavior automatically chooses the expedited or non-expedited nature of the queue based on the forwarding classes mapped to it. As long as all forwarding classes mapped to the queue are expedited (nc, ef, h1, or h2), the queue is treated as an expedited queue by the hardware schedulers. When any non-expedited forwarding classes are mapped to the queue (be, af, l1, or l2), the queue is treated as best effort (be) by the hardware schedulers. The expedited hardware schedulers are used to enforce expedited access to egress ports. The hardware status of the queue must be defined at the time of queue creation within the policy.
The no form of the command removes the queue-id from the service egress policy. Removing the queue-id also removes it from any existing SAPs using the policy. If any forwarding classes are mapped to the queue, they revert to the default queue.
When a queue is removed, pending accounting information for each service egress queue created due to the definition of the queue in the policy is discarded.
n/a
the queue-id for the service egress queue, expressed as a decimal integer. The queue-id uniquely identifies the queue within the policy.
the expedite, best-effort and auto-expedite queue types are mutually exclusive. Each defines the method that the system uses to service the queue from a hardware perspective. A keyword must be specified at the time the queue is created in the service egress policy. If an attempt is made to change the keyword after the queue is initially defined, an error is generated.
the queue is treated in an expedited manner independent of the forwarding classes mapped to the queue
the queue is treated in a non-expedited manner independent of the forwarding classes mapped to the queue
the system auto-defines the way the queue is serviced by the hardware. When auto-expedite is defined on the queue, the queue is treated in an expedited manner when all forwarding classes mapped to the queue are configured as expedited types nc, ef, h1 or h2. When a single non-expedited forwarding class is mapped to the queue (be, af, l1 and l2) the queue automatically falls back to non-expedited status.
keyword used to create a service egress queue policy
scope {exclusive | template}
no scope
config>qos>sap-egress
This command is used to enter the scope of the policy. The scope of the policy cannot be changed if the policy is applied to one or more services.
The no form of this command sets the scope of the policy to the default of template.
template
when the scope of a policy is defined as exclusive, the policy can only be applied to a single SAP. Attempting to assign the policy to a second SAP will result in an error message. If the policy is removed from the exclusive SAP, it will become available for assignment to another exclusive SAP.
when the scope of a policy is defined as template, the policy can be applied to multiple SAPs on the router