This command enables the context to configure admit-deny statistics generation.

This commands creates a new AA interface within an IES or VPRN service. It is used by the aa-isa to send/receive IPv4 traffic. In the context of ICAP url-filtering this interface is used by the ISA to establish ICAP TCP connections to the ICAP servers.

This interface supports /31 subnet only, and uses by default .1q encapsulation.

The system will automatically configure the ISA IP address based on the address configured by the operator under the aa-interface object (which represents the ISA sap facing interface on the ISA).

This command enables the context to configure information for this custom record.

The no form of this command excludes aa-specific attributes in the AA subscriber's custom record.

This command specifies a Service Access Point (SAP) or an ESM subscriber as matching criteria.

The no form of this command removes the SAP or ESM matching criteria.

This command enables the context to configure accounting and statistics collection parameters per application assurance subscribers.

This command adds an existing subscriber identification to a group of special study subscribers (for example, subscribers for which per subscriber statistics and accounting records can be collected for protocols and applications of application assurance).

The no form of this command removes the subscriber from the special study subscribers.

Up to 100 subscribers can be configured into the special study group for protocols and up to a 100 potentially different subscribers can be configured into the special study group for applications.

When adding a subscriber to the special study group, accounting records and statistics generation will commence immediately. When removing a subscriber from the group, special study statistics and accounting records for that subscriber in the current interval will be lost.

This command configures a transit prefix policy entry subscriber.

The no form of this command removes the transit subscriber name from the transit prefix policy configuration.

This command enables the context to configure aa-specific attributes such as aa-sub-attributes and counters that will be available in the AA subscriber's custom record.

The no form of this command excludes aa specific attributes from the AA subscriber's custom record.

This command enables the context to configure Non-Location Based DEM (NLB-DEM) parameters.

Note: NLB-DEM and Access-Network Location (ANL) DEM mode are mutually exclusive, and cannot operate simultaneously.

This command enables the context to configure subscriber counter information. This command only applies to the 7750 SR.

The no form of this command excludes the aa-sub-counters attributes in the AA subscriber's custom record.

This command configures a transit prefix subscriber ip address prefix. It is used when the site is on the local side, being the same side of the system as the parent SAP. The local aa-sub-ip addresses represent the src-IP in the from-SAP direction and dest-IP in the to-SAP direction.

The no form of this command deletes the aa-sub-ip address assigned from the entry configuration.

This command specifies whether or not the from subscriber and to subscriber traffic direction is reversed for this group-partition.

This command enables the context to configure accounting and statistics collection parameters per application assurance special study subscribers.

This command configures an app-profile as “aa-sub-suppressible”, this function is used in the context of an SRRP group interface. If an SRRP group interface is configured as “suppress-aa-sub” then subscribers with an app-profile configured as “aa-sub-suppressible” will not be diverted to Application Assurance.

The no form of this command restores the default behavior.

This command specifies the tethering state of the subscriber where the AQP match entry will be applied.

The tethering state match condition is meaningful when configured in non-default subscriber policy AQP. Default subscriber policy consists of those AQPs that include match criteria based on the subscriber’s configuration. Tethering state match condition is also applicable in those AQPs that include matching criteria that are derived from actual subscriber’s traffic.

The no form of this command removes detection of sub-tethering state from the configuration.

This command enters the context to configure authentication, authorization, and accounting.

This command enters the context to configure AAA on the VPRN.

This command enables the configuration of AAL5 end-of-message (EOM) to be an indication to complete the cell concatenation operation.

The no form of this command resets the configuration to ignore the AAL5 EOM as an indication to complete the cell concatenation.

This command associates an AARP instance with a multi-homed SAP or spoke SDP. This instance uses the same AARP ID in the same node to provide traffic flow and packet asymmetry removal for a multi-homed SAP or spoke SDP.

The type specifies the role of this service point in the AARP: either, primary (dual-homed) or secondary (dual-homed-secondary). The AA service attributes (app-profile and transit-policy) of the primary are inherited by the secondary endpoints. All endpoints within an AARP must be of the same type (SAP or spoke), and all endpoints with an AARP must be within the same service.

The no form of this command removes the association between an AARP instance and a multi-homed SAP or spoke SDP.

This command associates an AARP instance to an Ipipe spoke SDP. This instance is paired with the same aarp-id in a peer node as part of a configuration to provide flow and packet asymmetry removal for traffic for a multi-homed SAP or spoke SDP. The type parameter specifies the role of this service point in the AARP instance.

The no form of this command removes the association.

This command associates an AARP instance to an AARP interface spoke SDP. This instance is paired with the same aarp-id in a peer node as part of a configuration to provide flow and packet asymmetry removal for traffic for a multi-homed SAP or spoke SDP. The type parameter specifies the role of this service point in the AARP instance.

The no form of this command removes the association.

This command associates an AARP instance with a multi-homed SAP or spoke SDP. This instance uses the same AARP ID in the same node or in a peer node (pre-configured) to provide traffic flow and packet asymmetry removal for a multi-homed SAP or spoke SDP.

The type specifies the role of this service point in the AARP: either, primary (dual-homed) or secondary (dual-homed-secondary). The AA service attributes (app-profile and transit-policy) of the primary are inherited by the secondary endpoints. All endpoints within an AARP must be of the same type (SAP or spoke), and all endpoints with an AARP must be within the same service.

The no form of this command removes the association between an AARP instance and a multi-homed SAP or spoke SDP.

This command associates an AARP instance to an AARP interface spoke SDP. This instance is paired with the same aarp-id in a peer node as part of a configuration to provide flow and packet asymmetry removal for traffic for a multi-homed SAP or spoke SDP. The type parameter specifies the role of this service point in the AARP instance.

The no form of this command removes the association.

This command associates an AARP instance with a multi-homed SAP or spoke SDP. This instance uses the same AARP ID in the same node or in a peer node (pre-configured) to provide traffic flow and packet asymmetry removal for a multi-homed SAP or spoke SDP.

The type specifies the role of this service point in the AARP: either, primary (dual-homed) or secondary (dual-homed-secondary). The AA service attributes (app-profile and transit-policy) of the primary are inherited by the secondary endpoints. All endpoints within an AARP must be of the same type (SAP or spoke), and all endpoints with an AARP must be within the same service.

The no form of this command removes the association between an AARP instance and a multi-homed SAP or spoke SDP.

This command defines an Application Assurance Redundancy Protocol (AARP) instance. This instance is paired with the same aarpId in a peer node as part of a configuration to provide flow and packet asymmetry removal for traffic for a multi-homed SAP or spoke SDP.

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

This command creates an AARP interface for connecting a service to a peer node AARP service. This instance is paired with the same AARP interface in a peer node as part of a configuration to provide flow and packet asymmetry removal for traffic for a multi-homed SAP or spoke SDP.

The no form of this command deletes the interface.

This command creates an AARP interface for connecting a service to a peer node AARP service. This instance is paired with the same AARP interface in a peer node as part of a configuration to provide flow and packet asymmetry removal for traffic for a multi-homed SAP or spoke SDP.

The no form of this command deletes the interface.

This command ends the current editing session and aborts any changes entered during this policy editing session.

This command discards the changes made to a BFD template during an active session.

This command discards the changes made to route next-hop templates during an active session.

This command is required to discard changes that have been made to the synchronous interface timing configuration during a session.

This command is required to discard changes made to a route policy.

This command enters the context to edit the parameters that control the child's above-offered-allowance bandwidth. These parameters are only applicable when the port scheduler is configured to use the above-offered-allowance-control algorithm, otherwise they are ignored.

This command is used to limit the operationally configured shaping or policing rate on the child associated with the policy. After the parent virtual scheduler or policer control policy determines the appropriate rate for a given child, a separate operation decides the actual PIR that should be configured for that child. When the parent determines that the distributed rate is equal to or less than the child’s offered rate, the configured operational PIR will be equal to that determined rate. But when the parent determines that the child’s offered rate is less than the available bandwidth the child could consume, the operational PIR may be set to a value larger than the distributed bandwidth. This extra rate is not currently used by the child since the offered rate is less. The system provides this extra bandwidth in case the child’s offered rate increases before the next sampling interval is complete, in order to mitigate the periodic nature of the child’s operational PIR adjustments. The increase in the offered rate is not subtracted from the parent’s remaining distribution bandwidth for lower priority children, only the determined rate is considered consumed by the parent virtual scheduler or policer control policy instance. The actual operationally configured PIR will never be greater than the child’s administratively defined PIR.

This ‘fair share’ PIR configuration behavior may result in the sum of the children’s PIRs exceeding the aggregate rate of the parent. If this behavior violates the downstream QoS requirements, the above-offered-cap command may be used to minimize or eliminate the increase in the child’s configured PIR.

If the above-offered-cap command is used with a percent-based value, the increase is a function of the configured PIR value on the policer or queue. In this case, care should be taken that the child is either configured with an explicit PIR rate (other than max) or the child’s administrative PIR is defined using the percent-rate command with the local parameter enabled if an explicit value is not desired. When a maximum PIR is in use on the child, the system attempts to interpret the maximum child forwarding rate. This rate could be very large if the child is associated with multiple ingress or egress ports.

If the child’s administrative PIR is modified while a percent based above-offered-cap is in effect, the system automatically uses the new relative limit value the next time the child’s operational PIR is distributed.

When this command is not specified or removed, the child’s operational ‘fair share’ operational PIR may be configured up to the child’s administrative PIR, based on the actual parental bandwidth available at the child’s priority level.

The no form of this command is used to remove a fair share operational PIR rate increase limit from all child policers and queues associated with the policy.

This command specifies whether or not the system should handle the CoA messages initiated by the RADIUS server, and provide for mid-session interval changes of policies applicable to subscriber hosts.

The no form of this command reverts to the default.

This command configures this server for Change of Authorization messages. The system will process the CoA request from the external server if configured with this command; otherwise the CoA request is dropped.

The no form of this command disables the command.

This command configures BGP to accept and use the link-bandwidth extended community attached to any route received from any EBGP peer in the scope of the command, as long as that route belongs to one of the listed address families.

The link-bandwidth extended community is encoded as a non-transitive type. This means that by default it should not be attached to any route advertised to an EBGP peer and it should be discarded when received in any route from an EBGP peer. This command overrides the standard behavior.

Up to three families may be configured.

The no form of this command restores the default behavior of discarding the link-bandwidth extended community in any route received from an EBGP peer.

This command configures BGP to accept and use the link-bandwidth extended community attached to any route received from any EBGP peer in the scope of the command, as long as that route belongs to one of the listed address families.

The link-bandwidth extended community is encoded as a non-transitive type. This means that by default it should not be attached to any route advertised to an EBGP peer and it should be discarded when received in any route from an EBGP peer. This command overrides the standard behavior.

Up to six families may be configured.

The no form of this command restores the default behavior of discarding the link-bandwidth extended community in any route received from an EBGP peer.

This command enables the system to accept non-zero Ethernet tag MAC routes and process them only for C-MAC flushing. This command can be changed on the fly without shutting down BGP-EVPN MPLS.

The no version of the command prevents the router from processing B-MAC/ISID routes for cmac-flush.

This command is applicable only to LAC. MRRU option is an indication that the session is of MLPPPoX type. The 7750 SR LAC never initiates the MRRU option in LCP negotiation process. However, it responds to MRRU negotiation request by the client.

This command provides an option to specifically enable or disable negotiation of MLPPPoX on a capture SAP level or on a group interface level.

The no form of this command causes the MRRU option in LCP to not be negotiated by LAC.

This command is applicable only to LAC. MRRU option is an indication that the session is of MLPPPoX type. The 7750 SR LAC will never initiate MRRU option in LCP negotiation process. However, it will respond to MRRU negotiation request by the client.

This command provides an option to specifically enable or disable negotiation of MLPPPoX on a capture SAP level or on a group-interface level.

This command instructs the router to negotiate the receive capability in the BGP ORF negotiation with a peer, and to accept filters that the peer wishes to send.

The no form of this command causes the router to remove the accept capability in the BGP ORF negotiation with a peer, and to clear any existing ORF filters that are currently in place.

This command enables reactions to loopback control OAM PDUs from peers.

The no form of this command disables reactions to loopback control OAM PDUs.

This command specifies name of the radius-script-policy to be applied for access-accept.

This command configures a RADIUS script policy used to change the RADIUS attributes of the incoming Access-Accept messages.

The no form of this command reverts to the default.

This command enables the system to accept both protected and unprotected CMPv2 error message. Without this command, system will only accept protected error messages.

The no form of this command causes the system to only accept protected PKI confirmation message.

This command enables the system to accept both protected and unprotected CMPv2 error message. Without this command, system will only accept protected error messages.

The no form of this command causes the system to only accept protected PKI confirmation message.

This command enables the system to accept both protected and unprotected CMPv2 PKI confirmation messages. Without this command, system will only accept protected PKI confirmation message.

The no form of this command causes the system to only accept protected PKI confirmation message.

This command enables the system to accept both protected and unprotected CMPv2 PKI confirmation messages. Without this command, the system will only accept protected PKI confirmation message.

The no form of this command causes the system to only accept protected PKI confirmation message.

This command specifies a routing instance to be used as a network VAS router in the steering profile.

The no form of this command removes the router instance.

This command configures Ethernet access port parameters.

This command enables the context to configure the access side of HLE for the VLAN range.

The no form of this command disables the vRGW parameters enabled in this context.

This command enables the access context to configure egress and ingress pool policy parameters.

On the MDA level, access egress and ingress pools are only allocated on channelized MDAs.

This CLI node contains the access forwarding-plane parameters.

This command enables the context to configure access parameters.

This command enables the context to configure eth-tunnel loadsharing access parameters.

This command enables SNMP access using VPRN interface addresses. This command allows SNMP messages destined to the VPRN interface IP addresses for this VPRN (including VPRN interfaces that are bound to R-VPLS services) to be processed by the SNMP agent on the router. SNMP messages that arrive on VPRN interfaces but are destined to IP addresses in the Base routing context that can be accessed in the VPRN (for example, the router system address via grt leaking) do not require snmp access to be enabled but do require allow-local-management to be enabled.

Using an SNMP community defined inside the VPRN context (configure service vprn snmp community) allows access to a subset of the full SNMP data model. This subset can be seen in the output of show system security view "vprn-view".

Using an SNMP community defined in the system context (configure system security snmp community) allows access to the full SNMP data model (unless otherwise restricted used SNMP views).

Alternatively, grt leaking and a Base routing IP address can be used (along with an SNMP community defined at the system context) to get access to the entire SNMP data model (see the allow-local-management command).

The Nokia NSP cannot discover or fully manage an SROS router using an SNMP community defined inside the VPRN context. Full SNMP access requires using one of the approaches described above.

Refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide for detailed information about SNMP.

This command grants a user permission for FTP, SNMP, console, lawful intercept (LI), NETCONF, or gRPC access.

If a user requires access to more than one application, then multiple applications can be specified in a single command. Multiple commands are treated additively.

The no form of this command removes access for a specific application, and denies permission for all management access methods.

To deny a single access method, enter the no form of this command followed by the method to be denied, for example, no access FTP denies FTP access.

This command creates an association between a user group, a security model, and the views that the user group can access. Access parameters must be configured unless security is limited to the preconfigured access groups and views for SNMPv1 and SNMPv2. An access group is defined by a unique combination of the group name, security model and security level.

Access groups are used by the usm-community command.

Access must be configured unless security is limited to SNMPv1/SNMPv2c with community strings. See the community command.

Default access group configurations cannot be modified or deleted.

To remove the user group with associated, security model(s), and security level(s), use:

no access group group-name

To remove a security model and security level combination from a group, use:

no access group group-name security-model {snmpv1 | snmpv2c | usm} security-level {no-auth-no-privacy | auth-no-privacy | privacy}

This command configures the algorithm used to access the list of configured RADIUS servers.

The no form of this command reverts to the default.

This command configures the algorithm used to access the list of configured RADIUS servers.

This command configures the algorithm used to access the list of configured RADIUS servers.

The no form of this command reverts to the default.

This command configures the algorithm used to select a RADIUS server from the pool of configured RADIUS servers.

This command indicates the algorithm used to access the set of RADIUS servers.

This command defines the algorithm used to access the list of available RADIUS servers. A RADIUS server is considered available initially and marked as unavailable if no response packets are received in a period equal to the configured packet timeout multiplied by the retry count after sending a request. A server is always marked as available when any valid RADIUS packet is received from that server. Some access algorithms periodically probe unavailable servers by sending a single request. If the server responds to the request, it is immediately marked as available.

This command indicates the algorithm used to access the set of RADIUS servers.

This command enables the context to configure access loop information.

This command enables the context to configure access loop information in the local user database.

This command enables inclusion of access loop information: Broadband Forum (BBF) access loop characteristics, DSL line state and DSL type. The BBF access loop characteristics are returned as BBF specific RADIUS attributes where DSL line state and DSL type are returned as Nokia-specific RADIUS VSAs.

Information obtained via the ANCP protocol has precedence over information received in PPPoE Vendor Specific BBF tags or DHCP Vendor Specific BBF Options.

If ANCP is utilized and interim accounting update is enabled, any Port Up event from GSMP will initiate in an interim update. Port Up messages can include information such as an update on the current subscriber actual-upstream-speed. The next interim accounting message is from port up triggering point.

The no form of this command reverts to the default.

This command provides the context to configure parameters related to dynamic experience management, also known as Access Network Location (ANL).

These parameters include location source type congestion point and congestion detection parameters (such as roundtrip delay thresholds), if applicable.

This command creates a context for one of the two accounting destinations specified in the dynamic services policy. In this context, overrides of RADIUS accounting parameters can be specified.

The no form of this command removes the RADIUS accounting overrides context from the configuration.

This command enables RADIUS accounting.

The no form of this command disables RADIUS accounting.

This command configures the type of accounting record packet that is to be sent to the TACACS+ server. The record-type parameter indicates whether TACACS+ accounting start and stop packets be sent or just stop packets be sent.

This command configures accounting for this server.

This command enables RADIUS accounting.

The no form of this command disables RADIUS accounting.

This command configures the type of accounting record packet that is to be sent to the TACACS+ server. The record-type parameter indicates whether TACACS+ accounting start and stop packets be sent or just stop packets be sent.

This command enables the context to configure the first RADIUS accounting destination and corresponding RADIUS accounting parameters for dynamic data services.

This command enables the context to configure the second RADIUS accounting destination and corresponding RADIUS accounting parameters for dynamic data services.

This command specifies the policy to use to collect accounting statistics on this subscriber profile.

A maximum of one accounting policy can be associated with a profile at one time. Accounting policies are configured in the config>log context.

The no form of this command removes the accounting policy association.

This command creates the accounting policy context that can be applied to an interface SAP or interface SAP spoke SDP.

An accounting policy must be defined before it can be associated with a SAP or SDP.

If the policy-id does not exist, an error message is generated.

A maximum of one accounting policy can be associated with a SAP or SDP at one time. Accounting policies are configured in the config>log context.

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

This command configures the ISA RADIUS accounting policy for the cross-connect.

The no form of this command removes the ISA RADIUS accounting policy from the cross-connect UE.

This command specifies the isa-radius-policy used for accounting messages originated from the ISAs in the wlan-gw group. The policy can specify up to five accounting servers and configuration-specific to these accounting servers. It also specifies configuration specific to RADIUS client on ISAs and RADIUS attributes to be included in accounting messages.

This command configures an accounting policy that can apply to a queue-group on the forwarding plane.

An accounting policy must be configured before it can be associated to an interface. If the accounting policy-id does not exist, an error is returned.

Accounting policies associated with service billing can only be applied to SAPs. The accounting policy can be associated with an interface at a time.

The no form of this command removes the accounting policy association from the queue-group.

This command configures an accounting policy that can apply to an interface.

An accounting policy must be configured before it can be associated to an interface. If the accounting policy-id does not exist, an error is returned.

Accounting policies associated with service billing can only be applied to SAPs. Accounting policies associated with network ports can only be associated with interfaces. Only one accounting policy can be associated with an interface at a time.

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

This command creates the accounting policy context that can be applied to a SAP.

An accounting policy must be defined before it can be associated with a SAP. If the policy-id does not exist, an error message is generated.

A maximum of one accounting policy can be associated with a SAP at one time. Accounting policies are configured in the config>log context.

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

This command configures an accounting-policy.

This command associates an accounting policy to the MPLS instance.

An accounting policy must be defined before it can be associated else an error message is generated.

The no form of this command removes the accounting policy association.

This command associates an accounting policy to the MPLS instance.

The config>router>mpls>ingr-stats>p2mp-template-lsp>accounting-policy command is supported on the 7750 SR, 7950 XRS, and with VPLS only on the 7450 ESS.

An accounting policy must be defined before it can be associated else an error message is generated.

The no form of this command removes the accounting policy association.

This command specifies the existing accounting policy to use for AA. Accounting policies are configured in the config>log>accounting-policy context.

This command associates an accounting policy to the SAA test. The accounting policy must already be defined before it can be associated otherwise an error message is generated.

A notification (trap) is issued whenever a test is completed or terminates.

The no form of this command removes the accounting policy association.

This optional command allows the operator to assign an accounting policy and the policy-id (configured under the config>log>accounting-policy) with a record-type of complete-pm. This runs the data collection process for completed measurement intervals in memory, file storage, and maintenance functions moving data from memory to flash. A single accounting policy can be applied to a measurement interval.

The no form of this command removes the accounting policy.

This command creates the accounting policy context that can be applied to an SDP. An accounting policy must be defined before it can be associated with a SDP. If the acct-policy-id does not exist, an error message is generated.

A maximum of one accounting policy can be associated with a SDP at one time. Accounting policies are configured in the config>log context.

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

This command creates an access or network accounting policy. An accounting policy defines the accounting records that are created.

Access accounting policies are policies that can be applied to one or more SAPs. Changes made to an existing policy, using any of the sub-commands, are applied immediately to all SAPs where this policy is applied.

If an accounting policy is not specified on a SAP, then accounting records are produced in accordance with the access policy designated as the default. If a default access policy is not specified, then no accounting records are collected other than the records for the accounting policies that are explicitly configured.

Only one policy can be regarded as the default access policy. If a policy is configured as the default policy, then a no default command must be used to allow the data that is currently being collected to be written before a new access default policy can be configured.

Network accounting policies are policies that can be applied to one or more network ports or SONET/SDH channels. Any changes made to an existing policy, using any of the sub-commands, will be applied immediately to all network ports or SONET/SDH channels where this policy is applied.

If no accounting policy is defined on a network port, accounting records will be produced in accordance with the default network policy as designated with the default command. If no network default policy is created, then no accounting records will be collected other than the records for the accounting policies explicitly configured. Default accounting policies cannot be explicitly applied. For example, for accounting-policy 10, if default is set, then that policy cannot be used:

Only one policy can be regarded as the default network policy. If a policy is configured as the default policy, then a no default command must be used to allow the data that is currently being collected to be written before a new network default policy can be configured.

The no form of this command deletes the policy from the configuration. The accounting policy cannot be removed unless it is removed from all the SAPs, network ports or channels where the policy is applied.

This command specifies a UDP port number on which to contact the RADIUS server for accounting requests.

This command specifies a UDP port number on which to contact the RADIUS server for accounting requests.

This command specifies the accounting type for the L2TP tunnel accounting policy.

The no form of this command reverts to the default.

This command configures the time interval between consecutive interim accounting update messages. If not configured, the system does not send interim accounting update messages.

The no form of this command removes the value from the cross-connect configuration.

This command enables the interim accounting and specifies the interim accounting interval.

This command enables the generation of the acct-authentic RADIUS attribute.

The no form of this command reverts to the default.

This command enables the generation of the acct-delay-time RADIUS attribute.

The no form of this command reverts to the default.

This command enables the acct-delay-time.

This command configures attributes to be included in RADIUS accounting messages.

This command enables RADIUS accounting interim update message buffering.

The no form of this command disables RADIUS accounting interim update message buffering.

This command controls the sending of Accounting-On and Accounting-Off messages and the acct-on-off oper-state of the radius-server-policy:

acct-on-off: enables the sending of Accounting-On and Accounting-Off messages for this radius-server-policy. The acct-on-off oper-state is always not blocked.

acct-on-off oper-state-change [group group-name]: enables the sending of Accounting-On and Accounting-Off messages for this radius-server-policy. The acct-on-off oper-state is function of the Accounting-response received for the Accounting-On and Accounting-Off. Optionally, sets the acct-on-off oper-state of the acct-on-off-group.

acct-on-off monitor-group group-name: no Accounting-On and Accounting-Off messages are sent for this radius-server-policy. The acct-on-off oper-state is inherited from the acct-on-off-group.

The no form of this command disables the sending of Accounting-On and Accounting-Off messages.

This command creates an acct-on-off-group.

An acct-on-off-group can be referenced by:

The no form of this command deletes the acct-on-off-group.

This command specifies the accounting policy used for sending an Accounting Stop message to report RADIUS authentication failures of PPPoE sessions. A duplicate policy can be specified if a copy of the Accounting Stop message must be sent to another destination.

Reporting RADIUS authentication failures with an Accounting Stop message must be enabled in the RADIUS authentication policy (“send-acct-stop-on-fail”).

A duplicate RADIUS accounting policy can be specified if the accounting stop resulting from a RADIUS authentication failure must also be sent to a second RADIUS destination.

The no form of this command reverts to the default.

This command specifies the UDP listening port for RADIUS accounting requests.

The no form of this commands resets the UDP port to its default value (1813)

This command configures the Python script policy to modify Accounting-Request messages.

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

This command specifies the name of the acct-request-script-policy pointing to the Python script to be applied for RADIUS accounting request messages.

The acct-session-id attribute for each subscriber host is generated at the very beginning of the session initiation. This command will enable or disable sending this attribute to the RADIUS server in the Access-Request messages regardless of whether the accounting is enabled or not. The acct-session-id attribute can be used to address the subscriber hosts from the RADIUS server in the CoA Request.

The acct-session-id attribute is unique per subscriber host network wide. It is a 22 byte field comprised of the system MAC address along with the creation time and a sequence number in a hex format.

The no form of this command reverts to the default.

This command enables the system to include accounting attributes in RADIUS acct-stop and interim-update packets.

The no form of this command disables the system from including accounting attributes in RADIUS acct-stop and interim-update packets.

This command enables RADIUS accounting stop message buffering.

The no form of this command disables RADIUS accounting stop message buffering.

This command enables the acct-trigger-reason.

This command configures the accounting tunnel connection ascii-specification.

This command specifies the string that is sent in the accounting message.

This command enables the context to enable or disable the sending of triggered interim-updates, with the exception of the following:

This command creates a storage policy for cumulative statistics for subscribers. The policy defines the specific direction for the policer or the queue to be stored and performs the following functions.

The no form of this command deletes the policy only when it is no longer referenced by a subscriber profile.

This command associates an accumulated statistics policy with a subscriber profile.

The no form of this command removes the association of the accu-stats-policy from the subscriber profile. It is possible to remove the policy from the subscriber profile while the subscriber is still online, however, the statistics remain in memory and must be cleared manually, using the clear subscriber-mgmt accu-stats active-subs no-accu-stats-policy command.

This command enables debugging for GMPLS Ack packets.

The no form of the command disables debugging for GMPLS Ack packets.

This command debugs ack events.

The no form of the command disables the debugging.

This command configures the number of retransmissions of an ACK_OUT message.

The no form of this command reverts to the default.

This command specifies the value of the MLFR bundle T_ACK timer.

This timer defines the maximum period to wait for a response to any message sent onto the bundle link before attempting to retransmit a message onto the bundle link.

This command enables the acknowledgment of control channel status messages. By default, no acknowledgment packets are sent.

This command enables the acknowledgment of control channel status messages. By default, no acknowledgment packets are sent.

This command enables the acknowledgment of control channel status messages. By default, no acknowledgment packets are sent.

This command enables the acknowledgment of control channel status messages. By default, no acknowledgment packets are sent.

This command specifies the action to take on DHCP host creation when the filter entry matches.

The no form of this command reverts to the default wherein the host creation proceeds as normal.

This command specifies the action to take on DHCP6 host creation when the filter entry matches.

The no form of this command reverts to the default wherein the host creation proceeds as normal.

This command configures the processing required when the SR-Series receives a DHCP request that already has a Relay Agent Information Option (Option 82) field in the packet.

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

This command creates the context to configure actions to take for routes matching a route policy statement entry.

This command is required and must be entered for the entry to be active.

Any route policy entry without the action command will be considered incomplete and will be inactive.

The no form of this command deletes the action context from the entry.

This command enables the context to configure an action to be performed for traffic that matches a configured match criteria in the filter entry. The action can be configured as being applicable to upstream traffic, downstream traffic, or both.

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

This command configures the action for the filter entry.

The no form of this command reverts to the default.

This command configures the action to take when the periodic connectivity verification failed.

The no form of this command reverts to the default.

This command specifies what should happen to packets that do match this entry.

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

This command specifies what happens to packets that are in-profile and out-of-profile.

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

This command defines the action to be taken when a specific hardware error event is raised against the target mda.

Only one action can be enabled at a time. Entering a new action will override a previously defined action.

The no form of this command sets the action to the default value.

This command specifies a drop or forward action associated with the filter entry. If neither drop nor forward is specified, the default-action will be used for traffic that conforms to the match criteria. This could be considered a No-Op filter entry used to explicitly exit a set of filter entries without modifying previous actions.

Multiple action statements entered will overwrite previous actions.

The no form of this command removes the specified action statement.

This command configures the action to be performed by single-bucket bandwidth policers for non-conformant traffic.

Dual bucket bandwidth policers cannot have their action configured and always mark traffic below CIR in profile, between CIR and PIR out of profile, and drop traffic above PIR. Flow policers always discard non-conformant traffic.

When multiple application assurance policers are configured against a single flow (including policers at both subscriber and system), the final action done to the flow/packet will be a logical OR of all policers actions. For example, if only of the policers requires the packet to be discarded, the packet will be dropped regardless of the action of the other policers.

This command enables the context to configure AQP actions to be performed on flows that match the AQP entry’s match criteria.

This command configures the action for this entry.

This command configures an action for the IMSI-APN filter entry.

This command specifies the action to take for packets that match this nat-classifier entry. The no form of the command removes the specified action statement.

This command enters the context to configure a primary (no option specified) or secondary (secondary option specified) action to be performed on packets matching this filter entry. An ACL filter entry remains inactive (is not programmed in hardware) until a specific action is configured for that entry.

A primary action supports any filter entry action, a secondary action is used for redundancy and defines a redundant Layer 3 PBR action for an Layer 3 PBR primary action or a redundant L2 PBF action for a Layer 2 PBF primary action.

The no form of this command removes the specific action configured in the context of the action command. The primary action cannot be removed if a secondary action exists.

This mandatory command associates the forwarding class or enqueuing priority with specific IP, IPv6, or MAC criteria entry ID. The action command supports setting the forwarding class parameter to a subclass. Packets that meet all match criteria within the entry have their forwarding class and enqueuing priority overridden based on the parameters included in the action parameters. When the forwarding class is not specified in the action command syntax, a matching packet preserves (or inherits) the existing forwarding class derived from earlier matches in the classification hierarchy. When the enqueuing priority is not specified in the action, a matching packet preserves (or inherits) the existing enqueuing priority derived from earlier matches in the classification hierarchy.

When a policer is specified in the action, a matching packet is directed to the configured policer instead of the policer/queue assigned to the forwarding class of the packet.

The action command must be executed for the match criteria to be added to the active list of entries. If the entry is designed to prevent more explicit (higher entry ID) entries from matching certain packets, the fc fc-name and match protocol fields should not be defined when executing action. This allows packets matching the entry to preserve the forwarding class and enqueuing priority derived from previous classification rules.

Each time action is executed on a specific entry ID, the previously entered values for fc fc-name and priority are overridden with the newly defined parameters or inherit previous matches when a parameter is omitted.

The no form of this command removes the entry from the active entry list. Removing an entry on a policy immediately removes the entry from all SAPs using the policy. All previous parameters for the action is lost.

If no action is specified, the action specified by the default-fc command will be used.

This command defines the reclassification actions that should be performed on any packet matching the defined IP flow criteria within the entries match node. When defined under the ip-criteria context, the reclassification only applies to IPv4 packets. When defined under the ipv6-criteria context, the reclassification only applies to IPv6 packets.

If an egress packet on the SAP matches the specified IP flow entry, the forwarding class, or profile or HSMDA or egress queue accounting behavior may be overridden. By default, the forwarding class and profile of the packet is derived from ingress classification and profiling functions. The default behavior for HSMDA queue accounting is to use the counters associated with the queue to which the packet is mapped. Matching an IP flow reclassification entry will override all IP precedence- or DSCP-based reclassification rule actions when an explicit reclassification action is defined for the entry.

It is also possible to redirect the egress packet to a configured policer. The forwarding class or profile can also be optionally specified, but redirection to a policer is mutually exclusive with the hsmda-counter-override keyword.

When an IP flow entry is first created, the entry will have no explicit behavior defined as the reclassification actions to be performed. In show and info commands, the entry will display no action as the specified reclassification action for the entry. When the entry is defined with no action, the entry will not be populated in the IP flow reclassification list used to evaluate packets egressing a SAP with the SAP egress policy defined. An IP flow reclassification entry is only added to the evaluation list when the action command for the entry is executed either with explicit reclassification entries or without any actions defined. Specifying action without any trailing reclassification actions allows packets matching the entry to exit the evaluation list without matching entries lower in the list. Executing no action on an entry removes the entry from the evaluation list and also removes any explicitly defined reclassification actions associated with the entry.

The fc keyword is optional. When specified, the egress classification rule will overwrite the forwarding class derived from ingress. The new forwarding class is used for egress remarking and queue mapping decisions.

The profile keyword is optional. When specified, the egress classification rule will overwrite the profile of the packet derived from ingress. The new profile value is used for egress remarking and queue congestion behavior.

The hsmda-counter-override keyword is optional. When specified and the egress SAP is created on an HSMDA, the egress classification rule will override the default queue accounting function for the packet. By default, the HSMDA uses each queue’s default queue counters for packets mapped to the queue. The hsmda-counter-override keyword is used to map the packet to an explicit exception counter. One of eight counters can be used. When the packet is mapped to an exception counter, the packet will not increment the queue’s discard or forwarding counters; instead, the exception discard and forwarding counters will be used. This keyword is mutually exclusive with the redirection to a policer.

The policer keyword is optional. When specified, the egress packet will be redirected to the configured policer. Optional parameters allow the user to control how the forwarded policed traffic exits the egress port. By default, the policed forwarded traffic will use a queue in the egress port’s policer-output-queue queue group; alternatively, a queue in an instance of a user-configured queue group can be used or a local SAP egress queue. This keyword is mutually exclusive with the hsmda-counter-override keyword.

The no form of this command removes all reclassification actions from the IP flow reclassification entry and also removes the entry from the evaluation list. An entry removed from the evaluation list will not be matched to any packets egress a SAP associated with the SAP egress QoS policy.

This command defines the reclassification actions that are performed on any packet matching the defined IP flow criteria within the entry’s matched node. When defined under the ip-criteria context, the reclassification only applies to IPv4 packets. When defined under the ipv6-criteria context, the reclassification only applies to IPv6 packets.

If an egress packet matches the specified IP flow entry, the forwarding class and profile may be overridden. By default, the forwarding class and profile of the packet are derived from ingress classification and profiling functions. Matching an IP flow reclassification entry will override all IP precedence-based or DSCP-based reclassification rule actions when an explicit reclassification action is defined for the entry.

When an IP flow entry is first created, the entry will have no explicit behavior defined as the reclassification actions to be performed. When the entry is defined with no action, the entry will not be populated in the IP flow reclassification list used to evaluate egress packets. An IP flow reclassification entry is only added to the evaluation list when the action command for the entry is executed.

The fc and profile keywords are optional. When specified, the egress classification rule will overwrite the forwarding class and profile derived from ingress. The new forwarding class and profile are used for egress remarking, queue mapping decisions, and queue congestion behavior.

The port-redirect-group keyword is optional. When specified, the egress packet will be redirected to the configured queue or policer in the specified egress network queue group. By default, the policed forwarded traffic will use the regular network queue to which the packet's forwarding class is mapped. Alternatively, a queue in the network egress queue group instance can be used for post-policed traffic by specifying a queue after the policer parameter. The port-redirect-group keyword requires that the network egress queue group instance is specified when this network QoS policy is applied to a network interface. The port-redirect-group is not supported on a 7750 SR-a4/a8.

The no form of this command removes all reclassification actions from the IP flow reclassification entry and also removes the entry from the evaluation list. An entry removed from the evaluation list will not be matched to any egress packets.

This command defines the reclassification actions that are performed on any packet matching the defined IP flow criteria within the entry’s matched node. When defined under the ip-criteria context, the reclassification only applies to IPv4 packets. When defined under the ipv6-criteria context, the reclassification only applies to IPv6 packets.

If an ingress packet matches the specified IP flow entry, the forwarding class and profile may be overridden. By default, the forwarding class and profile of the packet are derived from ingress classification and profiling functions. Matching an IP flow reclassification entry will override all non-criteria reclassification rule actions when an explicit reclassification action is defined for the entry.

When an IP flow entry is first created, the entry will have no explicit behavior defined as the reclassification actions to be performed. When the entry is defined with no action, the entry will not be populated in the IP flow reclassification list used to evaluate ingress packets. An IP flow reclassification entry is only added to the evaluation list when the action command for the entry is executed.

The no form of this command removes all reclassification actions from the IP flow reclassification entry and also removes the entry from the evaluation list. An entry removed from the evaluation list will not be matched to any ingress packets.

This command configures the processing required when the SR-Series router receives a DHCP request that already has a Relay Agent Information Option (Option 82) field in the packet.

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

This command specifies the action to be applied to the MMRP attributes (Group B-MACs) whose ISIDs match the specified ISID criteria in the related entry.

The action keyword must be entered for the entry to be active. Any filter entry without the action keyword will be considered incomplete and will be inactive. If neither keyword is specified (no action is used), this is considered a No-Op policy entry used to explicitly set an entry inactive without modifying match criteria or removing the entry itself. Multiple action statements entered will overwrite previous actions parameters when defined. To remove a parameter, use the no form of the action command with the specified parameter.

The no form of the command removes the specified action statement. The entry is considered incomplete and hence rendered inactive without the action keyword.

This command specifies a drop or forward action associated with the filter entry. If neither drop nor forward is specified, the default-action will be used for traffic that conforms to the match criteria. This could be considered a No-Op filter entry used to explicitly exit a set of filter entries without modifying previous actions.

Multiple action statements entered will overwrite previous actions.

The no form of this command removes the specified action statement.

This command creates the action associated with the management access filter match criteria entry.

The action keyword is required. If no action is defined, the filter is ignored. If multiple action statements are configured, the last one overwrites previous configured actions.

If the packet does not meet any of the match criteria the configured default action is applied.

This command specifies the action to take for packets that match this filter entry.

This command configures the action associated with the profile entry.

This command enables the context to configure the EHS handler action list.

This command specifies the action taken when Python fails to modify the given message.

The no form of this command reverts to the default.

specifies the action taken when Python fails to modify the RADIUS message.

The no form of this command reverts to the default.

This command performs an activation on the license file pointed to by the command line argument. The file is first validated as described in the admin>system>license>validate command and upon success, replaces the existing license attributes in the system with the information in the new license file.

The license attributes that are active on a system can be viewed with the show>licensing>entitlements command.

Note: If the CLM tool is being used for license management, it shall perform the validation and activation and there is no need to enter these commands manually.

This command enables the context for configuring IPv4 or IPv6 criteria overrides.

The no form of this command removes any existing entry tags from the SAP.

This command enables CPM protocols on this interface.

This command configures the maximum amount of time before an active flow is aged out of the active cache. If an individual flow is active for the specified amount of time, the flow is aged out and a new flow is created on the next packet sampled for that flow.

Existing flows do not inherit the new active-flow-timeout value if this parameter is changed while cflowd is active. The active-flow-timeout value for a flow is set when the flow is first created in the active cache table and does not change dynamically.

The no form of this command resets the timeout back to the default value.

This command specifies that the node will delay sending the change in the T-LDP status bits for the VLL endpoint when the MC-LAG transitions the LAG subgroup which hosts the SAP for this VLL endpoint from active to standby or when any object in the endpoint. For example, SAP, ICB, or regular spoke SDP, transitions from up to down operational state.

By default, when the MC-LAG transitioned the LAG subgroup which hosts the SAP for this VLL endpoint from active to standby, the node sends immediately new T-LDP status bits indicating the new value of “standby” over the spoke SDPs which are on the mate-endpoint of the VLL. The same applies when any object in the endpoint changes an operational state from up to down.

There is no delay applied to the VLL endpoint status bit advertisement when the MC-LAG transitions the LAG subgroup which hosts the SAP from standby to active or when any object in the endpoint transitions to an operationally up state.

This command configures the active instance of a P2MP candidate path for the P2MP SR tree as a primary or a secondary instance. Before configuring the active instance ID, the candidate path instance must be configured using the instance command.

The no form of this command removes the active instance.

This command specifies the number of WLAN-GW IOMs used as active IOMs from the total number of configured WLAN-GW IOMs. If there are more configured IOM than active-iom-limit, then the remaining number of IOMs is designated as backup(s).

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

This command configures the lease time for an authenticated user.

This command specifies how many ISAs may be in active use by the WLAN-GW group at the same time. If the maximum number of active ISAs is reached and more ISAs are added to the group, the new ISAs are considered to be in standby mode.

The no form of this command removes the limit on the maximum number of active ISAs.

This command configures the number of active ISAs in active-standby ISA redundancy model for NAT. The active ISAs are automatically selected by the system and any the remaining ISA beyond the number of active limit will automatically assume the standby role. An ISA in the standby mode is idle until the failure of an active ISA occurs. Standby ISA can accept traffic from exactly one failed active ISA. Multiple standby ISAs can be configured in the system to protect against multiple simultaneous failures.

Once the active ISA fails, the standby ISA will start forwarding traffic. NAT translations from the failed ISA will have to be re-initiated by the clients and consequently setup on the newly active ISA.

In order for this command to take effect, the intra-chassis redundancy mode must be set to active-standby (config>isa>nat-group>redundancy active-standby).

This command specifies the number of active MS-ISA within all configured MS-ISA in the tunnel-group with multi-active enabled. IPsec traffic will be load balanced across all active MS-ISAs. If the number of configured MS-ISA is greater than the active-mda-number then the delta number of MS-ISA will be backup.

This command specifies the Security Association, referenced by the Security Parameter Index (SPI), to use when performing encryption and authentication on NGE packets egressing the node for all services configured using this key group.

The no form of the command returns the parameter to its default value and is the same as removing this key group from all outbound direction key groups in all services configured with this key group (that is, all packets of services using this key group will egress the node in without being encrypted).

This command specifies the signaled preferred lifetime in DHCPv6 or SLAAC after full authentication. This is only applicable to DSM.

The no form of this command reverts to the default.

This command specifies the active transmitting pre-shared-key. If two pre-shared-keys are configured, the arriving MACsec MKA can be decrypted via CAKs of both pre-shared keys; however, only the active-psk will be used for TX encryption of MKA PDUs.

This option controls the maximum number of active source messages that will be accepted by Multicast Source Discovery Protocol (MSDP), effectively controlling the number of active sources that can be stored on the system.

The no form of this command reverts the number of source message limit to default operation.

This option controls the maximum number of active source messages that will be accepted by Multicast Source Discovery Protocol (MSDP), effectively controlling the number of active sources that can be stored on the system.

The no form of this command sets no limit on the number of source active records.

This command specifies the signaled valid lifetime in DHCPv6 or SLAAC after full authentication. This is only applicable to DSM.

The no form of this command reverts to the default.

This command configures the threshold that is applied to determine whether or not there is activity. This is only valid for credit-type = time (not volume).

The no form of this command reverts to the default.

This command enables the ad insert server for the group. Ad insertion cannot be enabled if an FCC server or local RT server is enabled.

The no form of the command disables the server.

This command controls how Ethernet AD per-ES routes are generated.

The system can either send a separate Ethernet AD per-ES route per service, or an Ethernet AD per-ES routes aggregating the route-targets for multiple services. While both alternatives will inter-operate, RFC 7432 states that the EVPN Auto-Discovery per-ES route must be sent with a set of route-targets corresponding to all the EVIs defined on the Ethernet Segment. The command supports both options.

The default option ad-per-es-route-target evi-rt configures the system to send a separate AD per-ES route per service.

When enabled, the evi-rt-set option allows the aggregation of routes: A single AD per-ES route with the associated RD (ip-address:1) and a set of EVI route-targets will be advertised (to a maximum of 128). When a significant number of EVIs are defined in the Ethernet Segment (hence the number of route-targets), the system will send more than one route. For example:

This command configures the ad server address. A TCP session will be accepted for SCTE 30 messaging only for IP addresses that appear in this configuration.

The no form of the command removes the address from the ad server configuration.

This command enables validation of the presence of the AD-bit in responses from the DNS servers, and reports a warning to the SECURITY log if DNSSEC validation was not possible.

This command requires either the fall-through or drop parameters be configured. When the fall-through parameter is supplied, the system will allow DNS responses that do not pass DNSSEC validation to be accepted and logged. When the drop parameter is specified, the system will reject and log DNS responses that do not pass DNSSEC validation and the resolution will appear to fail.

This command specifies how the LAG SAP queue and virtual scheduler buffering and rate parameters are adapted over multiple active XMAs/MDAs. This command applies only to access LAGs.

This command specifies how the emulated LAG queue and virtual scheduler buffering and rate parameters are adapted over multiple active MDAs.

The no form of the command reverts to the default.

This command defines the method used by the system to derive the operational CIR and PIR settings when the queue is provisioned in hardware. For the CIR and PIR parameters individually, the system attempts to find the best operational rate depending on the defined constraint.

When a specific adaptation-rule is removed, the default constraints for pir and cir apply.

The no form of this command removes any explicitly defined constraints used to derive the operational CIR and PIR created by the application of the policy.

This command overrides specific attributes of the specified queue’s adaptation rule parameters. The adaptation rule controls the method used by the system to derive the operational CIR and PIR settings when the queue is provisioned in hardware. For the CIR and PIR parameters individually, the system attempts to find the best operational rate depending on the defined constraint.

This command is ignored for egress HSQ queue group queues which are attached to an HS WRR group within an associated HS attachment policy. In this case, the configuration of the adaptation rule is performed under the hs-wrr-group within the SAP egress QoS policy.

The no form of this command removes any explicitly defined constraints used to derive the operational CIR and PIR created by the application of the policy. When a specific adaptation-rule is removed, the default constraints for rate and cir apply.

For operational efficiency, the operational rate of a policer cannot take on every value in the configurable range. This configuration defines a rule that must be followed when mapping a configured rate to an operational rate.

The cir adaptation-rule can only be set on dual-bucket-bandwidth policers.

The no form of this command reverts to its default.

This command specifies the method used by the system to derive the operational CIR and PIR settings when the queue is provisioned in hardware. For the CIR and PIR parameters individually, the system attempts to find the best operational rate depending on the defined constraint.

This command is ignored for egress HSQ queue group queues which are attached to an HS WRR group within an associated HS attachment policy. In this case the configuration of the adaptation rule is performed under the hs-wrr-group within the egress queue group template.

The no form of this command removes any explicitly defined constraints used to derive the operational CIR and PIR created by the application of the policy. When a specific adaptation-rule is removed, the default constraints for rate and cir apply.

This command can be used to override specific attributes of the specified queue’s adaptation rule parameters. The adaptation rule controls the method used by the system to derive the operational CIR and PIR settings when the queue is provisioned in hardware. For the CIR and PIR parameters individually, the system attempts to find the best operational rate depending on the defined constraint.

This command is ignored for egress HSQ queue group queues which are attached to an HS WRR group within an associated HS attachment policy. In this case the configuration of the adaptation rule is performed under the hs-wrr-group within the SAP egress QoS policy.

The no form of this command removes any explicitly defined constraints used to derive the operational CIR and PIR created by the application of the policy. When a specific adaptation-rule is removed, the default constraints for rate and cir apply.

This command can be used to override specific attributes of the specified queue’s adaptation rule parameters. The adaptation rule controls the method used by the system to derive the operational CIR and PIR settings when the queue is provisioned in hardware. For the CIR and PIR parameters individually, the system attempts to find the best operational rate depending on the defined constraint.

This command is ignored for egress HSQ queue group queues which are attached to an HS WRR group within an associated HS attachment policy. In this case, the configuration of the adaptation rule is performed under the hs-wrr-group within the SAP egress QoS policy.

The no form of this command removes any explicitly defined constraints used to derive the operational CIR and PIR created by the application of the policy. When a specific adaptation-rule is removed, the default constraints for rate and cir apply.

This command defines the method used by the system to derive the operational CIR and PIR settings when the queue is provisioned in hardware. For the CIR and PIR parameters individually, the system attempts to find the best operational rate depending on the defined option. To change the CIR adaptation rule only, the current PIR rule must be part of the command executed.

The no form of this command removes any explicitly defined constraints used to derive the operational CIR and PIR created by the application of the policy. When a specific adaptation-rule is removed, the default constraints for rate and cir apply.

This command is used to define how the policer’s configuration parameters are translated into the underlying hardware capabilities used to implement each policer instance. For instance, the configured rates for the policer need to be mapped to the timers and decrement granularity used by the hardware's leaky bucket functions that actually perform the traffic metering. If a rate is defined that cannot be exactly matched by the hardware, the adaptation-rule setting provides guidance for which hardware rate should be used.

The hardware also needs to adapt the given mbs and cbs values into the PIR bucket violate threshold (discard) and the CIR bucket exceed threshold (out-of-profile). The hardware may not have an exact threshold match that it can use. The system treats the mbs and cbs values as minimum threshold values.

The no form of this command is used to return the policer’s metering and profiling hardware adaptation rules to closest.

This command defines the method used by the system to derive the operational FIR, CIR, and PIR settings when the queue is provisioned in hardware. For the FIR, CIR, and PIR parameters individually, the system attempts to find the best operational rate depending on the defined constraint.

When a specific adaptation-rule is removed, the default constraints for pir, cir, and fir apply.

The no form of this command removes any explicitly defined constraints used to derive the operational FIR, CIR, and PIR created by the application of the policy.

This command defines the method used by the system to derive the operational FIR, CIR and PIR settings when the queue is provisioned in hardware. For the FIR, CIR and PIR parameters individually, the system attempts to find the best operational rate depending on the defined constraint.

When a specific adaptation-rule is removed, the default constraints for pir, cir and fir apply.

The no form of this command removes any explicitly defined constraints used to derive the operational FIR, CIR and PIR created by the application of the policy.

This command is used to define how the policer’s configuration parameters are translated into the underlying hardware capabilities used to implement each policer instance. For instance, the configured rates for the policer need to be mapped to the timers and decrement granularity used by the hardware's leaky bucket functions that actually perform the traffic metering. If a rate is defined that cannot be exactly matched by the hardware, the adaptation-rule setting provides guidance for which hardware rate should be used.

The no form of this command is used to return the policer’s metering and profiling hardware adaptation rules to closest.

This command specifies how the system should resolve differences between the specified scheduling limit derived from the WRR group’s rate command and the actual operational rate obtainable in hardware. The min, max, and closest mutually exclusive keywords specify whether the next highest rate, next lowest rate, or closest rate should be selected by the system.

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

This command specifies how the system resolves differences between the specified scheduling limit derived from the WRR group’s rate command and the actual operational rate obtainable in hardware. The mutually exclusive min, max, and closest keywords specify whether the next highest rate, next lowest, or closest rate should be selected by the system.

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

This command specifies how the system should resolve differences between the specified scheduling limit derived from the WRR group’s rate command and the actual operational rate obtainable in hardware. The mutually exclusive min, max, and closest keywords specify whether the next highest rate, next lowest rate, or closest rate should be selected by the system.

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

This command defines the method used by the system to derive the operational PIR settings when the HSMDA queue is provisioned in hardware. For the PIR parameters individually, the system attempts to find the best operational rate depending on the defined constraint.

The no form of this command removes any explicitly defined constraints used to derive the operational PIR created by the application of the policy. When a specific adaptation-rule is removed, the default constraints for pir apply.