The no form of this command removes any description string from the context.
The copy command is a configuration level maintenance tool used to create new policies using existing policies. It also allows bulk modifications to an existing policy with the use of the
overwrite keyword.
Indicates that the source policy ID and the destination policy ID are sap-egress policy IDs. Specify the source policy ID that the copy command will attempt to copy from and specify the destination policy ID to which the command will copy a duplicate of the policy.
Indicates that the source policy ID and the destination policy ID are SAP ingress policy IDs. Specify the source policy ID that the copy command will attempt to copy from and specify the destination policy ID to which the command will copy a duplicate of the policy.
Indicates that the source HSMDA pool policy ID and the destination policy ID are HSMDA pool policy IDs. Specify the source policy ID that the copy command will attempt to copy from and specify the destination policy ID to which the command will copy a duplicate of the policy.
Indicates that the source HSMDA scheduler policy ID and the destination policy ID are HSMDA scheduler policy IDs. Specify the source policy ID that the copy command will attempt to copy from and specify the destination policy ID to which the command will copy a duplicate of the policy.
Indicates that the source HSMDA slope policy ID and the destination policy ID are HSMDA slope policy IDs. Specify the source policy ID that the copy command will attempt to copy from and specify the destination policy ID to which the command will copy a duplicate of the policy.
renum old-entry-number new-entry-number
This can be required in some cases since the router exits when the first match is found and executes the actions in accordance with the accompanying action command. This requires that entries be sequenced correctly from most to least explicit.
|
Values
|
normal — Regular match criteria are allowed; ISID match not allowed. vid — Configures the VID filter type used to match on ethernet_II frame types. This allows matching VLAN tags for explicit filtering.
|
[no
] sap-ingress
policy-id | policy-name
Policies in effect are templates that can be applied to multiple services as long as the scope of the policy is template. Queues defined in the policy are not instantiated until a policy is applied to a service SAP.
It is possible that a SAP ingress policy will include the dscp map command, the
dot1p map command and an IP or MAC match criteria. When multiple matches occur for the traffic, the order of precedence will be used to arrive at the final action. The order of precedence is as follows:
The SAP ingress policy with policy-id 1 is a system-defined policy applied to services when no other policy is explicitly specified. The system SAP ingress policy can be modified but not deleted. The
no sap-ingress command restores the factory default settings when used on
policy-id 1. The default SAP ingress policy defines one queue associated with the best effort (
be) forwarding class, with CIR of zero and PIR of line rate.
The no sap-ingress policy-id command deletes the SAP ingress policy. A policy cannot be deleted until it is removed from all services where it is applied. The system default SAP ingress policy is a special case; the
no command restores the factory defaults to policy-id 1.
The policy-id uniquely identifies the policy.
The policy-name uniquely identifies the policy.
scope {exclusive
| template
}
The no form of this command sets the scope of the policy to the default of
template.
The default forwarding class is best effort (be). The
default-fc settings are displayed in the
show configuration and
save output regardless of inclusion of the
detail keyword.
Setting the enqueuing parameter to high for a packet increases the likelihood of enqueuing the packet when the ingress queue is congested. Ingress enqueuing priority only affects ingress SAP queuing, once the packet is placed in a buffer on the ingress queue, the significance of the enqueuing priority is lost.
Setting the enqueuing parameter to low for a packet decreases the likelihood of enqueuing the packet when the ingress queue is congested. Ingress enqueuing priority only affects ingress SAP queuing, once the packet is placed in a buffer on the ingress queue, the significance of the enqueuing priority is lost.
The fc command creates a class or sub-class instance of the forwarding class fc-name. Once the
fc-name is created, classification actions can be applied and the sub-class can be used in match classification criteria. Attempting to use an undefined sub-class in a classification command will result in an execution error and the command will fail.
The no form of the command removes all the explicit queue mappings for
fc-name forwarding types. The queue mappings revert to the default queues for
fc-name. To successfully remove a sub-class, all associations with the sub-class in the classification commands within the policy must first be removed or diverted to another forwarding class or sub-class.
policer policer-id [fp-redirect-group
]
Within a sap-ingress QoS policy forwarding class context, the policer command is used to map packets that match the forwarding class and are considered unicast in nature to the specified policer-id. The specified policer-id must already exist within the
sap-ingress QoS policy. While the system is determining the forwarding class of a packet, it is also looking up its forwarding destination. If ingress forwarding logic has resolved a unicast destination (the packet does not need to be sent to multiple destinations), it is considered to be a unicast packet and will be mapped to either an ingress queue (using the
queue queue-id or
queue queue-id group ingress-queue-group commands) or an ingress policer (
policer policer-id). The
queue and
policer commands within the forwarding class context are mutually exclusive. By default, the unicast forwarding type is mapped to the SAP ingress default queue (queue 1). If the
policer policer-id command is executed, any previous policer mapping or queue mapping for the unicast forwarding type within the forwarding class is overridden if the policer mapping is successful.
A policer defined within the sap-ingress policy is not actually created on an ingress SAP or a subscriber using an
sla-profile where the policy is applied until at least one forwarding type (unicast, broadcast, unknown or multicast) from one of the forwarding classes is mapped to the policer. If insufficient policer resources exist to create the policer for a SAP
or subscriber or ingress policing is not supported on the port associated with the SAP
or subscriber, the initial forwarding class forwarding type mapping will fail.
The no form of this command is used to restore the mapping of the unicast forwarding type within the forwarding class to the default queue. If all forwarding class forwarding types had been removed from the default queue, the queue will not exist on the SAPs
or subscribers associated with the QoS policy and the
no policer command will cause the system to attempt to create the default queue on each object. If the system cannot create the default queue in each instance, the
no policer command will fail and the unicast forwarding type within the forwarding class will continue its mapping to the existing policer-id. If the
no policer command results in a policer without any current mappings, the policer will be removed from the SAPs and subscribers associated with the QoS policy. All statistics associated with the policer on each SAP and subscriber will be lost.
When the forwarding class policer command is executed, a valid
policer-id must be specified. The parameter
policer-id references a
policer-id that has already been created within the
sap-ingress QoS policy.
Within a sap-ingress QoS policy forwarding class context, the
broadcast-policer command is used to map packets that match the forwarding class and are considered broadcast in nature to the specified policer-id. The specified policer-id must already exist within the
sap-ingress QoS policy. While the system is determining the forwarding class of a packet, it is also looking up its forwarding destination based on the ingress service type and the service instance forwarding records. If the service type is VPLS and the destination MAC address is the broadcast address (ff:ff:ff:ff:ff:ff), the packet is classified into the broadcast forwarding type.
Broadcast forwarding type packets are mapped to either an ingress multipoint queue (using the broadcast queue-id or
broadcast queue-id group ingress-queue-group commands) or an ingress policer (
broadcast-policer policer-id). The
broadcast and
broadcast-policer commands within the forwarding class context are mutually exclusive. By default, the broadcast forwarding type is mapped to the SAP ingress default multipoint queue. If the
broadcast-policer policer-id command is executed, any previous policer mapping or queue mapping for the broadcast forwarding type within the forwarding class is overridden if the policer mapping is successful.
A policer defined within the sap-ingress policy is not actually created on an ingress SAP or a subscriber using an
sla-profile where the policy is applied until at least one forwarding type (unicast, broadcast, unknown or multicast) from one of the forwarding classes is mapped to the policer. If insufficient policer resources exist to create the policer for a SAP or
subscriber or ingress policing is not supported on the port associated with the SAP or
subscriber, the initial forwarding class forwarding type mapping will fail.
The broadcast-policer command is ignored for instances of the policer applied to SAPs or
subscribers where broadcast packets are not supported.
The no form of this command is used to restore the mapping of the broadcast forwarding type within the forwarding class to the default multipoint queue. If all forwarding class forwarding types had been removed from the default multipoint queue, the queue will not exist on the SAPs or
subscribers associated with the QoS policy and the
no broadcast-policer command will cause the system to attempt to create the default multipoint queue on each object. If the system cannot create the queue on each instance, the
no broadcast-policer command will fail and the broadcast forwarding type within the forwarding class will continue its mapping to the existing policer-id. If the
no broadcast-policer command results in a policer without any current mappings, the policer will be removed from the SAPs and subscribers associated with the QoS policy. All statistics associated with the policer on each SAP and subscriber will be lost.
When the forwarding class broadcast-policer command is executed, a valid
policer-id must be specified. The parameter
policer-id references a
policer-id that has already been created within the sap-ingress QoS policy.
Within a sap-ingress QoS policy forwarding class context, the
multicast-policer command is used to map packets that match the forwarding class and are considered multicast in nature to the specified policer-id. The specified policer-id must already exist within the
sap-ingress QoS policy. While the system is determining the forwarding class of a packet, it is also looking up its forwarding destination based on the ingress service type and the service instance forwarding records. Two basic types of services support multicast packets; routed services (IES and VPRN) and L2 multipoint services (VPLS, I-VPLS and B-VPLS). For the routed service types, a multicast packet is destined to an IPv4 or IPv6 multicast address. For the L2 multipoint services, a multicast packet is a packet destined to a multicast MAC address (multicast bit set in the destination MAC address but not the ff:ff:ff:ff:ff:ff broadcast address). The VPLS services also support two other multipoint forwarding types (broadcast and unknown) which are considered separate from the multicast forwarding type.
If ingress forwarding logic has resolved a packet to the multicast forwarding type within the forwarding class, it will be mapped to either an ingress multipoint queue (using the multicast queue-id or
multicast queue-id group ingress-queue-group commands) or an ingress policer (
multicast-policer policer-id). The
multicast and
multicast-policer commands within the forwarding class context are mutually exclusive. By default, the multicast forwarding type is mapped to the SAP ingress default multipoint queue. If the
multicast-policer policer-id command is executed, any previous policer mapping or queue mapping for the multicast forwarding type within the forwarding class is overridden if the policer mapping is successful.
A policer defined within the sap-ingress policy is not actually created on an ingress SAP or a subscriber using an
sla-profile where the policy is applied until at least one forwarding type (unicast, broadcast, unknown or multicast) from one of the forwarding classes is mapped to the policer. If insufficient policer resources exist to create the policer for a SAP or
subscriber or ingress policing is not supported on the port associated with the SAP or
subscriber, the initial forwarding class forwarding type mapping will fail.
The no form of this command is used to restore the mapping of the multicast forwarding type within the forwarding class to the default multipoint queue. If all forwarding class forwarding types had been removed from the default multipoint queue, the queue will not exist on the SAPs
subscribers associated with the QoS policy and the no multicast-policer command will cause the system to attempt to create the default multipoint queue on each object. If the system cannot create the queue on each instance, the no multicast-policer command will fail and the multicast forwarding type within the forwarding class will continue its mapping to the existing policer-id. If the no multicast-policer command results in a policer without any current mappings, the policer will be removed from the SAPs and subscribers associated with the QoS policy. All statistics associated with the policer on each SAP and subscriber will be lost.
When the forwarding class multicast-policer command is executed, a valid
policer-id must be specified. The parameter
policer-id references a
policer-id that has already been created within the
sap-ingress QoS policy.
Within a sap-ingress QoS policy forwarding class context, the
unknown-policer command is used to map packets that match the forwarding class and are considered unknown in nature to the specified policer-id. The specified policer-id must already exist within the
sap-ingress QoS policy. While the system is determining the forwarding class of a packet, it is also looking up its forwarding destination based on the ingress service type and the service instance forwarding records. If the service type is VPLS and the destination MAC address is unicast but the MAC has not been learned and populated within the VPLS services FDB, the packet is classified into the unknown forwarding type.
Unknown forwarding type packets are mapped to either an ingress multipoint queue (using the unknown queue-id or
unknown queue-id group ingress-queue-group commands) or an ingress policer (
unknown-policer policer-id). The
unknown and
unknown-policer commands within the forwarding class context are mutually exclusive. By default, the unknown forwarding type is mapped to the SAP ingress default multipoint queue. If the
unknown-policer policer-id command is executed, any previous policer mapping or queue mapping for the unknown forwarding type within the forwarding class is overridden if the policer mapping is successful.
A policer defined within the sap-ingress policy is not actually created on an ingress SAP or a subscriber using an
sla-profile where the policy is applied until at least one forwarding type (unicast, broadcast, unknown or multicast) from one of the forwarding classes is mapped to the policer. If insufficient policer resources exist to create the policer for a SAP or
subscriber or ingress policing is not supported on the port associated with the SAP or
subscriber, the initial forwarding class forwarding type mapping will fail.
The unknown-policer command is ignored for instances of the policer applied to SAPs or
subscribers where unknown packets are not supported.
The no form of this command is used to restore the mapping of the unknown forwarding type within the forwarding class to the default multipoint queue. If all forwarding class forwarding types had been removed from the default multipoint queue, the queue will not exist on the SAPs or
subscriber associated with the QoS policy and the no broadcast-policer command will cause the system to attempt to create the default multipoint queue on each object. If the system cannot create the queue on each instance, the no unknown-policer command will fail and the unknown forwarding type within the forwarding class will continue its mapping to the existing policer-id. If the no unknown-policer command results in a policer without any current mappings, the policer will be removed from the SAPs and subscribers associated with the QoS policy. All statistics associated with the policer on each SAP and subscriber will be lost.
When the forwarding class unknown-policer command is executed, a valid
policer-id must be specified. The parameter
policer-id references a
policer-id that has already been created within the
sap-ingress QoS policy.
dot1p dot1p-value [fc
fc-name] [profile
{in |out
| use-de
}]
This command explicitly sets the forwarding class or sub-class or enqueuing priority when a packet is marked with a dot1p-priority specified. Adding a dot1p rule on the policy forces packets that match the
dot1p-priority specified to override the forwarding class and enqueuing priority based on the parameters included in the dot1p rule. When the forwarding class is not specified in the rule, a matching packet preserves (or inherits) the existing forwarding class derived from earlier matches in the classification hierarchy. When the enqueuing priority is not specified in the rule, a matching packet preserves (or inherits) the existing enqueuing priority derived from earlier matches in the classification hierarchy.
The dot1p-priority is derived from the most significant three bits in the IEEE 802.1Q or IEEE 802.1P header. The three dot1p bits define 8 Class-of-Service (CoS) values commonly used to map packets to per-hop Quality-of-Service (QoS) behavior.
The no form of this command removes the explicit dot1p classification rule from the SAP ingress policy. Removing the rule on the policy immediately removes the rule on all ingress SAPs using the policy.
|
Values
|
in — All frames are treated as in-profile.
|
out — All frames are treated as out of profile.
use-de — The profile of all frames is set according to the DEI bit.
dscp dscp-name fc
fc-name [profile
{in
| out
}]
This command explicitly sets the forwarding class or subclass or enqueuing priority when a packet is marked with the DiffServ Code Point (DSCP) value contained in the dscp-name. Adding a DSCP rule on the policy forces packets that match the DSCP value specified to override the forwarding class and enqueuing priority based on the parameters included in the DSCP rule. When the forwarding class is not specified in the rule, a matching packet preserves (or inherits) the existing forwarding class derived from earlier matches in the classification hierarchy. When the enqueuing priority is not specified in the rule, a matching packet preserves (or inherits) the existing enqueuing priority derived from earlier matches in the classification hierarchy.
The DSCP value (referred to by dscp-name) is derived from the most significant six bits in the IP header ToS byte field (DSCP bits). The six DSCP bits define 64 DSCP values used to map packets to per-hop Quality-of-Service (QoS) behavior. The most significant three bits in the IP header ToS byte field are also commonly used in a more traditional manner to specify an IP precedence value, causing an overlap between the precedence space and the DSCP space. Both IP precedence and DSCP classification rules are supported. DSCP rules have a higher match priority than IP precedence rules and where a
dscp-name DSCP value overlaps an
ip-prec-value, the DSCP rule takes precedence.
Multiple dscp-name entries in the DSCP master table can point to the same DSCP bits value. When two DSCP rules specify different
dscp-name, but the names contain the same DSCP bits value, the previous DSCP name is removed and replaced by the latest entry.
The no form of the command removes the explicit DSCP classification rule from the SAP ingress policy. Removing the rule on the policy immediately removes the rule on all ingress SAPs using the policy.
The dscp-name is a required parameter that specifies the unique IP header ToS byte DSCP bits value that will match the DSCP rule. If the command is executed multiple times with the same
dscp-name or a
dscp-name that contains the same DSCP bit value, the previous forwarding class and enqueuing priority is completely overridden by the new parameters or defined to be inherited when a forwarding class or enqueuing priority parameter is missing.
The specified name must exist as a dscp-name.
SR OS software provides names for the well-known code points. The system-defined names available are as follows. The system-defined names are referenced lower case letters or exactly as shown in the first column in the following tables.
The value given for fc-name must be one of the predefined forwarding classes in the system. Specifying the
fc-name is optional. When a packet matches the rule the forwarding class is only overridden when the
fc fc-name parameter is defined on the rule. If the packet matches and the forwarding class is not explicitly defined in the rule, the forwarding class is inherited based on previous rule matches.
|
Default
|
Inherit (When fc fc-name is not defined, the rule preserves the previous forwarding class of the packet.)
|
This parameter is used in conjunction with the priority parameter. Setting the enqueuing parameter to
high for a packet increases the likelihood of enqueuing the packet when the ingress queue is congested. Ingress enqueuing priority only affects ingress SAP queuing. Once the packet is placed in a buffer on the ingress queue, the significance of the enqueuing priority is lost.
This parameter is used in conjunction with the priority parameter. Setting the enqueuing parameter to
low for a packet decreases the likelihood of enqueuing the packet when the ingress queue is congested. Ingress enqueuing priority only affects ingress SAP queuing, once the packet is placed in a buffer on the ingress queue, the significance of the enqueuing priority is lost.
|
Default
|
Inherit (When priority is not defined, the rule preserves the previous enqueuing priority of the packet.)
|
dscp dscp-name [fc
fc-name] [hsmda-counter-override
counter-id] [profile
{in
| out
}]
This command defines a specific IP Differentiated Services Code Point (DSCP) value that must be matched to perform the associated reclassification actions. If an egress packet on the SAP matches the specified IP DSCP value, the forwarding class, profile or HSMDA egress queue accounting behavior may be overridden. By default, the forwarding class and profile of the packet is derived from ingress classification and profiling functions. The default behavior for HSMDA queue accounting is to use the counters associated with the queue to which the packet is mapped. Matching a DHCP based reclassification rule will override all IP precedence based reclassification rule actions.
The fc keyword is optional. When specified, the egress classification rule will overwrite the forwarding class derived from ingress. The new forwarding class is used for egress remarking and queue mapping decisions. If an ip-criteria match occurs after the prec match, the new forwarding class may be overridden by the higher priority match actions. If the higher priority match actions do not specify a new fc, the fc from the dscp match will be used.
The profile keyword is optional. When specified, the egress classification rule will overwrite the profile of the packet derived from ingress. The new profile value is used for egress remarking and queue congestion behavior. If an ip-criteria match occurs after the dscp match, the new profile may be overridden by the higher priority match actions. If the higher priority match actions do not specify a new profile, the profile from the dscp match will be used.
The no form of the command removes the reclassification rule from the SAP egress QoS policy.
The fc reclassification action is optional. When specified, packets matching the IP DSCP value will be explicitly reclassified to the forwarding class specified as fc-name regardless of the ingress classification decision. The explicit forwarding class reclassification may be overwritten by an ip-criteria reclassification match. The fc-name defined must be one of the eight forwarding classes supported by the system. To remove the forwarding class reclassification action for the specified dscp-value, the dscp command must be re-executed without the fc reclassification action defined.
The in parameter is mutually excusive to the out parameter following the profile reclassification action keyword. Either in or out must be specified when the profile keyword is present. When in is specified, any packets matching the reclassification rule will be treated as in-profile by the egress forwarding plane. This value may be overwritten by an explicit profile action in an ip-criteria reclassification match.
The out parameter is mutually excusive to the in parameter following the profile reclassification action keyword. Either in or out must be specified when the profile keyword is present. When out is specified, any packets matching the reclassification rule will be treated as out-of-profile by the egress forwarding plane. This value may be overwritten by an explicit profile action in an ip-criteria reclassification match.
IP criteria-based SAP ingress policies are used to select the appropriate ingress queue and corresponding forwarding class for matched traffic.
7750 SR OS implementation will exit on the first match found and execute the actions in accordance with the accompanying action command. For this reason entries must be sequenced correctly from most to least explicit.
The no form of this command deletes all the entries specified under this node. Once IP criteria entries are removed from a SAP ingress policy, the IP criteria is removed from all services where that policy is applied.
IP criteria-based SAP egress policies are used to select the appropriate ingress queue and corresponding forwarding class for matched traffic.
7750 SR OS implementation will exit on the first match found and execute the actions in accordance with the accompanying action command. For this reason entries must be sequenced correctly from most to least explicit.
The no form of this command deletes all the entries specified under this node. Once IP criteria entries are removed from a SAP ingress policy, the IP criteria is removed from all services where that policy is applied.
IPv6 criteria-based SAP ingress policies are used to select the appropriate ingress queue and corresponding forwarding class for matched traffic.
7750 SR OS implementation will exit on the first match found and execute the actions in accordance with the accompanying action command. For this reason entries must be sequenced correctly from most to least explicit.
The no form of this command deletes all the entries specified under this node. Once ipv6-criteria entries are removed from a SAP ingress policy, the ipv6-criteria is removed from all services where that policy is applied.
lsp-exp lsp-exp-value [fc fc-name] [priority {low|high}] [hsmda-counter-override counter-id]
The lsp-exp-value is derived from the MPLS LSP EXP bits of the top label.
The no form of this command removes the explicit lsp-exp classification rule from the SAP ingress policy. Removing the rule on the policy immediately removes the rule on all ingress SAPs using the policy.
The mac-criteria based SAP ingress policies are used to select the appropriate ingress queue and corresponding forwarding class for matched traffic.
Router implementation will exit on the first match found and execute the actions in accordance with the accompanying action command. For this reason entries must be sequenced correctly from most to least explicit.
The no form of this command deletes all the entries specified under this node. Once mac-criteria entries are removed from a SAP ingress policy, the mac-criteria is removed from all services where that policy is applied.
The no form of this command is used to delete a policer from a sap-ingress or sap-egress QoS policy. The specified policer cannot currently have any forwarding class mappings for the removal of the policer to succeed. It is not necessary to actually delete the policer ID for the policer instances to be removed from SAPs or
subscriber associated with the QoS policy once all forwarding classes have been moved away from the policer. It is automatically deleted from each policing instance although it still appears in the QoS policy.
The policer-id must be specified when executing the policer command. If the specified ID already exists, the system enters that policer's context to allow the policer’s parameters to be modified. If the ID does not exist and is within the allowed range for the QoS policy type, a context for the policer ID will be created (depending on the system's current create keyword requirements which may require the create keyword to actually add the new policer ID to the QoS policy) and the system will enter that new policer’s context for possible parameter modification.
The description command is used to define an informational ASCII string associated with the policer control policy. The string value can be defined or changed at any time once the policy exists.
The no form of this command is used to remove an explicit description string from the policer.
The description-string parameter defines the ASCII description string for the policer control policy. The description string can be up to 80 characters. If the string contains spaces, it must be placed within beginning and ending double quotation marks. Beginning and ending quotation marks are not considered part of the description string. Only printable ASCII characters are allowed in the string. The sting does not need to be unique and may be repeated in the descriptions for other policer control policies or other objects. If the command is executed without the description-sting present, any existing description string will be unaffected.
[no
] adv-config-policy
policy-name
Once a policy is created, it may be applied to a queue or policer defined within a sap-egress or
sap-ingress QoS policy. It may also be applied to a queue or policer defined within an ingress or
egress queue-group template. When a policy is currently associated with a QoS policy or template, the policy may be modified but not deleted (even in the event that the QoS policy or template is not in use).
The no form of this command
removes the specified advanced policy.
The max keyword tells the system that the defined rate is the maximum rate that should be given to the policer. If the hardware cannot exactly match the given rate, the next lowest hardware supported rate is used.
The min keyword tells the system that the defined rate is the minimum rate that should be given to the policer. If the hardware cannot exactly match the given rate, the next highest hardware supported rate is used.
The closest keyword tells the system that the defined rate is the target rate for the policer. If the hardware cannot exactly match the given rate, the system will use the closest hardware supported rate compared to the target rate.
The no form of this command is used to return the policer’s metering and profiling hardware adaptation rules to closest.
pir {
max |
min |
closest}
When the optional pir parameter is specified, the
max,
min or
closest keyword qualifier must follow.
The max keyword is used to inform the system that the metering rate defined for the policer is the maximum allowed rate. The system will choose a hardware supported rate that is closest but not exceeding the specified rate.
The min keyword is used to inform the system that the metering rate defined for the policer is the minimum allowed rate. The system will choose a hardware supported rate that is closest but not lower than the specified rate.
The closest keyword is used to inform the system that the metering rate defined for the policer is the target rate. The system will choose a hardware supported rate that is closest to the specified rate.
cir {
max |
min |
closest}
When the optional cir parameter is specified, the
max,
min or
closest keyword qualifier must follow.
The max keyword is used to inform the system that the profiling rate defined for the policer is the maximum allowed rate. The system will choose a hardware supported rate that is closest but not exceeding the specified rate.
cbs {size [bytes
| kilobytes
] | default
}
The policer’s cbs size defined in the QoS policy may be overridden on an
sla-profile or SAP where the policy is applied.
The size parameter is required when specifying
cbs and is expressed as an integer representing the required size in either bytes or kilobytes. The default is kilobytes. The optional
byte and
kilobyte keywords are mutually exclusive and are used to explicitly define whether size represents bytes or kilobytes.
When byte is defined, the value given for size is interpreted as the queue’s MBS value given in bytes.
When kilobytes is defined, the value is interpreted as the queue’s MBS value given in kilobytes.
This command is used to configure the percentage of the policer’s PIR leaky bucket's MBS (maximum burst size) that is reserved for high priority traffic. While the mbs value defines the policer’s high priority violate threshold, the percentage value defined is applied to the
mbs value to derive the bucket’s low priority violate threshold. See the
mbs command details for information on which types of traffic is associated with each violate threshold.
The percent-of-mbs parameter is required when specifying
high-prio-only and is expressed as a percentage with granularity of 1,000th of a percent.
mbs {size [bytes
| kilobytes
] | default
}
This command is used to configure the policer’s PIR leaky bucket’s high priority violate threshold. The high-prio-only command is applied to the MBS value to derive the bucket’s low priority violate threshold. For ingress, trusted in-profile packets and un-trusted high priority packets use the policer’s high priority violate threshold while trusted out-of-profile and un-trusted low priority packets use the policer's low priority violate threshold. At egress, in-profile packets use the policer’s high priority violate threshold and out-of-profile packets use the policer's low priority violate threshold.
The size parameter is required when specifying
mbs and is expressed as an integer representing the required size in either bytes or kilobytes. The default is kilobytes. The optional
byte and
kilobyte keywords are mutually exclusive and are used to explicitly define whether size represents bytes or kilobytes.
When byte is defined, the value given for size is interpreted as the queue’s MBS value given in bytes.
When kilobytes is defined, the value is interpreted as the queue’s MBS value given in kilobytes.
This command is used to modify the size of each packet handled by the policer by adding or subtracting a number of bytes. The actual packet size is not modified; only the size used to determine the bucket depth impact is changed. The packet-byte-offset command is meant to be an arbitrary mechanism the can be used to either add downstream frame encapsulation or remove portions of packet headers. Both the policing metering and profiling throughput is affected by the offset as well as the stats associated with the policer.
The policer’s packet-byte-offset defined in the QoS policy may be overridden on an
sla-profile or SAP where the policy is applied.
The no version of this command is used to remove per packet size modifications from the policer.
The add keyword is mutually exclusive to the
subtract keyword. Either
add or
subtract must be specified. When
add is defined the corresponding bytes parameter specifies the number of bytes that is added to the size each packet associated with the policer for rate metering, profiling and accounting purposes. From the policer’s perspective, the maximum packet size is increased by the amount being added to the size of each packet.
The subtract keyword is mutually exclusive to the
add keyword. Either
add or
subtract must be specified. When b is defined the corresponding bytes parameter specifies the number of bytes that is subtracted from the size of each packet associated with the policer for rate metering, profiling and accounting purposes. From the policer’s perspective, the maximum packet size is reduced by the amount being subtracted from the size of each packet.
parent {root
| arbiter-name} [level
level] [weight
weight-within-level]
This command is used to create a child to parent mapping between each instance of the policer and either the root arbiter or a specific tiered
arbiter on the object where the policy is applied. Defining a parent association for the policer causes the policer to compete for the parent policer’s available bandwidth with other child policers mapped to the policer control hierarchy.
Policer control hierarchies may be created on SAPs or on a subscriber context. To create a policer control hierarchy on an ingress or egress SAP context, a
policer-control-policy must be applied to the SAP. Once applied, the system will create a parent policer that is bandwidth limited by the policy’s
max-rate value under the root arbiter. The root arbiter in the policy also provides the information used to determine the various priority level discard-unfair and discard-all thresholds. Besides the root arbiter, the policy may also contain user defined tiered arbiters that provide arbitrary bandwidth control for subsets of child policers that are either directly or indirectly parented by the arbiter.
When the QoS policy containing the policer with a parent mapping to an arbiter name exists on the SAP, the system will scan the available arbiters on the SAP. If an arbiter exists with the appropriate name, the policer to arbiter association is created. If the specified arbiter does not exist either because a
policer-control-policy is not currently applied to the SAP or the arbiter name does not exist within the applied policy, the policer is placed in an orphan state. Orphan policers operate as if they are not parented and are not subject to any bandwidth constraints other than their own PIR. When a policer enters the orphan state, it is flagged as operationally degraded due to the fact that it is not operating as intended and a trap is generated. Whenever a
policer-control-policy is added to the SAP or the existing policy is modified, the SAP's policer's parenting configurations must be reevaluated. If an orphan policer becomes parented, the degraded flag should be cleared and a resulting trap should be generated.
For subscribers, the policer control hierarchy is created through the policer-control-policy applied to the
sub-profile used by the subscriber. A unique policer control hierarchy is created for each subscriber associated with the
sub-profile. The QoS policy containing the policer with the parenting command comes into play through the subscriber
sla-profile which references the QoS policy. The combining of the
sub-profile and the
sla-profile at the subscriber level provides the system with the proper information to create the policer control hierarchy instance for the subscriber.
Executing the parent command will fail if:
A policer with a parent command applied cannot be configured with
stat-mode no-stats in either the QoS policy or as an override on an instance of the policer
Once a policer is successfully parented to an arbiter, the parent commands
level and
weight parameters are used to determine at what priority level and at which weight in the priority level that the child policer competes with other children (policers or other arbiters) for bandwidth.
The no form of this command is used to remove the parent association from all instances of the policer.
When the parent command is executed, either the keyword
root or an
arbiter-name must be specified.
The root keyword specifies that the policer is intended to become a child to the
root arbiter where an instance of the policer is created. If the
root arbiter does not exist, the policer will be placed in the orphan state.
The arbiter-name parameter specifies that the policer is intended to become a child to one of the tiered arbiters with the given arbiter-name where an instance of the policer is created. If the specified arbiter-name does not exist, the policer will be placed in the orphan state.
The weight weight-within-level keyword and parameter are optional when executing the
parent command. When
weight is not specified, a default level of 1 is used in the parent arbiters priority level. When
weight is specified, the
weight-within-level parameter must be specified as an integer value from 1 through 100.
The percent-rate command within the egress queue group template and on the port queue group queue overrides enables supports a queue’s shaping rate and CIR rate as a percentage of the egress port’s line rate. When the rates are expressed as a percentage within the template, the actual rate used per instance of the queue group queue-id will vary based on the port speed. For example, when the same template is used to create a queue group on a 1-Gigabit and a 10-Gigabit Ethernet port, the queue’s rates will be 10 times greater on the 10 Gigabit port due to the difference in port speeds. This enables the same template to be used on multiple ports without needing to use port based queue overrides to modify a queue’s rate to get the same relative performance from the queue.
The no form of this command returns the queue to its default shaping rate and cir rate. When
no percent-rate is defined within a port egress queue group queue override, the queue reverts to the defined shaping and CIR rates within the egress queue group template associated with the queue.
The percent-of-line-rate parameter is used to express the queue’s shaping rate as a percentage of line rate. The line rate associated with the queue’s port may dynamically change due to configuration or auto-negotiation. The line rate may also be affected by an egress port scheduler defined max-rate.
The cir keyword is optional and when defined the required
percent-of-line-rate CIR parameter expresses the queue’s committed scheduling rate as a percentage of line rate. The line rate associated with the queue’s port may dynamically change due to configuration or auto-negotiation. The line rate may also be affected by an egress port scheduler defined max-rate.
rate {max
| kilobits-per-second
} [cir
{max
| kilobits-per-second
}]
The policer’s adaptation-rule command settings are used by the system to convert the specified rates into hardware timers and decrement values for the policer’s buckets.
By default, the policer’s metering rate is max and the profiling rate is 0 Kbps (all packets out-of-profile).
The rate settings defined for the policer in the QoS policy may be overridden on an
sla-profile or SAP where the policy is applied.
The no form of this command is used to restore the default metering and profiling rate to a policer.
{max |
kilobits-per-second}
Specifying the keyword max or an explicit
kilobits-per-second parameter directly following the rate command is required and identifies the policer’s metering rate for the PIR leaky bucket. When the policer is first created, the metering rate defaults to max. The
kilobits-per-second value must be expressed as an integer and defines the rate in kilobits-per-second. The integer value is multiplied by 1,000 to derive the actual rate in bits-per-second.
cir {max | kilobits-per-second
}
The optional cir keyword is used to override the default CIR rate of the policer. Specifying the keyword max or an explicit
kilobits-per-second parameter directly following the cir keyword is required and identifies the policer’s profiling rate for the CIR leaky bucket. When the policer is first created, the profiling rate defaults to 0 Kbps. The
kilobits-per-second value must be expressed as an integer and defines the rate in kilobits-per-second. The integer value is multiplied by 1,000 to derive the actual rate in bits-per-second.
stat-mode {no-stats
| minimal
| offered-profile-no-cir
| offered-priority-no-cir
| offered-limited-profile-cir
| offered-profile-cir
| offered-priority-cir
| offered-total-cir | offered-profile-capped-cir | offered-limited-capped-cir
}
While a no-stats mode is supported which prevents any packet accounting, the use of the policer’s
parent command requires at the policer's
stat-mode to be set at least to the
minimal setting so that offered stats are available for the policer's Fair Information Rate (FIR) to be calculated. Once a policer has been made a child to a parent policer, the
stat-mode cannot be changed to
no-stats unless the policer parenting is first removed.
Each time the policer’s stat-mode is changed, any previous counter values are lost and any new counters are set to zero.
Each mode uses a certain number of counters per policer instance that are allocated from the forwarding plane’s policer counter resources. You can view the the total/allocated/free stats by using the tools dump system-resources command. If insufficient counters exist to implement a mode on any policer instance, the
stat-mode change will fail and the previous mode will continue unaffected for all instances of the policer.
The default stat-mode when a policer is created within the policy is
minimal.
The stat-mode setting defined for the policer in the QoS policy may be overridden on an
sla-profile or SAP where the policy is applied. If insufficient policer counter resources exist to implement the override, the
stat-mode override command will fail. The previous
stat-mode setting active for the policer will continue to be used by the policer.
The no form of this command attempts to return the policer’s stat-mode setting to minimal. The command will fail if insufficient policer counter resources exist to implement minimal where the QoS policer is currently applied and has a forwarding class mapping.
When collect-stats is enabled, the lack of counters causes the system to generate the following statistics:
The default stat-mode for a policer is
minimal. The
minimal mode allocates 1 forwarding plane offered counter and one traffic manager discard counter. The forwarding counter is derived by subtracting the discard counter from the offered counter. The counters do not differentiate possible offered types (profile or priority) and do not count green or yellow output. This does not prevent the policer from supporting different offered packet types and does not prevent the policer from supporting a CIR rate.
When collect-stats is enabled, the counters are used by the system to generate the following statistics:
With minimal enabled as the policer
stat-mode, the SAP offered stats for the policer returned via MIB query and CLI show commands will return the following values:
The offered-profile-no-cir mode allocates two forwarding plane offered counters and two traffic manager discard counters.
The offered-profile-no-cir mode is most useful when the policer is receiving only in-profile and out-of-profile pre-marked (and trusted) packets. It is expected that in this instance a CIR rate will not be defined since all packet are already pre-marked. This mode does not prevent the policer from receiving un-trusted (color undefined) nor does it prevent the policer from being configured with a CIR rate.
When collect-stats is enabled, the counters are used by the system to generate the following statistics:
With offered-profile-no-cir enabled as the policer
stat-mode, the SAP offered stats for the policer returned via MIB query and CLI show commands will return the following values:
The offered-priority-no-cir mode allocates two forwarding plane offered counters and two traffic manager discard counters.
The offered-priority-no-cir mode is most useful when the policer is receiving only un-trusted packets and the ingress priority high and priority low classification options are being used without a CIR profiling rate defined. This mode does not prevent the policer from receiving trusted packets that are pre-marked in-profile or out-of-profile nor does it prevent the policer from being configured with a CIR rate.
When collect-stats is enabled, the counters are used by the system to generate the following statistics:
With offered-priority-no-cir enabled as the policer
stat-mode, the SAP offered stats for the policer returned via MIB query and CLI show commands will return the following values:
The offered-limitied-profile-cir mode allocates three forwarding plane offered counters and three traffic manager discard counters.
The offered-limited-profile-cir mode is most useful when the policer is receiving trusted out-of-profile (profile out but no profile in) traffic and un-trusted packets are being applied to a defined CIR profiling rate. This mode does not prevent the policer from receiving trusted in-profile packets.
When collect-stats is enabled, the counters are used by the system to generate the following statistics:
With offered-limited-profile-cir enabled as the policer
stat-mode, the SAP offered stats for the policer returned via MIB query and CLI show commands will return the following values:
The offered-profile-cir mode allocates four forwarding plane offered counters and four traffic manager discard counters.
The offered-profile-cir mode is most useful when the policer is receiving trusted out-of-profile and in-profile traffic and is also receiving un-trusted packets that are being applied to a defined CIR profiling rate. This mode differs from
offered-limited-profile-cir mode in that it expects both trusted in-profile and out-of-profile packets while still performing CIR profiling on packets with un-trusted markings. It is expected that in most cases where both trusted and un-trusted packets are received, the predominate case will not include trusted in-profile packets making the offered-limited-profile-cir accounting mode acceptable.
When collect-stats is enabled, the counters are used by the system to generate the following statistics:
With offered-profile-cir enabled as the policer
stat-mode, the SAP offered stats for the policer returned via MIB query and CLI show commands will return the following values:
The offered-priority-cir mode allocates four forwarding plane offered counters and four traffic manager discard counters.
The offered-priority-cir mode is most useful when the policer is receiving only un-trusted packets that are being classified as high priority or low priority and are being applied to a defined CIR profiling rate. This mode differs from
offered-profile-cir mode in that it does not expect trusted in-profile and out-of-profile packets but does not exclude the ability of the policer to receive them.
When collect-stats is enabled, the counters are used by the system to generate the following statistics:
With offered-priority-cir enabled as the policer
stat-mode, the SAP offered stats for the policer returned via MIB query and CLI show commands will return the following values:
The offered-total-cir mode allocates two forwarding plane offered counters and two traffic manager discard counters.
The offered-total-cir mode is most useful when the policer is not receiving trusted in-profile or out-of-profile traffic and both high and low priority classifications are not being used on the un-trusted packets and the offered packets are being applied to a defined CIR profiling rate. This mode does not prevent the policer from receiving trusted in-profile or out-of-profile packets and does not prevent the use of priority high or low classifications on the un-trusted packets.
When collect-stats is enabled, the counters are used by the system to generate the following statistics:
With offered-total-cir enabled as the policer
stat-mode, the SAP offered stats for the policer returned via MIB query and CLI show commands will return the following values:
When offered-profile-capped-cir is defined, the system creates five offered-output counters in the forwarding plane and five discard counters in the traffic manager.
The offered-profile-capped-cir mode is similar to the offered-profile-cir mode except that it includes support for profile in and
soft-in-profile that may be output as ‘out-of-profile’ due to enabling
profile-capped mode on the ingress policer.
The impact of using offered-profile-capped-cir stat-mode while
profile-capped mode is disabled are that one of the counting resources in the forwarding plane and traffic manager will not be used and soft-in-profile will be treated as ‘offered-in’ instead of ‘offered-undefined’.
offered-limited-capped-cir is defined, the system creates four forwarding plane offered-output counters in the network processor and four discard counters in the traffic manager.
The offered-limited-capped-cir mode is similar to the
offered-profile-capped-cir mode except that it combines
profile out and
soft-out-of-profile and eliminates the ‘offered-undefined’ statistic.
The impact of using offered-limited-capped-cir stat-mode while
profile-capped mode is disabled are that one of the counting resources in the forwarding plane and traffic manager will not be used and
soft-in-profile will be treated as ‘offered-in’ instead of ‘offered-undefined’.
prec ip-prec-value fc
fc-name [priority
{high
| low
}]
This command explicitly sets the forwarding class or enqueuing priority when a packet is marked with an IP precedence value (ip-prec-value). Adding an IP precedence rule on the policy forces packets that match the specified
ip-prec-value to override the forwarding class and enqueuing priority based on the parameters included in the IP precedence rule.
The ip-prec-value is derived from the most significant three bits in the IP header ToS byte field (precedence bits). The three precedence bits define 8 Class-of-Service (CoS) values commonly used to map packets to per-hop Quality-of-Service (QoS) behavior. The precedence bits are also part of the newer DiffServ Code Point (DSCP) method of mapping packets to QoS behavior. The DSCP uses the most significant six bits in the IP header ToS byte and so overlaps with the precedence bits. Both IP precedence and DSCP classification rules are supported. DSCP rules have a higher match priority than IP precedence rules and where a
dscp-name DSCP value overlaps an
ip-prec-value, the DSCP rule takes precedence.
The no form of the command removes the explicit IP precedence classification rule from the SAP ingress policy. Removing the rule on the policy immediately removes the rule on all ingress SAPs using the policy.
The ip-prec-value is a required parameter that specifies the unique IP header ToS byte precedence bits value that will match the IP precedence rule. If the command is executed more than once with the same
ip-prec-value, the previous forwarding class and enqueuing priority is completely overridden by the new parameters or defined to be inherited when a forwarding class or enqueuing priority parameter is missing.
The value given for the fc-name parameter must be one of the predefined forwarding classes in the system. Specifying the
fc-name is optional. When a packet matches the rule the forwarding class is only overridden when the
fc fc-name parameter is defined on the rule. If the packet matches and the forwarding class is not explicitly defined in the rule, the forwarding class is inherited based on previous rule matches.
|
Default
|
Inherit (When fc is not defined, the rule preserves the previous forwarding class of the packet.)
|
This parameter is used in conjunction with the priority parameter. Setting the enqueuing parameter to
high for a packet increases the likelihood of enqueuing the packet when the ingress queue is congested. Ingress enqueuing priority only affects ingress SAP queuing. When the packet is placed in a buffer on the ingress queue, the significance of the enqueuing priority is lost.
This parameter is used in conjunction with the priority parameter. Setting the enqueuing parameter to
low for a packet decreases the likelihood of enqueuing the packet when the ingress queue is congested. Ingress enqueuing priority only affects ingress SAP queuing. When the packet is placed in a buffer on the ingress queue, the significance of the enqueuing priority is lost.
|
Default
|
Inherit (When priority is not defined, the rule preserves the previous enqueuing priority of the packet.)
|
prec ip-prec-value fc
fc-name [hsmda-counter-override
counter-id] [profile
{in
| out
}]
The fc keyword is optional. When specified, the egress classification rule will overwrite the forwarding class derived from ingress. The new forwarding class is used for egress remarking and queue mapping decisions. If a dhcp or ip-criteria match occurs after the prec match, the new forwarding class may be overridden by the higher priority match actions. If the higher priority match actions do not specify a new fc, the fc from the prec match will be used.
The profile keyword is optional. When specified, the egress classification rule will overwrite the profile of the packet derived from ingress. The new profile value is used for egress remarking and queue congestion behavior. If a dhcp or ip-criteria match occurs after the prec match, the new profile may be overridden by the higher priority match actions. If the higher priority match actions do not specify a new profile, the profile from the prec match will be used.
The no form of the command removes the reclassification rule from the SAP egress QoS policy.
queue queue-id [multipoint
] [queue-type] [queue-mode] pool pool-name
queue queue-id [multipoint
] [queue-type] pool pool-name
Explicit definition of an ingress queue’s hardware scheduler status is supported. A single ingress 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 internal switch fabric destinations. The hardware status of the queue must be defined at the time of queue creation within the policy.
The queue command allows the creation of multipoint queues. Only multipoint queues can receive ingress packets that need flooding to multiple destinations. By separating the unicast for multipoint traffic at service ingress and handling the traffic on separate multipoint queues special handling of the multipoint traffic is possible. Each queue acts as an accounting and (optionally) shaping device offering precise control over potentially expensive multicast, broadcast and unknown unicast traffic. Only the back-end support of multipoint traffic (between the forwarding class and the queue based on forwarding type) needs to be defined. The individual classification rules used to place traffic into forwarding classes are not affected. Queues must be defined as multipoint at the time of creation within the policy.
When an ingress SAP QoS policy with multipoint queues is applied to an Epipe SAP, the multipoint queues are not created. When an ingress SAP QoS policy with multipoint queues is applied to an IES SAP, a multipoint queue will be created when PIM is enabled on the IES interface.
The no form of this command removes the queue-id from the SAP ingress QoS policy and from any existing SAPs using the policy. If any forwarding class forwarding types are mapped to the queue, they revert to their default queues. When a queue is removed, any pending accounting information for each SAP queue created due to the definition of the queue in the policy is discarded.
The queue-id for the queue, expressed as an integer. The
queue-id uniquely identifies the queue within the policy. This is a required parameter each time the queue command is executed.
The expedite,
best-effort and
auto-expedite queue types are mutually exclusive to each other. Each defines the method that the system uses to service the queue from a hardware perspective. While parental virtual schedulers can be defined for the queue, they only enforce how the queue interacts for bandwidth with other queues associated with the same scheduler hierarchy. An internal mechanism that provides access rules when the queue is vying for bandwidth with queues in other virtual schedulers is also needed. A keyword must be specified at the time the queue is created in the SAP ingress policy. If an attempt to change the keyword after the queue is initially defined, an error is generated.
This keyword specifies that this queue-id is for multipoint forwarded traffic only. This queue-id can only be explicitly mapped to the forwarding class multicast, broadcast, or unknown unicast ingress traffic. If you attempt to map forwarding class unicast traffic to a multipoint queue, an error is generated and no changes are made to the current unicast traffic queue mapping.
A queue must be created as multipoint. The multipoint designator cannot be defined after the queue is created. If an attempt is made to modify the command to include the multipoint keyword, an error is generated and the command will not execute.
The multipoint keyword can be entered in the command line on a pre-existing multipoint queue to edit queue-id parameters.
|
Values
|
profile-mode: When the queue is operating in the profile mode (or, the color aware mode), the queue tries to provide the appropriate bandwidth to the packets with different profiles. The profiles are assigned according to the configuration of the forwarding class or the sub-forwarding class.
|
priority-mode: The queue is capable of handling traffic differently with two distinct priorities. These priorities are assigned by the stages preceding the queueing framework in the system. In priority mode, the queue does not have the functionality to support the profiled traffic and in such cases the queue will have a degraded performance. However, the converse is not valid and a queue in profile mode should be capable of supporting the different priorities of traffic.
This command overrides the default broadcast forwarding type queue mapping for fc fc-name. The specified
queue-id must exist within the policy as a multipoint queue before the mapping can be made. Once the forwarding class mapping is executed, all broadcast traffic on a SAP using this policy will be forwarded using the
queue-id.
The no form of the command sets the broadcast forwarding type
queue-id back to the default of tracking the multicast forwarding type queue mapping.
The queue-id parameter must be an existing, multipoint queue defined in the
config>qos>sap-ingress context.
The priority option if used has no effect. All FR VLL DE=1 frames have automatically their priority set to low while DE=0 frames have their priority set to high. Furthermore, DE=1 frames have drop-preference bit set in the internal header. The internal settings of the priority bit and of the drop-preference bit of the frame is independent of the use or not of the profile mode.
This de-1-out-profile keyword has an effect when applied to the ingress of a SAP which is part of an fpipe service. It can also be used on the ingress of an epipe or vpls SAP.
The no form of the command disables the color profile mode of operation on all SAPs this ingress QoS policy is applied.
The no form of the command disables ingress remarking of in-profile packets classified to the forwarding class or sub-class.
32 characters, maximum, The name specified by dscp-name is used to refer to the six bit value represented by dscp-name. It must be one of the predefined DSCP names defined on the system.
|
Values
|
be, cp1, cp2, cp3, cp4, cp5, cp6, cp7, cs1, cp9, af11, cp11, af12, cp13, af13, cp15, cs2, cp17, af21, cp19, af22, cp21, af23, cp23, cs3, cp25, af31, cp27, af32, cp29, af33, cp31, cs4, cp33, af41, c p35, af42, cp37, af43, cp39, cs5, cp41, cp42, cp43, cp44, cp45, ef, cp47, nc1, cp49, cp50, cp51, cp52, cp53, cp54, cp55, nc2, cp57, cp58, cp59, cp60, cp61, cp62, cp63
|
This command overrides the default multicast forwarding type queue mapping for fc fc-name. The specified
queue-id must exist within the policy as a multipoint queue before the mapping can be made. Once the forwarding class mapping is executed, all multicast traffic on a SAP using this policy is forwarded using the
queue-id.
The multicast forwarding type includes the unknown unicast forwarding type and the
broadcast forwarding type unless each is explicitly defined to a different multipoint queue. When the unknown and broadcast forwarding types are left as default, they will track the defined queue for the multicast forwarding type.
The no form of the command sets the multicast forwarding type
queue-id back to the default queue for the forwarding class. If the
broadcast and
unknown forwarding types were not explicitly defined to a multipoint queue, they will also be set back to the default multipoint queue (queue 11).
The queue-id parameter specified must be an existing, multipoint queue defined in the
config>qos>sap-ingress context.
The no form of the command disables ingress remarking of out-of-profile packets classified to the forwarding class or sub-class.
|
Values
|
be, cp1, cp2, cp3, cp4, cp5, cp6, cp7, cs1, cp9, af11, cp11, af12, cp13, af13, cp15, cs2, cp17, af21, cp19, af22, cp21, af23, cp23, cs3, cp25, af31, cp27, af32, cp29, af33, cp31, cs4, cp33, af41, c p35, af42, cp37, af43, cp39, cs5, cp41, cp42, cp43, cp44, cp45, e f, cp47, nc1, cp49, cp50, cp51, cp52, cp53, cp54, cp55, nc2, cp57 , cp58, cp59, cp60, cp61, cp62, cp63
|
policer policer-id [fp-redirect-group
]
The no form of the command removes an explicit in-profile or out-of-profile configuration on a forwarding class or sub-class.
no profile — The default profile state of a forwarding class or sub-class is not to treat ingress packets as color aware. An explicit definition for in-profile or out-of-profile must be specified on the forwarding class or sub-class.
The in keyword is mutually exclusive to the
out keyword. When the profile in command is executed, all packets associated with the class will be handled as in-profile. Packets explicitly handled as in-profile or out-of-profile still flow through the ingress service queue associated with the class to preserve order within flows. In-profile packets will count against the CIR of the queue, diminishing the amount of CIR available to other classes using the queue that are not configured with an explicit profile.
The out keyword is mutually exclusive to the
in keyword. When the profile out command is executed, all packets associated with the class will be handled as out-of-profile. Packets explicitly handled as in-profile or out-of-profile still flow through the ingress service queue associated with the class to preserve order within flows. Out-of-profile packets will not count against the CIR of the queue, allowing other classes using the queue that are not configured with an explicit profile to be measured against the full CIR.
This command overrides the default unknown unicast forwarding type queue mapping for fc fc-name. The specified
queue-id must exist within the policy as a multipoint queue before the mapping can be made. Once the forwarding class mapping is executed, all unknown traffic on a SAP using this policy is forwarded using the
queue-id.
The no form of this command sets the unknown forwarding type
queue-id back to the default of tracking the multicast forwarding type queue mapping.
queue queue-id [{group queue-group-name [instance instance-id]} | port-redirect-group-queue]
This command overrides the default queue mapping for fc fc-name. The specified queue-id must exist within the policy before the mapping can be made. Once the forwarding class mapping is executed, all traffic classified to fc-name on a SAP using this policy.
The no form of this command sets the queue-id back to the default queue for the forwarding class (queue 1).
This optional parameter is used to redirect the forwarding type within the forwarding class to the specified queue-id within the
queue-group-name. When the policy is applied, all packets matching the forwarding class and forwarding type will be redirected to the queue within the specified queue group. The queue-group-name are configured in the
config>qos>queue-group-templates egress and ingress contexts. This parameter is used when policy based queue group redirection is desired. That is, the specific queue group to redirect to is named in the QoS policy.
This command enables the context to configure queue definitions for use on SAPs or subscribers on HSMDAs. A single QoS policy simultaneously defines queues for both standard MDA and for HSMDA subscribers and SAPs. This allows the policy association decision to be ignorant of the type of hardware the SAP or subscriber is traversing.
queue queue-id [port-redirect-group-queue]
The no form of the command restores the defined queue-id to its default parameters. All HSMDA queues having the queue-id and associated with the QoS policy are re-initialized to default parameters.
This command adds or subtracts the specified number of bytes to the accounting function for each packet handled by the HSMDA queue. Normally, the accounting and leaky bucket functions are based on the Ethernet DLC header, payload and the 4 byte CRC (everything except the preamble and inter-frame gap). As an example, the packet-byte-offset command can be used to add the frame encapsulation overhead (20 bytes) to the queues accounting functions.
The secondary shaper leaky bucket, scheduler priority level leaky bucket and the port maximum rate updates are not affected by the configured packet-byte-offset. Each of these accounting functions are frame based and always include the preamble, DLC header, payload and the CRC regardless of the configured byte offset.
The packet-byte-offset command accepts either add or subtract as valid keywords which define whether bytes are being added or removed from each packet traversing the queue. Up to 20 bytes may be added to the packet and up to 43 bytes may be removed from the packet. An example use case for subtracting bytes from each packet is an IP based accounting function. Given a Dot1Q encapsulation, the command packet-byte-offset subtract 14 would remove the DLC header and the Dot1Q header from the size of each packet for accounting functions only. The 14 bytes are not actually removed from the packet, only the accounting size of the packet is affected.
As inferred above, the variable accounting size offered by the packet-byte-offset command is targeted at the queue and queue group level. When the queue group represents the last-mile bandwidth constraints for a subscriber, the offset allows the HSMDA queue group to provide an accurate accounting to prevent overrun and underrun conditions for the subscriber. The accounting size of the packet is ignored by the secondary shapers, the scheduling priority level shapers and the scheduler maximum rate. The actual on-the-wire frame size is used for these functions to allow an accurate representation of the behavior of the subscribers packets on an Ethernet aggregation network.
The no form of the command removes any accounting size changes to packets handled by the queue. The command does not affect overrides that may exist on SAPs or subscriber profiles associated with the queue.
The no form of the command returns the class id for the queue to the default value.
Specifies the class identifier of the low burst max class for the HSMDA queue.
The no form of the command returns the weight value for the queue to the default value.
This command associates an existing HSMDA slope policy to the QoS policy HSMDA queue. The specified hsmda-slope-policy-name must exist for the command to succeed. If the policy name does not exist, the command has no effect on the existing slope policy association. Once a slope policy is associated with a QoS policy queue, subscriber profile override or SAP override, the slope policy cannot be removed from the system. Any edits to an associated slope policy are immediately applied to the queues using the slope policy.
Within the ingress and egress QoS policies, packets are classified as high priority or low-priority. For color aware policies, packets are also potentially classified as in-profile, out-of-profile or profile-undefined. Based on these classifications, packets are mapped to the RED slopes in the following manner:
The specified policy contains a value that defines the queue’s MBS value (queue-mbs). This is the maximum depth of the queue specified in bytes where all packets start to discard. The high and low priority RED slopes provide congestion control mechanisms that react to the current depth of the queue and start a random discard that increases in probability as the queue depth increases. The start point and end point for each discard probability slope is defined as follows:
The system maintains a slope policy named hsmda-default which acts as a default policy when an explicit slope policy has not been defined for an HSMDA queue. The default policy may be edited, but it cannot be deleted. If a no slope-policy hsmda-default command is executed, the default slope policy returns to the factory default settings. The factory default settings are as follows:
The no form of the command restores the association between the queue and the HSMDA default slope policy. The command has no immediate effect for queues that have a local override defined for the slope policy.
action [fc
fc-name] [priority
{high
| low
}]
This mandatory command associates the forwarding class or enqueuing priority with specific IP, IPv6 or MAC criteria entry ID. The action command supports setting the forwarding class parameter to a sub-class. Packets that meet all match criteria within the entry have their forwarding class and enqueuing priority overridden based on the parameters included in the
action parameters. When the forwarding class is not specified in the
action command syntax, a matching packet preserves (or inherits) the existing forwarding class derived from earlier matches in the classification hierarchy. When the enqueuing priority is not specified in the action, a matching packet preserves (or inherits) the existing enqueuing priority derived from earlier matches in the classification hierarchy.
The action command must be executed for the match criteria to be added to the active list of entries. If the entry is designed to prevent more explicit (higher entry ID) entries from matching certain packets, the
fc fc-name and
match protocol fields should not be defined when executing action. This allows packets matching the entry to preserve the forwarding class and enqueuing priority derived from previous classification rules.
Each time action is executed on a specific entry ID, the previous entered values for fc fc-name and
priority areoverridden with the newly defined parameters or inherits previous matches when a parameter is omitted.
The no form of the command removes the entry from the active entry list. Removing an entry on a policy immediately removes the entry from all SAPs using the policy. All previous parameters for the action is lost.
The value given for fc fc-name must be one of the predefined forwarding classes in the system. Specifying the
fc fc-name is required. When a packet matches the rule, the forwarding class is only overridden when the
fc fc-name parameter is defined on the rule. If the packet matches and the forwarding class is not explicitly defined in the rule, the forwarding class is inherited based on previous rule matches.
|
Default
|
Inherit (When fc fc-name is not defined, the rule preserves the previous forwarding class of the packet.)
|
The priority parameter overrides the default enqueuing priority for all packets received on a SAP using this policy that match this rule. Specifying the priority (
high or
low) is optional. When a packet matches the rule, the enqueuing priority is only overridden when the priority parameter is defined on the rule. If the packet matches and priority is not explicitly defined in the rule, the enqueuing priority is inherited based on previous rule matches.
|
Default
|
Inherit (When the priority ( high or low) is not defined, the rule preserves the previous enqueuing priority of the packet)
|
The high parameter is used in conjunction with the
priority parameter. Setting the
priority enqueuing parameter to
high for a packet increases the likelihood to enqueue the packet when the queue is congested. The enqueuing priority only affects ingress SAP queuing. When the packet is placed in a buffer on the queue, the significance of the enqueuing priority is lost.
The low parameter is used in conjunction with the
priority parameter. Setting the
priority enqueuing parameter to
low for a packet decreases the likelihood to enqueue the packet when the queue is congested. The enqueuing priority only affects ingress SAP queuing. When the packet is placed in a buffer on the ingress queue, the significance of the enqueuing priority is lost.
action [fc
fc-name] [hsmda-counter-override
counter-id] [profile
{in
| out
}]
If an egress packet on the SAP matches the specified IP flow entry, the forwarding class, profile or HSMDA egress queue accounting behavior may be overridden. By default, the forwarding class and profile of the packet is derived from ingress classification and profiling functions. The default behavior for HSMDA queue accounting is to use the counters associated with the queue to which the packet is mapped. Matching an IP flow reclassification entry will override all IP precedence or DSCP based reclassification rule actions when an explicit reclassification action is defined for the entry.
The fc keyword is optional. When specified, the egress classification rule will overwrite the forwarding class derived from ingress. The new forwarding class is used for egress remarking and queue mapping decisions.
The profile keyword is optional. When specified, the egress classification rule will overwrite the profile of the packet derived from ingress. The new profile value is used for egress remarking and queue congestion behavior.
The hsmda-counter-override keyword is optional. When specified and the egress SAP is created on an HSMDA, the egress classification rule will override the default queue accounting function for the packet. By default, the HSMDA uses each queues default queue counters for packets mapped to the queue. The hsmda-counter-override keyword is used to map the packet to an explicit exception counter. One of eight counters may be used. When the packet is mapped to an exception counter, the packet will not increment the queues discard or forwarding counters, instead the exception discard and forwarding counters will be used.
The no form of this command removes all reclassification actions from the IP flow reclassification entry and also removes the entry from the evaluation list. An entry removed from the evaluation list will not be matched to any packets egress a SAP associated with the SAP egress QoS policy.
[no
] entry
entry-id [create]
This command is used to create or edit an IP or IPv6 criteria entry for the policy. Multiple entries can be created using unique
entry-id numbers.
The no form of this command removes the specified entry from the policy. Entries removed from the policy are immediately removed from all services where that policy is applied.
The entry-id, expressed as an integer, uniquely identifies a match criterion and the corresponding action. It is recommended that multiple entries be given
entry-ids in staggered increments. This allows users to insert a new entry in an existing policy without requiring renumbering of all the existing entries.
[no
] match
[protocol
protocol-id]
A match context can consist of multiple match criteria, but multiple
match statements cannot be entered per entry.
It is possible that a SAP policy includes the dscp map command, the
dot1p map command, and an IP match criteria. When multiple matches occur for the traffic, the order of precedence is used to arrive at the final action. The order of precedence is as follows:
The no form of this command removes the match criteria for the
entry-id.
Specifies an IP protocol to be used as a SAP QoS policy match criterion.
|
Values
|
protocol-id: 0 — 255 protocol numbers accepted in DHB
keywords: none, crtp, crudp, egp, eigrp, encap, ether-ip, gre, icmp, idrp, igmp, igp, ip, ipv6, ipv6-frag, ipv6-icmp, ipv6-no-nxt, ipv6-opts, ipv6-route, isis, iso-ip, l2tp, ospf-igp, pim, pnni, ptp, rdp, rsvp, stp, tcp, udp, vrrp* — udp/tcp wildcard
|
match [next-header next-header]
This command creates a context to configure match criteria for ingress SAP QoS policy match IPv6 criteria. When the match criteria have been satisfied the action associated with the match criteria is executed.
A match context can consist of multiple match criteria, but multiple match statements cannot be entered per entry.
It is possible that a SAP ingress policy includes the dscp map command, the dot1p map command, and an IPv6 match criteria. When multiple matches occur for the traffic, the order of precedence is used to arrive at the final action. The order of precedence is as follows:
The no form of this command removes the match criteria for the entry-id.
|
Values
|
protocol numbers accepted in DHB: 0 — 42, 45 — 49, 52 — 59, 61 — 255
keywords: none, crtp, crudp, egp, eigrp, encap, ether-ip, gre, icmp, idrp, igmp, igp, ip, ipv6, ipv6-icmp, ipv6-no-nxt, isis, iso-ip, l2tp, ospf-igp, pim, pnni, ptp, rdp, rsvp, stp, tcp, udp, vrrp
* — udp/tcp wildcard
|
match [frame-type
{802dot3 | 802dot2-llc | 802dot2-snap | ethernet-II | atm
}]
A match context can consist of multiple match criteria, but multiple
match statements cannot be entered per entry.
The no form of the command removes the match criteria for the
entry-id.
The frame-type keyword configures an Ethernet frame type or an ATM frame type to be used for the MAC filter match criteria.
The no form of this command removes the VCI value as the match criterion.
The no form of this command removes the DSCP match criterion.
|
Values
|
be, cp1, cp2, cp3, cp4, cp5, cp6, cp7, cs1, cp9, af11, cp11, af12, cp13, af13, cp15, cs2, cp17, af21, cp19, af22, cp21, af23, cp23, cs3, cp25, af31, cp27, af32, cp29, af33, cp31, cs4, cp33, af41, c p35, af42, cp37, af43, cp39, cs5, cp41, cp42, cp43, cp44, cp45, ef, cp47, nc1, cp49, cp50, cp51, cp52, cp53, cp54, cp55, nc2, cp57, cp58, cp59, cp60, cp61, cp62, cp63
|
Each forwarding class has a default queue ID based on the intrinsic hierarchy between the forwarding classes as represented in Table 34. Executing the queue command within the HSMDA context of a forwarding class with a different queue ID than the default overrides the default mapping. Multiple forwarding classes may be mapped to the same HSMDA queue ID.
Table 35 presents the way that packets are mapped to queues based on the type of service and the various forwarding types.
dst-ip {ip-address/mask | ip-address netmask}
The no form of this command removes the destination IP address match criterion.
|
Values
|
ip-address: a.b.c.d
ipv6-address: x:x:x:x:x:x:x:x (eight 16-bit pieces) x:x:x:x:x:x:d.d.d.d x: [0 — FFFF]H d: [0 — 255]D prefix-length: 1 — 128
|
The no form of this command removes the destination port match criterion.
lt | gt
| eq
dst-port-number
The no form of this command removes the match criterion.
Configures a match on all non-fragmented IP packets. Non-fragmented IP packets are packets that have the MF bit set to zero and have the Fragment Offset field also set to zero.
src-ip {ip-address/mask | ip-address netmask}
This command configures a source IP or IPv6 address range to be used as an SAP QoS policy match criterion.
To match on the source IP or IPv6 address, specify the address and its associated mask, e.g. 10.1.0.0/16. The conventional notation of 10.1.0.0 255.255.0.0 can also be used.
The no form of the command removes the source IP or IPv6 address match criterion.
The IP or IPv6 address of the source IP interface. This address must be unique within the subnet and specified in dotted decimal notation.
|
Values
|
ip-address: a.b.c.d
ipv6-address: x:x:x:x:x:x:x:x (eight 16-bit pieces) x:x:x:x:x:x:d.d.d.d x: [0 — FFFF]H d: [0 — 255]D prefix-length: 1 — 128
|
The no form of this command removes the source port match criterion.
lt | gt
| eq
src-port-number
dot1p dot1p-value [dot1p-mask]
Use the no form of this command to remove the dot1p value as the match criterion.
dsap dsap-value [dsap-mask]
dst-mac ieee-address [ieee-address-mask]
The optional vid_mask is defaulted to 4095 (exact match) but may be specified to allow pattern matching. The masking operation is ((value & vid-mask) = = (tag & vid-mask)). A value of 6 and a mask of 7 would match all VIDs with the lower 3 bits set to 6.
The no form of this command removes the criterion from the match criteria.
Note: snap-pid match criteria is independent of the OUI field within the SNAP header. Two packets with different three-byte OUI fields but the same PID field will both match the same policy entry based on a snap-pid match criteria.
The no form of this command removes the snap-pid value as the match criteria.
src-mac ieee-address [ieee-address-mask]
The no form of this command removes the source mac as the match criteria.
ssap ssap-value [ssap-mask]
The no form of this command removes the ssap match criterion.
The fc fc
-name node 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 node 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.
|
Values
|
be, l2, af, l1, h2, ef, h1, nc
|
policer policer-id [ {[port-redirect-group-queue
] [queue
queue-id]} | {group
queue-group-name [instance
instance-id] [queue
group-queue-id]} ]
|
•
|
If the policer policer-id command is successfully executed, the default egress queuing is performed for the forwarding class using the policer-output-queues queue group and the queue-id within the group based on the forwarding class map from the group template
|
|
•
|
If the policer policer-id queue queue-id command is successfully executed, the specified SAP queue-id within egress QoS policy is used instead of the default policer output queues.
|
|
•
|
If the policer policer-id port-redirect-group-queue keyword is successfully executed, the system will map the forwarding class to the queue within the egress queue group instance specified at the time the QoS policy is applied to the SAP, using the forwarding class map from the queue group template.
|
|
•
|
If the policer policer-id port-redirect-group queue queue-id command is successfully executed, the system will map the forwarding class to the configured queue-id within the egress queue group instance that is specified at the time the QoS policy is applied to the SAP (ignoring using the forwarding class map from the queue group template).
|
|
•
|
If the policer policer-id group queue-group-name instance instace-id command is successfully executed, the system will map the forwarding class to the queue within the specified egress queue group instance using the forwarding class map from the group template.
|
|
•
|
If the policer policer-id group queue-group-name instance instance-id queue queue-id command is successfully executed, the system will map the forwarding class to the specified queue-id within the specified egress queue group instance (ignoring the forwarding class map in the group template).
|
If the specified group queue-group-name is not defined as an egress queue-group-template, the
policer command will fail. Further, if the specified group does not exist on the port for the SAPs or subscribers associated with the
sap-egress QoS policy, the policer command will fail. While a group queue-group-name is specified in a
sap-egress QoS policy, the groups corresponding egress template cannot be deleted. While a port egress queue group is associated with a policer instance, the port queue group cannot be deleted.
If the specified queue group-queue-id is not defined in the egress queue-group-template queue-group- name, the policer command will fail. While a queue-id within an egress queue group template is referenced by a
sap-egress QoS policy forwarding class policer command, the queue cannot be deleted from the queue group template.
The no form of this command is used to restore the mapping of the forwarding class to the default queue. If all forwarding classes have been removed from the default queue, the queue will not exist on the SAPs or subscribers associated with the QoS policy and the no policer command will cause the system to attempt to create the default queue on each object. If the system cannot create the default queue in each instance, the no policer command will fail and the forwarding class will continue its mapping to the existing
policer-id. If the no policer command results in a policer without any current mappings, the policer will be removed from the SAPs and subscribers associated with the QoS policy. All statistics associated with the policer on each SAP and subscribers will be lost.
When the forwarding class policer command is executed, a valid
policer-id must be specified. The parameter
policer-id references a
policer-id that has already been created within the
sap-ingress QoS policy.
The group queue-group-name is optional and is used to override the forwarding class's default egress queue destination. If the queue group-queue-id parameter is not specified, the forwarding class map within the specified group's template is used to derive which queue within the group will receive the forwarding class's packets. An egress queue group template must exist for the specified queue-group-name or the policer command will fail. The specified queue-group-name must also exist as an egress queue group on the ports where SAPs and subscribers associated with the sap-egress policy is applied or the policer command will fail.
The queue group-queue-id is optional when the group queue-group-name parameter is specified and is used to override the forwarding class mapping within the group's egress queue group template. The specified group-queue-id must exist within the group's egress queue group template or the policer command will fail.
The description command is used to define an informational ASCII string associated with the policer control policy. The string value can be defined or changed at any time once the policy exists.
The no form of this command is used to remove an explicit description string from the policer.
The description-string parameter defines the ASCII description string for the policer control policy. The description string can be up to 80 characters. If the string contains spaces, it must be placed within beginning and ending double quotation marks. Beginning and ending quotation marks are not considered part of the description string. Only printable ASCII characters are allowed in the string. The sting does not need to be unique and may be repeated in the descriptions for other policer control policies or other objects. If the command is executed without the description-sting present, any existing description string will be unaffected.
The max keyword tells the system that the defined rate is the maximum rate that should be given to the policer. If the hardware cannot exactly match the given rate, the next lowest hardware supported rate is used.
The min keyword tells the system that the defined rate is the minimum rate that should be given to the policer. If the hardware cannot exactly match the given rate, the next highest hardware supported rate is used.
The closest keyword tells the system that the defined rate is the target rate for the policer. If the hardware cannot exactly match the given rate, the system will use the closest hardware supported rate compared to the target rate.
The no form of this command is used to return the policer’s metering and profiling hardware adaptation rules to closest.
pir {
max |
min |
closest}
When the optional pir parameter is specified, the
max,
min or
closest keyword qualifier must follow.
The max keyword is used to inform the system that the metering rate defined for the policer is the maximum allowed rate. The system will choose a hardware supported rate that is closest but not exceeding the specified rate.
The min keyword is used to inform the system that the metering rate defined for the policer is the minimum allowed rate. The system will choose a hardware supported rate that is closest but not lower than the specified rate.
The closest keyword is used to inform the system that the metering rate defined for the policer is the target rate. The system will choose a hardware supported rate that is closest to the specified rate.
cir {
max |
min |
closest}
When the optional cir parameter is specified, the
max,
min or
closest keyword qualifier must follow.
The max keyword is used to inform the system that the profiling rate defined for the policer is the maximum allowed rate. The system will choose a hardware supported rate that is closest but not exceeding the specified rate.
cbs {size [bytes
| kilobytes
] | default
}
The policer’s cbs size defined in the QoS policy may be overridden on an
sla-profile or SAP where the policy is applied.
The size parameter is required when specifying
cbs and is expressed as an integer representing the required size in either bytes or kilobytes. The default is kilobytes. The optional
byte and
kilobyte keywords are mutually exclusive and are used to explicitly define whether size represents bytes or kilobytes.
When byte is defined, the value given for size is interpreted as the queue’s MBS value given in bytes.
When kilobytes is defined, the value is interpreted as the queue’s MBS value given in kilobytes.
This command is used to configure the percentage of the policer’s PIR leaky bucket's MBS (maximum burst size) that is reserved for high priority traffic. While the mbs value defines the policer’s high priority violate threshold, the percentage value defined is applied to the
mbs value to derive the bucket’s low priority violate threshold. See the
mbs command details for information on which types of traffic is associated with each violate threshold.
The percent-of-mbs parameter is required when specifying
high-prio-only and is expressed as a percentage with granularity of 1,000th of a percent.
mbs {size [bytes
| kilobytes
] | default
}
This command is used to configure the policer’s PIR leaky bucket’s high priority violate threshold. The high-prio-only command is applied to the MBS value to derive the bucket’s low priority violate threshold. For egress, trusted in-profile packets and un-trusted high priority packets use the policer’s high priority violate threshold while trusted out-of-profile and un-trusted low priority packets use the policer's low priority violate threshold. At egress, in-profile packets use the policer’s high priority violate threshold and out-of-profile packets use the policer's low priority violate threshold.
The size parameter is required when specifying
mbs and is expressed as an integer representing the required size in either bytes or kilobytes. The default is kilobytes. The optional
byte and
kilobyte keywords are mutually exclusive and are used to explicitly define whether size represents bytes or kilobytes.
When byte is defined, the value given for size is interpreted as the queue’s MBS value given in bytes.
When kilobytes is defined, the value is interpreted as the queue’s MBS value given in kilobytes.
This command is used to modify the size of each packet handled by the policer by adding or subtracting a number of bytes. The actual packet size is not modified; only the size used to determine the bucket depth impact is changed. The packet-byte-offset command is meant to be an arbitrary mechanism the can be used to either add downstream frame encapsulation or remove portions of packet headers. Both the policing metering and profiling throughput is affected by the offset as well as the stats associated with the policer.
The policer’s packet-byte-offset defined in the QoS policy may be overridden on an
sla-profile or SAP where the policy is applied.
The no version of this command is used to remove per packet size modifications from the policer.
The add keyword is mutually exclusive to the
subtract keyword. Either
add or
subtract must be specified. When
add is defined the corresponding bytes parameter specifies the number of bytes that is added to the size each packet associated with the policer for rate metering, profiling and accounting purposes. From the policer’s perspective, the maximum packet size is increased by the amount being added to the size of each packet.
The subtract keyword is mutually exclusive to the
add keyword. Either
add or
subtract must be specified. When b is defined the corresponding bytes parameter specifies the number of bytes that is subtracted from the size of each packet associated with the policer for rate metering, profiling and accounting purposes. From the policer’s perspective, the maximum packet size is reduced by the amount being subtracted from the size of each packet.
parent {root
| arbiter-name} [level
level] [weight
weight-within-level]
This command is used to create a child to parent mapping between each instance of the policer and either the root arbiter or a specific tiered
arbiter on the object where the policy is applied. Defining a parent association for the policer causes the policer to compete for the parent policer’s available bandwidth with other child policers mapped to the policer control hierarchy.
Policer control hierarchies may be created on SAPs or on a
subscriber context. To create a policer control hierarchy on an ingress or egress SAP context, a
policer-control-policy must be applied to the SAP. Once applied, the system will create a parent policer that is bandwidth limited by the policy’s
max-rate value under the root arbiter. The root arbiter in the policy also provides the information used to determine the various priority level discard-unfair and discard-all thresholds. Besides the root arbiter, the policy may also contain user defined tiered arbiters that provide arbitrary bandwidth control for subsets of child policers that are either directly or indirectly parented by the arbiter.
When the QoS policy containing the policer with a parent mapping to an arbiter name exists on the SAP, the system will scan the available arbiters on the SAP. If an arbiter exists with the appropriate name, the policer to arbiter association is created. If the specified arbiter does not exist either because a
policer-control-policy is not currently applied to the SAP or the arbiter name does not exist within the applied policy, the policer is placed in an orphan state. Orphan policers operate as if they are not parented and are not subject to any bandwidth constraints other than their own PIR. When a policer enters the orphan state, it is flagged as operationally degraded due to the fact that it is not operating as intended and a trap is generated. Whenever a
policer-control-policy is added to the SAP or the existing policy is modified, the SAP's policer's parenting configurations must be reevaluated. If an orphan policer becomes parented, the degraded flag should be cleared and a resulting trap should be generated.
For subscribers, the policer control hierarchy is created through the policer-control-policy applied to the
sub-profile used by the subscriber. A unique policer control hierarchy is created for each subscriber associated with the
sub-profile. The QoS policy containing the policer with the parenting command comes into play through the subscriber
sla-profile which references the QoS policy. The combining of the
sub-profile and the
sla-profile at the subscriber level provides the system with the proper information to create the policer control hierarchy instance for the subscriber.
Executing the parent command will fail if:
A policer with a parent command applied cannot be configured with
stat-mode no-stats in either the QoS policy or as an override on an instance of the policer
Once a policer is successfully parented to an arbiter, the parent commands
level and
weight parameters are used to determine at what priority level and at which weight in the priority level that the child policer competes with other children (policers or other arbiters) for bandwidth.
The no form of this command is used to remove the parent association from all instances of the policer.
When the parent command is executed, either the keyword
root or an
arbiter-name must be specified.
The root keyword specifies that the policer is intended to become a child to the
root arbiter where an instance of the policer is created. If the
root arbiter does not exist, the policer will be placed in the orphan state.
The arbiter-name parameter specifies that the policer is intended to become a child to one of the tiered arbiters with the given arbiter-name where an instance of the policer is created. If the specified arbiter-name does not exist, the policer will be placed in the orphan state.
The weight weight-within-level keyword and parameter are optional when executing the
parent command. When
weight is not specified, a default level of 1 is used in the parent arbiters priority level. When
weight is specified, the
weight-within-level parameter must be specified as an integer value from 1 through 100.
rate {max
| kilobits-per-second
} [cir
{max
| kilobits-per-second
}]
The policer’s adaptation-rule command settings are used by the system to convert the specified rates into hardware timers and decrement values for the policer’s buckets.
By default, the policer’s metering rate is max and the profiling rate is 0 Kbps (all packets out-of-profile).
The rate settings defined for the policer in the QoS policy may be overridden on an
sla-profile or SAP where the policy is applied.
The no form of this command is used to restore the default metering and profiling rate to a policer.
{max |
kilobits-per-second}
Specifying the keyword max or an explicit
kilobits-per-second parameter directly following the rate command is required and identifies the policer’s metering rate for the PIR leaky bucket. When the policer is first created, the metering rate defaults to max. The
kilobits-per-second value must be expressed as an integer and defines the rate in kilobits-per-second. The integer value is multiplied by 1,000 to derive the actual rate in bits-per-second.
cir {max | kilobits-per-second
}
The optional cir keyword is used to override the default CIR rate of the policer. Specifying the keyword max or an explicit
kilobits-per-second parameter directly following the cir keyword is required and identifies the policer’s profiling rate for the CIR leaky bucket. When the policer is first created, the profiling rate defaults to 0 Kbps. The
kilobits-per-second value must be expressed as an integer and defines the rate in kilobits-per-second. The integer value is multiplied by 1,000 to derive the actual rate in bits-per-second.
stat-mode {no-stats
| minimal
| offered-profile-no-cir
| offered-profile-cir
| offered-total-cir | offered-profile-capped-cir | offered-limited-capped-cir
}
The sap-egress QoS policy's policer
stat-mode command is used to configure the forwarding plane counters that allow offered, output and discard accounting to occur for the policer. An egress policer has multiple types of offered packets (soft in-profile and out-of-profile from ingress and hard in-profile and out-of-profile due to egress profile overides) and each of these offered types is interacting with the policer’s metering and profiling functions resulting in colored output packets (green, yellow and red). Due to the potential large number of egress policers, it is not economical to allocate counters in the forwarding plane for all possible offered packet types and output conditions. Many policers will not be configured with a CIR profiling rate and not all policers will receive explicitly re-profiled offered packets. The
stat-mode command allows provisioning of the number of counters each policer requires and how the offered packet types and output conditions should be mapped to the counters.
While a no-stats mode is supported which prevents any packet accounting, the use of the policer's
parent command requires at the policer’s
stat-mode to be set at least to the
minimal setting so that offered stats are available for the policer’s Fair Information Rate (FIR) to be calculated. Once a policer has been made a child to a parent policer, the
stat-mode cannot be changed to
no-stats unless the policer parenting is first removed.
Each time the policer's stat-mode is changed, any previous counter values are lost and any new counters are set to zero.
Each mode uses a certain number of counters per policer instance that are allocated from the forwarding plane's policer counter resources. You can view the the total/allocated/free stats by using the tools dump system-resources command. If insufficient counters exist to implement a mode on any policer instance, the
stat-mode change will fail and the previous mode will continue unaffected for all instances of the policer.
The default stat-mode when a policer is created within the policy is
minimal.
The stat-mode setting defined for the policer in the QoS policy may be overridden on an
sla-profile or SAP where the policy is applied. If insufficient policer counter resources exist to implement the override, the
stat-mode override command will fail. The previous
stat-mode setting active for the policer will continue to be used by the policer.
The no form of this command attempts to return the policer’s
stat-mode setting to
minimal. The command will fail if insufficient policer counter resources exist to implement
minimal where the QoS policer is currently applied and has a forwarding class mapping.
When collect-stats is enabled, the lack of counters causes the system to generate the following statistics:
The default stat-mode for a policer is
minimal. The
minimal mode allocates 1 forwarding plane offered counter and one traffic manager discard counter. The forwarding counter is derived by subtracting the discard counter from the offered counter. The counters do not differentiate possible offered types (profile or priority) and do not count green or yellow output. This does not prevent the policer from supporting different offered packet types and does not prevent the policer from supporting a CIR rate.
When collect-stats is enabled, the counters are used by the system to generate the following statistics:
The offered-profile-no-cir mode allocates two forwarding plane offered counters and two traffic manager discard counters.
The offered-profile-no-cir mode is most useful when profile based offered, discard and forwarding stats are required from the egress policer, but a CIR is not being used to recolor the soft in-profile and out-of-profile packets. This mode does not prevent the policer from being configured with a CIR rate.
When collect-stats is enabled, the counters are used by the system to generate the following statistics:
The offered-profile-cir mode allocates three forwarding plane offered counters and three traffic manager discard counters.
The offered-profile-cir mode is most useful when profile based offered, discard and forwarding stats are required from the egress policer and a CIR rate is being used to recolor the soft in-profile and out-of-profile packets.
When collect-stats is enabled, the counters are used by the system to generate the following statistics:
The offered-total-cir mode allocates two forwarding plane offered counters and two traffic manager discard counters.
The offered-total-cir mode is most useful when the policer is not receiving trusted in-profile or out-of-profile traffic and both high and low priority classifications are not being used on the un-trusted packets and the offered packets are being applied to a defined CIR profiling rate. This mode does not prevent the policer from receiving trusted in-profile or out-of-profile packets and does not prevent the use of priority high or low classifications on the un-trusted packets.
When collect-stats is enabled, the counters are used by the system to generate the following statistics:
When offered-profile-capped-cir is defined, the system creates five offered-output counters in the forwarding plane and five discard counters in the traffic manager.
The offered-profile-capped-cir mode is similar to the
offered-profile-cir mode except that it includes support for
profile in and
soft-in-profile that may be output as ‘out-of-profile’ due to enabling profile-capped mode on the ingress policer.
The impact of using offered-profile-capped-cir stat-mode while
profile-capped mode is disabled are that one of the counting resources in the forwarding plane and traffic manager will not be used and soft-in-profile will be treated as ‘offered-in’ instead of ‘offered-undefined’.
When collect-stats is enabled, the counters are used by the system to generate the following statistics:
offered-limited-capped-cir is defined, the system creates four forwarding plane offered-output counters in the network processor and three discard counters in the traffic manager.
The offered-limited-capped-cir mode is similar to the
offered-profile-capped-cir mode except that it combines
profile out and
soft-out-of-profile and eliminates the ‘offered-undefined’ statistic.
The impact of using offered-limited-capped-cir stat-mode while profile-capped mode is disabled are that one of the counting resources in the forwarding plane and traffic manager will not be used and
soft-in-profile will be treated as ‘offered-in’ instead of ‘offered-undefined’.
When collect-stats is enabled, the counters are used by the system to generate the following statistics:
dscp {dscp-name | in-profile dscp-name out-profile dscp-name}
|
Values
|
be, cp1, cp2, cp3, cp4, cp5, cp6, cp7, cs1, cp9, af11, cp11, af12, cp13, af13, cp15, cs2, cp17, af21, cp19, af22, cp21, af23, cp23, cs3, cp25, af31, cp27, af32, cp29, af33, cp31, cs4, cp33, af41, c p35, af42, cp37, af43, cp39, cs5, cp41, cp42, cp43, cp44, cp45, ef, cp47, nc1, cp49, cp50, cp51, cp52, cp53, cp54, cp55, nc2, cp57, cp58, cp59, cp60, cp61, cp62, cp63
|
prec ip-prec-value [fc
fc-name] [hsmda-counter-override
counter-id] [profile
{in
| out
}]
The ip-prec-value is a required parameter that specifies the unique IP header ToS byte precedence bits value that will match the IP precedence rule. If the command is executed more than once with the same
ip-prec-value, the previous forwarding class and enqueuing priority is completely overridden by the new parameters or defined to be inherited when a forwarding class or enqueuing priority parameter is missing.
scope {exclusive
| template
}
[no
] sap-egress
policy-id | policy-name
A default-action parameter is required to specify the default queue used by all forwarding classes not specifically mapped within the queue parameters. A sap-egress policy will be considered incomplete, if it does not include definition of at least one queue and does not specify the default action. Incomplete sap-egress policies cannot be applied to services.
The policy-name uniquely identifies the policy.
[no
] de-mark
[force
de-value]
This command is used to explicitly define the marking of the DE bit for fc fc-name according to the in and out of profile status of the packet (fc-name may be used to identify the dot1p-value).
[no] dot1p {dot1p-value | in-profile dot1p-value out-profile dot1p-value}
This command explicitly defines the egress IEEE 802.1P (dot1p) bits marking for fc-name. When the marking is set, all packets of
fc-name that have either an IEEE 802.1Q or IEEE 802.1P encapsulation use the explicitly defined
dot1p-value. If the egress packets for
fc-name are not IEEE 802.1Q or IEEE 802.1P encapsulated, the dot1p command has no effect.
The optional in-profile |
dot1p-value out-profile dot1p-value structure added to the existing dot1p command will add the capability to mark on an egress SAP the in and out of profile status via a certain dot1p combination, similarly with the DE options.
The no form of the command sets the IEEE 802.1P or IEEE 802.1Q priority bits to 0.
The no form of the command removes any explicitly defined constraints used to derive the operational CIR and PIR created by the application of the policy. When a specific
adaptation-rule is removed, the default constraints for
rate and
cir apply.
|
Values
|
pir — Defines the constraints enforced when adapting the PIR rate defined within the queue queue-id rate command. The pir parameter requires a qualifier that defines the constraint used when deriving the operational PIR for the queue. When the rate command is not specified, the default applies.
|
cir — Defines the constraints enforced when adapting the CIR rate defined within the
queue queue-id
rate command. The
cir parameter requires a qualifier that defines the constraint used when deriving the operational CIR for the queue. When the
cir parameter is not specified, the default constraint applies.
max — The
max (maximum) option is mutually exclusive with the
min and
closest options. When
max is defined, the operational PIR for the queue will be equal to or less than the administrative rate specified using the
rate command.
min — The
min (minimum) option is mutually exclusive with the
max and
closest options. When
min is defined, the operational PIR for the queue will be equal to or greater than the administrative rate specified using the
rate command.
closest — The
closest parameter is mutually exclusive with the
min and
max parameter. When
closest is defined, the operational PIR for the queue will be the rate closest to the rate specified using the
rate command.
[no
] adv-config-policy
policy-name
Once a policy is created, it may be applied to a queue or policer defined within a sap-egress or
sap-ingress QoS policy. It may also be applied to a queue or policer defined within an ingress or
egress queue-group template. When a policy is currently associated with a QoS policy or template, the policy may be modified but not deleted (even in the event that the QoS policy or template is not in use).
The no form of this command
removes the specified advanced policy.
The no form of the command removes any explicitly defined constraints used to derive the operational CIR and PIR created by the application of the policy. When a specific
adaptation-rule is removed, the default constraints for
rate and
cir apply.
|
Values
|
pir — Defines the constraints enforced when adapting the PIR rate defined within the queue queue-id rate command. The pir parameter requires a qualifier that defines the constraint used when deriving the operational PIR for the queue. When the rate command is not specified, the default applies.
|
max — The
max (maximum) option is mutually exclusive with the
min and
closest options. When
max is defined, the operational PIR for the queue will be equal to or less than the administrative rate specified using the
rate command.
min — The
min (minimum) option is mutually exclusive with the
max and
closest options. When
min is defined, the operational PIR for the queue will be equal to or greater than the administrative rate specified using the
rate command.
closest — The
closest parameter is mutually exclusive with the
min and
max parameter. When
closest is defined, the operational PIR for the queue will be the rate closest to the rate specified using the
rate command.
The no form of this command restores the average frame overhead parameter for the queue to the default value of 0 percent. When set to 0, the system uses the packet based queue statistics for calculating port scheduler priority bandwidth allocation. If the no avg-frame-overhead command is executed in a queue-override queue id context, the avg-frame-overhead setting for the queue within the sap-egress QoS policy takes effect.
The queue burst-limit command is used to define an explicit shaping burst size for a queue. The configured size defines the shaping leaky bucket threshold level that indicates the maximum burst over the queue’s shaping rate.
The burst-limit command is supported under the sap-ingress and sap-egress QoS policy queues. The command is also supported under the ingress and egress queue-group-templates queues.
The no form of this command
is used to restore the default burst limit to the specified queue. This is equivalent to specifying burst-limit default within the QoS policies or queue group templates. When specified within a queue-override queue context, any current burst limit override for the queue will be removed and the queue’s burst limit will be controlled by its defining policy or template.
The bytes qualifier is used to specify that the value given for size must be interpreted as the burst limit in bytes. The byte qualifier is optional and mutually exclusive with the kilobytes qualifier.
The kilobyte qualifier is used to specify that the value given for size must be interpreted as the burst limit in Kilobytes. The kilobyte qualifier is optional and mutually exclusive with the bytes qualifier. If neither bytes nor kilobytes is specified, the default qualifier is kilobytes.
The no form of this command returns the CBS size to the default value.
The high-prio-only command configures the percentage of buffer space for the queue, used exclusively by high priority packets. The specified value overrides the default value for the context.
The no form of this command restores the default high priority reserved size.
mbs size [bytes | kilobytes
]
The no form of this command
returns the MBS size assigned to the queue to the value.
The no form of this command is used to remove per packet size modifications from the queue.
The add keyword is mutually exclusive to the
subtract keyword. Either parameter must be specified. When
add is defined, the corresponding bytes parameter specifies the number of bytes that is added to the size of each packet associated with the queue for scheduling and accounting purposes.
The subtract keyword is mutually exclusive to the
add keyword. Either parameter must be specified. When subtract is defined, the corresponding bytes parameter specifies the number of bytes that is subtracted to the size of each packet associated with the queue for scheduling and accounting purposes.
parent scheduler-name [weight
weight] [level
level] [cir-weight
cir-weight] [cir-level
cir-level]
Checks are not performed to see if a scheduler-name exists when the parent command is defined on the queue. Scheduler names are configured in the
config>qos>scheduler-policy>tier level context. Multiple schedulers can exist with the
scheduler-name and the association pertains to a scheduler that should exist on the egress SAP as the policy is applied and the queue created. When the queue is created on the egress SAP, the existence of the
scheduler-name is dependent on a scheduler policy containing the
scheduler-name being directly or indirectly applied (through a multi-service customer site) to the egress SAP. If the
scheduler-name does not exist, the queue is placed in the orphaned operational state. The queue will accept packets but will not be bandwidth limited by a virtual scheduler or the scheduler hierarchy applied to the SAP. The orphaned state must generate a log entry and a trap message. The SAP which the queue belongs to must also depict an orphan queue status. The orphaned state of the queue is automatically cleared when the
scheduler-name becomes available on the egress SAP.
The no form of the command removes a child association with a parent scheduler. If a parent association does not currently exist, the command has no effect and returns without an error. Once a parent association has been removed, the former child queue attempts to operate based on its configured rate parameter. Removing the parent association on the queue within the policy takes effect immediately on all queues using the SAP egress QoS policy.
The defined scheduler-name conforms to the same input criteria as the schedulers defined within a scheduler policy. Scheduler names are configured in the
config>qos>scheduler-policy>tier level context. There are no checks performed at the time of definition to ensure that the
scheduler-name exists within an existing scheduler policy. For the queue to use the defined
scheduler-name, the scheduler exists on each egress SAP the queue is eventually created on. For the duration where
scheduler-name does not exist on the egress SAP, the queue operates in an orphaned state.
weight defines the relative weight of this queue in comparison to other child schedulers and queues while vying for bandwidth on the parent
scheduler-name. Any queues or schedulers defined as weighted receive no parental bandwidth until all strict queues and schedulers on the parent have reached their maximum bandwidth or are idle. In this manner, weighted children are considered to be the lowest priority.
All weight values from all weighted active queues and schedulers with a common parent scheduler are added together. Then, each individual active weight is divided by the total, deriving the percentage of remaining bandwidth provided to the queue or scheduler after the strict children are serviced. A weight is considered to be active when the pertaining queue or scheduler has not reached its maximum rate and still has packets to transmit. All child queues and schedulers with a weight of 0 are considered to have the lowest priority level and are not serviced until all strict and non-zero weighted queues and schedulers are operating at the maximum bandwidth or are idle.
The optional level parameter defines the level of hierarchy when compared to other schedulers and queues when vying for bandwidth on the parent
scheduler-name. Any queues or schedulers defined as
strict receive no parental bandwidth until all strict queues and schedulers with a higher (numerically larger) priority on the parent have reached their maximum bandwidth or are idle.
Children of the parent scheduler with a lower strict
priority or that are weighted will not receive bandwidth until all children with a higher strict priority have either reached their maximum bandwidth or are idle. Children with the same strict
level are serviced in a round robin fashion.
percent-rate pir-percent [cir
cir-percent] [port-limit
|local-limit
]
The no form of this command returns the queue to its default shaping rate and cir rate. When no percent-rate is defined within a SAP ingress or egress queue-override, the queue reverts to the defined shaping and CIR rates within the SAP ingress and egress QOS policy associated with the queue.
The cir keyword is optional and when defined the required cir-percent CIR parameter expresses the queue’s CIR as a percentage dependant on the use of the port-limit or local-limit.
The port-limit keyword specifies that the configure PIR and CIR percentages are relative to the rate of the port to which this queue connects.
The no pool command is used to remove a named pool association for the queue. When the pool name is removed, the queue will be placed on the appropriate default pool.
The specified pool-name identifies a named pool where the policy will be applied. Each queue created within the system is tied to a physical port. When the policy is applied and the queue is created, the system will scan the named pools associated with the port to find the specified pool name. If the pool is not found on the port, the system will then look at named pools defined at the ports MDA level. If the pool name is not found on either the port or MDA, the queue will be marked as ‘pool-orphaned’ and will be mapped to the appropriate default pool. If the pool comes into existence, the queue will be moved from the default pool to the new named pool and the ‘pool-orphaned’ state will be cleared. The specified name must be an ASCII name string up to 32 characters long.
port-parent [weight
weight] [level
level] [cir-weight
cir-weight] [cir-level
cir-level]
The port-parent command defines a child/parent association between an egress queue and a port based scheduler or between an intermediate service scheduler and a port based scheduler. The command may be issued in three distinct contexts;
sap-egress queue queue-id,
network-queue queue queue-id and
scheduler-policy scheduler scheduler-name. The
port-parent command allows for a set of within-cir and above-CIR parameters that define the port priority levels and weights for the queue or scheduler. If the
port-parent command is executed without any parameters, the default parameters are assumed.
In this context, the port-parent command is mutually exclusive to the
parent command (used to create a parent/child association between a queue and an intermediate scheduler). Executing a
port-parent command when a parent definition is in place causes the current intermediate scheduler association to be removed and replaced by the defined port-parent association. Executing a
parent command when a port-parent definition exists causes the port scheduler association to be removed and replaced by the defined intermediate scheduler name.
Changing the parent context on a SAP egress policy queue may cause a SAP or
subscriber context of the queue (policy associated with a SAP or subscriber profile) to enter an orphaned state. If an instance of a queue is created on a port or channel that does not have a port scheduler enabled and the sap-egress policy creating the queue has a port-parent association, the queue will be allowed to run according to its own rate parameters and will not be controlled by a virtual scheduling context. If an instance of a queue is on a port or channel that has a port scheduler configured and the sap-egress policy defines the queue as having a non-existent intermediate scheduler parent, the queue will be treated as an orphan and will be handled according to the current orphan behavior on the port scheduler.
The no form of this command removes a port scheduler parent association for the queue or scheduler. If a port scheduler is defined on the port which the queue or scheduler instance exists, the queue or scheduler will become orphaned if an port scheduler is configured on the egress port of the queue or scheduler.
rate pir-rate [cir
cir-rate | police]
This command defines the administrative Peak Information Rate (PIR) and the administrative Committed Information Rate (CIR) parameters for the queue. The PIR defines the maximum rate that the queue can transmit packets through the switch fabric (for SAP ingress queues). Defining a PIR does not necessarily guarantee that the queue can transmit at the intended rate. The actual rate sustained by the queue can be limited by oversubscription factors or available egress bandwidth.
The CIR can be used by the queue’s parent commands cir-level and
cir-weight parameters to define the amount of bandwidth considered to be committed for the child queue during bandwidth allocation by the parent scheduler.
The rate command can be executed at anytime, altering the PIR and CIR rates for all queues created through the association of the SAP ingress or SAP egress QoS policy with the
queue-id.
The no form of the command returns all queues created with the
queue-id by association with the QoS policy to the default PIR and CIR parameters (
max, 0).
The max default specifies the amount of bandwidth in kilobits per second (thousand bits per second). The
max value is mutually exclusive to the
pir-rate value.
The cir parameter overrides the default administrative CIR used by the queue. When the
rate command is executed, a CIR setting is optional. When the
rate command has not been executed or the
cir parameter is not explicitly specified, the default CIR (0) is assumed.
Fractional values are not allowed and must be given as a positive integer.
rate pir-rate [cir
cir-rate]
The CIR can be used by the queue’s parent commands cir-level and
cir-weight parameters to define the amount of bandwidth considered to be committed for the child queue during bandwidth allocation by the parent scheduler.
The rate command can be executed at anytime, altering the PIR and CIR rates for all queues created through the association of the SAP egress QoS policy with the
queue-id.
The no form of the command returns all queues created with the
queue-id by association with the QoS policy to the default PIR and CIR parameters (
max, 0).
The max default specifies the amount of bandwidth in kilobits per second (thousand bits per second). The
max value is mutually exclusive to the
pir-rate value.
The cir parameter overrides the default administrative CIR used by the queue. When the
rate command is executed, a CIR setting is optional. When the
rate command has not been executed or the
cir parameter is not explicitly specified, the default CIR (0) is assumed.
Fractional values are not allowed and must be given as a positive integer.
rate pir-rate {max
| kilobits-per-second}
The no form of the command returns all queues created with the
queue-id by association with the QoS policy to the default PIR and CIR parameters (
max, 0).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Specifies the enqueuing priority when a packet is marked with a dot1p-value specified.
|
|
|
Specifies that an IP criteria-based SAP ingress policy is used to select the appropriate ingress queue and corresponding forwarding class for matched traffic.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Specifies the default CBS value for the queue.
|
|
|
Specifies the value to override the default reserved buffers for the queue .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Specifies the forwarding class overrides.
|
|
|
|
|
|
Specifies that the high enqueuing parameter for a packet increases the likelihood of enqueuing the packet when the ingress queue is congested.
|
|
|
Specifies that the low enqueuing parameter for a packet decreases the likelihood of enqueuing the packet when the ingress queue is congested.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Specifies the default broadcast forwarding type queue mapping.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Specifies a DiffServ Code Point (DSCP) name used for an ingress SAP QoS policy match.
|
|
|
|
|
|
Configures a match on all non-fragmented IP packets.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Specifies a IEEE 802.1p value to be used as the match.
|
|
|
Specifies an IEEE 802.3 LLC SNAP Ethernet Frame PID value to be used as a Service Ingress QoS policy match.
|
|
|
Specifies an Ethernet type II Ethertype value to be used as a Service Ingress QoS policy match.
|
|
|
Specifies an IEEE 802.3 LLC SNAP Ethernet Frame OUI zero or non-zero value to be used as a Service Ingress QoS policy match.
|
|
|
Specifies an Ethernet 802.2 LLC DSAP value or range for an ingress SAP QoS policy match.
|
|
|
Specifies an Ethernet 802.2 LLC DSAP value or range for an ingress SAP QoS policy match.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
QoS Sap Ingress
===============================================================================
Sap Ingress Policy (100)
-------------------------------------------------------------------------------
Policy-id : 100 Scope : Template
Default FC : be Priority : Low
Criteria-type : IP
Description : Used on VPN sap
-------------------------------------------------------------------------------
Queue Mode CIR Admin PIR Admin CBS HiPrio PIR Lvl/Wt Parent
CIR Rule PIR Rule MBS CIR Lvl/Wt
-------------------------------------------------------------------------------
1 Prio 0 max def def 1/1 None
closest closest def 0/1
2 Prio 0 max def def 1/1 None
closest closest def 0/1
10 Prio 0 11000 def def 1/1 VPN_be
closest closest def 0/1
11 Prio 0 max def def 1/1 None
closest closest def 0/1
12 Prio 0 11000 def def 1/1 VPN_prio*
closest closest def 0/1
13 Prio 0 1 def def 1/1 VPN_rese*
closest closest def 0/1
15 Prio 1500 1500 def def 1/1 VPN_video
closest closest def 0/1
16 Prio 2500 2500 def def 1/1 VPN_voice
closest closest def 0/1
17 Prio 36 100 def def 1/1 VPN_nc
closest closest def 0/1
20 Prio 0 11000 def def 1/1 VPN_be
closest closest def 0/1
22 Prio 0 11000 def def 1/1 VPN_prio*
closest closest def 0/1
23 Prio 0 1 def def 1/1 VPN_rese*
closest closest def 0/1
25 Prio 1500 1500 def def 1/1 VPN_video
closest closest def 0/1
26 Prio 2500 2500 def def 1/1 VPN_voice
closest closest def 0/1
27 Prio 36 100 def def 1/1 VPN_nc
closest closest def 0/1
-------------------------------------------------------------------------------
FC UCastQ MCastQ BCastQ UnknownQ
-------------------------------------------------------------------------------
be 10 20 20 20
af 12 22 22 22
h2 16 26 26 26
ef 13 23 23 23
h1 15 25 25 25
nc 17 27 27 27
-------------------------------------------------------------------------------
SubFC Profile In-Remark Out-Remark
-------------------------------------------------------------------------------
af None None None
be None None None
ef None None None
h1 None None None
h2 None None None
nc None None None
-------------------------------------------------------------------------------
Dot1p FC Priority
-------------------------------------------------------------------------------
0 af High
1 ef High
7 be Low
-------------------------------------------------------------------------------
DSCP FC Priority
-------------------------------------------------------------------------------
af41 af High
-------------------------------------------------------------------------------
Prec Value FC Priority
-------------------------------------------------------------------------------
0 be Default
2 af Default
3 ef Default
5 h1 Default
6 h2 Default
7 nc Default
-------------------------------------------------------------------------------
Match Criteria
-------------------------------------------------------------------------------
IP Match Criteria
-------------------------------------------------------------------------------
Entry : 10
Description : Entry 10-FC-AF
Source IP : 10.10.10.104/24 Source Port : None
Dest. IP : Undefined Dest. Port : None
Protocol : 6 DSCP : None
Fragment : Off
FC : af Priority : High
Entry : 20
Description : Entry 20-FC-BE
Source IP : Undefined Source Port : None
Dest. IP : Undefined Dest. Port : eq 255
Protocol : 17 DSCP : None
Fragment : Off
FC : Default Priority : Default
-------------------------------------------------------------------------------
IPv6 Match Criteria
-------------------------------------------------------------------------------
No Match Criteria Entries found.
-------------------------------------------------------------------------------
Associations
-------------------------------------------------------------------------------
Service-Id : 700 (VPLS) Customer-Id : 7
- SAP : 1/1/9:0 override
===============================================================================
*A:ALA-48>config>qos#
config>qos# show qos sap-ingress 2 detail
========================================================================
QoS Sap Ingress
------------------------------------------------------------------------
Sap Ingress Policy (2)
------------------------------------------------------------------------
Policy-id : 2 Scope : Template
Default FC : be Priority : Low
Criteria-type : None
------------------------------------------------------------------------
Queue Mode CIR Admin PIR Admin CBS HiPrio PIR Lvl/Wt Parent
CIR Rule PIR Rule MBS CIR Lvl/Wt
------------------------------------------------------------------------
1 Prio 0 max def def 1/1 None
closest closest def 0/1
11 Prio 0 max def def 1/1 None
closest closest def 0/1
------------------------------------------------------------------------
FC UCastQ MCastQ BCastQ UnknownQ
------------------------------------------------------------------------
af def def def def
ef def def def def
------------------------------------------------------------------------
SubFC DE-1-out-profile Profile In-Remark Out-Remark
------------------------------------------------------------------------
af No None None None
ef Yes None None None
------------------------------------------------------------------------
Dot1p FC Priority
------------------------------------------------------------------------
No Dot1p-Map Entries Found.
------------------------------------------------------------------------
DSCP FC Priority
------------------------------------------------------------------------
No DSCP-Map Entries Found.
------------------------------------------------------------------------
Prec Value FC Priority
------------------------------------------------------------------------
No Prec-Map Entries Found.
------------------------------------------------------------------------
Match Criteria
------------------------------------------------------------------------
No Matching Criteria.
------------------------------------------------------------------------
Associations
------------------------------------------------------------------------
No Associations Found.
config>qos#
A:ALA-49# show qos sap-egress
===============================================================================
Sap Egress Policies
===============================================================================
Policy-Id Scope Description
-------------------------------------------------------------------------------
1 Template Default SAP egress QoS policy.
1010 Template
1020 Template
===============================================================================
A:ALA-49#
A:ALA-49# show qos sap-egress 1010
===============================================================================
QoS Sap Egress
===============================================================================
-------------------------------------------------------------------------------
Sap Scheduler Policy (1010)
-------------------------------------------------------------------------------
Policy-id : 1010 Scope : Template
===============================================================================
A:ALA-49#
A:ALA-49# show qos sap-egress 1010 detail
===============================================================================
QoS Sap Egress
===============================================================================
-------------------------------------------------------------------------------
Sap Scheduler Policy (1010)
-------------------------------------------------------------------------------
Policy-id : 1010 Scope : Template
-------------------------------------------------------------------------------
Queue CIR Admin PIR Admin CBS HiPrio PIR Lvl/Wt Parent
CIR Rule PIR Rule MBS CIR Lvl/Wt
-------------------------------------------------------------------------------
1 0 max def def 1/1 None
closest closest def 0/1
8 0 max def def 1/1 None
closest closest def 0/1
-------------------------------------------------------------------------------
FC Name Queue-id Explicit/Default
-------------------------------------------------------------------------------
be 8 Explicit (7)
-------------------------------------------------------------------------------
Associations
-------------------------------------------------------------------------------
Service-Id : 1 (VPRN) Customer-Id : 1
- SAP : 1/1/10:1
SLA Profiles :
- test override
-------------------------------------------------------------------------------
Mirror SAPs
-------------------------------------------------------------------------------
No Mirror SAPs Found.
===============================================================================
A:ALA-49#
config>qos# show qos sap-egress 2 detail
========================================================================
QoS Sap Egress
------------------------------------------------------------------------
Sap Scheduler Policy (2)
------------------------------------------------------------------------
Policy-id : 2 Scope : Template
------------------------------------------------------------------------
Queue CIR Admin PIR Admin CBS HiPrio PIR Lvl/Wt Parent AvgOvrhd
CIR Rule PIR Rule MBS CIR Lvl/Wt
------------------------------------------------------------------------
1 0 max def def 1/1 None 0.00
closest closest def 0/1
------------------------------------------------------------------------
FC Name Queue-id Explicit/Default DE-Mark
------------------------------------------------------------------------
af def Explicit (4) Profile
l1 def Explicit (In:5 Out:6) Force 0
ef def Default None
------------------------------------------------------------------------
Associations
------------------------------------------------------------------------
No Associations Found.
------------------------------------------------------------------------
Mirror SAPs
------------------------------------------------------------------------
No Mirror SAPs Found.
========================================================================
config>qos#
queue from {sap
sap-id | queue-group
port-id queue-group-name | subscriber
subscriber-id | network
{mda-id | port-id} | system
{card
slot-number | mda
mda-id port
port-id}} {ingress
| egress
} [id
queue-id]
system {card
slot-number |mda-id |
port-id}
bcg burst-control-group-name [
member-queues [
at-risk-only]] [
exp-util-bw megabits-per-second]
The show qos bcg command allows visibility into a BCG’s historic and current visitation time. The system samples the amount of time it takes each list to visit each of its associated queues once each second and stores the last 10 samples. It also keeps the longest visitation time seen since the last time the BCG statistics were cleared, the longest visitation time for the current queue-to-BCG lists associations, calculated longest visitation time based on maximum scheduling bandwidth and lastly the longest visitation time for an optionally defined scheduling rate.
*A:ALA-49>config>qos# show qos hsmda-pool-policy
===============================================================================
Qos HSMDA Pool Policy
===============================================================================
Policy Name Description
-------------------------------------------------------------------------------
test test
default Default hsmda Pool policy.
===============================================================================
*A:ALA-98>config>qos#
*A:ALA-49>config# show qos hsmda-pool-policy test detail
=============================================================================
Qos HSMDA Pool Policy
=============================================================================
Policy Name : test
=============================================================================
Description : test
Sys. Reserve : 10.00
===========================================================
Class Tier
===========================================================
Class Pool Root Parent Alloc. Percent
-----------------------------------------------------------
1 1 50.00
2 1 35.00
3 1 30.00
4 1 25.00
5 1 20.00
6 2 50.00
7 2 40.00
8 2 30.00
===========================================================
Root Tier
===========================================================
Root Pool Root Weight
-----------------------------------------------------------
1 75
2 25
3 0
4 0
5 0
6 0
7 0
8 0
-----------------------------------------------------------------------------
Associations
-----------------------------------------------------------------------------
- MDA Egress: 9/2
=============================================================================
*A:ALA-49>config#
*A:ALA-49>config# show qos hsmda-pool-policy association
=============================================================================
Qos HSMDA Pool Policy
=============================================================================
Policy Name : test
=============================================================================
Description : test
-----------------------------------------------------------------------------
Associations
-----------------------------------------------------------------------------
- MDA Egress: 9/2
=============================================================================
Policy Name : default
=============================================================================
Description : Default hsmda Pool policy.
-----------------------------------------------------------------------------
Associations
-----------------------------------------------------------------------------
- MDA Ingress: 9/2
=============================================================================
*A:ALA-49>config#
|
Values
|
null port-id | lag-id
dot1q port-id | lag-id:* | qtag1 qinq port-id | lag-id:qtag1.qtag2 port-id slot/ mda/ port[. channel] lag-id lag- id
lag keyword id 1 — 200 qtag1 0 — 4094 qtag2 *, 0 — 4094
|
