This command enables debugging for PIM selective provider multicast service interface.

The no form of this command disables the debugging.

This command determines the inner VIDs (for a specified outer VID) associated with the virtual Ethernet Segment on a specific qinq port or LAG based on the following:

Note: Not all qtag1 and qtag2 combinations are valid for values 0, *, and null. The following combinations are allowed: s-tag 0 c-tag-range * s-tag * c-tag-range * s-tag * c-tag-range null s-tag null c-tag-range null s-tag X c-tag-range 0 (where: X=1 to 4094) s-tag X c-tag-range * (where: X=1 to 4094)

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

This command determines the VIDs associated with the virtual Ethernet Segment on a specific qinq 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 enables GTP configuration related to S11 termination in this VRF.

This command creates a root-to-leaf (S2L) sub-LSP path for the primary instance of a P2MP LSP. The primary instance of a P2MP LSP is modeled as a set of root-to-leaf (S2L) sub-LSPs. The root, for example, head-end node, triggers signaling using one path message per S2L path. The leaf sub-LSP paths are merged at branching points.

Each S2L sub-LSP is signaled in a separate path message. Each leaf node will respond with its own RESV message. A branch LSR node will forward the path message of each S2L sub-LSP to the downstream LSR without replicating it. It will also forward the RESV message of each S2L sub-LSP to the upstream LSR without merging it with the RESV messages of other S2L sub-LSPs of the same P2MP LSP. The same is done for subsequent refreshes of the path and RESV states.

The S2L paths can be empty paths or can specify a list of explicit hops. The path name must exist and must have been defined using the config>router>mpls>path command. The same path name can be re-used by more than one S2L of the primary P2MP instance. However, the to keyword must have a unique argument per S2L as it corresponds to the address of the egress LER node.

This command is not supported on the 7450 ESS.

This command enables debugging for Multicast Source Discovery Protocol (MSDP) source-active requests.

The no form of the command disables the MSDP source-active database debugging.

This command configures the source and destination MAC addresses for IP mirroring.

The no form of this command reverts to the default.

This command configures the value for the SA entries in the cache. If these entries are not refreshed within the timeout value, they are removed from the cache. Normally, the entries are refreshed at least once a minute. But under high load with many of MSDP peers, the refresh cycle could be incomplete. A higher timeout value (more then 90) could be useful to prevent instabilities in the MSDP cache.

This command configures the value for the SA entries in the cache. If these entries are not refreshed within the timeout value, they are removed from the cache. Normally, the entries are refreshed at least once a minute. But under high load with many of MSDP peers, the refresh cycle could be incomplete. A higher timeout value (more than 90) could be useful to prevent instabilities in the MSDP cache.

Commands in this context configure the Service Assurance Agent (SAA) tests.

This command starts or stops an SAA test that is not configured as continuous.

This command configures the Source Individual Attachment Identifier (SAII) for an MPLS-TP spoke-sdp. If this is configured on a spoke-sdp for which vc-switching is also configured (for example, it is at an S-PE), then the values must match those of the taii-type2 of the mate spoke-sdp.

This command configures the source attachment individual identifier for the spoke-sdp. This is only applicable to FEC129 AII type 2.

This command configures the source individual attachment identifier (SAII) for an MPLS-TP spoke SDP. If this is configured on a spoke SDP for which vc-switching is also configured (for example, it is at an S-PE), then the values must match those of the taii-type2 of the mate spoke SDP.

This command configures the source individual attachment identifier (SAII) for an MPLS-TP spoke SDP. If this is configured on a spoke SDP for which vc-switching is also configured (for example, it is at an S-PE), then the values must match those of the taii-type2 of the mate spoke SDP.

This command enables the system to use same recipNonce as the last CMPv2 response for poll request.

This command enables the system to use same recipNonce as the last CMPv2 response for poll request.

The no form of this command disables system to use same recipNonce as the last CMPv2 response for poll request.

This command sets the dark bandwidth sample interval to the specified value. Changing this parameter in the course of dark bandwidth accounting restarts the accounting cycle. The user is encouraged to specify values as multiples of 10. Selecting other values may lead to inconsistent estimation of Dark Bandwidth.

This command is used to define the number of intervening sample periods before a new offered rate is measured and is only applicable when the policy is applied to a policer. By decreasing the sampling interval, the system will measure a child’s new offered rate more frequently. Inversely, increasing the sampling interval causes the child’s offered rate to be measured less frequently.

The overall number of offered rate measurements the system attempts within a given timeframe is not affected by the sample-interval command. If the system is asked to perform offered rate measurements more often on some policers, it will take longer to get to all children.

When this command is not specified or removed, the system evaluates the offered rate of each child after 1 sampling period.

The no form of this command is used to restore the sampling interval default of 1 sample period.

This command configures the sample interval for persistent subscription.

This sampling interval only applies when the mode command is set to either target-defined or sample.

This command sets the dark bandwidth sample interval multiplier to the specified value. Changing this parameter in the course of dark bandwidth accounting restarts the accounting cycle.

Commands in this context create and define sampling parameters.

The no form of this command removes the associated sample-profile. sample-profile 1 cannot be deleted.

This command allows traffic matching of an IPv4 or IPv6 filter to be sampled for cflowd processing using a specific sample profile.

This command is only compatible if the associated interface is configured for interface-based sampling and is only supported for ingress sampling.

An IP filter can only specify a single alternate sample profile for cflowd sampling, but that sample profile can be used in multiple entries.

The no form of this command removes the specified sampling profile from the configuration. Cflowd continues to process traffic based on the default or configured interface cflowd sampling profile.

This command defines the cflowd sampling rate for the sample profile ID.

The sample rate indicates that the associated interface samples 1 in N packets for cflowd analysis. Only one rate profile below 1:256 with a specific IOM, IMM, or XMA can be associated.

This command specifies the sample window duration in seconds for the template. This configuration option represents time over which the average will be calculated and subsequently streamed.

The no form of this command reverts to the default.

Commands in this context configure sample window parameters to be used when the measurement-template is assigned to an IP interface. The sample window is the collection of individual probe results, over a defined period.

This command enables and configures the cflowd sampling behavior to collect traffic flow samples through a router for analysis.

This command can be used to configure the sampling parameters for unicast and multicast traffic separately. If sampling is not configured for either unicast or multicast traffic, then that type of traffic will not be sampled.

If cflowd is enabled without either egress-only or both keywords specified or with the ingress-only keyword specified, then only ingress sampling is enabled on the associated IP interface.

The no form of this command disables the associated type of traffic sampling.

This command enables and configures the cflowd sampling behavior to collect traffic flow samples through a router for analysis.

This command can be used to configure the sampling parameters for unicast and multicast traffic separately. If sampling is not configured for either unicast or multicast traffic, then that type of traffic will not be sampled.

If cflowd is enabled without either egress-only or both specified or with the ingress-only keyword specified, then only ingress sampling will be enabled on the associated IP interface.

The no form of this command disables the associated type of traffic sampling on the associated interface.

This command configures the packet sampling rate for mirrored traffic and is supported with config and debug mirror sources. The sampling rate is common to all endpoints on a specified line card FP per mirror destination service.

The no form of this command disables the packet sampling rate for mirrored traffic.

This command creates a Service Access Point (SAP) within a service. A SAP is a combination of port and encapsulation parameters which identifies the service access point on the interface and within the 7450 ESS or 7750 SR. Each SAP must be unique. All SAPs must be explicitly created within a service or on an IP interface.

Enter an existing SAP without the create keyword to edit SAP parameters. The SAP is owned by the service in which it was created.

A SAP can only be associated with a single service. A SAP can only be defined on a port that has been configured as an access port using the config interface port-type port-id mode access command. Channelized TDM ports are always access ports (TDM applies to the 7750 SR only).

If a port is shut down, all SAPs on that port become operationally down. When a service is shut down, SAPs for the service are not displayed as operationally down although all traffic traversing the service is discarded. The operational state of a SAP is relative to the operational state of the port on which the SAP is defined.

The no form of this command deletes the SAP with the specified port. When a SAP is deleted, all configuration parameters for the SAP are also deleted. For Internet Ethernet Service (IES), the IP interface must be shut down before the SAP on that interface may be removed.

This command configures attributes of a SAP on the B-VPLS service.

This command creates a Service Access Point (SAP) within a service. A SAP is a combination of port and encapsulation parameters which identifies the service access point on the interface and within the device. Each SAP must be unique.

All SAPs must be explicitly created. If no SAPs are created within a service or on an IP interface, a SAP will not exist on that object.

Enter an existing SAP without the create keyword to edit SAP parameters. The SAP is owned by the service in which it was created.

A SAP can only be associated with a single service. A SAP can only be defined on a port that has been configured as an access port. Channelized TDM ports are always access ports.

If a port is shutdown, all SAPs on that port become operationally down. When a service is shutdown, SAPs for the service are not displayed as operationally down although all traffic traversing the service will be discarded.

The operational state of a SAP is relative to the operational state of the port on which the SAP is defined.

The following are supported on the 7750 SR only:

Ethernet SAPs support null, dot1q, and qinq is supported for all routers.

The no form of this command deletes the SAP with the specified port. When a SAP is deleted, all configuration parameters for the SAP will also be deleted. For Internet Enhanced Service (IES), the IP interface must be shutdown before the SAP on that interface may be removed.

By default, no SAPs are defined.

This command creates a Service Access Point (SAP) within a service. A SAP is a combination of port and encapsulation parameters which identifies the service access point on the interface and within the router. Each SAP must be unique.

All SAPs must be explicitly created. If no SAPs are created within a service or on an IP interface, a SAP will not exist on that object.

Enter an existing SAP without the create keyword to edit SAP parameters. The SAP is owned by the service in which it was created.

A SAP can only be associated with a single service. A SAP can only be defined on a port that has been configured as an access port using the config interface port-type port-id mode access command. For the 7750 SR, channelized TDM ports are always access ports.

If a port is shutdown, all SAPs on that port become operationally down. When a service is shutdown, SAPs for the service are not displayed as operationally down although all traffic traversing the service will be discarded. The operational state of a SAP is relative to the operational state of the port on which the SAP is defined.

Note: Configure an IES interface as a loopback interface by issuing the loopback command instead of the sap sap-id command. The loopback flag cannot be set on an interface where a SAP is already defined and a SAP cannot be defined on a loopback interface.

The no form of this command deletes the SAP with the specified port. When a SAP is deleted, all configuration parameters for the SAP are also deleted. For Internet Enhanced Service (IES), the IP interface must be shutdown before the SAP on that interface may be removed. The no form of this command causes the ptp-hw-assist to be disabled.

This command creates a Service Access Point (SAP) within a service. A SAP is a combination of port and encapsulation parameters which identifies the service access point on the interface and within the router. Each SAP must be unique.

All SAPs must be explicitly created. If no SAPs are created within a service or on an IP interface, a SAP will not exist on that object. Enter an existing SAP without the create keyword to edit SAP parameters. The SAP is owned by the service in which it was created.

A SAP can only be associated with a single service. A SAP can only be defined on a port that has been configured as an access port using the config interface port-type port-id mode access command. Channelized TDM ports are always access ports.

If a port is shut down, all SAPs on that port become operationally down. When a service is shut down, SAPs for the service are not displayed as operationally down although all traffic traversing the service will be discarded. The operational state of a SAP is relative to the operational state of the port on which the SAP is defined.

The no form of this command deletes the SAP with the specified port. When a SAP is deleted, all configuration parameters for the SAP will also be deleted. The no form of this command causes the ptp-h-assist to be disabled.

This command creates a SAP for the interface.

The no form of this command removes the SAP.

This command enables PPP debug output for the specified SAP, this command allow multiple instances.

The no form of this command disables debugging.

This command configures a SAP for the site.

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

This command filters debug events and only shows events for the particular SAP.

The no form of this command removes the debug filter.

This command configures a SAP for the site.

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

This command enables STP debugging for a specific SAP.

The no form of the command disables debugging.

This command declares a specified SAP as a primary (or secondary) VPLS port.

This command displays ARP host events for a particular SAP.

This command shows IGMP packets for a specific SAP.

The no form of this command disables the debugging for the SAP.

This command shows MLD packets for a specific SAP.

The no form of this command disables the debugging for the SAP.

This command displays Subscriber Host Connectivity Verification (SHCV) events for a particular SAP.

This commands specifies which ISA card and which VLAN is used by a given AA Interface.

This command configures the AA interface SAP.

This command creates a service access point (SAP) within a mirror destination service. The SAP is owned by the mirror destination service ID.

The SAP is defined with port and encapsulation parameters to uniquely identify the (mirror) SAP on the interface and within the box. The specified SAP may be defined on an Ethernet access port with a dot1q, null, or q-in-q encapsulation type.

Only one SAP can be created within a mirror-dest service ID. If the defined SAP has not been created on any service within the system, the SAP is created and the context of the CLI will change to the newly created SAP. In addition, the port cannot be a member of a multi-link bundle, APS group or IMA bundle.

If the defined SAP exists in the context of another service ID, mirror-dest or any other type, an error is generated.

Mirror destination SAPs can be created on Ethernet interfaces that have been defined as an access interface. If the interface is defined as network, the SAP creation returns an error.

When the no form of this command is used on a SAP created by a mirror destination service ID, the SAP with the specified port and encapsulation parameters is deleted.

This command enables mirroring of traffic ingressing or egressing a service access port (SAP). A SAP that is defined within a mirror destination cannot be used in a mirror source. The mirror source SAP referenced by the sap-id is owned by the service ID of the service in which it was created. The SAP is only referenced in the mirror source name for mirroring purposes. The mirror source association does not need to be removed before deleting the SAP from its service ID. If the SAP is deleted from its service ID, the mirror association is removed from the mirror source.

More than one SAP can be associated within a single mirror-source. Each SAP has its own ingress and egress parameter keywords to define which packets are mirrored to the mirror destination.

The SAP must be valid and properly configured. If the associated SAP does not exist, an error occurs and the command will not execute.

The same SAP cannot be associated with multiple mirror source definitions for ingress packets.

The same SAP cannot be associated with multiple mirror source definitions for egress packets.

If a particular SAP is not associated with a mirror source name, then that SAP will not have mirroring enabled for that mirror source.

Note that the ingress and egress options cannot be supported at the same time on a CEM encap-type SAP. The options must be configured in either the ingress or egress contexts (applies to the 7750 SR and 7950 XRS).

The no form of this command disables mirroring for the specified SAP. All mirroring for that SAP on ingress and egress is terminated. Mirroring of packets on the SAP can continue if more specific mirror criteria is configured. If the egress or ingress parameter keywords are specified in the no command, only the ingress or egress mirroring condition is removed.

This command creates a service access point (SAP) within an LI configuration. The specified SAP must define a FastE, GigE, or XGigE, or XGigE access port with a dot1q, null, or q-in-q encapsulation type.

When the no form of this command is used on a SAP, the SAP with the specified port and encapsulation parameters is deleted.

This command enables mirroring of traffic ingressing or egressing a service access port (SAP). A SAP that is defined within a mirror destination cannot be used in a mirror source. The mirror source SAP referenced by the sap-id is owned by the service ID of the service in which it was created. The SAP is only referenced in the mirror source name for mirroring purposes. The mirror source association does not need to be removed before deleting the SAP from its service ID. If the SAP is deleted from its service ID, the mirror association is removed from the mirror source.

More than one SAP can be associated within a single mirror-source. Each SAP has its own ingress and egress parameter keywords to define which packets are mirrored to the mirror destination.

The SAP must be valid and properly configured. If the associated SAP does not exist, an error occurs and the command will not execute.

The same SAP cannot be associated with multiple mirror source definitions for ingress packets.

The same SAP cannot be associated with multiple mirror source definitions for egress packets.

If a particular SAP is not associated with a mirror source name, then that SAP will not have mirroring enabled for that mirror source.

Note that the ingress and egress options cannot be supported at the same time on a CEM encap-type SAP. The options must be configured in either the ingress or egress contexts (applies to the 7750 SR and 7950 XRS).

The no form of this command disables mirroring for the specified SAP. All mirroring for that SAP on ingress and egress is terminated. Mirroring of packets on the SAP can continue if more specific mirror criteria is configured. If the egress or ingress parameter keywords are specified in the no command, only the ingress or egress mirroring condition is removed.

This command configures a Service Access Point (SAP) used in satellite local forward instances defined in the system.

The no form of this command removes the satellite access point from the local-forward instance.

This command is used to create or edit a Service Egress QoS policy. The egress policy defines the SLA for service packets as they egress on the SAP.

Policies are templates that can be applied to multiple services as long as the scope of the policy is template. The queues defined in the policy are not instantiated until a policy is applied to a service.

Sap-egress policies determine queue mappings based on ingress DSCP, IP precedence, dot1p, and IPv4 or IPv6 match criteria. Multiple queues can be created per forwarding class and each queue can have different CIR or PIR parameters.

Egress SAP QoS policies allow the definition of queues and the mapping of forwarding classes to those queues. Each queue needs to have a relative CIR for determining its allocation of QoS resources during periods of congestion. A PIR can also be defined that forces a hard limit on the packets transmitted through the queue. When the forwarding class is mapped to the queue, a DSCP, IP precedence, or dot1p value can optionally be specified.

The sap-egress policy with policy-id 1 is the default sap-egress QoS policy and is applied to service egress SAPs when an explicit policy is not specified or removed. The default sap-egress policy cannot be modified or deleted.

By default, all forwarding classes map to queue 1.

Any changes made to an existing policy, using any of the sub-commands, will be applied immediately to all egress SAPs where this policy is applied. For this reason, when many changes are required on a policy, it is highly recommended that the policy be copied to a work area policy-id. That work-in-progress policy can be modified until complete, then written over the original policy-id. Use the config qos copy command to maintain policies in this manner.

The no form of this command deletes the sap-egress policy. A policy cannot be deleted until it is removed from all service SAPs where it is applied. When a sap-egress policy is removed from a SAP, the SAP will revert to the default sap-egress policy-id 1.

This command copies existing QoS policy entries for a QoS policy-id to another QoS policy-id.

The copy command is a configuration-level maintenance tool used to create new policies using existing policies. It also allows bulk modifications to an existing policy with the use of the overwrite keyword.

This command configures the maximum number of ARP hosts per SAP.

The no form of this command reverts to the default.

This command specifies the SAP ID to match for a host lookup. When the LUDB is accessed using a DHCPv4 server, the SAP-ID is matched against the Nokia vendor-specific sub-option in DHCP Option 82.

Note: This command is used only when sap-id is configured as one of the match-list parameters.

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

This command enables the sending of the SAP ID in the Nokia vendor-specific sub-option of the DHCP relay packet.

The no form of this command disables the sending of the SAP ID in the Nokia vendor-specific sub-option of the DHCP relay packet.

This command specifies the dynamic data service SAP that is created. A dynamic service SAP ID uniquely identifies a dynamic data service instance. For a local authenticated dynamic service data trigger, one of the dynamic service SAP IDs must be the data trigger SAP.

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

This command is used to create or edit the ingress policy. The ingress policy defines the SLA enforcement that service packets receive as they ingress a SAP. SLA enforcement is accomplished through the definition of queues that have Forwarding Class (FC), Fair Information Rate (FIR), Committed Information Rate (CIR), Peak Information Rate (PIR), Committed Burst Size (CBS), and Maximum Burst Size (MBS) characteristics.

Policies in effect are templates that can be applied to multiple services as long as the scope of the policy is template. Queues defined in the policy are not instantiated until they are assigned to at least one forwarding class and a policy is applied to a service SAP.

It is possible that a SAP ingress policy will include the dscp map command, the dot1p map command, and an IP or MAC match criteria. When multiple matches occur for the traffic, the order of precedence will be used to arrive at the final action. The order of precedence is as follows:

The SAP ingress policy with policy-id 1 is a system-defined policy applied to services when no other policy is explicitly specified. The system SAP ingress policy cannot be modified or deleted. The default SAP ingress policy defines one unicast and one multipoint queue associated with all forwarding classes, with an FIR of zero, a CIR of zero, and a PIR of line rate.

Any changes made to the existing policy, using any of the sub-commands, are applied immediately to all services where this policy is applied. For this reason, when many changes are required on a policy, it is recommended that the policy be copied to a work area policy ID. That work-in-progress policy can be modified until complete, then written over the original policy-id. Use the config>qos>copy command to maintain policies in this manner.

The no form of this command deletes the SAP ingress policy. A policy cannot be deleted until it is removed from all services where it is applied.

This command copies existing QoS policy entries for a QoS policy-id to another QoS policy-id.

The copy command is a configuration-level maintenance tool used to create new policies using existing policies. It also allows bulk modifications to an existing policy with the use of the overwrite keyword.

This command specifies a limit for the number of dynamic data service instances (SAPs) that can be setup simultaneously using a given dynamic services policy.

A value of zero (0) means the policy is drained: existing dynamic data services can be modified and torn down but no new dynamic data services can be setup.

Commands in this context configure parameters that can be applied to automatically-generated internal SAPs.

This command includes sap-session-index attributes.

The no form of this command excludes sap-session-index attributes.

This command specifies the number of PPPoE hosts per SAP allowed for this group-interface.

The no form of this command reverts to the default.

This command specifies the number of IPoE sessions per SAP allowed for this group-interface.

The no form of this command reverts to the default.

This command specifies the VPLS SAP template that is applied on the internal SAPs created for communication between the VPLS and the ISAs.

The no form of this command removes the SAP template.

This command configures a template that specifies parameters for automatically generated subscriber SAPs, for example, when creating CUPS sessions. A template with the name "default" is used if no specific name is provided, but this must be manually provisioned.

The no form of this command removes the template.

This command configures the binding to a SAP template to be used to instantiate SAPs in the data VPLS using as input variables the VLAN IDs generated by the vid-range command.

The no form of this command removes the binding and deletes the related SAP instances. The command will fail if any of the affected VPLS instances have either a provisioned SAP or an active MVRP declaration/registration or if the related vpls-group is in no shutdown state. Any changes to the sap-template-binding require the vpls-group to be in shutdown state. New control SAP additions to the management VPLS are allowed as long as data VPLS instantiations/removals for vpls-groups are not in progress. Control SAPs can be removed at any time generating the removal of related data SAPs from the data VPLS. The shutdown or no shutdown state for the control SAPs does not have any effect on data SAPs instantiated with this command.

This command configures the type of satellite variant for the associated satellite chassis.

The no form of the command deletes the sat-type configuration.

This command enables the satellite configuration context. Within the satellite context, the administrator can specify the configuration details for a satellite chassis that is hosted by the associated local system.

This command performs satellite operations.

This command is required to save LI configuration parameters.

This command uses the boot option parameters currently in memory and writes them from the boot option file to the specified compact flash.

The BOF must be located in the root directory of the internal or external compact flash drives local to the system and have the mandatory filename of bof.cfg.

If a location is not specified, the BOF is saved to the default compact flash drive (cf3:) on the active CPM (typically the CPM in slot A, but the CPM in slot B could also be acting as the active CPM). The slot name is not case-sensitive. You can use upper or lowercase “A” or “B”.

Command usage:

To save the BOF to a compact flash drive on the standby CPM (for example, the redundant (standby) CPM is installed in slot B), specify -A or -B option.

Command usage:

The slot name is not case-sensitive. You can use upper or lowercase “A” or “B”.

The bof save and show bof commands allow you to save to or read from the compact flash of the standby CPM. Use the show card command to determine the active and standby CPM (A or B).

This command saves the current candidate to a file.

If the optional rescue keyword is not used, this command saves a rollback checkpoint at the location and with the filename specified by the rollback-location with a suffix of .rb. The previously saved checkpoints will have their suffixes incremented by one (.rb.1 becomes .rb.2, and so on). If there are already as many checkpoint files as the maximum number supported, then the last checkpoint file is deleted.

If the rescue keyword is used, then this command saves the current operational configuration as a rescue configuration at the location and with the filename specified by the rescue location. The filename will have the suffix .rc appended.

This command saves the running configuration to a configuration file. For example:

By default, the running configuration is saved to the primary configuration file.

This command saves the script that calculates Deterministic NAT map entries.

Once the location for the Python deterministic NAT script is configured, the script is generated/updated every time deterministic NAT configuration is modified. However, the script must be manually exported to the remote location. This command triggers the export of the script to a remote location.

This command enables saved indicator in the prompt. When changes are made to the configuration file a “*” appears in the prompt string indicating that the changes have not been saved. When an admin save command is executed the “*” disappears.

This command determines profiles for NAT scaling. Lower profile numbers allocate less resources, therefore, supporting lower scaling.

Contact your Nokia representative for more information about NAT scaling figures in each profile.

This command configures the scheduling class for the hardware aggregate shaper scheduler policy.

The no form of this command removes the scheduling class configuration.

This command configures the scheduling class for the hardware aggregate shaper scheduler policy.

The no form of this command removes the scheduling class configuration.

This command configures the scheduling class elevation.

The no form of this command removes the scheduling class elevation configuration.

This command overrides the default minimum time that must elapse before a virtual scheduler may redistribute bandwidth based on changes to the offered rates of member policers or queues. A minimum run interval is enforced to allow a minimum amount of “batching” queue changes before reacting to the changed rates. This minimum interval is beneficial since the periodic function of determining policer or queue offered rates is performed sequentially and the interval allows a number policer and queue rates to be determined prior to determining the distribution of bandwidth to the policers and queues.

The default minimum scheduler run interval is 0.5 seconds. The sched-run-min-int command uses a percent value to modify the default interval.

The no form of this command restores the default minimum scheduler run interval for all virtual schedulers on the card.

This command configures the type of schedule to run, including one-time only (oneshot), periodic or calendar-based runs. All runs are determined by month, day of month or weekday, hour, minute and interval (seconds).

The no form of the command removes the context from the configuration.

This command specifies the schedule type for auto CRL update. The system supports two types:

This command provides a way to override parameters of the existing scheduler associated with the egress or ingress scheduler policy. A scheduler defines bandwidth controls that limit each child (other schedulers and queues) associated with the scheduler. Scheduler objects are created within the hierarchical tiers of the policy. It is assumed that each scheduler created will have queues or other schedulers defined as child associations. The scheduler can be a child (take bandwidth from a scheduler in a higher tier).

The no form of this command reverts to the default.

This command overrides specific attributes of the specified scheduler name.

A scheduler defines a bandwidth control that limits each child (other schedulers, policers and queues) associated with the scheduler. Scheduler objects are created within the hierarchical tiers of the policy. It is assumed that each scheduler created has policers, queues or other schedulers defined as child associations. The scheduler can be a child which takes bandwidth from a scheduler in a higher tier. A total of 32 schedulers can be created within a single scheduler policy with no restriction on the distribution between the tiers.

Each scheduler must have a unique name within the context of the scheduler policy; however the same name can be reused in multiple scheduler policies. If scheduler-name already exists within the policy tier level (regardless of the inclusion of the keyword create), the context changes to that scheduler name for the purpose of editing the scheduler parameters. Modifications made to an existing scheduler are executed on all instantiated schedulers created through association with the policy of the edited scheduler. This can cause policers, queues or schedulers to become orphaned (invalid parent association) and adversely affect the ability of the system to enforce service level agreements (SLAs).

If the scheduler-name exists within the policy on a different tier (regardless of the inclusion of the keyword create), an error occurs and the current CLI context does not change.

If the scheduler-name does not exist in this or another tier within the scheduler policy, it is assumed that an attempt is being made to create a scheduler of that name. The success of the command execution is dependent on the following:

When the maximum number of schedulers has been exceeded on the policy, a configuration error occurs and the command does not execute, nor does the CLI context change.

If the provided scheduler-name is invalid according to the criteria below, a name syntax error occurs, the command does not execute, and the CLI context does not change.

The no form of this command removes the scheduler name from the configuration.

This command can be used to override specific attributes of the specified scheduler name. A scheduler defines bandwidth controls that limit each child (other schedulers and queues) associated with the scheduler. Scheduler objects are created within the hierarchical tiers of the policy. It is assumed that each scheduler created will have queues or other schedulers defined as child associations. The scheduler can be a child which takes bandwidth from a scheduler in a higher tier. A total of 32 schedulers can be created within a single scheduler policy with no restriction on the distribution between the tiers. The scheduler-name must exist in the applied scheduler policy.

The no form of this command removes the scheduler overrides for the specified scheduler and returns the scheduler’s parent weight and CIR weight, and its PIR and CIR to the values configured in the applied scheduler policy.

This command can be used to override specific attributes of the specified scheduler name. A scheduler defines bandwidth controls that limit each child (other schedulers, policers, and queues) associated with the scheduler. Scheduler objects are created within the hierarchical tiers of the policy. It is assumed that each scheduler created will have policers, queues or other schedulers defined as child associations. The scheduler can be a child which takes bandwidth from a scheduler in a higher tier. A total of 32 schedulers can be created within a single scheduler policy with no restriction on the distribution between the tiers.

Each scheduler must have a unique name within the context of the scheduler policy; however the same name can be reused in multiple scheduler policies. If scheduler-name already exists within the policy tier level (regardless of the inclusion of the keyword create), the context changes to that scheduler name for the purpose of editing the scheduler parameters. Modifications made to an existing scheduler are executed on all instantiated schedulers created through association with the policy of the edited scheduler. This can cause policers, queues, or schedulers to become orphaned (invalid parent association) and adversely affect the ability of the system to enforce service level agreements (SLAs).

If the scheduler-name exists within the policy on a different tier (regardless of the inclusion of the keyword create), an error occurs and the current CLI context will not change.

If the scheduler-name does not exist in this or another tier within the scheduler policy, it is assumed that an attempt is being made to create a scheduler of that name. The success of the command execution is dependent on the following:

When the maximum number of schedulers has been exceeded on the policy, a configuration error occurs and the command will not execute, nor will the CLI context change.

If the provided scheduler-name is invalid according to the following criteria, a name syntax error will occur, the command will not execute, and the CLI context will not change.

This command can be used to override specific attributes of the specified scheduler name.

A scheduler defines a bandwidth controls that limit each child (other schedulers, policers, and queues) associated with the scheduler. Scheduler objects are created within the hierarchical tiers of the policy. It is assumed that each scheduler created will have policers, queues, or other schedulers defined as child associations. The scheduler can be a child which takes bandwidth from a scheduler in a higher tier. A total of 32 schedulers can be created within a single scheduler policy with no restriction on the distribution between the tiers.

Each scheduler must have a unique name within the context of the scheduler policy; however the same name can be reused in multiple scheduler policies. If scheduler-name already exists within the policy tier level (regardless of the inclusion of the keyword create), the context changes to that scheduler name for the purpose of editing the scheduler parameters. Modifications made to an existing scheduler are executed on all instantiated schedulers created through association with the policy of the edited scheduler. This can cause queues or schedulers to become orphaned (invalid parent association) and adversely affect the ability of the system to enforce service level agreements (SLAs).

If the scheduler-name exists within the policy on a different tier (regardless of the inclusion of the keyword create), an error occurs and the current CLI context will not change.

If the scheduler-name does not exist in this or another tier within the scheduler policy, it is assumed that an attempt is being made to create a scheduler of that name. The success of the command execution is dependent on the following:

When the maximum number of schedulers has been exceeded on the policy, a configuration error occurs and the command will not execute, nor will the CLI context change.

If the provided scheduler-name is invalid according to the criteria below, a name syntax error will occur, the command will not execute, and the CLI context will not change.

This command can be used to override specific attributes of the specified scheduler name.

A scheduler defines a bandwidth controls that limit each child (other schedulers, policers, and queues) associated with the scheduler. Scheduler objects are created within the hierarchical tiers of the policy. It is assumed that each scheduler created will have policers, queues, or other schedulers defined as child associations. The scheduler can be a child which takes bandwidth from a scheduler in a higher tier. A total of 32 schedulers can be created within a single scheduler policy with no restriction on the distribution between the tiers.

Each scheduler must have a unique name within the context of the scheduler policy; however the same name can be reused in multiple scheduler policies. If scheduler-name already exists within the policy tier level (regardless of the inclusion of the keyword create), the context changes to that scheduler name for the purpose of editing the scheduler parameters. Modifications made to an existing scheduler are executed on all instantiated schedulers created through association with the policy of the edited scheduler. This can cause queues or schedulers to become orphaned (invalid parent association) and adversely affect the ability of the system to enforce service level agreements (SLAs).

If the scheduler-name exists within the policy on a different tier (regardless of the inclusion of the keyword create), an error occurs and the current CLI context will not change.

If the scheduler-name does not exist in this or another tier within the scheduler policy, it is assumed that an attempt is being made to create a scheduler of that name. The success of the command execution is dependent on the following:

When the maximum number of schedulers has been exceeded on the policy, a configuration error occurs and the command will not execute, nor will the CLI context change.

If the provided scheduler-name is invalid according to the criteria below, a name syntax error will occur, the command will not execute, and the CLI context will not change.

This command creates a new scheduler or edits an existing scheduler within the scheduler policy tier. A scheduler defines bandwidth controls that limit each child (other schedulers and queues) associated with the scheduler. Scheduler objects are created within the hierarchical tiers of the policy. It is assumed that each scheduler created will have queues or other schedulers defined as child associations. The scheduler can be a child which takes bandwidth from a scheduler in a higher tier. A total of 32 schedulers can be created within a single scheduler policy with no restriction on the distribution between the tiers.

Each scheduler must have a unique name within the context of the scheduler policy; however, the same name can be reused in multiple scheduler policies. If scheduler-name already exists within the policy tier level (regardless of the inclusion of the keyword create), the context changes to that scheduler name for the purpose of editing the scheduler parameters. Modifications made to an existing scheduler are executed on all instantiated schedulers created through association with the policy of the edited scheduler. This can cause queues or schedulers to become orphaned (invalid parent association) and adversely affect the ability of the system to enforce SLAs.

If the scheduler-name exists within the policy on a different tier (regardless of the inclusion of the keyword create), an error occurs and the current CLI context will not change.

If the scheduler-name does not exist in this or another tier within the scheduler policy, it is assumed that an attempt is being made to create a scheduler of that name. The success of the command execution is dependent on the following:

When the maximum number of schedulers has been exceeded on the policy, a configuration error occurs, the command will not execute, nor will the CLI context change.

If the provided scheduler-name is invalid according to the criteria below, a name syntax error will occur, the command will not execute, and the CLI context will not change.

This command override specifics attributes of the specified scheduler name.

A scheduler defines bandwidth controls that limit each child (other schedulers, policers and queues) associated with the scheduler. Scheduler objects are created within the hierarchical tiers of the policy. It is assumed that each scheduler created will have policers, queues or other schedulers defined as child associations. The scheduler can be a child which takes bandwidth from a scheduler in a higher tier. A total of 32 schedulers can be created within a single scheduler policy with no restriction on the distribution between the tiers.

Each scheduler must have a unique name within the context of the scheduler policy; however the same name can be reused in multiple scheduler policies. If scheduler-name already exists within the policy tier level (regardless of the inclusion of the keyword create), the context changes to that scheduler name for the purpose of editing the scheduler parameters. Modifications made to an existing scheduler are executed on all instantiated schedulers created through association with the policy of the edited scheduler. This can cause policer, queues or schedulers to become orphaned (invalid parent association) and adversely affect the ability of the system to enforce service level agreements (SLAs).

If the scheduler-name exists within the policy on a different tier (regardless of the inclusion of the keyword create), an error occurs and the current CLI context will not change.

If the scheduler-name does not exist in this or another tier within the scheduler policy, it is assumed that an attempt is being made to create a scheduler of that name. The success of the command execution is dependent on the following:

When the maximum number of schedulers has been exceeded on the policy, a configuration error occurs and the command will not execute, nor will the CLI context change.

If the provided scheduler-name is invalid according to the criteria below, a name syntax error will occur, the command will not execute, and the CLI context will not change.

The no form of the command disables the scheduler override.

This command provides a way to override parameters of the existing scheduler associated with the egress scheduler policy. A scheduler defines bandwidth controls that limit each child (other schedulers and queues) associated with the scheduler. Scheduler objects are created within the hierarchical tiers of the policy. It is assumed that each scheduler created will have queues or other schedulers defined as child associations. The scheduler can be a child (take bandwidth from a scheduler in a higher tier).

The no form of this command reverts to the default.

Commands in this context configure the set of attributes whose values have been overridden via management on this virtual scheduler. Clearing a given flag returns the corresponding overridden attribute to the value defined on the SAP's ingress scheduler policy.

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

This command specifies the set of attributes whose values have been overridden by management on this virtual scheduler. Clearing a given flag will return the corresponding overridden attribute to the value defined on the ingress or egress queue group template.

The no form of this command removes all of the scheduler overrides and returns the scheduler’s parent weight and CIR weight, and its PIR and CIR to the values configured in the applied scheduler policy.

This command specifies the set of attributes whose values have been overridden by management on this virtual scheduler. Clearing a given flag will return the corresponding overridden attribute to the value defined on the SAP's ingress scheduler policy.

This command specifies the set of attributes whose values have been overridden via management on this virtual scheduler. Clearing a given flag will return the corresponding overridden attribute to the value defined on the SAP's ingress scheduler policy.

This command specifies the set of attributes whose values have been overridden via management on this virtual scheduler. Clearing a given flag will return the corresponding overridden attribute to the value defined on the SAP's ingress scheduler policy.

This command specifies the set of attributes whose values have been overridden by management on this virtual scheduler. Clearing a given flag will return the corresponding overridden attribute to the value defined on the SAP's ingress and egress scheduler policy.

The no form of the command disables the override.

This command defines an optional parent scheduler that governs the available bandwidth given to a policer in addition to the PIR setting of the policer. When multiple schedulers, queues, or policers share a child status with the parent scheduler, the weight or level parameters define how this policer contends with the other children for the bandwidth of the parent. This command and the configuration of a SAP policer port-parent or parent arbiter are mutually exclusive.

Multiple schedulers can exist in different scheduler policies with the same scheduler-name; in this command, the associated scheduler-name pertains to a scheduler that should exist on the SAP as the policy is applied and the policer is created. When the policer is created on the SAP, the existence of the scheduler-name is dependent on a scheduler policy containing the scheduler-name being directly applied or indirectly applied (through a multiservice customer site) to the SAP. The policer accepts packets, but is not bandwidth limited by a virtual scheduler or the scheduler hierarchy applied to the SAP. The SAP to which the policer belongs displays an orphan policer status with the SapEgressPolicerMismatch flag in the show service sap-using output. The orphaned state of the policer is automatically cleared when the scheduler-name becomes available on the SAP.

The parent scheduler can be made unavailable by the removal of a scheduler policy or scheduler. When an existing parent scheduler is removed or inoperative, the policer enters the orphaned state. The policer automatically returns to normal operation when the parent scheduler is available again.

The no form of this command removes a child association with a parent scheduler. If a parent association does not currently exist, the command has no effect and no error message is returned. When a parent association has been removed, the former child policer attempts to operate based on its configured rate parameter.

Removing the parent association on the policer within the policy takes effect immediately on all policers using the SAP QoS policy.

This command defines an optional parent scheduler that governs the available bandwidth given to a policer in addition to the PIR setting of the policer. When multiple schedulers, queues, or policers share a child status with the parent scheduler, the weight or level parameters define how this policer contends with the other children for the bandwidth of the parent. This command and the configuration of a SAP policer scheduler-parent or parent arbiter are mutually exclusive.

Multiple schedulers can exist in different scheduler policies with the same scheduler-name; in this command, the associated scheduler-name pertains to a scheduler that should exist on the SAP as the policy is applied and the policer is created. When the policer is created on the SAP, the existence of the scheduler-name is dependent on a scheduler policy containing the scheduler-name being directly applied or indirectly applied (through a multiservice customer site) to the SAP. The policer accepts packets, but is not bandwidth limited by a virtual scheduler or the scheduler hierarchy applied to the SAP.

The parent scheduler can be made unavailable by the removal of a scheduler policy or scheduler. When an existing parent scheduler is removed or inoperative, the policer enters the orphaned state. The policer automatically returns to normal operation when the parent scheduler is available again.

The no form of this command removes a child association with a parent scheduler. If a parent association does not currently exist, the command has no effect and no error message is returned. When a parent association has been removed, the former child policer attempts to operate based on its configured rate parameter.

Removing the parent association on the policer within the policy takes effect immediately on all policers using the SAP QoS policy.

This command specifies a scheduler policy to associate to the sla profile. Scheduler policies are configured in the configure>qos>scheduler>policy context. Each scheduler policy is divided up into groups of schedulers based on the tier each scheduler is created under. A tier is used to give structure to the schedulers within a policy and define rules for parent scheduler associations. The policy defines the hierarchy and operating parameters for virtual schedulers.

The no form of this command removes the scheduler-policy-name from the configuration.

This command specifies a scheduler policy to associate to the subscriber profile. Scheduler policies are configured in the configure>qos>scheduler>policy context. Each scheduler policy is divided up into groups of schedulers based on the tier each scheduler is created under. A tier is used to give structure to the schedulers within a policy and define rules for parent scheduler associations. The policy defines the hierarchy and operating parameters for virtual schedulers.

The no form of this command reverts to the default.

This command applies an existing scheduler policy to an ingress or egress scheduler used by ingress SAP queues or egress SAP policers and queues associated with this multi-service customer site. The schedulers defined in the scheduler policy can only be created once the customer site has been appropriately assigned to a chassis port, channel or slot. Scheduler policies are defined in the config>qos>scheduler-policy scheduler-policy-name context.

The no form of this command removes the configured ingress or egress scheduler policy from the multi-service customer site. When the policy is removed, the schedulers created due to the policy are removed also making them unavailable for the SAP policers or queues associated with the customer site. Policers and queues that lose their parent scheduler association are deemed to be orphaned and are no longer subject to a virtual scheduler. The SAPs that have policers or queues reliant on the removed schedulers enter into an operational state depicting the orphaned status of one or more policers or queues. When the no form of this command executed, the customer site ingress or egress node will not contain an applied scheduler policy.

This command specifies a scheduler policy to associate to the Vport. Scheduler policies are configured in the configure>qos>scheduler>policy context. Each scheduler policy is divided up into groups of schedulers based on the tier each scheduler is created under. A tier is used to give structure to the schedulers within a policy and define rules for parent scheduler associations. The policy defines the hierarchy and operating parameters for virtual schedulers.

The no form of this command removes the configured egress scheduler policy from the Vport.

The agg-rate rate, port-scheduler-policy and scheduler-policy commands are mutually exclusive. Changing between the use of a scheduler policy and the use of an agg-rate/port-scheduler-policy involves removing the existing command and applying the new command.

The configuration of a scheduler policy under a Vport is mutually exclusive with the configuration of the egress-rate-modify parameter.

The no form of this command reverts to the default.

This command applies an existing scheduler policy to an ingress or egress scheduler used by SAP queues associated with this multi-service customer site. The schedulers defined in the scheduler policy can only be created once the customer site has been appropriately assigned to a chassis port, channel or slot. Scheduler policies are defined in the config>qos>scheduler-policy scheduler-policy-name context.

The no form of this command removes the configured ingress or egress scheduler policy from the multi-service customer site. When the policy is removed, the schedulers created due to the policy are removed also making them unavailable for the ingress SAP queues and egress SAP policers and queues associated with the customer site. Policers and queues that lose their parent scheduler association are deemed to be orphaned and are no longer subject to a virtual scheduler. The SAPs that have policers or queues reliant on the removed schedulers enter into an operational state depicting the orphaned status of one or more policers or queues. When the no scheduler-policy command is executed, the customer site’s ingress or egress node will not contain an applied scheduler policy.

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

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

This command configures a scheduler policy for the egress queue group.

This command applies an existing scheduler policy to an ingress or egress scheduler used by SAP queues associated with this multi-service customer site. The schedulers defined in the scheduler policy can only be created when the customer site has been appropriately assigned to a chassis port, channel or slot. Scheduler policies are defined in the config>qos>scheduler-policy scheduler-policy-name context.

The no form of this command removes the configured ingress or egress scheduler policy from the multi-service customer site. When the policy is removed, the schedulers created due to the policy are removed also making them unavailable for the ingress SAP queues associated with the customer site. Policers or queues that lose their parent scheduler association are deemed to be orphaned and are no longer subject to a virtual scheduler. The SAPs that have policers or queues reliant on the removed schedulers enter into an operational state depicting the orphaned status of one or more policers or queues. When the no scheduler-policy command is executed, the customer site ingress or egress node will not contain an applied scheduler policy.

This command configures the scheduler policy.

Each scheduler policy is divided up into groups of schedulers based on the tier each scheduler is created under. A tier is used to give structure to the schedulers within a policy and define rules for parent scheduler associations.

The scheduler-policy command creates a scheduler policy or allows editing of an existing policy. The policy defines the hierarchy and operating parameters for virtual schedulers. Creating a policy does not create the schedulers; it only provides a template for the schedulers to be created when the policy is associated with a SAP or multiservice site.

Each scheduler policy must have a unique name within the context of the system. Modifications made to an existing policy are executed on all schedulers that use the policy. This can cause queues or schedulers to become orphaned (invalid parent association) and adversely affect the ability of the system to enforce SLAs.

If a scheduler-policy-name does not exist, it is assumed that an attempt is being made to create a new policy. The success of the command execution is dependent on the following:

When the maximum number of scheduler policies has been exceeded, a configuration error occurs, the command will not execute, and the CLI context will not change.

If the provided scheduler-policy-name is invalid according to the criteria below, a name syntax error occurs, the command will not execute, and the CLI context will not change.

This command applies an existing scheduler policy to an ingress or egress scheduler used by SAP queues or, at egress only, policers associated with this multi-service customer site. The schedulers defined in the scheduler policy can only be created once the customer site has been appropriately assigned to a chassis port, channel or slot. Scheduler policies are defined in the config>qos>scheduler-policy scheduler-policy-name context.

The no form of this command removes the configured ingress or egress scheduler policy from the multi-service customer site. When the policy is removed, the schedulers created due to the policy are removed also making them unavailable for the SAP policers and queues associated with the customer site. Policers and queues that lose their parent scheduler association are deemed to be orphaned and are no longer subject to a virtual scheduler.

The SAPs that have ingress queues reliant on the removed schedulers enter into an operational state depicting the orphaned status of one or more policers and queues. When the no scheduler-policy command is executed, the customer site ingress or egress node will not contain an applied scheduler policy.

This command copies existing QoS policy entries for a QoS policy to another QoS policy.

The copy command is a configuration-level maintenance tool used to create new policies using existing policies. It also allows bulk modifications to an existing policy with the use of the overwrite keyword.

If overwrite is not specified, an error will occur if the destination policy exists.

This command overrides the scheduling class configuration in the HS scheduler policy applied to the port egress. The scheduling class rate or weight within the WRR group can be overridden.

The no form of this command removes the scheduling class override parameters from the port egress configuration.

This command specifies the scheduling class to use for this SAP.

This command specifies the scheduling class to use for this SAP. This object is only applicable for a SAP whose bundle type is set to MLFR.

This command assigns a Frame Relay scheduling class for a Frame Relay SAP. The scheduling class dictates which queue the frame or frame fragments are stored in FRF.12 end-to-end fragmentation, FRF.12 UNI/NNI link fragmentation and MLFR applications.

This command specifies the scheduling class to use for this SAP.

This command configures the behavior of a specific scheduling class on all HSQ schedulers associated with the policy. The scheduler-class command performs one of two operations: it configures a maximum rate for the scheduling class or places the scheduling class into the weighted scheduling group. The two operations are mutually exclusive.

By default, none of the scheduling classes are members of the weighted scheduling group and each class is set to a rate limit of max (no rate limit applied).

Specifying Scheduling Class Rate (or Removing the Scheduling Class from Group) — If the scheduling-class command is executed with the rate keyword specified, either max or a specified rate value must follow. If a class-id was previously mapped into the weighted scheduling group, the class is removed from the group. However, if removing the class from the group causes the group to no longer have contiguous class members, the command fails with no effect on the specified class. A “non-contiguous grouping error” is returned. The lowest or highest members within a weighted group must be removed prior to removing the middle members. For example, if scheduling classes 3, 4, and 5 were members of weighted group 1, class 4 cannot be removed first.

This command using the rate keyword also fails when an override for the group weight is in place on the scheduling class within a scheduler associated with the policy. The override expects the class to be associated with a weighted scheduling group and the policy rate definition is attempting to remove the class from the group. An “override mismatch” error is generated, specifying the scheduling object where the override exists.

After a rate has been successfully defined for a scheduling class, the specified rate is automatically updated on all HSQ scheduler instances associated with the scheduling policy. The exception is where the scheduler instance has a local override for the rate on the scheduling class.

Specifying Scheduling Class Weighted Group Membership — If the scheduling-class command is executed with the group keyword specified, the group ID value of 1 must follow. The corresponding optional weight keyword is used to specify the weight of the scheduling class within the group. If weight is not specified, the default weight of 1 is used. If the specified scheduling class is not contiguous with the other scheduling classes in the group, the command fails with no change to the current state of the scheduling class and a “non-contiguous grouping” error is returned, specifying the weighted scheduling group and the current group members.

The scheduling-class command fails using the group keyword when a rate override for the scheduling class exists on an HSQ scheduler instance associated with the policy. The rate override for the scheduling class indicates the class is directly attached to a strict priority level, conflicting with the policy group keyword trying to place the class in the specified group. The command fails without affecting the scheduling class definition on the policy and returns an error specifying the scheduling object where the override exists.

Other Override Constraints — The scheduling overrides cannot change or remove a scheduling class from a policy-defined weighted group membership.

The no form of the command returns the scheduling class represented by class-id to the default behavior. The default behavior for a scheduling class is to not be a member of the weighted scheduling class group and have a rate set to max. The no scheduling-class command fails if the scheduling class is currently a member of the weighted scheduling class group and a weight override is in effect on a scheduling object for the class, in which case an error is returned.

This command defines a schema path where the SR OS YANG modules can be manually copied by the user prior to using a <get-schema> request.

By default, no schema path is configured, and the software upgrade process manages the YANG schema files to ensure they are synchronized with the software image on both the primary and standby CPM.

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

This command configures the filter policy scope as exclusive or template. If the scope of the policy is template and is applied to one or more services, the scope cannot be changed.

The no form of this command sets the scope of the policy to the default of template.

This command configures the Service Ingress QoS policy scope as exclusive or template.

The policy’s scope cannot be changed if the policy is applied to a service.

The no form of this command sets the scope of the policy to the default of template.

Enter the scope of this policy. The scope of the policy cannot be changed if the policy is applied to one or more services.

The no form of this command sets the scope of the policy to the default of template.

This command configures the network policy scope as exclusive or template. The policy’s scope cannot be changed if the policy is applied to an interface.

The no form of this command sets the scope of the policy to the default of template.

This command configures the filter policy scope as exclusive, template, embedded or system.

The scope of the policy cannot be changed when:

Changing the scope to/from system is only allowed when a policy is not active and the policy has no entries configured.

The no form of the command sets the scope of the policy to the default of template.

This command copies a local file to a remote host file system. It uses ssh for data transfer, and uses the same authentication and provides the same security as ssh. The following prompt appears:

“Are you sure (y/n)?” The destination must specify a user and a host.

This command enables payload scrambling on channel groups.

Scrambling randomizes the pattern of 1s and 0s carried in a SONET frame. Rearranging or scrambling the pattern prevents continuous strings of all 1s or all 0s and meets the needs of physical layer protocols that rely on sufficient transitions between 1s and 0s to maintain clocking.

For ATM, this command enables or disables ATM cell-level payload scrambling/descrambling using x43+1 polynomial as defined in ITU-T I.432.1. Scrambling is enabled by default for the ATM path/channel. Note that this scrambling is done in addition to SONET/SDH frame scrambling/descrambling, which is always enabled in the framer.

The no form of this command disables scrambling.

This command enables SONET/SDH payload scrambling. Scrambling randomizes the pattern of 1s and 0s carried in a SONET frame. Rearranging or scrambling the pattern prevents continuous strings of all 1s or all 0s and meets the needs of physical layer protocols that rely on sufficient transitions between 1s and 0s to maintain clocking.

For ATM, this command enables or disables ATM cell-level payload scrambling/descrambling using x43+1 polynomial as defined in ITU-T I.432.1. Scrambling is enabled by default for the ATM path/channel. Note that this scrambling is done in addition to SONET/SDH frame scrambling/descrambling, which is always enabled in the framer.

The no form of this command disables scrambling.

Commands in this context configure dynamic services script debugging for a specific script.

This command is used to configure a script to be run.

The no form of the command removes the script.

This command enables the script-compile-error, script-export-variables, script-output, script-output-on-error, and script-runtime-error functionalities.

This command enables the script-compile-error, script-export-variables, script-output, script-output-on-error, and script-runtime-error functionalities.

This command sends the traceback of the compile error to the logger. The traceback contains detailed information about where and why the compilation fails. The compilation takes place when the CLI user changes the admin state of the Python script from shutdown to no shutdown.

This command send the traceback of the compile error to the logger. The traceback contains detailed information about where and why the compilation fails. The compilation takes place when the CLI user changes the admin state of the Python URL from shutdown to no-shutdown.

The no form of this command disables debugging.

Commands in this context configure command script parameters.

This command sends the output variables of the Python script to the logger when the script ran successfully.

This command sends the result (the three output variables) of the Python script to the logger when the script ran successfully.

The no form of this command disables debugging.

This command sends the output (such as from print statements) of the Python script to the logger.

This command sends the output (such as from 'print' statements) of the Python script to the logger.

The no form of this command disables debugging.

This command sends the output (such as traceback data) of the Python script to the logger, only when the script fails.

This command sends the output (such as from print statements) of the Python script to the logger, but only when the script fails.

The no form of this command disables debugging.

This command specifies the first part of parameters as input to the dynamic data service Python script. The concatenation of all four script-parameters strings are passed to the Python script and must be formatted as function-key <dictionary>. The function-key specifies which Python functions is called, and <dictionary> contains the actual parameters in a Python dictionary structure format. The no form of this command removes script-parameters-1 from the configuration.

This command specifies the second part of parameters as input to the dynamic data service Python script. The concatenation of all four script-parameters strings are passed to the Python script and must be formatted as function-key <dictionary>. The function-key specifies which Python functions is called, and <dictionary> contains the actual parameters in a Python dictionary structure format. The no form of this command removes the script-parameters-2 from the configuration.

This command specifies the third part of parameters as input to the dynamic data service Python script. The concatenation of all four script-parameters strings are passed to the Python script and must be formatted as function-key <dictionary>. The function-key specifies which Python functions is called, and <dictionary> contains the actual parameters in a Python dictionary structure format. The no form of this command removes the script-parameters-3 from the configuration.

This command specifies the fourth part of parameters as input to the dynamic data service Python script. The concatenation of all four script-parameters strings are passed to the Python script and must be formatted as function-key <dictionary>. The function-key specifies which Python functions is called, and <dictionary> contains the actual parameters in a Python dictionary structure format. The no form of this command removes the script-parameters-4 from the configuration.

This command specifies the radius script policy to be used to setup the dynamic data services. The script-policy configuration cannot be changed when there are active dynamic data services referencing the policy.

The no form of this command removes the script-policy from the configuration. This is only allowed when there are no active dynamic data services referencing this policy.

This command is used to configure the CLI script policy.

This command is used to configure the CLI script policy.

This command configures the script policy parameters to use for this EHS handler action-list entry. The associated script is launched when the handler is triggered.

This command generates log information when detecting a script runtime error.

This command sends the traceback of the Python script failure to the logger.

The no form of this command disables debugging.

This command configures the URL of the primary script.

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

Specifies the URL of the secondary script to change RADIUS attributes of the RADIUS message.

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

This command specifies the URL of the identification scripts.

The no form of this command reverts to the default.

This command configures the URL of the script used by the http notification policy.

The no form of this command removes the script URL from the http-notification policy.

Commands in this context configure dynamic services script debugging.

This command enables the debug of the VSD fully dynamic integration scripts.

Commands in this context configure SCTE 30 parameters.

This command specifies whether the Society of Cable Telecommunications Engineers 35 (SCTE 35) cue avails in the stream need to be forwarded or not. When specified to forward, SCTE 35 messages will be forwarded downstream. When specified to drop, SCTE 35 messages will not be forwarded downstream. They will be still be processed for local splicing decisions.

This command assigns an existing SCTP filter as an action on flows matching this AQP entry.

The no form of this command removes this SCTP filter from actions on flows matching this AQP entry.

This command configures TCA generation for an SCTP filter.

Commands in this context configure Stream Control Transmission Protocol (SCTP) parameters.

The no form of this command removes this filter.

This command configures whether to include or exclude SCTP filter admit-deny statistics in accounting records.

Commands in this context configure within a video interface policy the properties relating to requests received by the video interface for Standard Definition (SD) channel requests.

If the pre-FEC error rate of the associated DWDM port crosses the configured sd-threshold, this offset-value is added to the IS-IS interface metric. This parameter is only effective if the interface is associated with a DWDM port and the sd-threshold value is configured under that port.

The no form of this command reverts the offset value to 0.

If the pre-FEC error rate of the associated DWDM port crosses the configured sd-threshold, this offset-value is added to the IS-IS interface metric. This parameter is only effective if the interface is associated with a DWDM port and the sd-threshold value is configured under that port.

The no form of this command reverts the offset value to 0.

This command defines the error rate at which to declare the signal degrade (SD) condition.

The parameters define an error rate of (coefficient/10) * 10E-threshold. For example, sd-threshold 5 coefficient 20 defines an error rate of (20/10) * 10E-5, or 2 * 10E-5, or 0.000 02.

The SD threshold must be:

The coefficient parameter is only used when sf-sd-method is set to fec. When sf-sd-method is set to bip8, coefficient is considered to have the value of 10.