This command determines the VIDs associated with the virtual Ethernet Segment on a specific dot1q port or LAG based on the following considerations:

The no form of the command removes the configured range. Only the first qtag1 value is required to remove the range.

This command configures the QoS Class Identifier (QCI) to send in the Bearer Level QoS IE in GTPv2 messages.

The no form of this command reverts to the default.

Commands in this context configure q-tag and s-tag additions to the port or LAG virtual Ethernet Segments.

This command configures the Ethertype used for Q-in-Q encapsulation.

The no form of this command reverts the qinq-etype value to the default.

This command configures the QinQ Ethertype on the PW port. The PW port is used to extract a customer's Ethernet traffic that is transported in a tunnel over an IP/MPLS network. The qinq-etype represents the first two bytes (TPID) in the outer 801.1Q header of the double-tagged Ethernet frame inside the tunnel.

The no form of this command removes the configuration.

When the encapsulation type is qinq for the access port for the specified SAP, enabling this command specifies which P-bits or DEI bit to mark during packet egress. Only the P-bits or DEI bit in the top Q tag are marked. When this command is disabled, both sets of P-bits and the DEI bit are marked.

When enabled (the encapsulation type of the access port where this SAP is defined as qinq), the qinq-mark-top-only command specifies which P-bits/DEI bit to mark during packet egress. When disabled, both set of P-bits/DEI bit are marked. When the enabled, only the P-bits/DEI bit in the top Q-tag are marked.

When enabled (the encapsulation type of the access port where this SAP is defined as qinq), the qinq-mark-top-only command specifies which P-bits/DEI bit to mark during packet egress. When disabled, both set of P-bits/DEI bit are marked. When enabled, only the P-bits/DEI bit in the top Q-tag are marked.

The no form of this command disables the command.

When enabled (the encapsulation type of the access port where this SAP is defined as qinq), the qinq-mark-top-only command specifies which P-bits/DEI bit to mark during packet egress. When disabled, both set of P-bits/DEI bit are marked. When the enabled, only the P-bits/DEI bit in the top Q-tag are marked.

This command provides ingress VLAN translation for two service-delimiting VLAN values, as opposed to the vlan-translation command that provides translation for only one service-delimiting VLAN value. This command is used with the force-qinq-vc-forwarding command so that the VLAN values that are pushed on SDP bindings or EVPN-MPLS can be normalized (translated). The command has no effect without the configuration of force-qinq-vc-forwarding and cannot be used in non-QinQ SAPs.

The no version of the command disables QinQ VLAN translation.

This command configures the minimum acceptable QL value that a signal must have in order to be selected for the BITSout port. This ensures that the signal has traceability to a source with at least this quality level so that attached equipment can function properly.

The no form of this command disables this check.

This command configures the minimum acceptable QL value that a signal must have in order to be considered for selection by the system timing module.

The no form of this command disables this check.

This command configures the QL value to be used for the reference for SETS input selection and BITS output selection. This value overrides any value received by that reference's SSM process.

This command configures the QL value to be used for the reference for SETS input selection and BITS output. This value overrides any value received by that reference's SSM process.

When enabled, the selection of system timing reference and BITS output timing reference takes into account quality level. Quality level is conveyed via the SSM or forced using the ql-override command.

Commands in this context configure QoS for a GGSN Mobile Gateway.

This command specifies the ingress or egress Quality of Service (QoS) policy that is associated with a Managed SAP (MSAP). Only QoS policies with scope template can be associated with MSAPs.

The no form of this command resets the default value. The system default QoS policy is used in that case.

This command specifies the egress QoS policy applicable to this SLA profile. The policy must already be defined in the config>qos>sap-egress context.

The no form of this command reverts to the default.

This command specifies the ingress QoS policy applicable to this SLA profile. The policy must already be defined in the config>qos>sap-ingress context.

The no form of this command reverts to the default.

Associates a Quality of Service (QoS) policy with an egress Service Access Point (SAP) or IP interface.

QoS egress policies are important for the enforcement of SLA agreements. The policy ID must be defined prior to associating the policy with a SAP or IP interface. If the policy-id does not exist, an error are returned.

The qos command is used to associate egress QoS policies. The qos command only allows egress policies on SAP or IP interface egress. Attempts to associate a QoS policy of the wrong type returns an error.

Only one ingress QoS policy can be associated with a SAP or IP interface at one time. Attempts to associate a second QoS policy of a given type returns an error.

By default, no specific QoS policy is associated with the SAP or IP interface for egress, so the default QoS policy is used.

The normal behavior is for queues to be created per destination.

The no form of this command removes the QoS policy association from the SAP or IP interface, and the QoS policy reverts to the default.

This command associates a Quality of Service (QoS) policy with an egress Service Access Point (SAP) or IP interface.

QoS egress policies are important for the enforcement of SLA agreements. The policy ID must be defined prior to associating the policy with a SAP or IP interface. If the policy ID does not exist, an error is returned.

The qos command associates both ingress and egress QoS policies. The qos command only allows ingress policies to be associated on SAP or IP interface ingress and egress policies on SAP or IP interface egress. Attempts to associate a QoS policy of the wrong type returns an error.

Only one ingress and one egress QoS policy can be associated with a SAP or IP interface at one time. Attempts to associate a second QoS policy of a given type returns an error.

By default, no specific QoS policy is associated with the SAP or IP interface for ingress or egress, so the default QoS policy is used.

The no form of this command removes the QoS policy association from the SAP or IP interface, and the QoS policy reverts to the default.

This command associates a Quality of Service (QoS) policy with an egress Service Access Point (SAP).

QoS ingress and egress policies are important for the enforcement of SLA agreements. The policy ID must be defined prior to associating the policy with a SAP. If the policy-id does not exist, an error will be returned.

The qos command is used to associate both ingress and egress QoS policies. The qos command only allows ingress policies to be associated on SAP ingress and egress policies on SAP egress. Attempts to associate a QoS policy of the wrong type returns an error.

Only one ingress and one egress QoS policy can be associated with a SAP at one time. Attempts to associate a second QoS policy of a specified type will return an error.

When an egress QoS policy is associated with an IES IP interface that has been bound to a VPLS, the policy becomes associated with every SAP on the VPLS and augments the egress QoS policy that is defined on each SAP. Packets that are bridged will be processed using the policy defined on the VPLS SAP; packets that are routed will be processed using the policy defined in the IES IP interface- binding context.

By default, if no specific QoS policy is associated with the SAP for ingress or egress, so the default QoS policy is used.

The no form of this command removes the QoS policy association from the SAP, and the QoS policy reverts to the default.

Associates a Quality of Service (QoS) policy with an ingress Service Access Point (SAP) or IP interface.

QoS ingress policies are important for the enforcement of SLA agreements. The policy ID must be defined prior to associating the policy with a SAP or IP interface. If the policy-id does not exist, an error is returned.

This qos command is used to associate ingress QoS policies. The qos command only allows ingress policies to be associated on SAP or IP interface ingress.

Only one ingress and one egress QoS policy can be associated with a SAP or IP interface at one time. Attempts to associate a second QoS policy of a given type returns an error.

By default, no specific QoS policy is associated with the SAP or IP interface for ingress so the default QoS policy is used.

The normal behavior is for queues to be created per destination. Shared and multipoint shared change this behavior creating either unicast or unicast and mcast shared queues.

The no form of this command removes the QoS policy association from the SAP or IP interface, and the QoS policy reverts to the default.

This command associates a Quality of Service (QoS) policy with an ingress Service Access Point (SAP).

QoS ingress and egress policies are important for the enforcement of SLA agreements. The policy ID must be defined prior to associating the policy with a SAP. If the policy ID does not exist, an error is returned.

The qos command is used to associate both ingress and egress QoS policies. The qos command only allows ingress policies to be associated on SAP ingress and egress policies on SAP egress. Attempts to associate a QoS policy of the wrong type returns an error.

Only one ingress and one egress QoS policy can be associated with a SAP or IP interface at one time. Attempts to associate a second QoS policy of a given type returns an error.

By default, no specific QoS policy is associated with the SAP for ingress or egress, so the default QoS policy is used.

The no form of this command removes the QoS policy association from the SAP, and the QoS policy reverts to the default.

The no form of this command removes the QoS policy association from the SAP or IP interface, and the QoS policy reverts to the default.

This command configures the identifier of the egress QoS policy associated with each wlan-gw tunnel of this interface.

The no form of this command removes the policy ID from the configuration.

This command associates a Quality of Service (QoS) policy with an egress Service Access Point (SAP).

QoS ingress and egress policies are important for the enforcement of SLA agreements. The policy ID must be defined prior to associating the policy with a SAP. If the policy-id does not exist, an error will be returned.

The qos command, when used under the egress context, is used to associate egress QoS policies.

The qos command only allows ingress policies to be associated on SAP ingress and egress policies on SAP egress. Attempts to associate a QoS policy of the wrong type returns an error.

Only one ingress and one egress QoS policy can be associated with a SAP at one time. Attempts to associate a second QoS policy of a specified type will return an error.

By default, if no specific QoS policy is associated with the SAP for ingress or egress, so the default QoS policy is used.

The no form of this command removes the QoS policy association from the SAP, and the QoS policy reverts to the default.

This command associates a Quality of Service (QoS) policy with an ingress Service Access Point (SAP).

QoS ingress and egress policies are important for the enforcement of SLA agreements. The policy ID must be defined prior to associating the policy with a SAP. If the policy-id does not exist, an error will be returned.

The qos command, when used under the ingress context, is used to associate ingress QoS policies. The qos command only allows ingress policies to be associated on SAP ingress and egress policies on SAP egress. Attempts to associate a QoS policy of the wrong type returns an error.

Only one ingress and one egress QoS policy can be associated with a SAP at one time. Attempts to associate a second QoS policy of a specified type will return an error.

By default, if no specific QoS policy is associated with the SAP for ingress or egress, so the default QoS policy is used.

The no form of this command removes the QoS policy association from the SAP, and the QoS policy reverts to the default.

This command is used to redirect pseudowire (PW) packets to an egress port queue-group for the purpose of shaping.

The egress PW shaping provisioning model allows the mapping of one or more PWs to the same instance of queues, or policers and queues, that are defined in the queue-group template.

Operationally, the provisioning model consists of the following steps:

One or more spoke-sdps can have their FCs redirected to use queues only, or queues and policers in the same queue-group instance.

The following are the constraints and rules of this provisioning model:

When the queue-group name the PW is redirected to exists and the redirection succeeds, the marking of the packet’s DEI/dot1p/DSCP and the tunnel’s DEI/dot1p/DSCP/EXP is performed according to the relevant mappings of the {FC, profile} in the egress context of the network QoS policy applied to the PW. This is true regardless of whether an instance of the queue-group exists or not on the egress port the PW packet is forwarded to. If the packet’s profile value changed due to egress child policer CIR profiling, the new profile value is used to mark the packet’s DEI/dot1p and the tunnel’s DEI/dot1p/EXP, and the DSCP/prec will be remarked if enable-dscp-prec-marking is enabled under the policer.

When the queue-group name the PW is redirected does not exist, the redirection command is failed. In this case, the marking of the packet’s DEI/dot1p/DSCP and the tunnel’s DEI/dot1p/DSCP/EXP fields is performed according to the relevant commands in the egress context of the network QoS policy applied to the network IP interface to which the PW packet is forwarded.

The no version of this command removes the redirection of the PW to the queue-group.

This command is used to redirect pseudowire packets to an egress port queue-group for the purpose of shaping.

The egress pseudowire shaping provisioning model allows the mapping of one or more pseudowires to the same instance of queues, or policers and queues, which are defined in the queue-group template.

Operationally, the provisioning model consists of the following steps:

One or more spoke-SDPs can have their FCs redirected to use queues only or queues and policers in the same queue-group instance.

The following are the constraints and rules of this provisioning model:

When the queue-group name the pseudowire is redirected to exists and the redirection succeeds, the marking of the packet DEI/dot1p/DSCP and the tunnel DEI/dot1p/DSCP/EXP is performed; according to the relevant mappings of the (FC, profile) in the egress context of the network QoS policy applied to the pseudowire. This is true regardless, whether an instance of the queue-group exists or not on the egress port to which the pseudowire packet is forwarded. If the packet profile value changed due to egress child policer CIR profiling, the new profile value is used to mark the packet DEI/dot1p and the tunnel DEI/dot1p/EXP, and the DSCP/prec will be remarked if enable-dscp-prec-marking is enabled under the policer.

When the queue-group name the pseudowire is redirected does not exist, the redirection command is failed. In this case, the marking of the packet DEI/dot1p/DSCP and the tunnel DEI/dot1p/DSCP/EXP fields is performed according to the relevant commands in the egress context of the network QoS policy applied to the network IP interface to which the pseudowire packet is forwarded.

The no version of this command removes the redirection of the pseudowire to the queue-group.

This command is used to redirect pseudowire packets to an ingress forwarding plane queue-group for the purpose of rate-limiting.

The ingress pseudowire rate-limiting feature uses a policer in queue-group provisioning model. This model allows the mapping of one or more pseudowires to the same instance of policers, which are defined in a queue-group template.

Operationally, the provisioning model in the case of the ingress pseudowire shaping feature consists of the following steps:

The following are the constraints and rules of this provisioning model when used in the ingress pseudowire rate-limiting feature:

When a pseudowire packet for that FC is received and an instance of the referenced queue-group name exists on that FP, the packet is processed by the policer and will then feed the per-FP ingress shared queues referred to as policer-output-queues.

When a pseudowire packet for that FC is received and an instance of the referenced queue-group name does not exist on that FP, the pseudowire packets will be fed directly into the corresponding ingress network shared queue for that FC defined in the network-queue policy applied to the ingress of the FP.

the ingress network shared queue for the packet FC defined in the network-queue policy applied to the ingress of the FP. This is the default behavior.

a queue-group policer followed by the per-FP ingress shared queues referred to as policer-output-queues if the ingress context of the network IP interface from which the packet is received is redirected to a queue-group (csc-policing). The only exceptions to this behavior are for packets received from a IES/VPRN spoke interface and from an R-VPLS spoke-SDP, which is forwarded to the R-VPLS IP interface. In these two cases, the ingress network shared queue for the packet FC defined in the network-queue policy applied to the ingress of the FP is used.

When a pseudowire is redirected to use a policer queue-group, the classification of the packet for the purpose of FC and profile determination is performed according to default classification rule or the QoS filters defined in the ingress context of the network QoS policy applied to the pseudowire. This is true regardless of whether an instance of the named policer queue-group exists on the ingress FP on which the pseudowire packet is received. The user can apply a QoS filter matching the dot1.p in the VLAN tag corresponding to the Ethernet port encapsulation, the EXP in the outer label when the tunnel is an LSP, the DSCP in the IP header if the tunnel encapsulation is GRE, and the DSCP in the payload IP header if the user enabled the ler-use-dscp option and the pseudowire terminates in IES or VPRN service (spoke-interface).

When the policer queue-group name the pseudowire is redirected does not exist, the redirection command is failed. In this case, the packet classification is performed according to default classification rule or the QoS filters defined in the ingress context of the network QoS policy applied to the network IP interface on which the pseudowire packet is received.

The no version of this command removes the redirection of the pseudowire to the queue-group.

This command is used to redirect pseudowire packets to an ingress forwarding plane queue-group for the purpose of rate-limiting.

The ingress pseudowire rate-limiting feature uses a policer in queue-group provisioning model. This model allows the mapping of one or more pseudowires to the same instance of policers, which are defined in a queue-group template.

Operationally, the provisioning model in the case of the ingress pseudowire shaping feature consists of the following steps:

The following are the constraints and rules of this provisioning model when used in the ingress pseudowire rate-limiting feature:

When a pseudowire is redirected to use a policer queue-group, the classification of the packet for the purpose of FC and profile determination is performed according to default classification rule or the QoS filters defined in the ingress context of the network QoS policy applied to the pseudowire. This is true regardless of whether an instance of the named policer queue-group exists on the ingress FP on which the pseudowire packet is received. The user can apply a QoS filter matching the dot1p in the VLAN tag corresponding to the Ethernet port encapsulation, the EXP in the outer label when the tunnel is an LSP, the DSCP in the IP header if the tunnel encapsulation is GRE, and the DSCP in the payload IP header if the user enabled the ler-use-dscp option and the pseudowire terminates in IES or VPRN service (spoke-interface).

When the policer queue-group name the pseudowire is redirected does not exist, the redirection command is failed. In this case, the packet classification is performed according to default classification rule or the QoS filters defined in the ingress context of the network QoS policy applied to the network IP interface on which the pseudowire packet is received.

The no form of this command removes the redirection of the pseudowire to the queue-group.

This command is used to redirect PW packets to an egress port queue-group for the purpose of shaping.

The egress PW shaping provisioning model allows the mapping of one or more PWs to the same instance of queues, or policers and queues, that are defined in the queue-group template.

Operationally, the provisioning model consists of the following steps:

One or more spoke-SDPs can have their FCs redirected to use queues only, or queues and policers in the same queue-group instance.

The following are the constraints and rules of this provisioning model.

When the queue-group name the PW is redirected to exists and the redirection succeeds, the marking of the packet’s DEI/dot1p/DSCP and the tunnel’s DEI/dot1p/DSCP/EXP is performed according to the relevant mappings of the {FC, profile} in the egress context of the network QoS policy applied to the PW. This is true regardless of whether an instance of the queue-group exists or not on the egress port the PW packet is forwarded to. If the packet’s profile value changed due to egress child policer CIR profiling, the new profile value is used to mark the packet’s DEI/dot1p and the tunnel’s DEI/dot1p/EXP, and the DSCP/prec will be remarked if enable-dscp-prec-marking is enabled under the policer.

When the queue-group name the PW is redirected does not exist, the redirection command is failed. In this case, the marking of the packet’s DEI/dot1p/DSCP and the tunnel’s DEI/ dot1p/DSCP/EXP fields is performed according to the relevant commands in the egress context of the network QoS policy applied to the network IP interface the PW packet is forwarded to.

The no version of this command removes the redirection of the PW to the queue-group.

This command is used to redirect PW packets to an ingress forwarding plane queue-group for the purpose of rate-limiting.

The ingress PW rate-limiting feature uses a policer in queue-group provisioning model. This model allows the mapping of one or more PWs to the same instance of policers that are defined in a queue-group template.

Operationally, the provisioning model in the case of the ingress PW shaping feature consists of the following steps:

One or more spoke-sdps can have their FCs redirected to use policers in the same policer queue-group instance.

The following are the constraints and rules of this provisioning model when used in the ingress PW rate-limiting feature:

When a PW is redirected to use a policer queue-group, the classification of the packet for the purpose of FC and profile determination is performed according to the default classification rule or the QoS filters defined in the ingress context of the network QoS policy applied to the PW. This is true regardless of whether an instance of the named policer queue-group exists on the ingress FP the pseudowire packet is received on. The user can apply a QoS filter matching the dot1-p in the VLAN tag corresponding to the Ethernet port encapsulation, the EXP in the outer label when the tunnel is an LSP, the DSCP in the IP header if the tunnel encapsulation is GRE, and the DSCP in the payload’s IP header if the user enabled the ler-use-dscp option and the pseudowire terminates in IES or VPRN service (spoke-interface).

When the policer queue-group name the pseudowire is redirected does not exist, the redirection command is failed. In this case, the packet classification is performed according to the default classification rule or the QoS filters defined in the ingress context of the network QoS policy applied to the network IP interface the pseudowire packet is received on.

The no version of this command removes the redirection of the pseudowire to the queue-group.

This command is used to redirect pseudowire packets to an ingress forwarding plane queue-group for the purpose of rate-limiting.

The ingress pseudowire rate-limiting feature uses a policer in queue-group provisioning model. This model allows the mapping of one or more pseudowires to the same instance of policers, which are defined in a queue-group template.

Operationally, the provisioning model in the case of the ingress pseudowire shaping feature consists of the following steps:

The following are the constraints and rules of this provisioning model when used in the ingress pseudowire rate-limiting feature:

When a pseudowire packet for that FC is received and an instance of the referenced queue-group name exists on that FP, the packet is processed by the policer and will then feed the per-FP ingress shared queues referred to as policer-output-queues.

When a pseudowire packet for that FC is received and an instance of the referenced queue-group name does not exist on that FP, the pseudowire packets will be fed directly into the corresponding ingress network shared queue for that FC defined in the network-queue policy applied to the ingress of the FP.

When a pseudowire is redirected to use a policer queue-group, the classification of the packet for the purpose of FC and profile determination is performed according to default classification rule or the QoS filters defined in the ingress context of the network QoS policy applied to the pseudowire. This is true regardless of whether an instance of the named policer queue-group exists on the ingress FP on which the pseudowire packet is received. The user can apply a QoS filter matching the dot1-p in the VLAN tag corresponding to the Ethernet port encapsulation, the EXP in the outer label when the tunnel is an LSP, the DSCP in the IP header if the tunnel encapsulation is GRE, and the DSCP in the payload IP header if the user enabled the ler-use-dscp option and the pseudowire terminates in IES or VPRN service (spoke-interface).

When the policer queue-group name the pseudowire is redirected does not exist, the redirection command is failed. In this case, the packet classification is performed according to default classification rule or the QoS filters defined in the ingress context of the network QoS policy applied to the network IP interface on which the pseudowire packet is received.

The no version of this command removes the redirection of the pseudowire to the queue-group.

This command is used to redirect pseudowire packets to an ingress forwarding plane queue-group for the purpose of rate-limiting.

The ingress pseudowire rate-limiting feature uses a policer in queue-group provisioning model. This model allows the mapping of one or more pseudowires to the same instance of policers which are defined in a queue-group template.

Operationally, the provisioning model in the case of the ingress pseudowire shaping feature consists of the following steps:

One or more spoke-sdps can have their FCs redirected to use policers in the same policer queue-group instance.

The following are the constraints and rules of this provisioning model when used in the ingress pseudowire rate-limiting feature:

When the policer queue-group name the pseudowire is redirected does not exist, the redirection command is failed. In this case, the packet classification is performed according to default classification rule or the QoS filters defined in the ingress context of the network QoS policy applied to the network IP interface the pseudowire packet is received on.

The no version of this command removes the redirection of the pseudowire to the queue-group.

This command associates an existing QoS policy with the template.

This command associates a Quality of Service (QoS) policy with an ingress Service Access Point (SAP) for the Epipe SAP template.

This command is used to redirect traffic arriving on VXLAN tunnels in an EVPN VXLAN service as a single entity (per forwarding class) to policers in an ingress forwarding plane queue group for the purpose of rate-limiting.

For the policer to be used, the following must be true:

The command will fail if the queue group template name does not exist or if the policer specified in the network QoS policy does not exist in the queue group template. If the queue group template name with the specified instance is not applied to the forwarding plane on which the VXLAN traffic arrives, then this traffic will use the ingress network queues related to the network interface; however, the ingress classification is still based on the applied network QoS policy.

The unicast traffic can be redirected to a policer under the forwarding class fp-redirect-group command in the ingress section of a network QoS policy. Similarly, broadcast, unknown and multicast traffic can be redirected to a broadcast-policer, unknown-policer or mcast-policer, respectively, also under the forwarding class fp-redirect-group command in the ingress section of a network QoS policy.

Ingress classification is based on the configuration of the ingress section of the specified network QoS policy, noting that the dot1p and DSCP classification is based on the outer Ethernet header and IP header, and the use of ler-use-dscp, ip-criteria and ipv6-criteria statements are ignored.

When this command is applied, it overrides the QoS applied to the related network interfaces for traffic arriving on VXLAN tunnels in that service but does not affect traffic received on a spoke-SDP in the same service.

The no version of this command removes the redirection of VXLAN tunnel traffic from the queue group policers.

This command configures the QoS ID.

This command associates a Quality of Service (QoS) policy with an ingress Service Access Point (SAP) for the Epipe SAP template.

This command associates an existing QoS policy with the template.

This command associates a Quality of Service (QoS) policy with an ingress Service Access Point (SAP).

QoS ingress and egress policies are important for the enforcement of SLA agreements. The policy ID must be defined prior to associating the policy with a SAP or IP interface. If the policy-id does not exist, an error will be returned.

The qos command is used to associate both ingress and egress QoS policies. The qos command only allows ingress policies to be associated on SAP ingress and egress policies on SAP egress. Attempts to associate a QoS policy of the wrong type returns an error.

Only one ingress and one egress QoS policy can be associated with a SAP at one time. Attempts to associate a second QoS policy of a specified type will return an error.

When an ingress QoS policy is defined on IES ingress IP interface that is bound to a VPLS, the policy becomes associated with every SAP on the VPLS and augments the QoS policy that is defined on each SAP. Packets that are bridged will be processed using the policy defined on the VPLS SAP; packets that are routed will be processed using the policy defined in the IES IP interface-binding context.

By default, if no specific QoS policy is associated with the SAP for ingress or egress, the default QoS policy is used.

The no form of this command removes the QoS policy association from the SAP, and the QoS policy reverts to the default.

This command associates a network Quality of Service (QoS) policy with a network IP interface. Only one network QoS policy can be associated with an IP interface at one time. Attempts to associate a second QoS policy return an error.

Associating a network QoS policy with a network interface is useful for the following purposes:

The no form of this command removes the network QoS policy association from the network IP interface, and the QoS policy reverts to the default.

This command is used to redirect unicast packets arriving on an automatically (using the auto-bind-tunnel command) or manually configured (using a spoke-sdp command, but not the spoke-sdp command under the VPRN IP interface) binding in a VPRN to a policer in an ingress forwarding plane queue-group for the purpose of rate-limiting.

For the policer to be used, the following must be true:

The command fails if the queue group template name does not exist or if the policer specified in the network QoS policy does not exist in the queue group template. If the queue group template name with the specified instance is not applied to the forwarding plane on which the VPRN binding unicast traffic arrives then this traffic uses the ingress network queues related to the network interface, however, the ingress classification is still based on the applied network QoS policy.

The unicast traffic can be redirected to a policer under the forwarding class fp-redirect-group command in the ingress section of a network QoS policy; any fp-redirect-group multicast-policer, broadcast-policer or unknown-policer commands are ignored for this traffic. Multicast traffic would use the ingress network queues or queue group related to the network interface.

Ingress classification is based on the configuration of the ingress section of the specified network QoS policy, noting that the dot1p and exp classification is based on the outer Ethernet header and MPLS label whereas the DSCP applies to the outer IP header if the tunnel encapsulation is GRE, or the DSCP in the first IP header in the payload if ler-use-dscp is enabled in the ingress section of the referenced network QoS policy.

When this command is applied, it overrides the QoS applied to the related network interfaces for unicast traffic arriving on bindings in that VPRN.

The no version of this command removes the redirection of VPRN binding traffic to the queue-group policers.

This command applies an QoS policy to the SAP.

Commands in this context configure Quality of Service for this application assurance group.

This command associates an existing egress or ingress QoS policy to a video interface. If the policy-id does not exist, an error will be returned. Attempts to associate a QoS policy of the wrong type returns an error. Only one QoS policy can be associated with a video interface at one time in the ingress and egress contexts. Attempts to associate a second QoS policy of a given type will return an error.

The no form of the command removes the QoS policy association from the video interface, and the QoS policy reverts to the default.

This command associates a QoS policy with an egress SAP for a mirrored service.

By default, no specific QoS policy is associated with the SAP for egress, so the default QoS policy is used.

The no form of this command removes the QoS policy association from the SAP, and the QoS policy reverts to the default.

This command associates a network Quality of Service (QoS) policy with a network IP interface. Only one network QoS policy can be associated with an IP interface at one time. Attempts to associate a second QoS policy return an error.

Associating a network QoS policy with a network interface is useful for the following purposes:

The no form of this command removes the network QoS policy association from the network IP interface, and the QoS policy reverts to the default.

Commands in this context configure criteria to monitor QoS scheduler statistics for specific customers and SAPs.

This command configures the network QoS policy that is applied to the SRv6 FPE network interface-a or interface-b.

This command sets the QoS policy from which the egress QoS marking rules are applied.

Note: If applied to a managed SAP, the default s-egress qos-policy (sap-egress 1) cannot be changed.

The no form of this command reverts to the egress QoS marking defined in SAP-egress policy defined at sla-profile level.

This command specifies the range of IDs used by SR OS to automatically assign an ID to QoS policies that are created in model-driven interfaces without an ID explicitly specified by the user or client.

A QoS policy created with an explicitly-specified ID cannot use an ID in this range. In classic CLI and SNMP, the ID range cannot be changed while objects exist inside the previous or new range. In MD interfaces, the range can be changed which will cause any previously existing objects in the previous ID range to be deleted and re-created using a new ID in the new range.

The no form of this command removes the range values.

See the config>eth-cfm md-auto-id command for further details.

This command specifies the ingress or egress QoS profile to be used for the configuration of the ingress or egress QoS parameters of an MLFR bundle or a Frame Relay port with FRF.12 UNI/NNI fragmentation enabled. Note that qos-profile on ingress is only applicable to MLFR.

The no form of this command removes the parameters from the configuration.

This command specifies the ingress or egress QoS profile to be used for the configuration of the egress QoS parameters of a Frame Relay port with FRF.12 UNI/NNI fragmentation enabled.

The no form of this command removes the parameters from the configuration.

This command specifies the egress QoS profile to be used for the outgoing traffic over this MLPPP bundle.

The no form of this command removes the parameters from the configuration.

This command specifies the ingress QoS profile to be used for the incoming traffic over this MLPPP bundle.

This command enables QoS classification of the ingress IP packets on an interface based on the QoS information associated with routes in the forwarding table.

If the optional destination parameter is specified and the destination address of an incoming IP packet matches a route with QoS information the packet is classified to the fc and priority associated with that route, overriding the fc and priority/profile determined from the sap-ingress or network qos policy associated with the IP interface. If the destination address of the incoming packet matches a route with no QoS information the fc and priority of the packet remain as determined by the sap-ingress or network QoS policy.

If the optional source parameter is specified and the source address of an incoming IP packet matches a route with QoS information the packet is classified to the fc and priority associated with that route, overriding the fc and priority/profile determined from the sap-ingress or network qos policy associated with the IP interface. If the source address of the incoming packet matches a route with no QoS information the fc and priority of the packet remain as determined by the sap-ingress or network QoS policy.

If neither the optional source or destination parameter is present, then the default is destination address matching.

The functionality enabled by the qos-route-lookup command can be applied to IPv4 packets or IPv6 packets on an interface, depending on whether it is present at the interface context (applies to IPv4) or the interface>ipv6 context (applies to IPv6). The ability to specify source address based QoS lookup is not supported for IPv6. For the 7740 ESS, subscriber management group interfaces also do not support the source QPPB option.

The no form of this command reverts to the default.

This command enables QoS classification of the ingress IP packets on an interface based on the QoS information associated with routes in the forwarding table.

If the optional destination parameter is specified and the destination address of an incoming IP packet matches a route with QoS information the packet is classified to the forwarding class (fc) and priority associated with that route, overriding the fc and priority/profile determined from the sap-ingress or network qos policy associated with the IP interface. If the destination address of the incoming packet matches a route with no QoS information the fc and priority of the packet remain as determined by the sap-ingress or network qos policy.

If the optional source parameter is specified and the source address of an incoming IP packet matches a route with QoS information the packet is classified to the fc and priority associated with that route, overriding the fc and priority/profile determined from the sap-ingress or network qos policy associated with the IP interface. If the source address of the incoming packet matches a route with no QoS information the fc and priority of the packet remain as determined by the sap-ingress or network qos policy.

If neither the optional source or destination parameter is present, then the default is destination address matching.

The functionality enabled by the qos-route-lookup command can be applied to IPv4 packets or IPv6 packets on an interface, depending on whether it is present at the interface context (applies to IPv4) or the interface>ipv6 context (applies to IPv6). Subscriber management group interfaces also do not support the source QPPB option.

The no form of this command reverts to the default destination address matching mode.

This command enables QoS classification of the ingress IP packets on an interface based on the QoS information associated with routes in the forwarding table.

If the optional destination parameter is specified and the destination address of an incoming IP packet matches a route with QoS information the packet is classified to the fc and priority associated with that route, overriding the fc and priority/profile determined from the sap-ingress or network qos policy associated with the IP interface. If the destination address of the incoming packet matches a route with no QoS information the fc and priority of the packet remain as determined by the sap-ingress or network QoS policy.

If the optional source parameter is specified and the source address of an incoming IP packet matches a route with QoS information the packet is classified to the fc and priority associated with that route, overriding the fc and priority/profile determined from the sap-ingress or network qos policy associated with the IP interface. If the source address of the incoming packet matches a route with no QoS information the fc and priority of the packet remain as determined by the sap-ingress or network QoS policy.

If neither the optional source nor destination parameter is present, then the default is destination address matching.

The functionality enabled by the qos-route-lookup command can be applied to IPv4 packets or IPv6 packets on an interface, depending on whether it is present at the interface context (applies to IPv4) or the interface>ipv6 context (applies to IPv6). The ability to specify source address based QoS lookup is not supported for IPv6. Subscriber management group interfaces also do not support the source QPPB option.

The no form of this command reverts to the default destination address matching mode.

This command enables QoS classification of the ingress IP packets on an interface based on the QoS information associated with routes in the forwarding table.

If the optional destination parameter is specified and the destination address of an incoming IP packet matches a route with QoS information the packet is classified to the fc and priority associated with that route, overriding the fc and priority/profile determined from the sap-ingress or network qos policy associated with the IP interface. If the destination address of the incoming packet matches a route with no QoS information the fc and priority of the packet remain as determined by the sap-ingress or network qos policy.

If the optional source parameter is specified and the source address of an incoming IP packet matches a route with QoS information the packet is classified to the fc and priority associated with that route, overriding the fc and priority/profile determined from the sap-ingress or network qos policy associated with the IP interface. If the source address of the incoming packet matches a route with no QoS information the fc and priority of the packet remain as determined by the sap-ingress or network qos policy.

If neither the optional source or destination parameter is present, then the default is destination address matching.

The functionality enabled by the qos-route-lookup command can be applied to IPv4 packets or IPv6 packets on an interface, depending on whether it is present at the interface context (applies to IPv4) or the interface>ipv6 context (applies to IPv6). Subscriber management group interfaces for the 7750 SR and 7450 ESS also do not support the source QPPB option.

The no form of this command reverts to the default.

This command configures the IGMP query interval. If the send-queries command is enabled, this parameter specifies the interval between two consecutive general queries sent by the system on this SAP or SDP.

The configured query-interval must be greater than the configured query-response-interval.

If send-queries is not enabled on this SAP or SDP, the configured query-interval value is ignored.

This command configures the query interval when the group interface is configured with no sub-hosts-only. If nothing is configured, by default, the query-interval takes the value defined in the config>router>igmp (or mld) context or in the config>service>vprn>igmp (or mld) context.

The no form of this command reverts to the default value.

This command specifies the frequency that the querier router transmits general host-query messages. The host-query messages solicit group membership information and are sent to the all-systems multicast group address, 224.0.0.1.

The no form of this command reverts to the default value.

This command specifies the frequency at which the querier router transmits general host-query messages. Host-query messages solicit group membership information and are sent to the all-systems multicast group address, 224.0.0.1. If nothing is configured, by default, the query-interval takes the value defined in the config>router>igmp context or in the config>service>vprn>igmp context. It is highly recommended that all three query intervals be configured together on each IGMP policy.

The no form of this command reverts to the default value.

This command configures the IGMP query interval. If the send-queries command is enabled, this parameter specifies the interval between two consecutive general queries sent by the system on an MSAP or SDP.

The configured query interval must be greater than the configured query-response interval.

If send-queries is not enabled on an MSAP or SDP, the configured query interval value is ignored.

This command specifies the frequency at which the querier router transmits general host-query messages. Host-query messages solicit group membership information and are sent to the link-scope all-node address, FF02::1. If nothing is configured, by default, the query-interval takes the value defined in the config>router>mld context or in the config> service>vprn>mld context. It is highly recommended that all three query intervals be configured together on each MLD policy.

The no form of this command reverts to the default.

This command specifies the frequency that the querier router transmits general host-query messages. The host-query messages solicit group membership information and are sent to the all-systems multicast group address, 224.0.0.1.

This command specifies the frequency that the querier router transmits general host-query messages. The host-query messages solicit group membership information and are sent to the all-systems multicast group address, 224.0.0.1.

This command specifies the frequency that the querier router transmits general host-query messages. The host-query messages solicit group membership information and are sent to the all-systems multicast group address, 224.0.0.1.

This command configures the IGMP query interval. If the send-queries command is enabled, this parameter specifies the interval between two consecutive general queries sent by the system on this SAP or SDP.

The configured query-interval must be greater than the configured query-response-interval.

If send-queries is not enabled on this SAP or SDP, the configured query-interval value is ignored.

This command configures the frequency at which the querier router sends a group-specific query messages, including the messages sent in response to leave-group messages and is only applicable when the group interface is configured with the no sub-hosts-only command. The shorter the interval, the faster the loss of the last listener of a group can be detected. If nothing is configured, by default, the query-last-listener-interval takes the value defined in the config>router>mld context or in the config>service>vprn>mld context.

The no form of this command reverts to the default value.

This command configures the frequency at which the querier router sends a group-specific query messages, including the messages sent in response to leave-group messages. The shorter the interval, the faster the loss of the last member of a group can be detected. If nothing is configured, by default, the query-last-listener-interval takes the value defined in the config>router>mld context or in the config>service>vprn>mld context. It is highly recommended that all three query intervals be configured together on each MLD policy.

The no form of this command reverts to the default.

This command specifies the Max Response Time inserted into Group-Specific Queries sent in response to Leave Group messages, and is also the amount of time between Group-Specific Query messages. This value may be tuned to modify the leave latency of the network. A reduced value results in reduced time to detect the loss of the last member of a group.

The no form of this command reverts to the default value.

This command configures the frequency at which the querier router sends group-specific query messages, including the messages sent in response to leave-group messages and is only applicable when the group interface is configured with no sub-hosts-only. The shorter the interval, the faster the loss of the last member of a group can be detected. If nothing is configured, by default, the query-last-member-interval takes the value defined in the config>router>igmp context or in the config>service>vprn>igmp context.

The no form of this command reverts to the default value.

This command configures the frequency at which the querier sends group-specific query messages including messages sent in response to leave-group messages. The lower the interval, the faster the detection of the loss of the last member of a group.

This command configures the frequency at which the querier router sends group-specific query messages, including the messages sent in response to leave-group messages. The shorter the interval, the faster a loss of the last member of a group can be detected. If nothing is configured, by default, the query-last-member-interval takes the value defined in the config>router>igmp context or the config>service>vprn>igmp context. It is highly recommended that all three query intervals be configured together on each IGMP policy.

The no form of this command reverts to the default value.

This command configures the frequency at which the querier sends group-specific query messages including messages sent in response to leave-group messages. The lower the interval, the faster the detection of the loss of the last member of a group.

This command configures the frequency at which the querier sends group-specific query messages including messages sent in response to leave-group messages. The lower the interval, the faster the detection of the loss of the last member of a group.

This command configures the IGMP query response interval. If the send-queries command is enabled, this parameter specifies the maximum response time advertised in IGMPv2 or IGMPv3 queries.

The configured query response interval must be smaller than the configured query interval.

If send-queries is not enabled on this SAP or SDP, the configured query response interval value is ignored.

The no form of this command reverts to the default value.

This command configures the query response interval on when the group interface is configured with the no sub-hosts-only command. If nothing is configured, by default, the query-response-interval takes the value defined in the config>router>igmp (or mld) context or in the config>service>vprn>igmp (or mld) context.

The no form of this command reverts to the default value.

This command specifies how long the querier router waits to receive a response to a host-query message from a host.

The no form of this command reverts to the default value.

This command specifies how long the querier router waits to receive a response to a host-query message from a host.

This command configures the query response interval. If nothing is configured, by default, the query-response-interval takes the value defined in the config>router>igmp context or in the config>service>vprn>igmp context. It is highly recommended that all three query intervals be configured together on each IGMP policy.

The no form of this command reverts to the default value.

This command configures the IGMP query response interval. If the send-queries command is enabled, this parameter specifies the maximum response time advertised in IGMPv2/v3 queries.

The configured query-response-interval must be smaller than the configured query-interval.

If send-queries is not enabled on an MSAP or SDP, the configured query-response-interval value is ignored.

The no form of this command reverts to the default.

This command configures the query response interval. If nothing is configured, by default, the query-response-interval takes the value defined in the config>router>mld context or in the config>service>vprn>mld context. It is highly recommended that all three query intervals be configured together on each MLD policy.

The no form of this command reverts to the default.

This command specifies how long the querier router waits to receive a response to a host-query message from a host.

This command configures the IGMP query response interval. If the send-queries command is enabled, this parameter specifies the maximum response time advertised in IGMPv2/v3 queries.

The configured query-response-interval must be smaller than the configured query-interval.

If send-queries is not enabled on this SAP or SDP, the configured query-response-interval value is ignored.

This command configures the IP source address used in IGMP or MLD queries.

The no form of this command removes the IP address from this configuration.

This command configures the IP source address used in MLD queries.

This command configures the query source IP address for the group interface. This IP address overrides the source IP address configured at the router level.

The no form of this command removes the IP address.

This command configures the query source IP address for the group interface. This IP address overrides the source IP address configured at the router level.

The no form of the command removes the IP address.

This command configures the query source IPv6 address for the group interface. This IP address overrides the source IP address configured at the router level.

The no form of this command removes the IPv6 address.

This command configures a queue in this category.

The no form of this command reverts to the default.

This command specifies the queue-id for which counters are collected in this custom record. The counters that are collected are defined in egress and ingress counters.

The no form of this command reverts to the default value.

Commands in this context configure egress or ingress queue parameters. Parameters defined in the config>qos>sap-egress policy-id or the config>qos>sap-ingress policy-id context are overridden by parameters specified in the subscriber management SLA profile context.

The classification and the queue mapping are shared by all the hosts on the same complex that use the same QoS policy (specified in the sla-profile SAP egress and SAP ingress policy IDs).

The queues are shared by all the hosts (of the same subscriber) on the same SAP that are using the same SLA profile. Queues are instantiated when, on a given SAP, a host of a subscriber is the first to use a certain SLA profile. This instantiation is referred to as an SLA profile instance.

The no form of this command removes the queue-id from the SLA profile.

This command specifies the ID of the queue whose parameters are to be overridden.

The no form of this command removes the queue ID from the configuration.

This command associates a queue for use in a queue group template. The defined queue-id acts as a repository for the default parameters for the queue. The template queue is created on each queue-group object which is created with the queue group template name. Each queue is identified within the template by a queue-id number. The template ensures that all queue groups created with the template’s name will have the same queue-ids providing a uniform structure for the forwarding class redirection commands in the SAP egress QoS policies. The parameters within the template queue will be used as the default settings for each queue in the actual queue group. The queue parameters may be individually changed for each queue in each queue group using per queue overrides.

The no form of this command removes the queue-id from the configuration.

This command associates a queue for use in a queue group template. The defined queue-id acts as a repository for the default parameters for the queue. The template queue is created on each queue-group object which is created with the queue group template name. Each queue is identified within the template by a queue-id number. The template ensures that all queue groups created with the template’s name will have the same queue-ids providing a uniform structure for the forwarding class redirection commands in the SAP egress QoS policies. The parameters within the template queue will be used as the default settings for each queue in the actual queue group. The queue parameters may be individually changed for each queue in each queue group using per queue overrides.

The no form of this command removes the queue-id from the configuration.

This command specifies the ID of the queue whose parameters are to be overridden.

This command specifies the ID of the queue whose parameters are to be overridden.

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. When 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.

This command creates the context to configure an ingress SAP QoS policy queue.

Explicit definition of an ingress queue’s type is supported. A single ingress queue allows support for multiple forwarding classes. The default behavior automatically chooses the expedited or best effort 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 best effort 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 queue type 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.

The multipoint queues are for multipoint-destined service traffic. Within non-multipoint services, such as Epipe services, all traffic is considered unicast due to the nature of the service type. Multicast and broadcast-destined traffic in an Epipe service will not be mapped to a multipoint service queue.

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.

Any billing or statistical queries about a multipoint queue on a non-multipoint service returns zero values. Any queue parameter information requested about a multipoint queue on a non-multipoint service returns the queue parameters in the policy. Buffers will not be allocated for multipoint queues on non-multipoint services. Buffer pool queries return zero values for actual buffers allocated and current buffer utilization.

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.

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. When the forwarding class mapping is executed, all traffic is 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 command creates the context to configure an egress service access point (SAP) QoS policy queue.

Explicit definition of an egress queue’s type is supported. A single egress queue allows support for multiple forwarding classes. The default behavior automatically chooses the expedited or best effort 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 best effort forwarding classes are mapped to the queue (be, af, l1, or l2), the queue is treated as best effort by the hardware schedulers. The queue type must be defined at the time of queue creation within the policy.

The no form of this command removes the queue-id from the SAP egress 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.

This command defines how the specified queue-id is attached to the scheduler. A queue may have one of four attachment states:

The following items are rules for attachment:

When an hs-attachment-policy is initially created, all queues and both WRR groups default to the unattached state. Each queue and WRR group attachment state must be explicitly configured.

The no form of the command reverts to the default unattached attachment state for queue ID. The command fails if the specified queue-id is currently in a WRR group and removing the queue from that group causes the queue IDs for that group to become discontinuous.

Commands in this context configure a QoS network-queue policy queue.

Explicit definition of an ingress queue’s type status is supported. A single ingress queue allows support for multiple forwarding classes. The default behavior automatically chooses the expedited or best effort 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 best effort 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 queue type 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.

The multipoint queues are for multipoint traffic.

The multipoint queues are for multipoint-destined service traffic. Within non-multipoint services, such as Epipe services, all traffic is considered unicast due to the nature of the service type. Multicast and broadcast-destined traffic in an Epipe service will not be mapped to a multipoint service queue.

When a QoS policy with multipoint queues is applied to an Epipe or IES SAP, the multipoint queues are not created. Any billing or statistical queries about a multipoint queue on a non-multipoint service returns zero values. Any queue parameter information requested about a multipoint queue on a non-multipoint service returns the queue parameters in the policy. Buffers will not be allocated for multipoint queues on non-multipoint services. Buffer pool queries return zero values for actual buffers allocated and current buffer utilization.

The no form of this command removes the queue-id from the network-queue 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.

This command creates a queue for use in a queue group template. When created, the defined queue-id acts as a repository for the default parameters for the queue. The template queue is created on each queue-group object that is created with the queue group template name. Each queue is identified within the template by a queue-id number. The template ensures that all queue groups created with the template name will have the same queue-ids providing a uniform structure for the forwarding class redirection commands in the SAP ingress QoS policies. The parameters within the template queue will be used as the default settings for each queue in the actual queue group. The queue parameters may be individually changed for each queue in each queue group using per queue overrides.

When a queue within a template is mapped by a forwarding class on any object, the queue may be edited, but not deleted.

The no form of this command removes a template queue from the queue group template. If the queue is specified as a forwarding class redirection target in any SAP ingress QoS policy, the command will fail.

This command is used to map the forwarding class to the specified queue-id. The specified queue-id must exist within the egress queue group template. When a queue is defined in a forwarding class mapping, that queue cannot be deleted unless the forwarding class mapping is moved to another queue within the template. Other criteria may also exist preventing the queue from being deleted from the template such as an applied SAP egress QoS policy mapping to the queue.

This command creates a queue for use in a queue group template. When created, the defined queue-id acts as a repository for the default parameters for the queue. The template queue is created on each queue group object that is created with the queue group template name. Each queue is identified within the template by a queue ID. The template ensures that all queue groups created with the template name will have the same queue-ids providing a uniform structure for the forwarding class redirection commands in the SAP egress QoS policies. The parameters within the template queue will be used as the default settings for each queue in the actual queue group. The queue parameters may be individually changed for each queue in each queue group using per queue overrides.

This command overrides the default unicast forwarding type queue mapping for fc fc-name. The specified queue-id must exist within the policy as a non-multipoint queue before the mapping can be made. When the forwarding class mapping is executed, all unicast traffic (this includes all traffic, even broadcast and multicast for services) on a SAP using this policy is forwarded using the queue-id.

The no form of this command sets the unicast (point-to-point) queue-id back to the default queue for the forwarding class (queue 1).

This command creates the context to configure a shared queue QoS policy queue.

Explicit definition of an ingress queue’s type is supported. A single ingress queue allows support for multiple forwarding classes. The default behavior automatically chooses the expedited or best effort 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 best effort forwarding classes are mapped to the queue (be, af, l1, or l2), the queue is treated as best effort by the hardware schedulers. The queue type can be overridden within the policy.

On the 7450 ESS, 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.

This command specifies the queue-id for which counters will be collected in this custom record. The counters that will be collected are defined in egress and ingress counters.

The no form of this command reverts to the default value.

This command allows users to allocate dedicated CPM. The first available queue is 33.

This command configures an Ethernet network queue ID.

The no form of this command removes the Ethernet network queue ID.

This command configures the target queue delay for packets forwarded through the queue. It is used to determine the related queue parameters based on the administrative PIR of the queue. This command and the mbs command are mutually exclusive.

In order 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 no form of this command disables the determination of the queue parameters based on the queue delay.

This command enables frame-based accounting on all queues associated with the agg-rate context. Only supported on Ethernet ports. Packet byte offset settings are not included in the applied rate when queue frame based accounting is configured, however the offsets are applied to the statistics.

The no form of this command disables frame-based accounting.

This command enables frame based accounting on all policers and queues associated with the agg-rate context. It is only supported on Ethernet ports. Packet byte offset settings are not included in the applied rate when queue frame-based accounting is configured, regardless of how offsets are applied to the statistics.

The no form of this command disables frame based accounting on all policers and queues associated with the agg-rate context.

This command is used to enable (or disable) frame based accounting on all policers and queues associated with the agg-rate context.

The command is supported on Ethernet ports only.

Packet byte offset settings are not included in the applied rate when queue frame based accounting is configured; however the offsets are applied to the statistics.

This command is used to enabled frame-based accounting on all policers and queues associated with the agg-rate context. Only supported on Ethernet ports. Packet byte offset settings are not included in the applied rate when queue frame based accounting is configured; however the offsets are applied to the statistics.

The no form of this command disables the-frame based accounting.

This command is used to enabled (or disable) frame based accounting on all policers and queues associated with the agg-rate context. Only supported on Ethernet ports. Packet byte offset settings are not included in the applied rate when queue frame-based accounting is configured; the offsets are applied to the statistics.

This command enables frame based accounting on all policers and queues associated with the agg-rate context. Only supported on Ethernet ports. Packet byte offset settings are not included in the applied rate when queue frame based accounting is configured, however the offsets are applied to the statistics.

The no form of the command disables frame based accounting.

This command creates an instance of a named queue group template on the ingress forwarding plane of a given IOM/IMM. The queue-group-name and instance instance-id are mandatory parameters when executing the command.

The named queue group template can contain only policers. If it contains queues, then the command will fail.

The no form of this command deletes a specific instance of a queue group.

This command creates a queue-group instance in the network ingress context of a forwarding plane.

Only a queue-group containing policers can be instantiated. If the queue-group template contains policers and queues, the queues are not instantiated. If the queue-group contains queues only, the instantiation in the data path is failed.

One or more instances of the same policer queue-group name and/or a different policer queue-group name can be created on the network ingress context of a forwarding plane.

The queue-group-name must be unique within all network ingress and access ingress queue groups in the system. The queue-group instance-id must be unique within the context of the forwarding plane.

The no form of this command deletes the queue-group instance from the network ingress context of the forwarding plane.

This command configures a queue-group instance in the network egress context of a port.

Queue-groups containing queues only or policers and queues can be instantiated. When a port is a LAG, one instance of the queue-group is instantiated on each member link.

One or more instances of the same queue-group name and/or a different queue-group name can be created in the network egress context of a port.

The queue-group-name must be unique within all network egress and access egress queue groups in the system. The queue-group instance-id must be unique within the context of the port.

The no version of this command deletes the queue-group instance from the network egress context of the port.

This command creates an ingress or egress queue group on an Ethernet port. A queue group is a collection of queues identified by a group name. Queue groups created on access ports are used as an alternative queue destination for SAPs.

Within a SAP, a forwarding class may be redirected from the local SAP queue to a port queue group queue. The forwarding classes from multiple SAPs may be redirected to the same queue group which can be used to minimize the number of per-SAP queues.

Queue groups may be created on both access and network oriented ports. When the port is in access mode, the queue groups must be created within the port access node.

Within the access node, queue groups are also configured as ingress or egress. Access ingress queue groups can only be used by ingress SAP forwarding classes and only a single ingress queue group per port is supported. Multiple access egress queue groups may be created on a single port and are used by egress SAP forwarding classes. The instance-id parameter identifies different instances of the same queue group template. Creating multiple queue groups with a different instance ID but the same queue group name results in separate queue groups being created on the port. The instance-id parameter is only valid for egress queue groups on access ports.

When the queue group is created in an ingress port context, the group-name must be an existing ingress queue group template. Similarly, queue groups created in an egress port context must have a group-name of an existing egress queue group template. Two ingress queue groups with the same name cannot be created on the same port. Two egress queue groups can only be created on the same port with the same queue group template name if they have different instance-id values.

The queues defined in the template are created on the queue group. The queue parameters within the template are used as the default queue parameters for each queue in the queue group. The default queue parameters for each queue may be overridden on the queue group with specific queue parameters.

Each queue group supports the application of a scheduler-policy for the purpose of managing the queues within the group into an aggregate SLA. The queues defined within the template may be configured with parent scheduler defining the mapping of a queue to one of the schedulers within the scheduler policy. Egress queue groups also support the agg-rate parameter and the queues in the egress template support the port-parent command. Each command is used for configuring egress port virtual scheduling behavior.

Each queue group allows the application of an accounting policy and the ability to enable and disable collecting statistics. The statistics are derived from the queue counters on each queue within the queue group. The accounting policy defines which queue counters are collected and to which accounting file they will be written.

A queue group does not have an administrative shutdown or no shutdown command. A queue group is considered to be always on once created.

When creating a queue group, the system will attempt to allocate queue resources based on the queues defined in the queue group template. If the appropriate queue resources do not currently exist, the queue group will not be created. Ingress port queue groups do not support the shared-queuing or multipoint-shared queuing behavior.

When the queue group is created on a LAG (Link Aggregation Group), it must be created on the primary port member. The primary port member is the port with the lowest port ID based on the slot, MDA position and port number on the MDA. A queue group created on the primary LAG port will be automatically created on all other port members. If a new port is being added to a LAG with an existing queue group, the queue group must first be created on the port prior to adding the port to the LAG. If the LAG queue group has queue overrides, the queue overrides must also be defined on the port queue group prior to adding the port to the LAG.

A port queue group cannot be removed from the port when a forwarding class is currently redirected to the group. All forwarding class redirections must first be removed prior to removing the queue group.

This command enables queue-group monitoring for the specified parameters.

This command creates a queue group template. The system does not maintain default queue groups or queue group templates. Each queue group template used in the system must be explicitly created.

The no form of this command removes the specified queue group template from the system. If the queue group template is currently in use by an ingress port, the command will fail. If queue-group-name does not exist, the command has no effect and does not return an error.

This command copies an existing queue-group-egress queue-group-name to another queue-group-egress queue-group-name. The copy command is a configuration level maintenance tool used to create new entries using an existing mapping policy name. If overwrite is not specified, an error occurs if the destination policy exists.

This command copies an existing queue-group-ingress to another queue-group-ingress. The copy command is a configuration level maintenance tool used to create new entries using an existing mapping policy name. If overwrite is not specified, an error occurs if the destination policy exists.

This command applies a queue group redirect list to the ingress or egress of an interface SAP within an IES or VPRN service. The redirect list is used to redirect traffic to different instances of the default queue group. This command requires the prior configuration of a default queue group instance, this being the queue group instance specified with the QoS policy under the SAP ingress or egress.

The no version of this command removes the queue group redirect list from the SAP.

This command applies a queue group redirect list to the ingress or egress of an interface SAP within a VPRN service. The redirect list is used to redirect traffic to different instances of the default queue group.

This command requires the prior configuration of a default queue group instance, which is the queue group instance specified with the QoS policy under the SAP ingress or egress.

The no version of this command removes the queue group redirect list from the SAP.

This command configures a queue group redirect list that is used to redirect traffic to different instances of a queue group.

The no form of this command deletes the queue group redirect list. A list can only be deleted when there no references to it.

Commands in this context define ingress and egress queue group templates.

This command enables per queue-instance-accounting. A stream of accounting messages (START/INTERIM-UPDATE/STOP) is generated per queuing instance. A queuing instance is equivalent to an sla-profile instance. Accounting session id is generated per queuing instance and this accounting session id cannot be included in RADIUS Access-Request message. Queue instance counters represent volume based aggregation for all hosts sharing the queuing instance.

CoA and LI is supported based on the acct-session-id of the queuing instance.

The no form of this command reverts to the default.

Commands in this context configure override values for the specified SAP egress or ingress QoS queue. These values override the corresponding ones specified in the associated SAP egress QoS policy.

Commands in this context configure override values for the specified SAP egress or ingress QoS queue. These values override the corresponding ones specified in the associated SAP egress or ingress QoS policy. If the policy was created as a template policy, this command overrides the parameter and its description and queue parameters in the policy.

Commands in this context define optional queue parameter overrides for each queue within the queue group.

Commands in this context configure queue parameters. This command defines the individual parameters for the queues through which multicast packets are forwarded into the switch fabric on each path.

The individual path queues may be viewed as shared queues. All multicast packets forwarded through the switch fabric associated with one of the paths traverses bypass the normal queuing behavior. Instead of being forwarded through the normal service or network multicast queue, a single queue associated with the multicast path is used. To retain billing and diagnostic information, the forwarding and discard statistics for the service or network queue the packet would have traversed without ingress multicast management is used to account for each packet’s behavior.

Note: Any ingress scheduling policy functions attempting to manage the service or network multicast queues is only able to read the statistics of the multicast queues and not able to manage the queues dynamic rate since the packets are flowing through different, non-managed queues. Since this is the case, multicast queues parented to a scheduling policy should be parented to the root scheduler at the highest priority without any rate limitation. Any ingress rate limiting for multicast traffic is performed by the multicast path bandwidth manger based on each records priority and a possible “black-hole” rate threshold.

All queues created for ingress multicast path management are automatically created by the system out of the system reserved queue space. Each queue is created as an expedited queue.

When forwarding through the queues, each packets forwarding class is ignored. However, the forwarding class is retained for proper egress processing. The packets expressed or implied profile is also ignored within the ingress path queues. A packets congestion priority is derived from the records cong-priority-threshold evaluation result as indicated by the policy or multicast-info-policy. The cong-priority-threshold sets the high or low congestion priority of a record based on the records preference value. Within each multicast information policy bundle the cong-priority-threshold preference-level is set with a value from 0 to 7 and defines the threshold at which all records with a preference equal to or higher than the defined preference is treated as congestion priority high. Multicast records with a preference lower than the defined class threshold is treated as congestion priority low. Low-priority packets use the low drop-tail threshold of the queue, while high-priority packets use the standard MBS value. In the event of path congestion, low-priority packets are discarded first, leaving room for the higher priority packets.

For the primary and secondary paths, a single queue exists for each path and every packet forwarded through the path by the bandwidth manager uses that queue.

This command specifies the network-queue policy which defines queue parameters such as CBS, high priority only burst size, MBS, CIR and PIR rates, as well as forwarding-class to queue mappings. The network-queue policy is defined in the config>qos>network-queue context.

This command specifies the existing network queue policy which defines queue parameters such as CBS, high priority only burst size, MBS, CIR and PIR rates, as well as forwarding-class to queue mappings. The network-queue policy is defined in the config>qos>network-queue context.

This command assigns an IOM network queue policy as applicable to specific application assurance group traffic.

Commands in this context modify the FP resource policy information for the queues.

This command specifies that the queues within this egress queue group template are to be managed by the Hierarchical QoS (HQoS) process when the template is applied to an Ethernet access egress or network egress context. It is applicable to all egress queue group templates, including the default policer-output-queues template.

The no queues-hqos-manageable command must be configured for access egress queue groups that are used for post-policer traffic in order to prevent HQoS from measuring the traffic through a policer managed by HQoS then again through a post-policer access egress queue group queue.

Avoid scenarios that result in traffic being either not being measured or being measured twice by HQoS as they will cause the HQoS result to be inaccurate.

A template configured for no queues-hqos-manageable cannot be applied to an Ethernet network egress context. Any egress queue group templates applied to an Ethernet network egress context cannot be configured as no queues-hqos-manageable. The configuration of no queues-hqos-manageable and the configuration of policers and queue packet-byte-offset within the egress queue group template are mutually exclusive.

When a queue group template with no queues-hqos-manageable is configured under a port's Ethernet access egress context, the configuration of an aggregate rate or scheduler policy is not permitted under that context, nor are parent overrides for any of the queues in the queue group. If a port scheduler is configured on the port, the queue group queues are not parented to the port scheduler.

The no form of this command specifies that queues within this egress queue group are not managed by HQoS.

This command configures the period between two authentication sessions during which no EAPOL frames are sent by the router.

The no form of this command returns the value to the default.

This command exits the edit-cfg mode. The contents of the current candidate will not be deleted and the operator can continue editing the candidate later.