Service ingress and egress QoS policies
Overview
There is one default service ingress policy and one default service egress policy. Each policy can have up to 32 ingress queues and 8 egress queues per service.
The default policies can be copied and modified but they cannot be deleted. The default policies are identified as policy ID 1.
The default policies are applied to the appropriate interface, by default. For example, the default SAP ingress policy is applied to access ingress SAPs. The default SAP egress policy is applied to access egress SAPs. Other QoS policies must be explicitly associated.
For information about the tasks and commands necessary to access the CLI and to configure and maintain routers, see the Entering CLI Commands chapter in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Classic CLI Command Reference Guide.
Basic configurations
A basic service egress QoS policy must have the following:
a unique service egress QoS policy ID
a QoS policy scope of template or exclusive
at least one defined default queue
A basic service ingress QoS policy must have the following:
a unique service ingress QoS policy ID
a QoS policy scope of template or exclusive
at least one default unicast forwarding class queue
at least one multipoint forwarding class queue
Configuring and applying QoS policies is optional. If no QoS policy is explicitly applied to a SAP or IP interface, a default QoS policy is applied.
Service ingress QoS policy
To create a service ingress policy, define the following:
a policy ID value. The system does not dynamically assign a value.
a description. The description provides a brief overview of policy features.
a default forwarding class for the policy. All packets received on an ingress SAP using this ingress QoS policy are classified to the default forwarding class.
a default priority for all packets received on an ingress SAP using this policy
mappings from incoming packet contents to a forwarding class, then separately, from the forwarding class to queue
forwarding class parameters:
Modify the multicast-queue default value to override the default multicast forwarding type queues mapping for fc fc-name.
Modify the unknown-queue default value to override the default unknown unicast forwarding type queues mapping for fc fc-name.
Modify the broadcast-queue default value to override the default broadcast forwarding type queues mapping for fc fc-name.
a precedence value for the forwarding class or enqueuing priority when a packet is marked with an IP precedence value
IP, IPv6, and MAC-based SAP ingress policies to select the appropriate ingress queue and corresponding forwarding class for matched traffic
a SAP ingress policy created with a template scope. The scope can be modified to exclusive for a special one-time use policy. Otherwise, the template scope enables the policy to be applied to multiple SAPs.
The following displays an service ingress policy configuration:
A:ALA-7>config>qos>sap-ingress# info
----------------------------------------------
...
sap-ingress 100 create
description "Used on VPN sap"
...
----------------------------------------------
A:ALA-7>config>qos>sap-ingress#
Service ingress QoS queue
To create a service ingress queue, define the following:
a new queue ID value. The system does not dynamically assign a value
queue parameters. Ingress queues support multipoint queues, explicit and auto-expedite hardware queue scheduling, and parent virtual scheduler definition.
The following displays an ingress queue configuration:
A:ALA-7>config>qos# info
#------------------------------------------
echo "QoS Policy Configuration"
#------------------------------------------
...
sap-ingress 100 create
description "Used on VPN sap"
queue 1 create
exit
queue 2 multipoint create
exit
queue 10 create
parent VPN_be
rate 11000
exit
queue 12 create
parent VPN_priority
rate 11000
exit
queue 13 create
parent VPN_reserved
rate 1
exit
queue 15 create
parent VPN_video
rate 1500 cir 1500
exit
queue 16 create
parent VPN_voice
rate 2500 cir 2500
exit
queue 17 create
parent VPN_nc
rate 100 cir 36
exit
queue 20 multipoint create
parent VPN_be
rate 11000
exit
queue 22 multipoint create
parent VPN_priority
rate 11000
exit
queue 23 multipoint create
parent VPN_reserved
rate 1
exit
queue 25 multipoint create
parent VPN_video
rate 1500 cir 1500
exit
queue 26 multipoint create
parent VPN_voice
rate 2500 cir 2500
exit
queue 27 multipoint create
parent VPN_nc
rate 100 cir 36
exit
...
#------------------------------------------
A:ALA-7>config>qos#
Ingress percent-rate support
The percent-rate command is supported in a SAP ingress QoS policy for pir and cir parameters for both queues and policers, with the fir parameter supported only for queues on FP4 or later hardware that is ignored when the related policy is applied to FP3-based hardware. For pir, the range is 0.01 to 100.00, and for cir and fir, the range is 0.00 to 100.00.
For queues, when the queue rate is percent-rate, either a local-limit or a port-limit can be applied.
When the local-limit is used, the percent-rate is relative to the queue’s parent scheduler rate. If there is no parent scheduler rate, or its rate is max, the port-limit is used. When the port-limit is used, the percent-rate is relative to the rate of the port (including the ingress-rate setting) to which the queue is attached. The port-limit is the default.
For policers, the percent-rate rate is always relative to the immediate parent root policer/arbiter rate or the FP capacity.
The following shows a SAP ingress QoS policy configuration:
*A:PE>config>qos>sap-ingress# queue 1 percent-rate
- no percent-rate
- percent-rate <pir-percent> [cir <cir-percent>] [fir <fir-percent>] [port-limit | local-limit] [fir <fir-percent>]
- percent-rate <pir-percent> police [port-limit | local-limit]
<pir-percent> : [0.01..100.00]
<cir-percent> : [0.00..100.00]
<fir-percent> : [0.00..100.00]
<police> : keyword
<port-limit | local-*> : keyword
*A:PE>config>qos>sap-ingress# policer 1 percent-rate
- no percent-rate
- percent-rate <pir-percent> [cir <cir-percent>]
<pir-percent> : [0.01..100.00]
<cir-percent> : [0.00..100.00]
*A:PE>config>qos>sap-ingress#
Ingress forwarding class (FC)
The following displays a forwarding class and precedence configurations:
A:ALA-7>config>qos# info
#------------------------------------------
...
fc af create
queue 12
broadcast-queue 22
multicast-queue 22
unknown-queue 22
exit
fc be create
queue 10
broadcast-queue 20
multicast-queue 20
unknown-queue 20
exit
fc ef create
queue 13
broadcast-queue 23
multicast-queue 23
unknown-queue 23
exit
fc h1 create
queue 15
broadcast-queue 25
multicast-queue 25
unknown-queue 25
exit
fc h2 create
queue 16
broadcast-queue 26
multicast-queue 26
unknown-queue 26
exit
fc nc create
queue 17
broadcast-queue 27
multicast-queue 27
unknown-queue 27
exit
prec 0 fc be
prec 2 fc af
prec 3 fc ef
prec 5 fc h1
prec 6 fc h2
prec 7 fc nc
...
#------------------------------------------
A:ALA-7>config>qos#
Ingress IP match criteria
When specifying SAP ingress match criteria, only one match criteria type (IP/IPv6 or MAC) can be configured in the SAP ingress QoS policy.
The following displays an ingress IP criteria configuration:
A:ALA-7>config>qos# info
...
#------------------------------------------
echo "QoS Policy Configuration"
#------------------------------------------
...
sap-ingress 100 create
...
ip-criteria
entry 10 create
description "Entry 10-FC-AF"
match protocol 6
src-ip 10.10.10.103/24
exit
action fc af priority high
exit
entry 20 create
description "Entry 20-FC-BE"
match protocol 17
dst-port eq 255
exit
no action
exit
exit
exit
..
#------------------------------------------
A:ALA-7>config>qos#
Ingress IPv6 match criteria
When specifying SAP ingress match criteria, only one match criteria type (IP/IPv6 or MAC) can be configured in the SAP ingress QoS policy. This feature applies only to the 7750 SR and 7950 XRS.
The following displays an ingress IPv6 criteria configuration:
A:ALA-48>config>qos>sap-ingress# info
----------------------------------------------
queue 1 create
exit
queue 11 multipoint create
exit
ip-criteria
exit
ipv6-criteria
entry 10 create
description "IPv6 SAP-ingress policy"
match
src-ip 2001:db8:1000::/64
dst-ip 2001:db8:2000::/64
exit
action fc be priority low
exit
entry 20 create
description "Entry 20-FC-AF"
match next-header tcp
src-port eq 500
exit
action fc af priority high
exit
exit
----------------------------------------------
A:ALA-48>config>qos>sap-ingress#
Tagging of Ingress IP-criteria and IPv6-criteria
The SAP ingress QoS policy allows the assignment of a tag to each IPv4/IPv6 criteria statement entry. This is useful when a single SAP ingress QoS policy needs to be used for a different service context and it is still needed to apply service specific entries at individual SAP level.
In this concept, the SAP ingress policy can contain entries with different tag values as well as untagged entries. The user configures a tag entry override per-SAP to select which tagged entries are included for the related SAP (untagged entries are always included). Using this tagging concept and matching on destination-port are mutually exclusive.
In the following example, a base configuration IPv4 prefix list is created together with two other lists (list1 and list2) that are used for different VPRN IP interfaces. Also, a base configuration IPv6 prefix list is created together with two other lists (list1 and list2) that are to be used for different VPRN IP interfaces.
The following entries are used for both the IPv4 and IPv6 criteria statement:
VPRN 1/int: 10, 20, 30
VPRN 2/int: 10, 20, 30, 1000
VPRN 3/int: 10, 20, 30, 2000
Example:
configure
qos
match-list
ip-prefix-list "ipv4-base-config" create
prefix 10.0.0.0/16
prefix 10.1.0.0/16
exit
ip-prefix-list "list1" create
prefix 172.16.1.0/24
prefix 172.16.2.0/24
exit
ip-prefix-list "list2" create
prefix 192.168.1.0/24
prefix 192.168.2.0/24
exit
ipv6-prefix-list "ipv6-base-config" create
prefix 2001:db8:1000::/64
prefix 2001:db8:2000::/64
exit
ipv6-prefix-list "list1" create
prefix 2001:db8:3000::/64
prefix 2001:db8:4000::/64
exit
ipv6-prefix-list "list2" create
prefix 2001:db8:5000::/64
prefix 2001:db8:6000::/64
exit
exit
sap-ingress 10 name "10" create
queue 1 create
exit
queue 11 multipoint create
exit
policer 1 create
exit
policer 2 create
exit
ip-criteria
type tagged-entries
entry 10 create
match
src-ip ip-prefix-list "ipv4-base-config"
exit
action fc "l2" policer 1
exit
entry 20 create
match
src-ip 10.2.0.0/16
exit
action fc "af" policer 2
exit
entry 30 create
match
src-ip 10.3.0.0/16
exit
action fc "af"
exit
entry 1000 create
tag 1
match
src-ip ip-prefix-list "list1"
exit
action fc "l1"
exit
entry 2000 create
tag 2
match
src-ip ip-prefix-list "list2"
exit
action fc "ef"
exit
exit
exit
ipv6-criteria
type tagged-entries
entry 10 create
match
src-ip ipv6-prefix-list "ipv6-base-config"
exit
action fc "l2" policer 1
exit
entry 20 create
match
src-ip 10.2.0.0/16
exit
action fc "af" policer 2
exit
entry 30 create
match
src-ip 10.3.0.0/16
exit
action fc "af"
exit
entry 1000 create
tag 1
match
src-ip ip-prefix-list "list1"
exit
action fc "l1"
exit
entry 2000 create
tag 2
match
src-ip ip-prefix-list "list2"
exit
action fc "ef"
exit
exit
exit
exit
service
vprn 1 name "1" customer 1 create
interface "int" create
address 10.10.10.1/24
sap 1/1/1:1 create
ingress
sap-ingress "10"
exit
exit
exit
vprn 2 name "2" customer 1 create
interface "int" create
address 10.20.20.1/24
sap 1/1/1:2 create
ingress
sap-ingress "10"
criteria-overrides
ip-criteria
activate-entry-tag 1
ipv6-criteria
activate-entry-tag 1
exit
exit
exit
exit
exit
vprn 3 name "3" customer 1 create
interface "int" create
address 10/30/30.1/24
sap 1/1/1:3 create
ingress
sap-ingress "10"
criteria-overrides
ip-criteria activate-entry-tag 2
ipv6-criteria activate-entry-tag 2
exit
exit
exit
exit
exit
exit
Ingress MAC match criteria
Both IP/IPv6 criteria and MAC criteria cannot be configured in the same SAP ingress QoS policy.
To configure service ingress policy MAC criteria, define the following:
a new entry ID value. Entries must be explicitly created. The system does not dynamically assign entries or a value.
the action to associate the forwarding class or enqueuing priority with a specific MAC criteria entry ID
a description. The description provides a brief overview of policy features.
match criteria for ingress SAP QoS policy. Optionally, specify an IP protocol to be used as an ingress SAP QoS policy match criterion.
The following displays an ingress MAC criteria configuration:
A:ALA-7>config>qos# info
...
#------------------------------------------
echo "QoS Policy Configuration"
#------------------------------------------
...
sap-ingress 101 create
...
mac-criteria
entry 10 create
description "Entry10-low prio"
match
dst-mac 04-67-ff-00-00-01 ff-ff-ff-ff-ff-ff
dot1p 7 7
exit
action fc be priority low
exit
exit
exit
#------------------------------------------
A:ALA-7>config>qos#
VLAN ID matching
On ingress, VLAN ID matching may be used to set QoS on SAP ingress. The matching rules are the same as for VID filter (See ‟VID filters” in the Filter Policies section of the 7450 ESS, 7750 SR, 7950 XRS, and VSR Router Configuration Guide) but the action allows setting of the forwarding class.
For example, to set the forwarding class of all VIDs with 6 in the lower 3 bits of the VID, a filter (as follows) could be constructed, then ingress qos 5 could be applied to any SAP that requires the policy.
qos
sap-ingress 5 create
queue 1 create
exit
queue 11 multipoint create
exit
mac-criteria
type vid
entry 1 create
match frame-type ethernet-II
outer-tag 6 7
exit
action fc "af"
exit
exit
exit
exit
Ingress criteria classification directly to policer
It is possible to classify traffic directly to a policer, independent of the policer/queue assigned to the traffic’s forwarding class. This is supported at SAP ingress by configuring a policer in the action statement: ip-criteria, ipv6-criteria, or mac-criteria.
The standard mechanisms are still used to assign a forwarding class to the related traffic, and this forwarding class continues to be used for QoS processing at egress.
The use of explicitly configured broadcast, unknown, or multicast policers is not supported. QPPB processing takes precedence over this feature.
This could be used, for example, when it is required that ingress OAM traffic is not subject to the same QoS control as other customer traffic on a specific SAP. The OAM traffic could be classified based on its source MAC address (for example, with an OUI of 00-xx-yy as shown in Ingress criteria classification directly to policer) and directed to policer 1 while the remainder of the customer’s traffic is processed using ingress queue 1.
The configuration would be as follows:
sap-ingress 10 create
queue 1 create
exit
queue 11 multipoint create
exit
policer 1 create
exit
mac-criteria
entry 10 create
match
src-mac 00-xx-yy-00-00-00 ff-ff-ff-00-00-00
exit
action policer 1
exit
exit
exit
Virtual network identifier classification
Virtual Network Identifier (VNI) classification is supported for VXLAN and VXLAN GPE traffic within a SAP ingress QoS policy. This classification is configured in the ip-criteria and ipv6-criteria contexts with type vxlan-vni (changed from the default type normal). The matching entry must be created with match protocol udp for IPv4 or match next-header udp for IPv6 and uses the vxlan-vni parameter within the match statement to match on a single VNI or a range of VNIs.
An alternative to SAP ingress VNI classification is queue group redirection, which provides a more advanced mechanism where individual VNIs can use their own access ingress and egress queue group instances for QoS control (see VXLAN VNI queue group redirection).
The type cannot be changed when ip-criteria or ipv6-criteria entries are configured. If there are no ip-criteria or ipv6-criteria entries configured, the type can be changed from vxlan-vni to normal. The type can only be changed from normal to vxlan-vni if there are no ip-criteria or ipv6-criteria entries configured and if the SAP ingress QoS policy has not been applied to any object.
The following is an example where traffic received with a VNI of 1 is sent to policer 1 and VNIs 2 to 10 are sent to policer 2:
sap-ingress 10 create
queue 1 create
exit
queue 11 multipoint create
exit
policer 1 create
exit
policer 2 create
exit
ip-criteria
type vxlan-vni
entry 10 create
match protocol udp
vxlan-vni eq 1
exit
action policer 1
exit
entry 20 create
match protocol udp
vxlan-vni range 2 10
exit
action policer 2
exit
exit
exit
Ingress VNI classification is applicable to all Ethernet SAPs, except for PW-SAPs, B-VPLS SAPs, and CCAG SAPs, in any applicable service.
The following restrictions also apply:
Source and destination port matching on a SAP, on which a SAP ingress QoS policy is applied that has ip-criteria or ipv6-criteria statements with type vxlan-vni, is not available for:
IPv4 QoS classification for VXLAN or VXLAN GPE traffic
IPv6 QoS and filter classification for VXLAN or VXLAN GPE traffic
If the criteria type is set to vxlan-vni and if source or destination port matching entries are configured in an IPv4 or IPv6 SAP ingress QoS policy or in an IPv6 filter policy, any VXLAN or VXLAN GPE ingress traffic do not match these entries on the SAP on which the SAP ingress QoS policy is applied.
The simultaneous configuration on a SAP of a QoS policy containing an ip-criteria entry with type vxlan-vni and of a MAC filter with type vid is not supported, and the other way around.
This is only applicable to Epipe and VPLS services.
If a SAP ingress QoS policy that has ip-criteria or ipv6-criteria statements with type vxlan-vni is applied to a SAP, any ip-criteria or ipv6-criteria entry match vxlan-vni statements do not match:
IPv4 packets containing options
IPv6 packets containing extension headers
ingress 802.1ah PBB frames
IPv6 over PPPoE traffic received with more than one VLAN tag
non-first fragments of an IPv4 or IPv6 fragmented packet
The configuration of a SAP ingress QoS policy containing ip-criteria or ipv6-criteria entry match vxlan-vni statements is not supported within an SLA profile.
FC mapping based on EXP bits
Use the lsp-exp command to set the sap-ingress qos policy on Ethernet L2 SAPs to perform FC mapping based on EXP bits.
The lsp-exp option causes the forwarding class and drop priority of incoming traffic to be determined by the mapping result of the EXP bits in the top label.
The following example displays FC mapping based on EXP bits:
*A:Dut-T>config>qos>sap-ingress# info
----------------------------------------------
queue 1 create
exit
queue 2 create
exit
queue 3 create
exit
queue 11 multipoint create
exit
fc "af" create
queue 2
exit
fc "be" create
queue 1
exit
fc "ef" create
queue 3
exit
lsp-exp 0 fc "be" priority low
lsp-exp 1 fc "af" priority high
Storing match criteria entries
Cards store QoS policy match-criteria entries in dedicated memory banks in hardware also referred to as CAM tables:
IP/MAC ingress
IP/MAC egress
IPv6 ingress
IPv6 egress
FP4-based or later cards
To optimize both scale and performance, policy match-criteria entries configured by the user are compressed by each FP4 line card before being installed in hardware.
This compression can result, in an unexpected scenario typically only achieved in a lab environment, in an overload condition where entries for a line card QoS policy on a line card FP are not programmed. This overload condition can occur when applying a QoS policy for the first time on a line card FP or when adding entries to a QoS policy.
- applying a QoS policy
A policy is installed for the first time on a line card FP if no router interface, service interface, SAP, spoke SDP, mesh SDP or ESM subscriber host was using the policy on this FP.
A policy installed for the first time on a line card FP can lead to a compression failure resulting in an overload condition for this policy on this FP. In this case, none of the entries for the affected QoS match-criteria policy are programmed, and the QoS policy queuing, FC mapping, and FC marking are unaffected.
-
adding QoS match-criteria entries
Adding an additional entry to a QoS policy can lead to a compression failure resulting in an overload condition.
In this case, the newly added entry is not programmed on the affected FP. Additional entries added to the same policy after the first overload condition are also not programmed on the affected FP as the system attempts to install all outstanding additions in order.
The CPM QoS management task controls the maximum number of match criteria entries per FP. If the user attempts to go over the scaling limit, the system returns an interactive error message.
Note: A trap is raised if a policy is in overload, there is no interactive error message. -
removing QoS match-criteria entries
Removing match-criteria entries from a QoS policy is always successful.
-
resolving overload
The overload condition should be resolved by the network operator before adding new entries in the affected policy.
To identify the affected policy, the system logs the overload event providing slot number, FP number, and impacted memory bank. Based on this information, the tools>dump>qos>match-criteria-overload command allows the user to identify the affected policy and policy entries in the system.
To resolve the overload condition, the network operator can remove the newly added entries from the affected policy or assign a different policy.
Service egress QoS policy
To create a service egress policy, define the following:
a new policy ID value. The system does not dynamically assign a value.
the scope. A QoS policy must be defined as having either an exclusive scope for one-time use, or a template scope, which enables its use with multiple SAPs.
a description. The description provides a brief overview of policy features.
Service egress QoS queue
To create a service egress QoS queue, define the following:
the forwarding class name or names associated with the egress queue. The egress queue for the service traffic is selected based on the forwarding classes that are associated with the queue.
a new queue ID value. The system does not dynamically assign a value.
queue parameters. Egress queues support explicit and auto-expedite hardware queue scheduling, and parent virtual scheduler definition.
The following displays an egress QoS policy configuration:
A:ALA-7>config>qos# info
--------------------------------------------------
...
sap-egress 105 create
description "SAP egress policy"
queue 1 create
parent "scheduler-tier1"
exit
queue 2 create
exit
queue 3 expedite create
parent "test1"
exit
fc af create
queue 1
exit
fc ef create
exit
exit
...
------------------------------------------------
A:ALA-7>config>qos#
Egress percent-rate support
The percent-rate command is supported in a SAP egress QoS policy for pir and cir parameters for both queues and policers. For pir, the range is 0.01 to 100.00, and for cir, the range is 0.00 to 100.00.
For queues, when the queue rate is percent-rate, either a local-limit or a port-limit can be applied.
When the local-limit is used, the percent-rate is relative to the queue’s parent scheduler rate or the agg-rate at egress. If there is no parent scheduler rate or agg-rate, or those rates are max, the port-limit is used. When the port-limit is used, the percent-rate is relative to the rate of the port (including the egress-rate setting) to which the queue is attached. The port-limit is the default.
For policers, the percent-rate rate is always relative to the immediate parent root policer/arbiter rate or the FP capacity.
The following shows a SAP egress QoS policy configuration:
*B:PE>config>qos>sap-egress# queue 1 percent-rate
- no percent-rate
- percent-rate <pir-percent> [cir <cir-percent>] [port-limit | local-limit]
<pir-percent> : [0.01..100.00]
<cir-percent> : [0.00..100.00]
<port-limit | local-*> : keyword
*B:PE>config>qos>sap-egress# policer 1 percent-rate
- no percent-rate
- percent-rate <pir-percent> [cir <cir-percent>]
<pir-percent> : [0.01..100.00]
<cir-percent> : [0.00..100.00]
*B:PE>config>qos>sap-egress#
Egress queue CBS and MBS as a function of delay
SR OS supports egress queue length configuration (CBS and MBS) as a function of the expected delay. The system automatically translates this configuration into kilobytes based on the administrative rate of the queue parent (for example, the scheduler or aggregate shaper) for queues that have a parent. The actual operational values of CBS and MBS are shown in kilobytes, and not as a function of the delay, in the corresponding show pools commands.
Nokia recommends using the same method of defining CBS, MBS, and burst limit for all queues within the same SAP egress policy. CBS and MBS as a function of delay is not supported on HSQ. Policies that contain a function of delay applied to an HSQ will have default egress queue CBS and MBS value.
CBS, MBS, and burst limit as a function of queue delay
SR OS supports CBS, MBS, and burst limit configuration, in microseconds, as a function of the delay in SAP egress policy using the following commands.
- MD-CLI
configure qos sap-egress queue burst-limit-delay-time cbs-delay-time mbs-delay-time - classic
CLI
configure qos sap-egress queue burst-limit delay-time cbs delay-time mbs delay-time
The actual CBS, MBS, and burst limit values are calculated based on the queue parent administrative rate and may differ depending on the scheduling hierarchy. This calculation can be done only if the queue parent has an explicit rate defined (for example, a scheduler rate or aggregate rate). The system uses the default values if the queue parent is a port without an explicit rate defined.
CBS and MBS as a function of SAP delay budget
SR OS supports egress queue CBS and MBS configuration as a function of the total latency budget for the specific SAP using the following procedures.
The actual CBS and MBS values are calculated based on the queue parent administrative rate and may differ depending on the scheduling hierarchy. This calculation can be done only if the queue parent has an explicit rate defined (for example, a scheduler rate or aggregate rate). The system uses the default values if the queue parent is a port without an explicit rate defined.
- MD-CLI
-
Configure the SAP latency budget, in microseconds, using one of the following commands:
configure service epipe sap egress qos latency-budget configure service ies interface sap egress qos latency-budget configure service vpls sap egress qos latency-budget configure service vprn interface sap egress qos latency-budget -
In the SAP egress policy, configure the percentage of the SAP latency budget for an individual queue:
configure qos sap-egress queue cbs-delay-percent configure qos sap-egress queue mbs-delay-percent
-
- classic CLI
-
Configure the SAP latency budget, in microseconds, using one of the following commands:
configure service epipe sap egress latency-budget configure service ies interface sap egress latency-budget configure service vpls sap egress latency-budget configure service vprn interface sap egress latency-budget -
In the SAP egress policy, configure the percentage of the SAP latency budget for an individual queue:
configure qos sap-egress queue cbs delay-percent configure qos sap-egress queue mbs delay-percent
-
Dynamic MBS for egress queue group queues
Dynamic MBS is used to constrain the maximum delay experienced by the traffic forwarded through an egress queue group queue when the operational PIR of the queue is modified as part of the HQoS algorithm.
The approximate maximum delay of traffic through a queue because of the length of the queue, when the queue is not using HQoS, is relative to its administrative PIR and can be approximated as (MBS[kB] ✕ 8) / PIR[kb/s]) in seconds. A queue’s PIR is set to max, and its administrative PIR is set to the rate of the port to which the queue is attached.
When using HQoS, the PIR is modified by the HQoS algorithm to give an operational PIR that is equal to or lower than the administrative PIR. As the operational PIR changes, the delay through the queue can also change if the length of the queue is fixed. Reducing the operational PIR could increase the delay, while increasing the operational PIR could reduce the delay. Enabling dynamic MBS on a queue allows the system to change the administrative MBS of the queue in a ratio of operational PIR to administrative PIR, giving an operational MBS, which aims to maintain the maximum queue delay. A queue’s drop tails and WRED slope parameters are defined as percentages of the MBS and are, therefore, adjusted accordingly.
When any of the queue parameters are reduced, packets that are already in the queue are not affected and are forwarded. Reducing these parameters constrains the latency for newly arriving packets, but those packets already in the queue before the new parameter values were set are forwarded with the delay associated with the actual queue depth when the packet was enqueued (based on the previous parameter values).
The configured CBS is used as a minimum operational MBS. The maximum MBS is capped by the maximum administrative MBS (1 GB).
If the operational MBS changes such that its value is similar or equal to the configured CBS, the system increases the CBS to ensure that buffers can be requested from the correct portion of the buffer pool (shared or reserved). This operation is automatic, and the CBS reverts to its configured value if the MBS is increased sufficiently. The automatic increase in the CBS could, however, cause the resv-cbs red or amber alarms to be raised if the increase in the related queues’ CBS results in the total CBS assigned (but not necessarily used) matching or exceeding the resv-cbs red and amber thresholds.
If a LAG is used together with pool-per-queue, the related hardware queues exist in their own pool in the egress WRED megapool on a specific FP and the operational MBS is used to size the shared part of the pool with the sum of the CBS defining the reserved part of the pool.
Dynamic MBS is supported for both native FP and pool-per-queue queues within an egress queue group template, which can be applied to access or network Ethernet ports and used for egress network interface traffic, egress SAP traffic, and subscriber egress policed traffic.
The configuration of dynamic MBS and queue depth monitoring are mutually exclusive.
Dynamic MBS is configured as follows:
configure
qos
queue-group-templates
egress
queue-group queue-group-name create
queue queue-idThe operational MBS can be shown using the show pools and show qos scheduler-hierarchy commands.
The following example shows the use of dynamic MBS. A queue group template is applied to port 5/1/1 configured with multiple queues using HQoS, one of which has the following parameters:
queue-group "qg1" create
queue 1 best-effort create
parent "s1"
rate 50000
mbs 1000 kilobytes
dynamic-mbs
exitWithout any traffic in the other queues constraining the operational PIR on this queue, the MBS used is the administrative MBS.
*B:PE# show pools access-egress 5/1/1 queue-group "qg1" instance 1
...
===============================================================================
Queue : accQGrp->qg1:1(5/1/1)->1
===============================================================================
FC Map : not-applicable
Dest Tap : not-applicable Dest FP : not-applicable
Admin PIR : 50000 Oper PIR : 50000
Admin CIR : 0 Oper CIR : 0
Admin MBS : 1008 KB Oper MBS : 1008 KB
High-Plus Drop Tail : 1008 KB High Drop Tail : 1008 KB
Low Drop Tail : 888 KB Exceed Drop Tail : 792 KB
CBS : 0 KB Depth : 0
Slope : not-applicable
If traffic is sent to the other queues in the queue group such that the operational PIR of queue 1 is reduced to 25 Mb/s, the show output changes to:
*B:PE# show pools 5/1/1 access-egress queue-group "qg1" instance 1
...
===============================================================================
Queue : accQGrp->qg1:1(5/1/1)->1
===============================================================================
FC Map : not-applicable
Dest Tap : not-applicable Dest FP : not-applicable
Admin PIR : 50000 Oper PIR : 25000
Admin CIR : 0 Oper CIR : 0
Admin MBS : 1008 KB Oper MBS : 504 KB
High-Plus Drop Tail : 1008 KB High Drop Tail : 1008 KB
Low Drop Tail : 948 KB Exceed Drop Tail : 900 KB
CBS : 0 KB Depth : 0
Slope : not-applicable
The output shows that the operational MBS is now 50% of the administrative MBS and that the queue’s drop tails have changed accordingly.
Queue length as a delay value
The length of a queue within an egress queue group template can be configured as a target queue delay, in ms, instead of an absolute byte/kbytes value. The queue MBS is calculated from the queue delay and the administrative PIR, with the MBS [kB] being approximately the value of ((queue delay[ms]/1000) ✕ (PIR[kb/s] / 8)).The queue delay is configured as follows:
configure
qos
queue-group-templates
egress
queue-group queue-group-name create
queue queue-id
queue-delay msThe queue-delay command and the mbs command are mutually exclusive. To change between the mbs and queue-delay parameters, the current parameter must be removed before adding the new parameter; that is, changing from mbs to queue-delay requires a no mbs before the queue-delay is configured and changing from queue-delay to mbs requires a no queue-delay before the mbs is configured. If queue-delay is configured for an egress queue group queue, it is not possible to override the MBS for that queue.
The following is an example of configuring queue delay and the resulting MBS:
*A:PE# configure qos queue-group-templates egress queue-group "qg2"
*A:PE>cfg>qos>qgrps>egr>qgrp# info
----------------------------------------------
queue 1 best-effort create
rate 50000
queue-delay 100
exit
----------------------------------------------
*A:PE>cfg>qos>qgrps>egr>qgrp# exit all
*A:PE# show pools access-egress 5/1/1 queue-group "qg2" instance 1
...
===============================================================================
Queue : accQGrp->qg2:1(5/1/1)->1
===============================================================================
FC Map : not-applicable
Dest Tap : not-applicable Dest FP : not-applicable
Admin PIR : 50000 Oper PIR : 50000
Admin CIR : 0 Oper CIR : 0
Admin MBS : 612 KB Oper MBS : 612 KB
High-Plus Drop Tail : 612 KB High Drop Tail : 612 KB
Low Drop Tail : 540 KB Exceed Drop Tail : 480 KB
CBS : 0 KB Depth : 0
Slope : not-applicable
Egress SAP FC and FP overrides
An access egress packet’s forwarding class can be changed to redirect the packet to an alternate queue than the ingress forwarding class determination would have used. An access egress packet’s profile can also be changed to modifying the congestion behavior within the egress queue. In both cases, egress marking decisions are based on the new forwarding class and profile as opposed to the egress forwarding class or profile. The exception is when ingress remarking is configured. An ingress remark decision is not affected by egress forwarding class or egress profile overrides.
The SAP egress QoS policy allows reclassification rules that are used to override the ingress forwarding class and profile of packets that egress a SAP where the QoS policy is applied.
Dot1p, IP precedence, DSCP, and IP quintuple entries can be defined, each with an explicit forwarding class or profile override parameters. The reclassification logic for each entry follows the same basic hierarchical behavior as the classification rules within the SAP ingress QoS policy. Dot1p, IP precedence, and DSCP have the lowest match priority while the IP criteria (quintuple) entries have the highest.
When an optional parameter (such as profile) for Dot1p, IP precedence, or DSCP entries is not specified, the value from the lower priority IP quintuple match for that parameter is preserved. If the IP precedence values overlap with DSCP values in that they match the same IP header TOS field, the DSCP entry parameters override or remove the IP precedence parameters. When none of the matched entries override a parameter, the ingress classification is preserved.
Egress IP match criteria
The following displays a SAP egress QoS policy IP criteria configuration:
*A:PE>config>qos# info
----------------------------------------------
#--------------------------------------------------
echo "QoS Policy Configuration"
#--------------------------------------------------
sap-egress 10 name "10" create
queue 1 create
exit
ip-criteria
entry 10 create
match
src-ip 192.168.0.0/16
exit
action fc "af"
exit
entry 20 create
match
dst-ip 10.0.0.0/8
exit
action fc "be"
exit
exit
exit
----------------------------------------------
*A:PE>config>qos#
Egress IPv6 match criteria
The following displays a SAP egress QoS policy IPv6 criteria configuration:
*A:PE>config>qos# info
----------------------------------------------
#--------------------------------------------------
echo "QoS Policy Configuration"
#--------------------------------------------------
sap-egress 10 name "10" create
queue 1 create
exit
ipv6-criteria
entry 10 create
match
dst-ip 2001:db8:1000::/64
exit
action profile in fc "ef"
exit
exit
exit
----------------------------------------------
*A:PE>config>qos#
Egress criteria classification directly to policer
It is possible to classify traffic directly to a policer, independent of the policer/queue assigned to the traffic’s forwarding class. This is supported at SAP egress by configuring a policer in the action statement within an ip-criteria or ipv6-criteria statement.
The policed traffic by default exits through one of the following methods:
a queue in the policer-output-queues queue group that is automatically created on an access or hybrid port with the queue used that was chosen by the forwarding class definition in that queue group. If the forwarding class is modified in the action statement, the new forwarding class selects the queue to be used.
a specific queue in a user-configured queue group. For SAP egress, this requires the use of the port-redirect-queue-group queue parameter in the criteria action statement with the queue group name being specified when the egress QoS policy is applied to the SAP. For subscribers, the queue group to be used is selected using the inter-dest-id associated with the subscriber and configured as the host-match dest under the port access queue group configuration.
a SAP queue configured within the SAP egress QoS policy
the queue to which the forwarding class for the traffic is mapped. This could be a queue group, SAP, or subscriber queue. This requires the use of the use-fc-mapped-queue parameter in the criteria action statement. If the forwarding class is modified in the action statement, new forwarding class selects the queue to be used.
The number of configuration combinations of a policer and one of the preceding methods is capped at 63 within a specific SAP egress QoS policy. For two or more definitions to be counted as a single combination, their action statement must have the same policer ID, the same queue ID (if specified in either statement), the same port-redirect-queue-group (if specified in either statement), and the parameter use-fc-mapped-queues (if specified in either statement).
The forwarding class and profile used are irrelevant when considering the number of combinations. For example, it is possible to configure 32 policers with traffic exiting queue 1, but then, only 31 of the same policers are exiting queue 2; this would use all 63 combinations. A resource is also allocated per FP where each combination configured corresponds to an egress bypass entry used in the FP per sap-instance or per subscriber-sap-sla instance that uses the egress qos policy. The number of egress bypass entries available on an FP, together with the number allocated and the number free, can be seen using the following tools command.
*A:PE>tools>dump>resource-usage# card 1 fp 1
===============================================================================
Resource Usage Information for Card Slot #1 FP #1
===============================================================================
Total Allocated Free
-------------------------------------------------------------------------------
...
Egress Qos Bypass | 262143 0 262143
...
This is supported on all hardware systems. QPPB processing takes precedence over this feature.
This could be used, for example, when it is required that egress traffic with a DSCP value EF is to be policed instead of shaped in a queue on a specific SAP. The traffic could be classified based on its DSCP value and directed to policer 1 while the remainder of the customer’s traffic is processed using egress queue 1. This is shown in Egress SAP.
The configuration would be as follows:
sap-egress 10 create
queue 1 create
exit
policer 1 create
exit
ip-criteria
entry 10 create
match
dscp ef
exit
action policer 1
exit
exit
exit
Storing match criteria entries
Cards store QoS policy match-criteria entries in dedicated memory banks in hardware, also referred to as CAM tables:
IP/MAC ingress
IP/MAC egress
IPv6 ingress
IPv6 egress
FP4-based or later cards
To optimize both scale and performance, policy match-criteria entries configured by the user are compressed by each FP4 or later line card before being installed in hardware.
This compression can result, in an unexpected scenario typically only achieved in a lab environment, in an overload condition where entries for a line card QoS policy on a line card FP are not programmed. This overload condition can occur when applying a QoS policy for the first time on a line card FP or when adding entries to a QoS policy.
- applying a QoS policy
A policy is installed for the first time on a line card FP if no router interface, service interface, SAP, spoke SDP, mesh SDP or ESM subscriber host was using the policy on this FP.
A policy installed for the first time on a line card FP can lead to a compression failure resulting in an overload condition for this policy on this FP. In this case, none of the entries for the affected QoS match-criteria policy are programmed, and the QoS policy queuing, FC mapping, and FC marking are unaffected.
-
adding QoS match-criteria entries
Adding an additional entry to a QoS policy can lead to a compression failure resulting in an overload condition.
In this case, the newly added entry is not programmed on the affected FP. Additional entries added to the same policy after the first overload condition are also not programmed on the affected FP as the system attempts to install all outstanding additions in order.
The CPM QoS management task controls the maximum number of match criteria entries per FP. If the user attempts to go over the scaling limit, the system returns an interactive error message.
Note: A trap is raised if a policy is in overload, there is no interactive error message. -
removing QoS match-criteria entries
Removing match-criteria entries from a QoS policy is always successful.
-
resolving overload
The overload condition should be resolved by the network operator before adding new entries in the affected policy.
To identify the affected policy, the system logs the overload event providing slot number, FP number, and impacted memory bank. Based on this information, the tools>dump>qos>match-criteria-overload command allows the user to identify the affected policy and policy entries in the system.
To resolve the overload condition, the network operator can remove the newly added entries from the affected policy or assign a different policy.
Dot1p egress remarking
Dot1p remarking can be performed on egress for all services and with respect to the profile of the packet and the VLAN tag.
The following commands can be used to remark the dot1p values at a SAP egress:
configure qos sap-egress policy-id create
use-policer-result-marking-dot1p-inner
fc fc-name create
dot1p {dot1p-value | in-profile dot1p-value out-
profile dot1p-value [exceed-profile dot1p-value]}
dot1p-inner {dot1p-value | in-profile dot1p-value
out-profile dot1p-value | exceed-profile dot1p-value}
dot1p-outer {dot1p-value | in-profile dot1p-value
out-profile dot1p-value [exceed-profile dot1p-
value]}
exitAll inplus-profile traffic is marked with the same value as in-profile traffic.
The precedence of these commands is summarized as follows, from highest to lowest precedence:
-
dot1p-outer used for outer tag markings
-
dot1p-inner used for inner tag markings
-
existing dot1p used for marking both tags
-
markings taken from packet received at ingress
- dot1p-inner marking is dependent on policer result if use-policer-result-marking-dot1p-inner is enabled
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. If QinQ-mark-top-only is omitted, both the inner and outer VLAN tags are remarked.
The egress remarking occurs after any egress classification.
DEI egress remarking
It is often desirable to meter traffic from different users to ensure fairness or to meet bandwidth guarantees. Dropping all traffic in excess of a committed rate is likely to result in severe under-utilization of the networks, because most traffic sources are bursty in nature. It is burdensome to meter traffic at all points in the network where bandwidth contention occurs. One solution is to mark those frames in excess of the committed rate as drop eligible on admission to the network.
Previously, the discard eligibility was determined using existing QoS fields; for example, the three MPLS EXP and Ethernet dot1p bits. Using specific combinations of these bits to indicate both forwarding class (priority) and discard eligibility meant decreasing the number of forwarding classes that can be differentiated in the network.
IEEE 802.1ad-2005 and IEEE 802.1ah standards allow drop eligibility to be conveyed separately from priority, preserving all the eight forwarding classes (priorities) that could be indicated using the three 802.1p bits. All the previously introduced traffic types are marked as drop eligible. Customers can continue to use the dot1p markings with the enhancement of changing the dot1p value used, in access, based on the profile information.
The following commands can be used to remark the DE values at a SAP egress:
sap-egress policy-id create
fc fc-name create
de-mark [force de-value]
de-mark-inner [force de-value]
de-mark-outer [force de-value]
exit
exitBy default, the DE bit is set to 0 for inplus-profile and in-profile traffic and 1 for out-of-profile and exceed-profile traffic, unless explicitly forced.
The precedence of these commands is summarized from highest to lowest precedence, as follows:
de-mark-outer used for outer tag markings
de-mark-inner used for inner tag markings
existing de-mark used for marking both tags
markings taken from packet received at ingress
The configuration of QinQ-mark-top-only under the SAP egress takes precedence over the use of the de-mark-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. If QinQ-mark-top-only is omitted, both the inner and outer VLAN tags are remarked.
Remarking the inner DE bit is not supported based on the profile result of egress policing.
The egress remarking occurs after any egress classification.
DEI in IEEE 802.1ad
The IEEE 802.1ad-2005 standard allows drop eligibility to be conveyed separately from priority in-service VLAN TAGs (S-tags). The S-tag has a new format where the priority and discard eligibility parameters are conveyed in the 3-bit priority code point (PCP) field and in the DE bit, respectively (see DE Bit in the 802.1ad S-tag).
The introduction of the DE bit allows the S-tag to convey eight forwarding classes/distinct priorities, each with a drop eligible indication.
When DE bit is set to 0 (DE = FALSE), the related packet is not discard eligible. This is the case for the packets that are within the CIR limits and must be given priority in case of congestion. If the DEI is not used or backwards compliance is required, the DE bit should be set to zero on transmission and ignored on reception.
When the DE bit is set to 1 (DE = TRUE), the related packet is discard eligible. This is the case for the packets that are sent above the CIR limit. In case of congestion, these packets are the first ones to be dropped.
DEI in IEEE 802.1ah
IEEE 802.1ah (PBB) standard provides a dedicated bit for DE indication in both the backbone VLAN ID (BVID) and the ITAG.
The BVID is a regular 802.1ad S-tag. Its DE bit may be used to convey the related tunnel QoS throughout an Ethernet backbone.
The ITAG header offers also an I-DEI bit that may be used to indicate the service drop eligibility associated with this frame.
These bits must follow the same rules as described in DEI in IEEE 802.1ad.
IEEE 802.1ad use case
DE aware 802.1ad access network shows an example of a topology where the new DE feature may be used: a DE aware, 802.1ad access network connected via a regular SAP to a router PE.
In the following example, PE1 can ensure coherent processing of the DE indication between the 802.1ad and the MPLS networks. For example, for packets ingressing the SAP connected to 802.1ad access, read the DE indication and perform classification, color aware metering/policing, marking of the related backbone QoS fields, and selective discarding of the frames throughout the queueing system, based on their discard eligibility. In addition, packets egressing the SAP toward the 802.1ad access provide correct DE indication by marking the new DE bit in the S-tag.
DEI processing ingress into the PE1 SAP shows an example of the QoS processing of the DEI processing steps for the IEEE 802.1ad use case for both ingress and egress directions (from a PE1 SAP perspective).
The following steps related to DEI are involved in the QoS processing as the packet moves from left to right:
The QinQ access device sets the DE bit from the S-tag based on the QoS classification or on the results of the metering/policing for the corresponding customer UNI.
The SAP on PE1 may use the DE bit from the customer S-tag to classify the frames as in/out-of-profile. Color aware policing/metering can generate additional out-of-profile packets as the result of packet flow surpassing the CIR.
When the packet leaves PE1 via SDP, the DE indication must be copied onto the appropriate tunnel QoS fields (outer VLAN ID or EXP bits, or both) using the internal PHB (per hop behavior) of the packet (for example, the FC and Profile).
As the packet arrives at PE2, on ingress into the related SDP, the DE indication is used to classify the packets into an internal PHB.
On egress from the PE2 SAP, the internal PHB may be used to perform marking of the DE bit.
A combination of two access networks can be possible. If PBB encapsulation is used, the configuration used for DE in SAP and SDP policies applies to both BVID and ITAG DE bits. When both fields are used, the BVID takes precedence.
IEEE 802.1ah use case
DE aware PBB topology shows an example of a PBB topology where the DE feature can be used. The processing requirements highlighted in the 802.1ad use case apply to the 802.1ah BVID, format and etype, these being identical with the 802.1ad S-tag. In addition, the DE bit from the 802.1ah ITAG header may need to be processed following the same rules as for the related field in the BVID/S-tag; for example, the DE bit from the BVID header represents the QoS associated with the ‟Ethernet Tunnel” while the DE bit from the ITAG represents the service QoS.
In this example, the BVID is not used for a part of the network, leaving the I-DEI bit from the ITAG as the only option for a dedicated DE field. If both are included, the QoS information from the BVID is to be used.
DSCP and IP precedence egress remarking
DSCP and IP precedence remarking can be performed on egress for layer 3 services only with respect to the profile of the packet.
Use the following CLI syntax to remark the DSCP and IP precedence values at a SAP egress:
configure qos sap-egress policy-id create
fc fc-name create
dscp {dscp dscp-name | in-profile dscp-name out-
profile dscp-name [exceed-profile dscp-name]}
prec {ip-prec-value | in-profile ip-prec-value out-
profile ip-prec-value} [exceed-profile ip-prec-
value]}
exit
exitAll inplus-profile traffic is marked with the same value as in-profile traffic.
Remarking the DSCP and IP precedence based on the profile result of egress policing must be enabled under the related policer configuration, as follows:
sap-egress policy-id create
policer policer-id create
enable-dscp-prec-remarking
exit
exitQueue depth monitoring
Queue-depth monitoring gives more visibility to the user of the queue depths being experienced on a set of queues when the traffic is bursty. The instantaneous depth of a queue can be seen using the show pools command, whereas queue-depth monitoring shows the variation in queue depth over a period of time. It is applicable to SAP ingress unicast and multipoint queues and SAP egress queues, and for ingress and egress access and network queue group queues used by any service or network interfaces. The monitoring uses a polling mechanism by the line card CPU. Consequently, the results provided are statistical.
An override (monitor-queue-depth command) is used to enable queue-depth monitoring, which is configured under the SAP or queue group queue-overrides. There are show and clear commands, using the queue-depth parameter, for both service SAPs and port queue groups with associated MIB variables.
The queue depth information is shown in the following example.
A:PE-1# show service id 1 sap 1/2/1 queue-depth
===============================================================================
Queue Depth Information (Ingress SAP)
===============================================================================
No Matching Entries
===============================================================================
===============================================================================
Queue Depth Information (Egress SAP)
===============================================================================
-------------------------------------------------------------------------------
Name : 1->1/2/1->1
MBS : Def
-------------------------------------------------------------------------------
Queue Depths (percentage)
-------------------------------------------------------------------------------
0%-10% 11%-20% 21%-30% 31%-40% 41%-50% 51%-60% 61%-70% 71%-80% 81%-90% 91%-100%
-------------------------------------------------------------------------------
68.21 3.64 3.43 3.47 3.86 3.22 3.86 2.87 3.78 3.66
-------------------------------------------------------------------------------
Average Elapsed Time : 0d 00:11:48
Wghtd Avg Polling Interval: 99 ms
-------------------------------------------------------------------------------
===============================================================================
The preceding output shows the percentage of polls for each 10% range of queue depth. The output includes the name of the queue, its MBS configuration, the average elapsed time over which the depth was monitored (this is the elapsed time since the start of monitoring or the last clear), and the weighted average polling interval.
For example, the output shows a queue depth in the range of 51% to 60% for 3.22% of the polls, for polling that was performed over an elapsed time of 11 minutes and 48 seconds, and with an average polling interval of 99 milliseconds.
The monitoring is performed on the hardware queues corresponding to the configured queue. The set of related hardware queues for a specific configured queue could change over time; for example, when LAG ports are added or removed resulting in monitored hardware queues being added or removed. If the set of hardware queues for the configured queue changes, the system only reports occupancy information of all currently instantiated hardware queues; it does not keep historical occupancy information.
The average polling interval is weighted based on the elapsed monitoring time of the individual hardware queues corresponding to the configured queue, and the elapsed monitoring time is averaged over the same set of hardware queues.
There is no limit on the number of queues that can be monitored, but the amount of each line card’s CPU resources allocated to the monitoring is bounded. Consequently, the average polling interval increases as more queues are monitored on the line card.
If the MBS of a queue is modified, the occupancy information is cleared, and the elapsed timers are reset to zero. Issuing a clear card command also clears this information. Packet drops caused at the pool level, instead of at the queue level, results in lower queue depths being reported
At egress, sap-egress queues as well as queue-groups used at network egress or sap-egress, the monitor-queue-depth command provides two additional parameters.
The fast-polling parameter enables polling of the hardware queue-depth by the on-chip CPU. This supports reduced polling to the order of 10 ms, depending on number of queues with fast-polling enabled. The values are integrated and reported in the same fashion as previously described. The main advantage of the fast-polling option is that short-term burst can be detected by the monitor-queue-depth command.
The violation-threshold parameter is used to set the queue-depth threshold and record the number of violations that occurred. This supports frequency monitoring of specific bursts that can occur in the traffic, allowing for better capacity planning.
All information gathered by the queue-depth monitoring feature is available in YANG state model and therefore it can be monitored through telemetry.
Service management tasks
This section discusses service ingress and egress service management tasks.
Applying service ingress and egress policies
Apply SAP ingress and egress policies to the following service SAPs:
See the Subscriber Services Overview section of the 7450 ESS, 7750 SR, 7950 XRS, and VSR Services Overview Guide for information about configuring service parameters on the 7750 SR and 7450 ESS.
Epipe
The following output displays an Epipe service configuration with SAP ingress policy 100 and SAP egress 105 applied to the SAP.
A:ALA-7>config>service# info
----------------------------------------------
epipe 6 customer 6 vpn 6 create
description "Distributed Epipe service to west coast"
sap 1/1/10:010 create
ingress
qos 100
exit
egress
qos 105
exit
exit
spoke-sdp 2:6 create
ingress
vc-label 6298
exit
egress
vc-label 6300
exit
exit
no shutdown
exit
----------------------------------------------
A:ALA-7>config>service#
IES
The following output displays an IES service configuration with SAP ingress policy 100 and SAP egress 105 applied to the SAP.
A:ALA-7>config>service# info
----------------------------------------------
ies 88 customer 8 vpn 88 create
interface "Sector A" create
sap 1/1/1.2.2 create
ingress
qos 100
exit
egress
qos 105
exit
exit
exit
no shutdown
exit
----------------------------------------------
VPLS
The following output displays a VPLS service configuration with SAP ingress policy 100. The SAP egress policy 1 is applied to the SAP by default.
A:ALA-7>config>service# info
----------------------------------------------
vpls 700 customer 7 vpn 700 create
description "test"
stp
shutdown
exit
sap 1/1/9:010 create
ingress
qos 100
exit
exit
spoke-sdp 2:222 create
exit
mesh-sdp 2:700 create
exit
no shutdown
exit
----------------------------------------------
A:ALA-7>config>service#
VPRN
The following output displays a VPRN service configuration for the 7750 SR and 7950 XRS.
A:ALA-7>config>service# info
----------------------------------------------
...
vprn 1 customer 1 create
ecmp 8
autonomous-system 10000
route-distinguisher 10001:1
auto-bind-tunnel
resolution-filter
resolution-filter ldp
vrf-target target:10001:1
interface "to-ce1" create
address 10.1.0.1/24
sap 1/1/10:1 create
ingress
qos 100
exit
egress
qos 105
exit
exit
exit
no shutdown
exit
...
----------------------------------------------
A:ALA-7>config>service#
Editing QoS policies
QoS existing policies and entries can be edited. The changes are applied immediately to all services where this policy is applied. To prevent configuration errors, copy the policy to a work area, make the edits, then write over the original policy.
Copying and overwriting QoS policies
Existing service egress or ingress policy can be copied, renamed with a new policy ID value, or overwrite an existing policy ID. The overwrite option must be specified or an error occurs if the destination policy ID exists.
CLI syntax:
config>qos# copy {sap-ingress | sap-egress} source-policy-id dest-policy-id [overwrite]
The following output displays the copied policies:
A:ALA-7>config>qos# info
---------------------------------------------
...
exit
sap-ingress 100 create
description "Used on VPN sap"
queue 1 create
exit
queue 2 multipoint create
exit
queue 10 create
parent "VPN_be"
rate 11000
exit
...
sap-ingress 101 create
description "Used on VPN sap"
queue 1 create
exit
queue 2 multipoint create
exit
queue 10 create
parent "VPN_be"
rate 11000
exit
sap-ingress 200 create
description "Used on VPN sap"
queue 1 create
exit
queue 2 multipoint create
exit
queue 10 create
parent "VPN_be"
rate 11000
exit
...
---------------------------------------------
A:ALA-7>config>qos#
Deleting QoS policies
Every service SAP is associated, by default, with the appropriate egress or ingress policy (policy ID 1). The default policy can be replaced with a customer-configured policy but cannot entirely remove the policy from the SAP configuration. When a non-default service egress or ingress policy is removed, the association reverts to the default policy ID 1.
A QoS policy cannot be deleted until it is removed from all SAPs where it is applied.
A:ALA-7>config>qos# no sap-ingress 100
MINOR: CLI SAP ingress policy "100" cannot be removed because it is in use.
A:ALA-7>config>qos#
Removing a policy from the QoS configuration
Use the following syntax to remove a policy from the QoS configuration:
config>qos# no sap-ingress policy-id
Example:
config>qos# no sap-ingress 100
config>qos# no sap-egress 1010