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 [dscp-name...(upto 8 max)] fc
fc-name [priority
{low
| high
}]
no dscp dscp-name [dscp-name...(upto 8 max)]
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. A list of up to 8 dscp-names can be entered on a single command. The lists of dscp-names within the configuration are managed by the system to ensure that each list does not exceed 8 names. Entering more than 8 dscp-names with the same parameters (
fc,
priority) will result in multiple lists being created. Conversely, multiple lists with the same parameters (fc, priority) are merged and the lists repacked to a maximum of 8 per list if dscp-names are removed or the parameters changed so the multiple lists use the same parameters. Also, if a subset of a list is entered with different parameters then a new list will be created for the subset. Note that when the list is stored in the configuration, the dscp-names are sorted by their DSCP value in ascending numerical order, consequently the order in the configuration may not be exactly what the user entered.
The DSCP value (referred to here by dscp-name) is derived from the most significant six bits in the IPv4 header ToS byte field (DSCP bits) or the Traffic Class field from the IPv6 header. If the packet does not have an IP header, dscp based matching is not performed. 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.
The no form of the command removes the specified the
dscp-names from the explicit DSCP classification rule in the SAP ingress policy. As
dscp-names are removed, the system repacks the lists of dscp-names with the same parameters (up to 8 per list). As the
no command does not have any additional parameters, it is possible to remove multiple
dscp-names from multiple DSCP statements having different parameters with one command. If a
dscp-name specified in a
no command does not exist in any DSCP statement, then the command is aborted at that point with an error message displayed; any
dscp-names in the list before the failed entry will be processed as normal but the processing will stop at the failed entry so that the remainder of the list is not processed.
Removing the dscp-name from the policy immediately removes the
dscp-name on all ingress SAPs using the policy.
A:PE# show qos dscp-table
============================================================
DSCP Mapping
============================================================
DSCP Name DSCP Value TOS (bin) TOS (hex)
------------------------------------------------------------
be 0 0000 0000 00
cp1 1 0000 0100 04
cp2 2 0000 1000 08
cp3 3 0000 1100 0C
cp4 4 0001 0000 10
cp5 5 0001 0100 14
cp6 6 0001 1000 18
cp7 7 0001 1100 1C
cs1 8 0010 0000 20
cp9 9 0010 0100 24
af11 10 0010 1000 28
cp11 11 0010 1100 2C
af12 12 0011 0000 30
cp13 13 0011 0100 34
af13 14 0011 1000 38
cp15 15 0011 1100 3C
cs2 16 0100 0000 40
cp17 17 0100 0100 44
af21 18 0100 1000 48
cp19 19 0100 1100 4C
af22 20 0101 0000 50
cp21 21 0101 0100 54
af23 22 0101 1000 58
cp23 23 0101 1100 5C
cs3 24 0110 0000 60
cp25 25 0110 0100 64
af31 26 0110 1000 68
cp27 27 0110 1100 6C
af32 28 0111 0000 70
cp29 29 0111 0100 74
af33 30 0111 1000 78
cp31 31 0111 1100 7C
cs4 32 1000 0000 80
cp33 33 1000 0100 84
af41 34 1000 1000 88
cp35 35 1000 1100 8C
af42 36 1001 0000 90
cp37 37 1001 0100 94
af43 38 1001 1000 98
cp39 39 1001 1100 9C
cs5 40 1010 0000 A0
cp41 41 1010 0100 A4
cp42 42 1010 1000 A8
cp43 43 1010 1100 AC
cp44 44 1011 0000 B0
cp45 45 1011 0100 B4
ef 46 1011 1000 B8
cp47 47 1011 1100 BC
nc1 48 1100 0000 C0
cp49 49 1100 0100 C4
cp50 50 1100 1000 C8
cp51 51 1100 1100 CC
cp52 52 1101 0000 D0
cp53 53 1101 0100 D4
cp54 54 1101 1000 D8
cp55 55 1101 1100 DC
nc2 56 1110 0000 E0
cp57 57 1110 0100 E4
cp58 58 1110 1000 E8
cp59 59 1110 1100 EC
cp60 60 1111 0000 F0
cp61 61 1111 0100 F4
cp62 62 1111 1000 F8
cp63 63 1111 1100 FC
============================================================
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 [dscp-name...(upto 8 max)] [fc
fc-name] [hsmda-counter-override
counter-id] [profile
{in
| out
}]
no dscp dscp-name [dscp-name...(upto 8 max)]
This command defines IP Differentiated Services Code Point (DSCP) names that must be matched to perform the associated reclassification actions. The specified name must exist as a dscp-name. SR OS software provides names for the well-known code points. A list of up to 8
dscp-names can be entered on a single command. The lists of
dscp-names within the configuration are managed by the system to ensure that each list does not exceed 8 names. Entering more than 8
dscp-names with the same parameters (fc, hsmda-counter-override, priority) will result in multiple lists being created. Conversely, multiple lists with the same parameters (fc, hsmda-counter-override, priority) are merged and the lists repacked to a maximum of 8 per list if
dscp-names are removed or the parameters changed so the multiple lists use the same parameters. Also, if a subset of a list is entered with different parameters then a new list will be created for the subset. Note that when the list is stored in the configuration, the
dscp-names are sorted by their DSCP value in ascending numerical order, consequently the order in the configuration may not be exactly what the user entered.
If an egress packet on the SAP matches an IP DSCP value corresponding to a specified dscp-name, 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 DSCP 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 DSCP 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 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 the command removes the specified the
dscp-names from the reclassification rule in the SAP egress QoS policy. As
dscp-names are removed, the system repacks the lists of
dscp-names with the same parameters (up to 8 per list). As the
no command does not have any additional parameters, it is possible to remove multiple
dscp-names from multiple DSCP statements having different parameters with one command. If a
dscp-name specified in a
no command does not exist in any DSCP statement then the command is aborted at that point with an error message displayed. Any
dscp-names in the list before the failed entry will be processed as normal but the processing will stop at the failed entry so that the remainder of the list is not processed.
The dscp-name parameter is required when defining a DSCP reclassification rule. The specified name must exist as a dscp-name. A maximum of 8 dscp-names can be specified in a single statement. SR OS software provides names for the well-known code points, these can be shown using the command below:
A:PE# show qos dscp-table
============================================================
DSCP Mapping
============================================================
DSCP Name DSCP Value TOS (bin) TOS (hex)
------------------------------------------------------------
be 0 0000 0000 00
cp1 1 0000 0100 04
cp2 2 0000 1000 08
cp3 3 0000 1100 0C
cp4 4 0001 0000 10
cp5 5 0001 0100 14
cp6 6 0001 1000 18
cp7 7 0001 1100 1C
cs1 8 0010 0000 20
cp9 9 0010 0100 24
af11 10 0010 1000 28
cp11 11 0010 1100 2C
af12 12 0011 0000 30
cp13 13 0011 0100 34
af13 14 0011 1000 38
cp15 15 0011 1100 3C
cs2 16 0100 0000 40
cp17 17 0100 0100 44
af21 18 0100 1000 48
cp19 19 0100 1100 4C
af22 20 0101 0000 50
cp21 21 0101 0100 54
af23 22 0101 1000 58
cp23 23 0101 1100 5C
cs3 24 0110 0000 60
cp25 25 0110 0100 64
af31 26 0110 1000 68
cp27 27 0110 1100 6C
af32 28 0111 0000 70
cp29 29 0111 0100 74
af33 30 0111 1000 78
cp31 31 0111 1100 7C
cs4 32 1000 0000 80
cp33 33 1000 0100 84
af41 34 1000 1000 88
cp35 35 1000 1100 8C
af42 36 1001 0000 90
cp37 37 1001 0100 94
af43 38 1001 1000 98
cp39 39 1001 1100 9C
cs5 40 1010 0000 A0
cp41 41 1010 0100 A4
cp42 42 1010 1000 A8
cp43 43 1010 1100 AC
cp44 44 1011 0000 B0
cp45 45 1011 0100 B4
ef 46 1011 1000 B8
cp47 47 1011 1100 BC
nc1 48 1100 0000 C0
cp49 49 1100 0100 C4
cp50 50 1100 1000 C8
cp51 51 1100 1100 CC
cp52 52 1101 0000 D0
cp53 53 1101 0100 D4
cp54 54 1101 1000 D8
cp55 55 1101 1100 DC
nc2 56 1110 0000 E0
cp57 57 1110 0100 E4
cp58 58 1110 1000 E8
cp59 59 1110 1100 EC
cp60 60 1111 0000 F0
cp61 61 1111 0100 F4
cp62 62 1111 1000 F8
cp63 63 1111 1100 FC
============================================================
The fc reclassification action is optional. When specified, packets matching the IP DSCP value corresponding to a specified
dscp-name 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.
The no for of the command reverts to the default.
IP criteria-based SAP ingress policies are used to select the appropriate ingress queue and corresponding forwarding class for matched traffic.
The software 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.
The 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 egress/ingress policies are used to select the appropriate ingress queue and corresponding forwarding class for matched traffic.
The 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
subtract 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. Note that the minimum resulting packet size used by the system is 1 byte.
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 no form of this command returns the queue to its default shaping rate and cir rate.
The cir keyword is optional and when defined the required cir-percent CIR parameter expresses the policer’s CIR as a percentage of the immediate parent root policer/arbiter rate or the FP capacity.
[no
] profile-out-preserve
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. When max is specified, the maximum policer rate used will be equal to the maximum capacity of the card on which the policer is configured. If the policer rate is set to a value larger than the maximum rate possible for the card, then the PIR used is equivalent to max.
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. When
max is specified, the maximum policer rate used will be equal to the maximum capacity of the card on which the policer is configured. If the policer rate is set to a value larger than the maximum rate possible for the card, then the CPIR used is equivalent to max.
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 14-byte Ethernet DLC header, 4-byte or 8-byte VLAN tag (optional), 20-byte IP header, IP payload and the 4-byte CRC (everything except the preamble and inter-frame gap). For 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.
Indicates that the byte value should be subtracted from the packet for queue and queue group level accounting functions. The subtract keyword is mutually exclusive with the add keyword. Either the add or subtract keyword must be specified. The corresponding byte value must be specified when executing the packet-byte-offset command. Note that the minimum resulting packet size used by the system is 64 bytes with an HS-MDA.
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
}] [policer policer-id]
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
}] [policer
policer-id [port-redirect-group-queue
queue
queue-id|queue
queue-id|use-fc-mapped-queue
]]
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. This keyword is mutually exclusive with the redirection to a policer.
The policer keyword is optional. When specified, the egress packet will be redirected to the configured policer. Optional parameters allow the user to control how the forwarded policed traffic exits the egress port. By default, the policed forwarded traffic will use a queue in the egress port’s policer-output-queue queue group, alternatively a queue in an instance of a user configured queue group can be used or a local SAP egress queue. This keyword is mutually exclusive with the
hsmda-counter-override keyword.
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.
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 37. 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 38 presents the way that packets are mapped to queues based on the type of service and the various forwarding types.
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.
dst-ip {ip-address/mask | ip-address ipv4-address-mask | ip-prefix-list prefix-list-name}
dst-ip {ipv6-address/prefix-length | ipv6-address ipv6-address-mask}
To match on the IPv4 or IPv6 destination 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 for IPv4.
The no form of this command removes the destination IPv4 or IPv6 address match criterion.
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 and matches all packets regardless of whether they are fragmented or not.
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.
fragment {true
| false
| first-only
| non-first-only
}
The no form of this command removes the match criterion and matches all packets regardless of whether they are fragmented or not.
src-ip {ip-address/mask | ip-address
ipv4-address-mask | ip-prefix-list
prefix-list-name}
src-ip {ipv6-address/prefix-length | ipv6-address
ipv6-address-mask}
The no form of the command removes the source IPv4 or IPv6 address match criterion.
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
|
The no form of the command reverts to the default.
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 instance-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-egress 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. Note that the minimum resulting packet size used by the system is 1 byte.
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. When max is specified, the maximum policer rate used will be equal to the maximum capacity of the card on which the policer is configured. If the policer rate is set to a value larger than the maximum rate possible for the card, then the PIR used is equivalent to max.
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).
The commands de-mark-inner and
de-mark-outer take precedence over the
de-mark command if both are specified in the same policy.
[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 commands dot1p-inner and
dot1p-outer take precedence over the dot1p command if both are specified in the same policy.
The no form of the command sets the IEEE 802.1P or IEEE 802.1Q priority bits to 0.
This command takes precedence over the de-mark command if both are specified in the same policy and over the default action.
The configuration of qinq-mark-top-only under the SAP egress takes precedence over the use of the
de-mark-inner in the policy, i.e. the inner VLAN tag is not remarked when
qinq-mark-top-only is configured (the marking used for the inner VLAN tag is based on the current default which is governed by the marking of the packet received at the ingress to the system).
If no de-mark commands are used, the DE bit is preserved if an ingress inner tag exists, or set to zero otherwise.
This command takes precedence over the de-mark command if both are specified in the same policy and over the default action.
If no de-mark commands are used, the DE bit is preserved if an ingress outer or single tag exists, or set to zero otherwise.
This command explicitly defines the egress inner VLAN tag IEEE 802.1P (dot1p) bits marking for fc-name. When the marking is set, all packets of
fc-name that have either an inner IEEE 802.1Q or IEEE 802.1P encapsulation on a qinq SAP will use the explicitly defined
dot1p-value. If the egress packets for
fc-name are not IEEE 802.1Q or IEEE 802.1P qinq encapsulated, this command has no effect.
The optional in-profile |
dot1p-value out-profile dot1p-value parameters on the
dot1p-inner command adds the capability to mark the in and out of profile status on an egress qinq SAP. The command with the additional parameters may be used on the SAP when the internal in and out of profile status needs to be communicated to an access network/customer device that does not support the DE bit. Once the in-profile keyword is added, then the rest of the structure must be specified.
This command takes precedence over the dot1p command if both are specified in the same policy and over the default action where the marking is taken from packet received at ingress.
The configuration of qinq-mark-top-only under the SAP egress takes precedence over the use of the
dot1p-inner in the policy, that is, the inner VLAN tag is not remarked when
qinq-mark-top-only is configured (the marking used for the inner VLAN tag is based on the current default which is governed by the marking of the packet received at the ingress to the system).
The no form of the command sets the inner IEEE 802.1P or IEEE 802.1Q priority bits to 0.
This command explicitly defines the egress outer or single VLAN tag IEEE 802.1P (dot1p) bits marking for fc-name. When the marking is set, all packets of fc-name that have either an outer or single IEEE 802.1Q or IEEE 802.1P encapsulation on a qinq or a dot1p SAP, respectively, will use the explicitly defined
dot1p-value. If the egress packets for
fc-name are not IEEE 802.1Q or IEEE 802.1P encapsulated, this command has no effect.
The optional in-profile |
dot1p-value out-profile dot1p-value parameters on the dot1p-outer command adds the capability to mark the in and out of profile status on an egress qinq or dot1p SAP. The command with the additional parameters may be used on the SAP when the internal in and out of profile status needs to be communicated to an access network/customer device that does not support the DE bit. Once the in-profile keyword is added, then the rest of the structure must be specified.
This command takes precedence over the dot1p command if both are specified in the same policy and over the default action where the marking is taken from packet received at ingress.
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 description string from the context.
The no form of this command deletes the specified list.
prefix ip-prefix/prefix-length
The no form of this command deletes the specified prefix from the list.
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 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.
mbs {[0..2625
][kilobytes
] | [0..2688000
]bytes
| default
}
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. Note that the minimum resulting packet size used by the system is 1 byte.
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 (including the
ingress-rate/
egress-rate setting) 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).
This command alters the generic buffer pool association of the queue for the purpose of allowing queue-specific WRED slopes with minimal provisioning. When the wred-queue command is defined and the queue ID is created on an IOM3-XP, a buffer pool is created specifically for the queue and the queue obtains all buffers from that pool. The size of the pool is the same as the size of the queue. In this manner, the WRED slopes that operate based on the pool’s buffer utilization are also reacting to the congestion depth of the queue.
In the case where the QoS policy is applied to a SAP on an IOM3-XP which has WRED queue support shutdown (config>card>>fp>egress>wred-queue-control>shutdown) the queue will continue to map to either to its default pool or the pool defined in the
pool command. If the
no shutdown command is executed on the IOM, the queue will at that point be automatically moved to its own WRED pool.
Each pool created for a queue using the wred-queue command shares buffers with all other wred-queue enabled queues on the same IOM3-XP. The WRED pool buffer management behavior is defined within the
config>card>fp>egress>wred-queue-control CLI context.
The no form of the command restores the generic buffer pool behavior to the queue. The WRED pool is removed from the system. The queue will be moved to either the default buffer pool or to a named pool if defined and the pool exists.
sap-ingress [policy-id] [association
| match-criteria
| hsmda
| detail
]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
show qos sap-ingress
===============================================================================
Sap Ingress Policies
===============================================================================
Policy-Id Scope Name Description
-------------------------------------------------------------------------------
1 Template default Default SAP ingress QoS policy.
3 Template
3:P2 Template Auto-created pcc-rule sap-ingres*
-------------------------------------------------------------------------------
Number of Policies : 3
-------------------------------------------------------------------------------
===============================================================================
show qos sap-ingress 3:P2 match-criteria
===============================================================================
QoS Sap Ingress
===============================================================================
-------------------------------------------------------------------------------
Sap Ingress Policy (3:P2)
-------------------------------------------------------------------------------
Policy-id : 3:P2 Scope : Template
Default FC : be Priority : Low
Criteria-type : IP
Name : (Not Specified)
Description : Auto-created pcc-rule sap-ingress qos policy
-------------------------------------------------------------------------------
Dynamic Configuration Information
-------------------------------------------------------------------------------
PccRule Insert Point : 40000 (size 100* DynPlcr Insert Point : 20 (size 20)
Shared Policies : 0
CBS : Def MBS : Def
Parent : (Not Specified)
Level : 1 Weight : 1
Packet Byte Offset : 0
Stat Mode : minimal
-------------------------------------------------------------------------------
* indicates that the corresponding row element may have been truncated.
-------------------------------------------------------------------------------
Match Criteria
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
IP Match Criteria
-------------------------------------------------------------------------------
Entry : 40000
Description : Auto-created entry for pcc-rule RULE_ingress_FC
Source IP : Undefined
Dest. IP : 75.24.24.3/32
Source Port : None Dest. Port : None
Protocol : tcp DSCP : cp60
Fragment : Off
FC : af Priority : Default
Policer : n/a
Entry : 40001
Description : Auto-created entry for pcc-rule RULE_ingress_FC_HTTP
Source IP : Undefined
Dest. IP : 75.24.24.4/32
Source Port : None Dest. Port : None
Protocol : tcp DSCP : cp60
Fragment : Off
FC : h2 Priority : Default
Policer : n/a
Entry : 40002
Description : Auto-created entry for pcc-rule RULE_ingress_FC_RDR
Source IP : Undefined
Dest. IP : 75.24.24.5/32
Source Port : None Dest. Port : None
Protocol : tcp DSCP : cp60
Fragment : Off
FC : h1 Priority : Default
Policer : n/a
Entry : 40003
Description : Auto-created entry for pcc-rule RULE_ingress_RATE_LIMIT
Source IP : Undefined
Dest. IP : 75.24.24.10/32
Source Port : None Dest. Port : None
Protocol : tcp DSCP : cp60
Fragment : Off
FC : Default Priority : Default
Policer : 20
…
-------------------------------------------------------------------------------
IPv6 Match Criteria
-------------------------------------------------------------------------------
No Match Criteria Entries found.
===============================================================================
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#
# show qos sap-ingress
===============================================================================
Sap Ingress Policies
===============================================================================
Policy-Id Scope Name Description
-------------------------------------------------------------------------------
1 Template default Default SAP ingress QoS policy.
10 Template
20 Template
-------------------------------------------------------------------------------
Number of policies : 3
-------------------------------------------------------------------------------
===============================================================================
*A:#
sap-egress [policy-id] [association
| match-criteria
| hsmda
| detail
]
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#
configure
#--------------------------------------------------
echo "QoS Policy Configuration"
#--------------------------------------------------
qos
match-list
ip-prefix-list "ip-prefix-list-1" create
description "IPv4 prefix list"
prefix 10.0.0.0/8
prefix 192.168.0.0/16
exit
exit
exit
#--------------------------------------------------
echo "QoS Policy Configuration"
#--------------------------------------------------
qos
sap-egress 10 create
queue 1 create
exit
queue 2 create
exit
fc af create
queue 2
exit
ip-criteria
entry 10 create
match
dst-ip ip-prefix-list "ip-prefix-list-1"
exit
action fc "af"
exit
exit
exit
exit
*A:PE# show qos match-list ip-prefix-list "ip-prefix-list-1"
===============================================================================
QoS Match IP Prefix List
===============================================================================
Prefix Name : ip-prefix-list-1
Description : IPv4 prefix list
-------------------------------------------------------------------------------
IP Prefixes
-------------------------------------------------------------------------------
10.0.0.0/8
192.168.0.0/16
-------------------------------------------------------------------------------
No. of Prefixes : 2
-------------------------------------------------------------------------------
===============================================================================
*A:PE#
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 — 800 qtag1 0 — 4094 qtag2 *, 0 — 4094
|
