p Commands – Part II
peer-address-change-policy
peer-address-change-policy
Syntax
peer-address-change-policy {accept | ignore | reject}
Context
[Tree] (config>service>vprn>l2tp peer-address-change-policy)
[Tree] (config>router>l2tp peer-address-change-policy)
Full Context
configure service vprn l2tp peer-address-change-policy
configure router l2tp peer-address-change-policy
Description
This command specifies what to do in case the system receives a L2TP response from another address than the one the request was sent to.
Default
peer-address-change-policy reject
Parameters
- accept
-
Specifies that this system accepts any source IP address change of received L2TP control messages related to a locally originated tunnel in the state waitReply and rejects any peer address change for other tunnels; in case the new peer IP address is accepted, it is learned and used as destination address in subsequent L2TP messages.
- ignore
-
Specifies that this system ignores any source IP address change of received L2TP control messages, does not learn any new peer IP address, and does not change the destination address in subsequent L2TP messages.
- reject
-
Specifies that this system rejects any source IP address change of received L2TP control messages and drops those messages.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
peer-as
peer-as
Syntax
peer-as as-number
no peer-as
Context
[Tree] (config>subscr-mgmt>bgp-prng-plcy peer-as)
Full Context
configure subscriber-mgmt bgp-peering-policy peer-as
Description
This command configures the autonomous system number for the remote peer. The peer AS number must be configured for each configured peer.
The no form of this command removes the as-number from the configuration.
Parameters
- as-number
-
Specifies the AS number for the remote peer.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
peer-as
Syntax
peer-as as-number
Context
[Tree] (config>service>vprn>bgp>group peer-as)
[Tree] (config>service>vprn>bgp>group>neighbor peer-as)
Full Context
configure service vprn bgp group peer-as
configure service vprn bgp group neighbor peer-as
Description
This command configures the autonomous system number for the remote peer. The peer AS number must be configured for each configured peer.
For EBGP peers, the peer AS number configured must be different from the autonomous system number configured for this router under the global level since the peer will be in a different autonomous system than this router
For IBGP peers, the peer AS number must be the same as the autonomous system number of this router configured under the global level.
This is a required command for each configured peer. This may be configured under the group level for all neighbors in a particular group.
Default
No AS numbers are defined.
Parameters
- as-number
-
The autonomous system number, expressed as a decimal integer.
Platforms
All
peer-as
Syntax
peer-as as-number
Context
[Tree] (config>router>bgp>group peer-as)
[Tree] (config>router>bgp>group>neighbor peer-as)
Full Context
configure router bgp group peer-as
configure router bgp group neighbor peer-as
Description
This command configures the autonomous system number for the remote peer. The peer AS number must be configured for each configured peer.
For EBGP peers, the peer AS number configured must be different from the autonomous system number configured for this router under the global level since the peer will be in a different autonomous system than this router.
For IBGP peers, the peer AS number must be the same as the autonomous system number of this router configured under the global level.
This is required command for each configured peer. This may be configured under the group level for all neighbors in a particular group.
Parameters
- as-number
-
Specifies the autonomous system number expressed as a decimal integer.
Platforms
All
peer-endpoint
peer-endpoint
Syntax
peer-endpoint sap sap-id encap-type {dot1q | null | qinq}
peer-endpoint spoke-sdp sdp-id:vc-id
no peer-endpoint
Context
[Tree] (config>app-assure>aarp peer-endpoint)
Full Context
configure application-assurance aarp peer-endpoint
Description
This command defines the peer endpoint ID of the SAP or spoke-SDP parent-aa-sub of the AARP peer.
The no form of this command removes the peer endpoint from the AARP instance.
Default
no peer-endpoint
Parameters
- sap-id
-
Specifies the physical port identifier portion of the SAP definition.
- sdp-id:vc-id
-
Specifies the spoke SDP ID and VC ID.
- dot1q | null | qinq
-
Specifies the encapsulation type.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
peer-group
peer-group
Syntax
peer-group tunnel-group-id
no peer-group
Context
[Tree] (config>redundancy>multi-chassis>peer>mc-ipsec>tunnel-group peer-group)
Full Context
configure redundancy multi-chassis peer mc-ipsec tunnel-group peer-group
Description
This command specifies the corresponding tunnel-group ID on peer node. The peer tunnel-group ID does not necessary equals to local tunnel-group ID.
The no form of this command removes the tunnel-group ID from the configuration.
Parameters
- tunnel-group-id
-
Specifies the tunnel-group identifier.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
peer-ip-prefix
peer-ip-prefix
Syntax
peer-ip-prefix ip-prefix/ip-prefix-length
peer-ip-prefix ipv4-any
peer-ip-prefix ipv6-any
no peer-ip-prefix
Context
[Tree] (config>ipsec>client-db>client>client-id peer-ip-prefix)
Full Context
configure ipsec client-db client client-identification peer-ip-prefix
Description
This command specifies match criteria that uses the peer’s tunnel IP address as the input. Only one peer-ip-prefix criteria can be configured for a given client entry.
The no form of this command reverts to the default.
Default
no peer-ip-prefix
Parameters
- ip-prefix/ip-prefix-length
-
Specifies an IPv4 or IPv6 prefix. It is considered a match if the peer’s tunnel IP address is within the specified prefix.
- ipv4-any
-
Matches any IPv4 address.
- ipv6-any
-
Matches any IPv6 address.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
peer-ip-prefix
Syntax
[no] peer-ip-prefix
Context
[Tree] (config>ipsec>client-db>match-list peer-ip-prefix)
Full Context
configure ipsec client-db match-list peer-ip-prefix
Description
This command enables the use of the peer’s tunnel IP address as the match input.
The no form of this command disables the peer IP prefix matching process.
Default
no peer-ip-prefix
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
peer-limit
peer-limit
Syntax
peer-limit limit
no peer-limit
Context
[Tree] (config>service>vprn>ptp peer-limit)
Full Context
configure service vprn ptp peer-limit
Description
This command specifies an upper limit to the number of discovered peers permitted within the routing instance. This command can ensure that a routing instance does not consume all the possible discovered peers and blocking discovered peers in other routing instances.
If it is desired to reserve a fixed number of discovered peers per router instance, then all router instances supporting PTP should have values specified with this command and the sum of all the peer-limit values must not exceed the maximum number of discovered peers supported by the system.
If the user attempts to specify a peer-limit, and there are already more discovered peers in the routing instance than the new limit being specified, the configuration is not accepted.
The no form of this command removes the limit from the configuration.
Default
no limit
Parameters
- limit
-
Specifies the maximum number of discovered peers allowed in the routing instance.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
peer-limit
Syntax
peer-limit limit
no peer-limit
Context
[Tree] (config>system>ptp peer-limit)
Full Context
configure system ptp peer-limit
Description
This command specifies an upper limit to the number of discovered peers permitted within the routing instance. This can be used to ensure that a routing instance does not consume all the possible discovered peers and blocking discovered peers in other routing instances.
If it is desired to reserve a fixed number of discovered peers per router instance, then all router instances supporting PTP should have values specified with this command and the sum of all the peer-limit values must not exceed the maximum number of discovered peers supported by the system.
If the user attempts to specify a peer-limit, and there are already more discovered peers in the routing instance than the new limit being specified, the configuration will not be accepted.
Default
no peer-limit
Parameters
- limit
-
Specifies the maximum number of discovered peers allowed in the routing instance.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
peer-name
peer-name
Syntax
peer-name name
no peer-name
Context
[Tree] (config>redundancy>multi-chassis>peer peer-name)
Full Context
configure redundancy multi-chassis peer peer-name
Description
This command specifies a peer name.
Default
no peer-name
Parameters
- name
-
Specifies the string up to 32 characters. Any printable, seven-bit ASCII characters can be used within the string. If the string contains special characters (#, ?, space), the entire string must be enclosed within double quotes.
Platforms
All
peer-node-id
peer-node-id
Syntax
peer-node-id fqdn fully-qualified-domain-name
peer-node-id use-ip-address
Context
[Tree] (config>subscr-mgmt>pfcp-association peer-node-id)
Full Context
configure subscriber-mgmt pfcp-association peer-node-id
Description
This command configures the method used to identify the peer node ID used to match incoming PFCP messages to the configured PFCP association.
Default
peer-node-id use-ip-address
Parameters
- fully-qualified-domain-name
-
Specifies the FQDN, up to 255 characters, that identifies the peer Node ID used to match incoming PFCP messages to the PFCP association.
- use-ip-address
-
Keyword that specifies to use the configured peer IP address to identify the peer Node ID used to match incoming PFCP messages to the PFCP association. This configuration is ignored if only one association is configured.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
peer-profile
peer-profile
Syntax
peer-profile profile-name [create]
no peer-profile profile-name
Context
[Tree] (config>subscr-mgmt>gtp peer-profile)
Full Context
configure subscriber-mgmt gtp peer-profile
Description
This command creates a new peer profile.
Parameters
- profile-name
-
Specifies the profile name, up to 32 characters.
- create
-
Creates an entry.
Platforms
7750 SR, 7750 SR-e, 7750 SR-s, VSR
peer-profile-map
peer-profile-map
Syntax
peer-profile-map
Context
[Tree] (config>router>gtp>uplink peer-profile-map)
[Tree] (config>service>vprn>gtp>s11 peer-profile-map)
[Tree] (config>service>vprn>gtp>uplink peer-profile-map)
[Tree] (config>router>gtp>s11 peer-profile-map)
Full Context
configure router gtp uplink peer-profile-map
configure service vprn gtp s11 peer-profile-map
configure service vprn gtp uplink peer-profile-map
configure router gtp s11 peer-profile-map
Description
This command configures a mapping of addresses and subnets to GTP peer profiles.
Platforms
7750 SR, 7750 SR-e, 7750 SR-s, VSR
peer-rdi-rx
peer-rdi-rx
Syntax
peer-rdi-rx
Context
[Tree] (config>port>ethernet>efm-oam peer-rdi-rx)
Full Context
configure port ethernet efm-oam peer-rdi-rx
Description
This container allows an action to be configured for the various event conditions that can be received from a peer under the context of the EFM OAM protocol.
Platforms
All
peer-template
peer-template
Syntax
[no] peer-template template-name
Context
[Tree] (config>router>ldp>targeted-session peer-template)
Full Context
configure router ldp targeted-session peer-template
Description
This command creates a targeted session peer parameter template that can be referenced in the automatic creation of targeted Hello adjacency and LDP session to a discovered peer.
The no form of this command deletes the peer template. A peer template cannot be deleted if it is bound to a peer prefix list.
Parameters
- template-name
-
Specifies the template name to identify targeted peer template. It must be 32 characters maximum.
Platforms
All
peer-template-map
peer-template-map
Syntax
peer-template-map template-name policy peer-prefix-policy1 [peer-prefix-policy2..up to 5]
no peer-template-map peer-template template-name
Context
[Tree] (config>router>ldp>targeted-session peer-template-map)
Full Context
configure router ldp targeted-session peer-template-map
Description
This command enables the automatic creation of a targeted Hello adjacency and LDP session to a discovered peer. The user configures a targeted session peer parameter template and binds it to a peer prefix policy.
Each application of a targeted session template to a given prefix in the prefix list will result in the establishment of a targeted Hello adjacency to an LDP peer using the template parameters as long as the prefix corresponds to a router-id for a node in the TE database. As a result of this, the user must enable the traffic-engineering option in ISIS or OSPF. The targeted Hello adjacency will either trigger a new LDP session or will be associated with an existing LDP session to that peer.
Up to 5 peer prefix policies can be associated with a single peer template at all times. Also, the user can associate multiple templates with the same or different peer prefix policies. Thus multiple templates can match with a given peer prefix. In all cases, the targeted session parameters applied to a given peer prefix are taken from the first created template by the user. This provides a more deterministic behavior regardless of the order in which the templates are associated with the prefix policies.
Each time the user executes the above command, with the same or different prefix policy associations, or the user changes a prefix policy associated with a targeted peer template, the system re-evaluates the prefix policy. The outcome of the re-evaluation will tell LDP if an existing targeted Hello adjacency needs to be torn down or if an existing targeted Hello adjacency needs to have its parameters updated on the fly.
If a /32 prefix is added to (removed from) or if a prefix range is expanded (shrunk) in a prefix list associated with a targeted peer template, the same prefix policy re-evaluation described above is performed.
The template comes up in the no shutdown state and as such it takes effect immediately. Once a template is in use, the user can change any of the parameters on the fly without shutting down the template. In this case, all targeted Hello adjacencies are updated.
The SR OS supports multiple ways of establishing a targeted Hello adjacency to a peer LSR:
-
User configuration of the peer with the targeted session parameters inherited from the config>router>ldp>targeted-session in the top level context or explicitly configured for this peer in the config>router>ldp>targ-session>peer context and which overrides the top level parameters shared by all targeted peers. Let us refer to the top level configuration context as the global context. Some parameters only exist in the global context; their value will always be inherited by all targeted peers regardless of which event triggered it.
-
User configuration of an SDP of any type to a peer with the signaling tldp option enabled (default configuration). In this case the targeted session parameter values are taken from the global context.
-
User configuration of a (FEC 129) PW template binding in a BGP-VPLS service. In this case the targeted session parameter values are taken from the global context.
-
User configuration of a (FEC 129 type II) PW template binding in a VLL service (dynamic multi-segment PW). In this case the target session parameter values are taken from the global context
-
User configuration of a mapping of a targeted session peer parameter template to a prefix policy when the peer address exists in the TE database (this feature). In this case, the targeted session parameter values are taken from the template.
Since the above triggering events can occur simultaneously or in any arbitrary order, the LDP code implements a priority handling mechanism in order to decide which event overrides the active targeted session parameters. The overriding trigger will become the owner of the targeted adjacency to a given peer. The following is the priority order:
-
Priority 1: manual configuration of session parameters
-
Priority 2: mapping of targeted session template to prefix policy.
-
Priority 3: auto-tx parameters
-
Priority 4: auto-rx parameters
-
Priority 5: manual configuration of SDP, PW template binding in BGP-AD VPLS and in FEC 129 VLL.
Any parameter value change to an active targeted Hello adjacency caused by any of the above triggering events is performed on the fly by having LDP immediately send a Hello message with the new parameters to the peer without waiting for the next scheduled time for the Hello message. This allows the peer to adjust its local state machine immediately and maintains both the Hello adjacency and the LDP session in UP state. The only exceptions are the following:
-
The triggering event caused a change to the local-lsr-id parameter value. In this case, the Hello adjacency is brought down which will also cause the LDP session to be brought down if this is the last Hello adjacency associated with the session. A new Hello adjacency and LDP session will then get established to the peer using the new value of the local LSR ID.
-
The triggering event caused the targeted peer shutdown option to be enabled. In this case, the Hello adjacency is brought down which will also cause the LDP session to be brought down if this is the last Hello adjacency associated with the session.
Finally, the value of any LDP parameter which is specific to the LDP/TCP session to a peer is inherited from the config>router>ldp>session-params>peer context. This includes MD5 authentication, LDP prefix per-peer policies, label distribution mode (DU or DOD), and so on.
The no form of this command deletes the binding of the template to the peer prefix list and brings down all Hello adjacencies to the discovered LDP peers.
Platforms
All
peer-to-peer
peer-to-peer
Syntax
[no] peer-to-peer
Context
[Tree] (debug>diameter>node>peer peer-to-peer)
Full Context
debug diameter node peer peer-to-peer
Description
This command reports only peer level message that are required for bringing up, maintaining and tearing down the peering connection (CER/A, DWR/A, and so on).
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
peer-tracking-policy
peer-tracking-policy
Syntax
peer-tracking-policy policy-name
no peer-tracking-policy
Context
[Tree] (config>service>vprn>bgp peer-tracking-policy)
Full Context
configure service vprn bgp peer-tracking-policy
Description
This command specifies the name of a policy statement to use with the BGP peer-tracking function on the BGP sessions where this is enabled. The policy controls which IP routes in RTM are eligible to indicate reachability of IPv4 and IPv6 BGP neighbor addresses. If the longest matching route in RTM for a BGP neighbor address is an IP route that is rejected by the policy, or it is a BGP route accepted by the policy, or if there is no matching route, the neighbor is considered unreachable and BGP tears down the peering session and holds it in the idle state until a valid route is once again available and accepted by the policy.
The default peer-tracking policy (when the no peer-tracking-policy command is configured) is to use the longest matching active route in RTM that is not an LDP shortcut route or an aggregate route.
When peer-tracking is configured, the peer-tracking policy should only permit one of direct-interface or direct routes to be advertised to a BGP peer. Advertising both routes will cause the best route to oscillate.
Default
no peer-tracking-policy
Parameters
- policy-name
-
Specifies the route policy name. Allowed values are any string up to 64 characters composed of printable, 7-bit ASCII characters. If the string contains special characters (#, ?, space), the entire string must be enclosed between double quotes. Route policies are configured in the config>router>policy-options context.
Platforms
All
peer-tracking-policy
Syntax
peer-tracking-policy policy-name
no peer-tracking-policy
Context
[Tree] (config>router>bgp peer-tracking-policy)
Full Context
configure router bgp peer-tracking-policy
Description
This command specifies the name of a policy statement to use with the BGP peer-tracking function on the BGP sessions where this is enabled. The policy controls which IP routes in RTM are eligible to indicate reachability of IPv4 and IPv6 BGP neighbor addresses. If the longest matching route in RTM for a BGP neighbor address is an IP route that is rejected by the policy, or it is a BGP route accepted by the policy, or if there is no matching route, the neighbor is considered unreachable and BGP tears down the peering session and holds it in the idle state until a valid route is once again available and accepted by the policy.
The default peer-tracking policy (when the no peer-tracking-policy command is configured) is to use the longest matching active route in RTM that is not an LDP shortcut route or an aggregate route.
When peer-tracking is configured, the peer-tracking policy should only permit one of direct-interface or direct routes to be advertised to a BGP peer. Advertising both routes will cause the best route to oscillate.
Default
no peer-tracking-policy
Parameters
- policy-name
-
Specifies the route policy name. Allowed values are any string up to 64 characters long composed of printable, 7-bit ASCII characters. If the string contains special characters (#, ?, space), the entire string must be enclosed within double quotes. Route policies are configured in the config>router>policy-options context.
Platforms
All
peer-transport
peer-transport
Syntax
peer-transport ip-address
no peer transport
Context
[Tree] (config>router>ldp>tcp-session-parameters peer-transport)
Full Context
configure router ldp tcp-session-parameters peer-transport
Description
This command configures the peer transport address, that is, the destination address of the TCP connection, and not the address corresponding to the LDP LSR-ID of the peer.
Parameters
- ip-address
-
Specifies the IPv4 or IPv6 address of the TCP connection to the LDP peer in dotted decimal notation.
Platforms
All
peer-tunnel-attributes
peer-tunnel-attributes
Syntax
peer-tunnel-attributes
Context
[Tree] (config>anysec>tnl-enc>enc-grp peer-tunnel-attributes)
Full Context
configure anysec tunnel-encryption encryption-group peer-tunnel-attributes
Description
Commands in this context configure the peer tunnel attributes.
Tunnel attributes are used to match and identify the outgoing tunnels for encryptoin with ANYsec. A single tunnel attribute is used for multiple peers. Since an LSP is unidirectional, the outgoing tunnel can have different attributes from the incoming tunnel (for example, security termination policy).
Default
peer-tunnel-attributes
Platforms
7750 SR-1-24D, 7750 SR-1-46S, 7750 SR-1-48D, 7750 SR-1-92S, 7750 SR-1x-48D, 7750 SR-1x-92S, 7750 SR-1se
peer6
peer6
Syntax
peer6 ipv6-address
no peer6
Context
[Tree] (config>service>vprn>nat>inside>redundancy peer6)
[Tree] (config>router>nat>inside>redundancy peer6)
Full Context
configure service vprn nat inside redundancy peer6
configure router nat inside redundancy peer6
Description
This command is used in NAT64 multi-chassis redundancy in conjunction with filters. The configured peer6 address is an IPv6 address configured under an interface on the peering NAT64 node (active or standby). This IPv6 interface address is advertised via routing on the inside in order to attract traffic from the standby to the active NAT64 node.
Under normal circumstances, the NAT64 prefix is advertised only from the active NAT64 node. Consequently, upstream traffic for NAT64 is attracted to the active NAT64 node. The nat action in the ipv6-filter on the active NAT64 node forwards traffic to the local MS-ISA where NAT64 function is performed. However, if that upstream traffic arrives on the standby NAT64 node, the nat action in the IPv6-filter forwards traffic to the peer6 address (active NAT64 node).
The no form of the command removes the peer6 ip-address from the configuration.
Parameters
- ipv6-address
-
Specifies the IPv6 address of the NAT redundancy peer.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
peers
peers
Syntax
peers
Context
[Tree] (config>li>x-interfaces>x3 peers)
Full Context
configure li x-interfaces x3 peers
Description
This command enables the configuration of X3 peer LICs.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
pending-requests-limit
pending-requests-limit
Syntax
pending-request-limit limit
no pending-request-limit
Context
[Tree] (config>router>radius-server>server pending-requests-limit)
[Tree] (config>service>vprn>radius-server>server pending-requests-limit)
Full Context
configure router radius-server server pending-requests-limit
configure service vprn radius-server server pending-requests-limit
Description
This command specifies the per-server maximum number of outstanding requests sent to the RADIUS server. If the maximum number is exceeded, the next RADIUS server in the pool is selected.
The no form of this command removes the limit value from the configuration.
Default
pending-requests-limit 4096
Parameters
- limit
-
Specifies the maximum number of outstanding requests sent to the RADIUS server.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
peq
peq
Syntax
[no] peq peq-slot [chassis chassis-id]
Context
[Tree] (config>system>pwr-mgmt peq)
Full Context
configure system power-management peq
Description
This command sets the APEQ slot number.
Parameters
- peq-slot
-
Identifies the APEQ slot.
- chassis-id
-
Specifies chassis ID for the router chassis.
Platforms
7750 SR-12e, 7950 XRS
peq-type
peq-type
Syntax
peq-type peq-type
no peq-type
Context
[Tree] (cfg>sys>pwr-mgmt>peq peq-type)
Full Context
configure system power-management peq peq-type
Description
This command sets the type of APEQ for the designated APEQ slot.
The no form of this command moves the APEQ to an unprovisioned state.
Default
no peq-type
Parameters
- peq-type
-
Identifies the APEQ type.
Platforms
7750 SR-12e, 7950 XRS
per-fp-egr-queuing
per-fp-egr-queuing
Syntax
[no] per-fp-egr-queuing
Context
[Tree] (config>lag>access per-fp-egr-queuing)
Full Context
configure lag access per-fp-egr-queuing
Description
This command specifies whether a more efficient method of queue allocation for LAG SAPs should be utilized.
The no form of this command disables the method of queue allocation for LAG SAPs.
Platforms
All
per-fp-ing-queuing
per-fp-ing-queuing
Syntax
[no] per-fp-ing-queuing
Context
[Tree] (config>lag>access per-fp-ing-queuing)
Full Context
configure lag access per-fp-ing-queuing
Description
This command provides the ability to reduce the number of hardware queues assigned on each LAG SAP ingress. When the feature is enabled, the queue allocation for SAPs on a LAG will be optimized and only one set of queues per ingress forwarding path (FP) is allocated instead of one per port.
The no form of this command disables the method of queue allocation for LAG SAPs.
Platforms
All
per-fp-ing-queuing
Syntax
[no] per-fp-ing-queuing
Context
[Tree] (config>eth-tunnel>lag-emulation>access per-fp-ing-queuing)
Full Context
configure eth-tunnel lag-emulation access per-fp-ing-queuing
Description
This command provides the ability to reduce the number of hardware queues assigned on each LAG SAP ingress. When the feature is enabled, the queue allocation for SAPs on a LAG will be optimized and only one set of queues per ingress forwarding path (FP) is allocated instead of one per port.
The no form of this command reverts the default.
Default
no per-fp-ing-queuing
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
per-fp-sap-instance
per-fp-sap-instance
Syntax
[no] per-fp-sap-instance
Context
[Tree] (config>lag>access per-fp-sap-instance)
Full Context
configure lag access per-fp-sap-instance
Description
This command enables optimized SAP instance allocation on a LAG. When enabled, SAP instance is allocated per each FP the LAG links exits on instead of per each LAG port.
The no form of this command disables optimized SAP instance allocation.
Default
no per-fp-sap-instance
Platforms
All
per-host-authentication
per-host-authentication
Syntax
[no] per-host-authentication
Context
[Tree] (config>port>ethernet>dot1x per-host-authentication)
Full Context
configure port ethernet dot1x per-host-authentication
Description
This command enables dot1x authenticating per host source mac or VLAN. The port does not allow traffic from any hosts or any MAC. When a host is authenticated via RADIUS policy, its source mac is then allowed through the port, while the port is closed for any other mac. Any traffic from the allowed host is forwarded on the port, including untagged and tagged traffic.
Default
no per-host-authentication
Platforms
All
per-host-replication
per-host-replication
Syntax
per-host-replication [uni-mac | mcast-mac]
no per-host-replication
Context
[Tree] (config>subscr-mgmt>igmp-policy per-host-replication)
Full Context
configure subscriber-mgmt igmp-policy per-host-replication
Description
This command enables per-host-replication in IPoE model. For PPPoX, per-host-replication is the only mode of operation. In the per-host-replication mode, multicast traffic is replicated per each host within the subscriber irrespective of the fact that some hosts may be subscribed to the same multicast stream. As a result, in case that multiple hosts within the subscriber are registered for the same multicast group, the multicast streams of that group is generated. The destination MAC address of multicast streams is changed to unicast so that each host receives its own copy of the stream. Multicast traffic in the per-host-replication mode can be classified via the existing QoS CLI structure. As such the multicast traffic will flow through the subscriber queues. HQoS Adjustment is not needed in this case.
The alternative behavior for multicast replication in IPoE environment is per-SAP- replication. In this model, only a single copy of the multicast stream is sent per SAP, irrespective of the number of hosts that are subscribed to the same multicast group. This behavior applies to 1:1 connectivity model as well as on 1:N connectivity model (SAP centric behavior as opposed to subscriber centric behavior).
In the per-SAP-replication model the destination MAC address is multicast (as opposed to unicast in the per-host-replication model). Multicast traffic is flowing via the SAP queue which is outside of the subscriber context. The consequence is that multicast traffic is not accounted in the subscriber HQoS. In addition, HQoS Adaptation is not supported in the per SAP replication model.
Default
no per-host-replication — By default there is no per host replication and replication is done per SAP. This mode utilizes the SAP queues. With per-host-replication it will allow the use of the subscriber queues. Per-host-replication uses unicast MAC and multicast IP to deliver multicast content to end hosts. This is useful for multi host per SAP cases. To interoperate with end devices that do not support unicast MAC, there is an option to use per-host-replication with a multicast MAC. The traffic is the same as replication per SAP but the difference of using the subscriber queues.
Parameters
- uni-mac
-
Specifies that multicast traffic is sent with a unicast MAC and multicast IP.
- mcast-mac
-
Specifies that multicast traffic is sent with a multicast MAC and IP.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
per-host-replication
Syntax
[no] per-host-replication [uni-mac | mcast-mac]
Context
[Tree] (config>subscr-mgmt>mld-policy per-host-replication)
Full Context
configure subscriber-mgmt mld-policy per-host-replication
Description
This command enables per-host-replication. In the per-host-replication mode, multicast traffic is replicated per each host within the subscriber irrespective of the fact that some hosts may be subscribed to the same multicast stream. As a result, in case that multiple hosts within the subscriber are registered for the same multicast group, the multicast streams of that group are generated. The destination MAC address of multicast streams is changed to unicast so that each host receives its own copy of the stream. Multicast traffic in the per-host-replication mode can be classified via the existing QoS CLI structure. As such the multicast traffic flows through the subscriber queues. HQoS Adjustment is not needed in this case.
The alternative behavior for multicast replication in IPoE environment is per-SAP- replication. In this model, only a single copy of the multicast stream is sent per SAP, irrespective of the number of hosts that are subscribed to the same multicast group. This behavior applies to 1:1 connectivity model as well as on 1:N connectivity model (SAP centric behavior as opposed to subscriber centric behavior).
In the per-SAP-replication model the destination MAC address is multicast (as opposed to unicast in the per-host-replication model). Multicast traffic is flowing via the SAP queue which is outside of the subscriber context. The consequence is that multicast traffic is not accounted in the subscriber HQoS. In addition, HQoS Adaptation is not supported in the per SAP replication model.
The no form of this command reverts to the default.
Parameters
- uni-mac
-
Specifies that multicast traffic s sent with a unicast MAC and multicast IP.
- mcast-mac
-
Specifies the multicast traffic is sent with a multicast MAC and IP.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
per-lag-hashing
per-lag-hashing
Syntax
[no] per-lag-hashing
Context
[Tree] (config>mirror>mirror-dest per-lag-hashing)
Full Context
configure mirror mirror-dest per-lag-hashing
Description
This command enables per-LAG hashing on the mirror destination.
When this command is enabled, the mirror destination SAP or SDP of type LAG uses all of the link members for flow hashing. Hashing to link members is based on IP flows.
The no form of this command disables per-LAG hashing. All mirrored packets sent to a SAP or SDP of type LAG, are sent to only one of the LAG link members. If the link member to which the mirrored packets are being sent fails, another link member takes over and provides mirrored packet forwarding. Although no hashing is performed, resiliency is still provided by this next link member.
Default
no per-lag-hashing
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
per-link-hash
per-link-hash
Syntax
per-link-hash
per-link-hash weighted [auto-rebalance] [subscriber-hash-mode mode]
no per-link-hash
Context
[Tree] (config>lag per-link-hash)
Full Context
configure lag per-link-hash
Description
This command configures per-link-hashing on a LAG. When enabled, SAPs/subscribers/interfaces are hashed on LAG egress to a single LAG link.
The no form of this command disables per-link-hashing on a LAG.
Default
no per-link-hash
Parameters
- weighted
-
SAPs, subscribers, and interfaces are distributed amongst LAG links based on their preconfigured class and weight. As new links are added to a LAG, existing SAPs, subscribers, and interfaces are not impacted.
- auto-rebalance
-
SAPs, subscribers, and interfaces are distributed amongst LAG links based on their preconfigured class and weight. As new links are added to a LAG, existing SAPs, subscribers, and interfaces are rebalanced automatically.
- mode
-
Subscriber traffic can be load balanced over LAG member links in a weighted way. Traffic hashing can be performed based on SAPs or Vports.
SAP-based hashing supports weights configured at the subscriber level in a subscriber profile. SAP hashing mode supports only SAP and subscriber (1:1) deployment models.
Vport based load balancing supports SAP and subscriber (1:1) and SAP and service (N:1) deployment models.
Platforms
All
per-mcast-plane-capacity
per-mcast-plane-capacity
Syntax
[no] per-mcast-plane-capacity
Context
[Tree] (config>mcast-mgmt>chassis-level per-mcast-plane-capacity)
Full Context
configure mcast-management chassis-level per-mcast-plane-capacity
Description
Commands in this context configure multicast plane bandwidth parameters. This CLI node contains the configuration of the overall multicast (primary plus secondary) and specific secondary rate limits for each switch fabric multicast plane.
Platforms
7450 ESS, 7750 SR-1x-48D, 7750 SR-1x-92S, 7750 SR-7/12/12e, 7750 SR-s, 7950 XRS, VSR
per-peer-queuing
per-peer-queuing
Syntax
[no] per-peer-queuing
Context
[Tree] (config>system>security per-peer-queuing)
Full Context
configure system security per-peer-queuing
Description
This command enables CPM hardware queuing per peer. This means that when a peering session is established, the router will automatically allocate a separate CPM hardware queue for that peer.
The no form of this command disables CPM hardware queuing per peer.
Default
per-peer-queuing
Platforms
All
per-service-hashing
per-service-hashing
Syntax
[no] per-service-hashing
Context
[Tree] (config>service>epipe>load-balancing per-service-hashing)
Full Context
configure service epipe load-balancing per-service-hashing
Description
This command enables on a per service basis, consistent per-service hashing for Ethernet services over LAG, over Ethernet tunnel (eth-tunnel) using load sharing protection-type or over CCAG. Specifically, it enables the new hashing procedures for Epipe, VPLS, regular or PBB services.
The following algorithm describes the hash-key used for hashing when the new option is enabled:
-
If the packet is PBB encapsulated (contains an I-TAG ethertype) at the ingress side, use the ISID value from the I-TAG
-
If the packet is not PBB encapsulated at the ingress side
-
For regular (non-PBB) VPLS and Epipe services, use the related service ID
-
If the packet is originated from an ingress IVPLS or PBB Epipe SAP
-
If there is an ISID configured use the related ISID value
-
If there is no ISID yet configured use the related service ID
-
For BVPLS transit traffic use the related flood list id
-
Transit traffic is the traffic going between BVPLS endpoints
-
An example of non-PBB transit traffic in BVPLS is the OAM traffic
-
The preceding rules apply regardless of traffic type
-
Unicast, BUM flooded without MMRP or with MMRP, IGMP snooped
-
The no form of this command implies the use of existing hashing options.
Default
no per-service-hashing
Platforms
All
per-service-hashing
Syntax
[no] per-service-hashing
Context
[Tree] (config>service>vpls>load-balancing per-service-hashing)
[Tree] (config>service>template>vpls-template>load-balancing per-service-hashing)
Full Context
configure service vpls load-balancing per-service-hashing
configure service template vpls-template load-balancing per-service-hashing
Description
This command enables on a per service basis, consistent per-service hashing for Ethernet services over LAG, over Ethernet tunnel (eth-tunnel) using load sharing protection-type or over CCAG. Specifically, it enables the new hashing procedures for Epipe, VPLS, regular or PBB services.
The following algorithm describes the hash-key used for hashing when the new option is enabled:
-
If the packet is PBB encapsulated (contains an I-TAG ethertype) at the ingress side, use the ISID value from the I-TAG
-
If the packet is not PBB encapsulated at the ingress side
-
For regular (non-PBB) VPLS and Epipe services, use the related service ID
-
If the packet is originated from an ingress IVPLS or PBB Epipe SAP
-
-
If there is an ISID configured use the related ISID value
-
If there is no ISID yet configured use the related service ID
-
For BVPLS transit traffic use the related flood list id
-
-
Transit traffic is the traffic going between BVPLS endpoints
-
An example of non-PBB transit traffic in BVPLS is the OAM traffic
-
The above rules apply regardless of traffic type
-
Unicast, BUM flooded without MMRP or with MMRP, IGMP snooped
-
The no form of this command implies the use of existing hashing options.
Default
no per-service-hashing
Platforms
All
per-source-rate
per-source-rate
Syntax
per-source-rate packet-rate-limit
no per-source-rate
Context
[Tree] (config>sys>security>cpu-protection>policy per-source-rate)
Full Context
configure system security cpu-protection policy per-source-rate
Description
This command configures a per-source packet arrival rate limit. Use this command to apply a packet arrival rate limit on a per source basis. A source is defined as a unique combination of SAP and MAC source address (mac-monitoring) or SAP and source IP address (ip-src-monitoring). The CPU will receive no more than the configured packet rate from each source (only certain protocols are rate limited for ip-src-monitoring as configured under include-protocols in the cpu-protection policy). The measurement is cleared each second.
This parameter is only applicable if the policy is assigned to an interface (some examples include saps, subscriber-interfaces, and spoke-sdps), and the mac-monitor or ip-src-monitor keyword is specified in the cpu-protection configuration of that interface.
The ip-src-monitoring is useful in subscriber management architectures that have routers between the subscriber and the BNG (router). In layer-3 aggregation scenarios, all packets from all subscribers behind the same aggregation router will arrive with the same source MAC address and as such the mac-monitoring functionality cannot differentiate traffic from different subscribers.
Default
per-source-rate max
Parameters
- packet-rate-limit
-
Specifies a per-source packet (per SAP/MAC source address or per SAP/IP source address) arrival rate limit in packets per second.
Platforms
7450 ESS, 7750 SR-7/12/12e, 7750 SR-7s, 7750 SR-14s, 7950 XRS
per-spi-replication
per-spi-replication
Syntax
[no] per-spi-replication
Context
[Tree] (config>subscr-mgmt>igmp-policy per-spi-replication)
Full Context
configure subscriber-mgmt igmp-policy per-spi-replication
Description
This command enables per-SLA Profile Instance (SPI) replication. In this mode, a multicast stream is transmitted for the subscriber host SLA profile for each registered multicast group (channel). As a result, multiple copies of the same multicast stream are transmitted over the same SAP. The replication of the multicast packets depends on the number of SLA profile instances configured for the subscriber. For example, if the subscriber hosts use three SLA profiles, the (S,G) is replicated three times, but if the subscriber hosts use the same SLA profile, the (S,G) is only replicated once.
The no form of this command disables per-SPI replication.
Default
no per-spi-replication
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
per-user
per-user
Syntax
per-user user-directory dir-url file-name file-name
no per-user
Context
[Tree] (config>system>login-control>login-scripts per-user)
Full Context
configure system login-control login-scripts per-user
Description
This command allows users to define their own login scripts that can be executed each time they first login to a CLI session. The command executes the script " file-url / username / file-name" when the user username logs into a CLI session (authenticated by any means including local user database, TACACS+, or RADIUS).
For example:
per-user user-directory "cf1:/local/users" file-name "login-script.txt"
would search for the following script when user "admin” logs in and authenticates via RADIUS:
cf1:/local/users/admin/login-script.txt
The per user login script is executed after any global script executes and before any login-exec script configured against a local user is executed. This allows users, for example, who are authenticated via TACACS+ or RADIUS to define their own login scripts.
This CLI script executes in the context of the user who opens the CLI session. Any commands in the script that the user is not authorized to execute will fail.
The no form of this command disables the execution of any per user login-scripts.
Default
no per-user
Parameters
- dir-url
-
Specifies the path or directory name.
- file-name
-
Specifies the name of the file (located in the dir-url directory) including the extension.
Platforms
All
percent-rate
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent]
Context
[Tree] (config>port>ethernet>network>egr>qgrp>qover>q percent-rate)
[Tree] (config>port>eth>access>egr>qgrp>qover>q percent-rate)
Full Context
configure port ethernet network egress queue-group queue-overrides queue percent-rate
configure port ethernet access egress queue-group queue-overrides queue percent-rate
Description
This command specifies percent rates (CIR and PIR).
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 percent-rate is performed under the hs-wrr-group within the egress queue group template.
Parameters
- pir-percent
-
Specifies the PIR as a percentage.
- cir-percent
-
Specifies the CIR as a percentage.
Platforms
All
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent]
no percent-rate
Context
[Tree] (config>service>ipipe>sap>ingress>policer-over>plcr percent-rate)
[Tree] (config>service>cpipe>sap>ingress>policer-over>plcr percent-rate)
[Tree] (config>service>ipipe>sap>egress>policer-over>plcr percent-rate)
[Tree] (config>service>cpipe>sap>egress>policer-over>plcr percent-rate)
[Tree] (config>service>epipe>sap>egress>policer-over>plcr percent-rate)
Full Context
configure service ipipe sap ingress policer-override policer percent-rate
configure service cpipe sap ingress policer-override policer percent-rate
configure service ipipe sap egress policer-override policer percent-rate
configure service cpipe sap egress policer-override policer percent-rate
configure service epipe sap egress policer-override policer percent-rate
Description
This command configures the percent rates (CIR and PIR) override.
Parameters
- pir-percent
-
Specifies the policer’s PIR as a percentage of the policers’s parent arbiter rate.
- cir-percent
-
Specifies the policer’s CIR as a percentage of the policers’s parent arbiter rate.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
- configure service epipe sap egress policer-override policer percent-rate
- configure service ipipe sap ingress policer-override policer percent-rate
- configure service ipipe sap egress policer-override policer percent-rate
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS
- configure service cpipe sap egress policer-override policer percent-rate
- configure service cpipe sap ingress policer-override policer percent-rate
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent]
no percent-rate
Context
[Tree] (config>service>epipe>sap>egress>queue-override>queue percent-rate)
[Tree] (config>service>ipipe>sap>egress>queue-override>queue percent-rate)
[Tree] (config>service>cpipe>sap>ingress>queue-override>queue percent-rate)
[Tree] (config>service>cpipe>sap>egress>queue-override>queue percent-rate)
[Tree] (config>service>ipipe>sap>ingress>queue-override>queue percent-rate)
Full Context
configure service epipe sap egress queue-override queue percent-rate
configure service ipipe sap egress queue-override queue percent-rate
configure service cpipe sap ingress queue-override queue percent-rate
configure service cpipe sap egress queue-override queue percent-rate
configure service ipipe sap ingress queue-override queue percent-rate
Description
The percent-rate command within the SAP ingress and egress QoS policy enables supports for a queue’s PIR and CIR rate to be configured as a percentage of the egress port’s line rate or of its parent scheduler’s rate.
When the rates are expressed as a port-limit, the actual rates used per instance of the queue will vary based on the port speed. For example, when the same QoS policy is used on a 1-Gb and a 10-Gb Ethernet port, the queue’s rates will be 10 times greater on the 10 Gb port due to the difference in port speeds. This enables the same QOS policy to be used on SAPs on different ports without needing to use SAP based queue overrides to modify a queue’s rate to get the same relative performance from the queue.
If the port’s speed changes after the queue is created, the queue’s PIR and CIR rates will be recalculated based on the defined percentage value.
When the rates are expressed as a local-limit, the actual rates used per instance of the queue are relative to the queue’s parent scheduler rate. This enables the same QOS policy to be used on SAPs with different parent scheduler rates without needing to use SAP based queue overrides to modify a queue’s rate to get the same relative performance from the queue.
If the parent scheduler rate changes after the queue is created, the queue’s PIR and CIR rates will be recalculated based on the defined percentage value.
Queue rate overrides can only be specified in the form as configured in the QoS policy (a SAP override can only be specified as a percent-rate if the associated QoS policy was also defined as percent-rate). Likewise, a SAP override can only be specified as a rate (kb/s) if the associated QoS policy was also defined as a rate. Queue-overrides are relative to the limit type specified in the QOS policy.
When no percent-rate is defined within a SAP ingress or egress queue-override, the queue reverts to the defined shaping and CIR rates within the SAP ingress and egress QOS policy associated with the queue.
Parameters
- percent-of-line-rate
-
The percent-of-line-rate parameter is used to express the queue’s shaping rate as a percentage of line rate. The line rate associated with the queue’s port may dynamically change due to configuration or auto-negotiation. The line rate may also be affected by an egress port scheduler defined max-rate.
- pir-percent
-
Specifies the queue’s PIR as a percentage dependent on the use of the port-limit or local-limit.
- cir-percent
-
Specifies the queue’s CIR as a percentage dependent on the use of the port-limit or local-limit.
Platforms
All
- configure service epipe sap egress queue-override queue percent-rate
- configure service ipipe sap ingress queue-override queue percent-rate
- configure service ipipe sap egress queue-override queue percent-rate
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
- configure service cpipe sap egress queue-override queue percent-rate
- configure service cpipe sap ingress queue-override queue percent-rate
percent-rate
Syntax
percent-rate percent
no percent-rate
Context
[Tree] (config>service>epipe>sap>egress>queue-override>hs-wrr-group percent-rate)
[Tree] (config>service>ipipe>sap>egress>queue-override>hs-wrr-group percent-rate)
Full Context
configure service epipe sap egress queue-override hs-wrr-group percent-rate
configure service ipipe sap egress queue-override hs-wrr-group percent-rate
Description
This command overrides the scheduling rate applied to the HS WRR group as a percentage of the port rate, including both the port's egress rate and port's HS scheduler policy maximum rate, if configured. The override rate type must match the corresponding rate type within the applied QoS policy.
The no form of this command removes the percent rate override value from the configuration.
Parameters
- percent
-
Specifies the percent rate of the HS WRR group.
Platforms
7750 SR-7/12/12e
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent]
no percent-rate
Context
[Tree] (config>service>vpls>sap>ingress>policer-override>plcr percent-rate)
[Tree] (config>service>vpls>sap>egress>policer-override>plcr percent-rate)
Full Context
configure service vpls sap ingress policer-override policer percent-rate
configure service vpls sap egress policer-override policer percent-rate
Description
This command configures the percent rates (CIR and PIR) override and can only be used when the rate for the associated policer in the applied SAP ingress QoS policy is also configured with the percent-rate command.
The no form of this command removes the percent-rate override so that the percent-rate configured for the policer in the applied SAP egress QoS policy is used.
Parameters
- pir-percent
-
Specifies the policer's PIR as a percentage of the policers' parent arbiter rate.
- cir-percent
-
Specifies the policer's CIR as a percentage of the policers' parent arbiter rate.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
percent-rate
Syntax
percent-rate percent
no percent-rate
Context
[Tree] (config>service>vpls>sap>egress>queue-override>hs-wrr-group percent-rate)
Full Context
configure service vpls sap egress queue-override hs-wrr-group percent-rate
Description
This command overrides the scheduling rate applied to the HS WRR group as a percentage of the port rate, including both the port's egress rate and port's HS scheduler policy max-rate, if configured. The override rate type must match the corresponding rate type within the applied QoS policy.
The no form of this command removes the percent rate override value from the configuration.
Parameters
- percent
-
Specifies the percent rate of the HS WRR group.
Platforms
7750 SR-7/12/12e
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent]
Context
[Tree] (config>service>vpls>sap>ingress>queue-override>queue percent-rate)
[Tree] (config>service>vpls>sap>egress>queue-override>queue percent-rate)
Full Context
configure service vpls sap ingress queue-override queue percent-rate
configure service vpls sap egress queue-override queue percent-rate
Description
The percent-rate command supports a queue’s shaping rate and CIR rate as a percentage of the egress port’s line rate. When the rates are expressed as a percentage within the template, the actual rate used per instance of the queue group queue-id will vary based on the port speed. For example, when the same template is used to create a queue group on a 1-Gb and a 10-Gb Ethernet port, the queue’s rates will be 10 times greater on the 10-Gb port due to the difference in port speeds. This enables the same template to be used on multiple ports without needing to use port based queue overrides to modify a queue’s rate to get the same relative performance from the queue.
If the port’s speed changes after the queue is created, the queue’s shaping and CIR rates will be recalculated based on the defined percentage value.
The rate and percent-rate commands override one another. If the current rate for a queue is defined using the percent-rate command and the rate command is executed, the percent-rate values are deleted. In a similar fashion, the percent-rate command causes any rate command values to be deleted. A queue’s rate may dynamically be changed back and forth from a percentage to an explicit rate at any time.
An egress port queue group queue rate override may be expressed as either a percentage or an explicit rate independent on how the queue's template rate is expressed.
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 percent-rate is performed under the hs-wrr-group within the SAP egress QoS policy.
The no form of this command returns the queue to its default shaping rate and cir rate. When no percent-rate is defined within a port egress queue group queue override, the queue reverts to the defined shaping and CIR rates within the egress queue group template associated with the queue.
Parameters
- pir-percent
-
Specifies the queue’s shaping rate as a percentage of line rate. The line rate associated with the queue’s port may dynamically change due to configuration or auto-negotiation. The line rate may also be affected by an egress port scheduler defined max-rate.
- cir-percent
-
Specifies the queue’s committed scheduling rate as a percentage of line rate. The line rate associated with the queue’s port may dynamically change due to configuration or auto-negotiation. The line rate may also be affected by an egress port scheduler defined max-rate.
Platforms
All
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent]
no percent-rate
Context
[Tree] (config>service>ies>if>sap>egress>policer-override>plcr percent-rate)
[Tree] (config>service>ies>if>sap>ingress>policer-override>plcr percent-rate)
Full Context
configure service ies interface sap egress policer-override policer percent-rate
configure service ies interface sap ingress policer-override policer percent-rate
Description
This command configures the percent rates (CIR and PIR) override and can only be used when the rate for the associated policer in the applied SAP ingress QoS policy is also configured with the percent-rate command.
The no form of this command removes the percent-rate override so that the percent-rate configured for the policer in the applied SAP egress QoS policy is used.
Parameters
- pir-percent
-
Specifies the policer's PIR as a percentage of the policers's parent arbiter rate.
- cir-percent
-
Specifies the policer's CIR as a percentage of the policers's parent arbiter rate.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
percent-rate
Syntax
percent-rate percent
no percent-rate
Context
[Tree] (config>service>ies>if>sap>egress>queue-override>hs-wrr-group percent-rate)
Full Context
configure service ies interface sap egress queue-override hs-wrr-group percent-rate
Description
This command overrides the scheduling rate applied to the HS WRR group as a percentage of the port rate, including both the port's egress rate and port's HS scheduler policy max-rate, if configured. The override rate type must match the corresponding rate type within the applied QoS policy.
The no form of this command removes the percent rate override value from the configuration.
Parameters
- percent
-
Specifies the percent rate of the HS WRR group.
Platforms
7750 SR-7/12/12e
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent]
no percent-rate
Context
[Tree] (config>service>ies>if>sap>ingress>queue-override>queue percent-rate)
[Tree] (config>service>ies>if>sap>egress>queue-override>queue percent-rate)
Full Context
configure service ies interface sap ingress queue-override queue percent-rate
configure service ies interface sap egress queue-override queue percent-rate
Description
The percent-rate command supports a queue’s shaping rate and CIR rate as a percentage of the egress port’s line rate. When the rates are expressed as a percentage within the template, the actual rate used per instance of the queue group queue-id will vary based on the port speed. For example, when the same template is used to create a queue group on a 1-Gigabit and a 10-Gigabit Ethernet port, the queue’s rates will be 10 times greater on the 10 Gigabit port due to the difference in port speeds. This enables the same template to be used on multiple ports without needing to use port based queue overrides to modify a queue’s rate to get the same relative performance from the queue.
If the port’s speed changes after the queue is created, the queue’s shaping and CIR rates will be recalculated based on the defined percentage value.
The rate and percent-rate commands override one another. If the current rate for a queue is defined using the percent-rate command and the rate command is executed, the percent-rate values are deleted. In a similar fashion, the percent-rate command causes any rate command values to be deleted. A queue’s rate may dynamically be changed back and forth from a percentage to an explicit rate at anytime.
An egress port queue group queue rate override may be expressed as either a percentage or an explicit rate independent on how the queue's template rate is expressed.
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 percent-rate is performed under the hs-wrr-group within the SAP egress QoS policy.
The no form of this command returns the queue to its default shaping rate and cir rate. When no percent-rate is defined within a port egress queue group queue override, the queue reverts to the defined shaping and CIR rates within the egress queue group template associated with the queue.
Parameters
- pir-percent
-
Specifies the queue’s shaping rate as a percentage of line rate. The line rate associated with the queue’s port may dynamically change due to configuration or auto-negotiation. The line rate may also be affected by an egress port scheduler defined max-rate.
- cir-percent
-
Specifies the queue’s committed scheduling rate as a percentage of line rate. The line rate associated with the queue’s port may dynamically change due to configuration or auto-negotiation. The line rate may also be affected by an egress port scheduler defined max-rate.
Platforms
All
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent]
no percent-rate
Context
[Tree] (config>service>vprn>if>sap>ingress>policer-override>plcr percent-rate)
[Tree] (config>service>vprn>if>sap>egress>policer-override>plcr percent-rate)
Full Context
configure service vprn interface sap ingress policer-override policer percent-rate
configure service vprn interface sap egress policer-override policer percent-rate
Description
This command configures the percent rates (CIR and PIR) override and can only be used when the rate for the associated policer in the applied SAP ingress QoS policy is also configured with the percent-rate command.
The no form of this command removes the percent-rate override so that the percent-rate configured for the policer in the applied SAP egress QoS policy is used.
Parameters
- pir-percent
-
Specifies the policer's PIR as a percentage of the policers's parent arbiter rate.
- cir-percent
-
Specifies the policer's CIR as a percentage of the policers's parent arbiter rate.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
percent-rate
Syntax
percent-rate percent
no percent-rate
Context
[Tree] (config>service>vprn>if>sap>egress>queue-override>hs-wrr-group percent-rate)
Full Context
configure service vprn interface sap egress queue-override hs-wrr-group percent-rate
Description
This command overrides the scheduling rate applied to the HS WRR group as a percentage of the port rate, including both the port's egress rate and port's HS scheduler policy max-rate, if configured. The override rate type must match the corresponding rate type within the applied QoS policy.
The no form of this command removes the percent rate override value from the configuration.
Parameters
- percent
-
Specifies the percent rate of the HS WRR group.
Platforms
7750 SR-7/12/12e
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent]
no percent-rate
Context
[Tree] (config>service>vprn>if>sap>egress>queue-override>queue percent-rate)
Full Context
configure service vprn interface sap egress queue-override queue percent-rate
Description
The percent-rate command supports a queue’s shaping rate and CIR rate as a percentage of the egress port’s line rate. When the rates are expressed as a percentage within the template, the actual rate used per instance of the queue group queue-id will vary based on the port speed. For example, when the same template is used to create a queue group on a 1-Gigabit and a 10-Gigabit Ethernet port, the queue’s rates will be 10 times greater on the 10 Gigabit port due to the difference in port speeds. This enables the same template to be used on multiple ports without needing to use port based queue overrides to modify a queue’s rate to get the same relative performance from the queue.
If the port’s speed changes after the queue is created, the queue’s shaping and CIR rates will be recalculated based on the defined percentage value.
The rate and percent-rate commands override one another. If the current rate for a queue is defined using the percent-rate command and the rate command is executed, the percent-rate values are deleted. In a similar fashion, the percent-rate command causes any rate command values to be deleted. A queue’s rate may dynamically be changed back and forth from a percentage to an explicit rate at anytime.
An egress port queue group queue rate override may be expressed as either a percentage or an explicit rate independent on how the queue's template rate is expressed.
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 percent-rate is performed under the hs-wrr-group within the SAP egress QoS policy.
The no form of this command returns the queue to its default shaping rate and cir rate. When no percent-rate is defined within a port egress queue group queue override, the queue reverts to the defined shaping and CIR rates within the egress queue group template associated with the queue.
Parameters
- pir-percent
-
Specifies the queue’s shaping rate as a percentage of line rate. The line rate associated with the queue’s port may dynamically change due to configuration or auto-negotiation. The line rate may also be affected by an egress port scheduler defined max-rate.
- cir-percent
-
Specifies the queue’s committed scheduling rate as a percentage of line rate. The line rate associated with the queue’s port may dynamically change due to configuration or auto-negotiation. The line rate may also be affected by an egress port scheduler defined max-rate.
Platforms
All
percent-rate
Syntax
percent-rate percentage [local-limit | reference-port-limit]
no percent-rate
Context
[Tree] (config>qos>plcr-ctrl-plcy>tier>arbiter percent-rate)
Full Context
configure qos policer-control-policy tier arbiter percent-rate
Description
This command configures the percent rate of this contexts policer policy.
The no form of this command removes the configuration.
Parameters
- percentage
-
Specifies the percentage.
- local-limit
-
Keyword used to specify the local limit.
- reference-port-limit
-
Keyword used to specify the reference port limit.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent] [local-limit | reference-port-limit]
no percent-rate
Context
[Tree] (config>qos>sap-ingress>policer percent-rate)
[Tree] (config>qos>sap-egress>policer percent-rate)
Full Context
configure qos sap-ingress policer percent-rate
configure qos sap-egress policer percent-rate
Description
The percent-rate command within the SAP ingress and egress QoS policies enables supports for a policer’s PIR and CIR rate to be configured as a percentage of the immediate parent root policer/arbiter rate or the FP capacity.
This enables the same QoS policy to be used on SAPs on different FPs without needing to use SAP-based policer overrides to modify a policer’s rate to get the same relative performance from the policer.
If the parent arbiter rate changes after the policer is created, the policer’s PIR and CIR rates will be recalculated based on the defined percentage value.
The rate and percent-rate commands override one another. If the current rate for a policer is defined using the percent-rate command and the rate command is executed, the percent-rate values are deleted. In a similar fashion, the percent-rate command causes any rate command values to be deleted. A policer’s rate may dynamically be changed back and forth from a percentage to an explicit rate at any time.
The no form of this command returns the queue to its default shaping rate and CIR rate.
Parameters
- pir-percent
-
Specifies the policer’s PIR as a percentage of the immediate parent root policer/arbiter rate or the FP capacity.
- cir-percent
-
The cir keyword is optional and, when defined, the required cir-percent CIR parameter expresses the policer’s CIR as a percentage of the immediate parent root policer/arbiter rate or the FP capacity.
- local-limit
-
Keyword used to specify the local limit.
- reference-port-limit
-
Keyword used to specify the reference port limit.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent] [fir fir-percent] [{ port-limit | local-limit | reference-port-limit}]
percent-rate pir-percent police [{port-limit | local-limit | reference-port-limit}]
no percent-rate
Context
[Tree] (config>qos>sap-ingress>queue percent-rate)
Full Context
configure qos sap-ingress queue percent-rate
Description
This command configures a queue's PIR and CIR as a percentage of the ingress port line rate or as a percentage of its parent scheduler rate. When the rates are expressed as a port-limit, the actual rates used per instance of the queue will vary based on the port speed. For example, when the same QoS policy is used on a 1 Gb and a 10 Gb Ethernet port, the queue's rates will be 10 times greater on the 10 Gb port due to the difference in port speeds. This enables the same QoS policy to be used on SAPs on different ports without needing to use SAP-based queue overrides to modify a queue's rate to get the same relative performance from the queue.
If the port’s speed changes after the queue is created, the queue’s PIR, CIR, and FIR rates will be recalculated based on the defined percentage value.
When the rates are expressed as a local-limit, the actual rates used per instance of the queue are relative to the queue's parent scheduler rate. This enables the same QoS policy to be used on SAPs with different parent scheduler rates without needing to use SAP-based queue overrides to modify a queue's rate to get the same relative performance from the queue. If the parent scheduler rate changes after the queue is created, the queue's PIR, CIR, and FIR will be recalculated based on the defined percentage value.
The rate and percent-rate commands override one another. If the current rate for a queue is defined using the percent-rate command and the rate command is executed, the percent-rate values are deleted. Similarly, the percent-rate command causes any rate command values to be deleted. A queue's rate may dynamically be changed back and forth from a percentage to an explicit rate at any time.
Queue rate overrides can only be specified in the form configured in the QoS policy (for example, a SAP override can only be specified as a percent-rate if the associated QoS policy was also defined as percent-rate). Likewise, a SAP override can only be specified as a rate (kb/s) if the associated QoS policy was also defined as a rate. Queue-overrides are relative to the limit type specified in the QoS policy.
When no percent-rate is defined within a SAP ingress queue-override, the queue uses the defined shaping rate, CIR, and FIR within the SAP ingress QoS policy associated with the queue.
The no form of this command returns the queue to its default shaping rate, CIR, and FIR.
Parameters
- pir-percent
-
Specifies the queue’s PIR as a percentage dependent on the use of the port-limit or local-limit.
- cir-percent
-
Specifies the queue's CIR as a percentage dependent on the use of the port-limit or local-limit.
- fir-percent
-
Specifies the queue's FIR as a percentage dependent on the use of the port-limit or local-limit. FIR is only supported on FP4 hardware and is ignored when the related policy is applied to FP2- or FP3-based hardware.
- police
-
Keyword used to specify that traffic feeding into the physical queue instance above the specified PIR rate is dropped. When the police keyword is defined, only the PIR rate may be overridden. The police keyword is only applicable to SAP ingress.
- port-limit
-
Keyword used to specify that the configured PIR, CIR, and FIR percentages are relative to the rate of the port (including the ingress-rate setting) to which the queue is attached. The port-limit is the default.
- local-limit
-
Keyword used to specify that the configured PIR, CIR, and FIR percentages are relative to the queue’s parent scheduler rate. If there is no parent scheduler rate, or its rate is max, the port-limit is used.
- reference-port-limit
-
Keyword used to specify that the configured PIR, CIR, and FIR percentages are relative to the rate of the reference port (including the ingress-rate setting) to which the queue is attached.
Platforms
All
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent] [{port-limit | local-limit | reference-port-limit}]
no percent-rate
Context
[Tree] (config>qos>sap-egress>queue percent-rate)
Full Context
configure qos sap-egress queue percent-rate
Description
This command configures a queue's PIR and CIR as a percentage of the egress port line rate or as a percentage of its parent scheduler rate or agg-rate rate. When the rates are expressed as a port-limit, the actual rates used per instance of the queue will vary based on the port speed. For example, when the same QoS policy is used on a 1 Gb and a 10 Gb Ethernet port, the queue’s rates will be 10 times greater on the 10 Gb port due to the difference in port speeds. This enables the same QoS policy to be used on SAPs on different ports without needing to use SAP-based queue overrides to modify a queue’s rate to get the same relative performance from the queue.
If the port’s speed changes after the queue is created, the queue’s PIR and CIR will be recalculated based on the defined percentage value.
When the rates are expressed as a local-limit, the actual rates used per instance of the queue are relative to the queue’s parent scheduler rate or agg-rate rate. This enables the same QoS policy to be used on SAPs with different parent scheduler rates without needing to use SAP-based queue overrides to modify a queue’s rate to get the same relative performance from the queue. If the parent scheduler rate changes after the queue is created, the queue’s PIR and CIR will be recalculated based on the defined percentage value.
The rate and percent-rate commands override one another. If the current rate for a queue is defined using the percent-rate command and the rate command is executed, the percent-rate values are deleted. Similarly, the percent-rate command causes any rate command values to be deleted. A queue’s rate may dynamically be changed back and forth from a percentage to an explicit rate at any time.
Queue rate overrides can only be specified in the form as configured in the QoS policy (a SAP override can only be specified as a percent-rate if the associated QoS policy was also defined as percent-rate). Likewise, a SAP override can only be specified as a rate (kb/s) if the associated QoS policy was also defined as a rate. Queue-overrides are relative to the limit type specified in the QoS policy.
When configured on an egress HSQ queue group queue, the cir keyword is ignored.
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 percent-rate is performed under the hs-wrr-group within the SAP egress QoS policy.
When no percent-rate is defined within a SAP egress queue-override, the queue uses the defined shaping rate and CIR within the SAP egress QoS policy associated with the queue.
The no form of this command returns the queue to its default shaping rate and CIR.
Parameters
- pir-percent
-
Specifies the queue’s PIR as a percentage dependent on the use of the port-limit or local-limit.
- cir-percent
-
Specifies the queue’s CIR as a percentage dependent on the use of the port-limit or local-limit.
- port-limit
-
Keyword used to specify that the configure PIR and CIR percentages are relative to the rate of the port (including the egress-rate setting) to which this queue connects. The port-limit is the default.
- local-limit
-
Keyword used to specify that the configure PIR and CIR percentages are relative to the rate of the queue’s parent scheduler rate or agg-rate rate at egress. If there is no parent scheduler rate or agg-rate rate, or those rates are max, the port-limit is used.
- reference-port-limit
-
Keyword used to specify that the configure PIR and CIR percentages are relative to the rate of the reference port (including the egress-rate setting) to which this queue connects.
Platforms
All
percent-rate
Syntax
percent-rate percent
no percent-rate
Context
[Tree] (config>qos>sap-egress>hs-wrr-group percent-rate)
Full Context
configure qos sap-egress hs-wrr-group percent-rate
Description
This command specifies the scheduling rate applied to the HS WRR group as a percentage of the port rate, including both the port's egress rate and port's HS scheduler policy max-rate, if configured. The percent-rate and rate commands are mutually exclusive.
The no form of the command reverts to the rate max.
Parameters
- percent
-
Specifies the percent rate of the HS WRR group.
Platforms
7750 SR-7/12/12e
percent-rate
Syntax
percent-rate percent
no percent-rate
Context
[Tree] (config>qos>qgrps>egr>qgrp>hs-wrr-group percent-rate)
Full Context
configure qos queue-group-templates egress queue-group hs-wrr-group percent-rate
Description
This command specifies the scheduling rate applied to the HS WRR group as a percentage of the port rate, including both the port's egress-rate and port's HS scheduler policy max-rate, if configured. The percent-rate and rate commands are mutually exclusive.
The no form of the command reverts to the rate max.
Parameters
- percent
-
Specifies the percent rate of the HS WRR group.
Platforms
7750 SR-7/12/12e
percent-rate
Syntax
percent-rate pir-percent [cir cir-percentage] [local-limit | reference-port-limit]
no percent-rate
Context
[Tree] (config>qos>qgrps>egr>qgrp>policer percent-rate)
Full Context
configure qos queue-group-templates egress queue-group policer percent-rate
Description
This command configures the percent rate for this contexts policer.
The no form of this command removes the configuration.
Parameters
- pir-percent
-
Specifies the policer’s PIR as a percentage of the immediate parent root policer/arbiter rate or the FP capacity.
- cir-percent
-
The cir keyword is optional and, when defined, the required cir-percent CIR parameter expresses the policer’s CIR as a percentage of the immediate parent root policer/arbiter rate or the FP capacity.
- local-limit
-
Keyword used to specify the local limit.
- reference-port-limit
-
Keyword used to specify the reference port limit.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
percent-rate
Syntax
percent-rate pir-percent [cir cir-percentage]
no percent-rate
Context
[Tree] (config>qos>qgrps>ing>qgrp>policer percent-rate)
Full Context
configure qos queue-group-templates ingress queue-group policer percent-rate
Description
This command configures the percent rate for this contexts policer.
The no form of this command removes the configuration.
Parameters
- pir-percent
-
Specifies the policer’s PIR as a percentage of the immediate parent root policer/arbiter rate or the FP capacity.
- cir-percent
-
The cir keyword is optional and, when defined, the required cir-percent CIR parameter expresses the policer’s CIR as a percentage of the immediate parent root policer/arbiter rate or the FP capacity.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent] [fir fir-percent] [{ port-limit | local-limit | reference-port-limit}]
percent-rate pir-percent police [{port-limit | local-limit | reference-port-limit}]
no percent-rate
Context
[Tree] (config>qos>queue-group-templates>ingress>queue-group>queue percent-rate)
Full Context
configure qos queue-group-templates ingress queue-group queue percent-rate
Description
This command configures a queue's PIR and CIR as a percentage of the ingress port line rate or as a percentage of its parent scheduler rate. When the rates are expressed as a port-limit, the actual rates used per instance of the queue will vary based on the port speed. For example, when the same QoS policy is used on a 1 Gb and a 10 Gb Ethernet port, the queue's rates will be 10 times greater on the 10 Gb port due to the difference in port speeds. This enables the same QoS policy to be used on SAPs on different ports without needing to use SAP-based queue overrides to modify a queue's rate to get the same relative performance from the queue.
If the port’s speed changes after the queue is created, the queue’s PIR, CIR, and FIR rates will be recalculated based on the defined percentage value.
When the rates are expressed as a local-limit, the actual rates used per instance of the queue are relative to the queue's parent scheduler rate. This enables the same QoS policy to be used on SAPs with different parent scheduler rates without needing to use SAP-based queue overrides to modify a queue's rate to get the same relative performance from the queue. If the parent scheduler rate changes after the queue is created, the queue's PIR, CIR, and FIR will be recalculated based on the defined percentage value.
The rate and percent-rate commands override one another. If the current rate for a queue is defined using the percent-rate command and the rate command is executed, the percent-rate values are deleted. Similarly, the percent-rate command causes any rate command values to be deleted. A queue's rate may dynamically be changed back and forth from a percentage to an explicit rate at any time.
Queue rate overrides can only be specified in the form configured in the QoS policy (for example, a SAP override can only be specified as a percent-rate if the associated QoS policy was also defined as percent-rate). Likewise, a SAP override can only be specified as a rate (kb/s) if the associated QoS policy was also defined as a rate. Queue-overrides are relative to the limit type specified in the QoS policy.
When no percent-rate is defined within a SAP ingress queue-override, the queue uses the defined shaping rate, CIR, and FIR within the SAP ingress QoS policy associated with the queue.
The no form of this command returns the queue to its default shaping rate, CIR, and FIR.
Parameters
- pir-percent
-
Specifies the queue’s PIR as a percentage dependent on the use of the port-limit or local-limit.
- cir-percent
-
Specifies the queue's CIR as a percentage dependent on the use of the port-limit or local-limit.
- fir-percent
-
Specifies the queue's FIR as a percentage dependent on the use of the port-limit or local-limit. FIR is only supported on FP4 hardware and is ignored when the related policy is applied to FP2- or FP3-based hardware.
- police
-
Keyword used to specify that traffic feeding into the physical queue instance above the specified PIR rate will be dropped. When the police keyword is defined, only the PIR rate may be overridden. The police keyword is only applicable to SAP ingress.
- port-limit
-
Keyword used to specify that the configured PIR, CIR, and FIR percentages are relative to the rate of the port (including the ingress-rate setting) to which the queue is attached. The port-limit is the default.
- local-limit
-
Keyword used to specify that the configured PIR, CIR, and FIR percentages are relative to the queue’s parent scheduler rate. If there is no parent scheduler rate, or its rate is max, the port-limit is used.
- reference-port-limit
-
Keyword used to specify that the configured PIR, CIR, and FIR percentages are relative to the rate of the reference port (including the ingress-rate setting) to which the queue is attached.
Platforms
All
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent] [{port-limit | local-limit | reference-port-limit}]
no percent-rate
Context
[Tree] (config>qos>qgrps>egr>queue-group>queue percent-rate)
Full Context
configure qos queue-group-templates egress queue-group queue percent-rate
Description
The percent-rate command within the egress queue group template enables support for a queue’s PIR and CIR rate to be configured as a percentage of the egress port’s line rate. When the rates are expressed as a percentage within the template, the actual rate used per instance of the queue group queue-id will vary based on the port speed. For example, when the same template is used to create a queue group on a 1-Gb and a 10-Gb Ethernet port, the queue’s rates will be 10 times greater on the 10 Gb port due to the difference in port speeds. This enables the same template to be used on multiple ports without needing to use port-based queue overrides to modify a queue’s rate to get the same relative performance from the queue.
If the port’s speed changes after the queue is created, the queue’s shaping and CIR rates will be recalculated based on the defined percentage value.
When configured on an egress HSQ queue group queue, the cir keyword is ignored.
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 rate is performed under the hs-wrr-group within the egress queue group template.
The rate and percent-rate commands override one another. If the current rate for a queue is defined using the percent-rate command and the rate command is executed, the percent-rate values are deleted. Similarly, the percent-rate command causes any rate command values to be deleted. A queue’s rate may dynamically be changed back and forth from a percentage to an explicit rate at any time.
The no form of this command returns the queue to its default shaping rate and CIR rate.
Parameters
- pir-percent
-
Expresses the queue’s shaping rate as a percentage of line rate. The line rate associated with the queue’s port may dynamically change due to configuration or auto-negotiation and the egress rate setting.
- cir-percent
-
The cir keyword is optional and when defined, the required pir-percent parameter expresses the queue’s committed scheduling rate as a percentage of line rate. The line rate associated with the queue’s port may change dynamically due to configuration or auto-negotiation and the egress rate setting.
- port-limit
-
Keyword used to specify that the configure PIR and CIR percentages are relative to the rate of the port (including the egress-rate setting) to which this queue connects. The port-limit is the default.
- local-limit
-
Keyword used to specify that the configure PIR and CIR percentages are relative to the rate of the queue’s parent scheduler rate or agg-rate rate at egress. If there is no parent scheduler rate or agg-rate rate, or those rates are max, the port-limit is used.
- reference-port-limit
-
Keyword used to specify that the configure PIR and CIR percentages are relative to the rate of the reference port (including the egress-rate setting) to which this queue connects.
Platforms
All
percent-rate
Syntax
percent-rate pir-percent [cir cir-percentage] [local-limit | reference-port-limit]
no percent-rate
Context
[Tree] (config>qos>scheduler-policy>tier>scheduler percent-rate)
Full Context
configure qos scheduler-policy tier scheduler percent-rate
Description
This command configures the percentage rate for the scheduler policy.
The no form of this command removes the configuration.
Parameters
- pir-percent
-
Specifies the policer’s PIR as a percentage of the immediate parent root policer/arbiter rate or the FP capacity.
- cir-percent
-
The cir keyword is optional and, when defined, the required cir-percent CIR parameter expresses the policer’s CIR as a percentage of the immediate parent root policer/arbiter rate or the FP capacity.
- local-limit
-
Keyword used to specify the local limit.
- reference-port-limit
-
Keyword used to specify the reference port limit.
Platforms
All
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent]
no percent-rate
Context
[Tree] (config>qos>port-scheduler-policy>group percent-rate)
Full Context
configure qos port-scheduler-policy group percent-rate
Description
The percent-rate command within the port scheduler policy group enables support for a policer’s PIR and CIR rate to be configured as a percentage of the immediate parent root policer/arbiter rate or the FP capacity.
If the parent arbiter rate changes after the policer is created, the policer’s PIR and CIR rates will be recalculated based on the defined percentage value.
The rate and percent-rate commands override one another. If the current rate for a policer is defined using the percent-rate command and the rate command is executed, the percent-rate values are deleted. In a similar fashion, the percent-rate command causes any rate command values to be deleted. A policer’s rate may dynamically be changed back and forth from a percentage to an explicit rate at any time.
The no form of this command returns the queue to its default shaping rate and cir rate.
Parameters
- pir-percent
-
Specifies the policer’s PIR as a percentage of the immediate parent root policer/arbiter rate or the FP capacity.
- cir cir-percent
-
The cir keyword is optional and, when defined, the required cir-percent CIR parameter expresses the policer’s CIR as a percentage of the immediate parent root policer/arbiter rate or the FP capacity.
Platforms
All
percent-reduction-from-mbs
percent-reduction-from-mbs
Syntax
percent-reduction-from-mbs percent
no percent-reduction-from-mbs
Context
[Tree] (config>mcast-mgmt>bw-plcy>t2>sec-path>queue>drop-tail>low percent-reduction-from-mbs)
[Tree] (config>mcast-mgmt>bw-plcy>t2>prim-path>queue>drop-tail>low percent-reduction-from-mbs)
Full Context
configure mcast-management bandwidth-policy t2-paths secondary-path queue-parameters drop-tail low percent-reduction-from-mbs
configure mcast-management bandwidth-policy t2-paths primary-path queue-parameters drop-tail low percent-reduction-from-mbs
Description
This command overrides the default percentage value used to determine the low drop-tail value for the queue. By default, 10 percent of the queue depth is reserved for high congestion priority traffic. When specified, the percent-reduction-from-mbs percentage value is applied to the queues’ MBS threshold. The resulting value is subtracted from the MBS to derive the low drop-tail threshold maintained by the queue. The low drop-tail threshold defines the point at which all low-congestion priority packets destined for the queue are discarded based on queue depth. Low- and high-congestion priority is derived from the multicast records preference value compared to the record’s bundle priority threshold.
The no form of this command restores the default value.
Default
percent-reduction-from-mbs 10
Parameters
- percent
-
Specifies the percent of queue depth reserved for high-congestion priority traffic.
Platforms
7450 ESS, 7750 SR-1x-48D, 7750 SR-1x-92S, 7750 SR-7/12/12e, 7750 SR-s, 7950 XRS, VSR
percent-reduction-from-mbs
Syntax
percent-reduction-from-mbs percent
no percent-reduction-from-mbs
Context
[Tree] (config>service>ies>if>sap>egress>queue-override>queue>drop-tail>low percent-reduction-from-mbs)
[Tree] (config>service>ies>if>sap>ingress>queue-override>queue>drop-tail>low percent-reduction-from-mbs)
[Tree] (config>service>vpls>sap>egress>queue-override>queue>drop-tail>low percent-reduction-from-mbs)
[Tree] (config>service>vpls>sap>ingress>queue-override>queue>drop-tail>low percent-reduction-from-mbs)
Full Context
configure service ies interface sap egress queue-override queue drop-tail low percent-reduction-from-mbs
configure service ies interface sap ingress queue-override queue drop-tail low percent-reduction-from-mbs
configure service vpls sap egress queue-override queue drop-tail low percent-reduction-from-mbs
configure service vpls sap ingress queue-override queue drop-tail low percent-reduction-from-mbs
Description
This command overrides the low queue drop tail as a percentage reduction from the MBS of the queue. For example, if a queue has an MBS of 600 kbytes and this percentage is configured to be 30% for the low drop tail, then the low drop tail is at 420 kbytes and out-of-profile packets are not accepted into the queue if its depth is greater than this value, and discarded.
Parameters
- percent
-
Specifies the percentage reduction from the MBS for a queue drop tail.
Platforms
All
percent-reduction-from-mbs
Syntax
percent-reduction-from-mbs percent
no percent-reduction-from-mbs
Context
[Tree] (config>port>ethernet>access>ing>qgrp>qover>q>drop-tail>low percent-reduction-from-mbs)
[Tree] (config>port>ethernet>access>egr>qgrp>qover>q>drop-tail>low percent-reduction-from-mbs)
[Tree] (config>port>ethernet>network>egr>qgrp>qover>q>drop-tail>low percent-reduction-from-mbs)
Full Context
configure port ethernet access ingress queue-group queue-overrides queue drop-tail low percent-reduction-from-mbs
configure port ethernet access egress queue-group queue-overrides queue drop-tail low percent-reduction-from-mbs
configure port ethernet network egress queue-group queue-overrides queue drop-tail low percent-reduction-from-mbs
Description
This command overrides the low queue drop tail as a percentage reduction from the MBS of the queue. For example, if a queue has an MBS of 600 kbytes and this percentage is configured to be 30% for the low drop tail, then the low drop tail will be at 420 kbytes and out-of-profile packets will not be accepted into the queue if its depth is greater than this value, and so will be discarded.
Parameters
- percent
-
Specifies the percentage reduction from the MBS for a queue drop tail.
Platforms
All
percent-reduction-from-mbs
Syntax
percent-reduction-from-mbs percent
no percent-reduction-from-mbs
Context
[Tree] (config>service>ipipe>sap>egress>queue-override>queue>drop-tail>low percent-reduction-from-mbs)
[Tree] (config>service>cpipe>sap>egress>queue-override>queue>drop-tail>low percent-reduction-from-mbs)
[Tree] (config>service>epipe>sap>egress>queue-override>queue>drop-tail>low percent-reduction-from-mbs)
[Tree] (config>service>ipipe>sap>ingress>queue-override>queue>drop-tail>low percent-reduction-from-mbs)
[Tree] (config>service>cpipe>sap>ingress>queue-override>queue>drop-tail>low percent-reduction-from-mbs)
[Tree] (config>service>epipe>sap>ingress>queue-override>queue>drop-tail>low percent-reduction-from-mbs)
Full Context
configure service ipipe sap egress queue-override queue drop-tail low percent-reduction-from-mbs
configure service cpipe sap egress queue-override queue drop-tail low percent-reduction-from-mbs
configure service epipe sap egress queue-override queue drop-tail low percent-reduction-from-mbs
configure service ipipe sap ingress queue-override queue drop-tail low percent-reduction-from-mbs
configure service cpipe sap ingress queue-override queue drop-tail low percent-reduction-from-mbs
configure service epipe sap ingress queue-override queue drop-tail low percent-reduction-from-mbs
Description
This command overrides the low queue drop tail as a percentage reduction from the MBS of the queue. For example, if a queue has an MBS of 600 kbytes and the percentage reduction is configured to be 30% for the low drop tail, then the low drop tail will be at 420 kbytes. Any out-of-profile packets will not be accepted into the queue if its depth is greater than this value, and so will be discarded.
Parameters
- percent
-
Specifies the percentage reduction from the MBS for a queue drop tail.
Platforms
All
- configure service ipipe sap egress queue-override queue drop-tail low percent-reduction-from-mbs
- configure service epipe sap ingress queue-override queue drop-tail low percent-reduction-from-mbs
- configure service epipe sap egress queue-override queue drop-tail low percent-reduction-from-mbs
- configure service ipipe sap ingress queue-override queue drop-tail low percent-reduction-from-mbs
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
- configure service cpipe sap egress queue-override queue drop-tail low percent-reduction-from-mbs
- configure service cpipe sap ingress queue-override queue drop-tail low percent-reduction-from-mbs
percent-reduction-from-mbs
Syntax
percent-reduction-from-mbs percent
no percent-reduction-from-mbs
Context
[Tree] (config>service>vprn>if>sap>ingress>queue-override>queue>drop-tail>low percent-reduction-from-mbs)
[Tree] (config>service>vprn>if>sap>egress>queue-override>queue>drop-tail>low percent-reduction-from-mbs)
Full Context
configure service vprn interface sap ingress queue-override queue drop-tail low percent-reduction-from-mbs
configure service vprn interface sap egress queue-override queue drop-tail low percent-reduction-from-mbs
Description
This command overrides the low queue drop tail as a percentage reduction from the MBS of the queue. For example, if a queue has an MBS of 600 kbytes and the percentage reduction is configured to be 30% for the low drop tail, then the low drop tail will be at 420 kbytes and out-of-profile packets will not be accepted into the queue if its depth is greater than this value, and so will be discarded.
Parameters
- percent
-
Specifies the percentage reduction from the MBS for a queue drop tail.
Platforms
All
percent-reduction-from-mbs
Syntax
percent-reduction-from-mbs percent
no percent-reduction-from-mbs
Context
[Tree] (config>qos>sap-ingress>queue>drop-tail>low percent-reduction-from-mbs)
Full Context
configure qos sap-ingress queue drop-tail low percent-reduction-from-mbs
Description
This command configures the ingress SAP low drop tail as a percentage reduction from the MBS of the queue. For example, if a queue has an MBS of 600 kbytes and this percentage is configured to be 30% for the low drop tail, then the low drop tail will be at 420 kbytes and out-of-profile packets will not be accepted into the queue if its depth is greater than this value and will be discarded.
Default
percent-reduction-from-mbs 10
Parameters
- percent
-
Specifies the percentage reduction from the MBS for a queue drop tail.
Platforms
All
percent-reduction-from-mbs
Syntax
percent-reduction-from-mbs percent
no percent-reduction-from-mbs
Context
[Tree] (config>qos>sap-egress>queue>drop-tail>high percent-reduction-from-mbs)
[Tree] (config>qos>sap-egress>queue>drop-tail>highplus percent-reduction-from-mbs)
[Tree] (config>qos>sap-egress>queue>drop-tail>low percent-reduction-from-mbs)
[Tree] (config>qos>sap-egress>queue>drop-tail>exceed percent-reduction-from-mbs)
Full Context
configure qos sap-egress queue drop-tail high percent-reduction-from-mbs
configure qos sap-egress queue drop-tail highplus percent-reduction-from-mbs
configure qos sap-egress queue drop-tail low percent-reduction-from-mbs
configure qos sap-egress queue drop-tail exceed percent-reduction-from-mbs
Description
This command configures the egress SAP queue drop tails as a percentage reduction from the MBS of the queue. For example, if a queue has an MBS of 600 kbytes and this percentage is configured to be 30% for the low drop tail, then the low drop tail will be at 420 kbytes and out-of-profile packets will not be accepted into the queue if its depth is greater than this value and will be discarded.
The drop tails apply to packets with the following profile state:
-
Exceed drop tail: exceed-profile
-
High drop tail: in-profile
-
Highplus drop tail: inplus-profile
-
Low drop tail: out-of-profile
Default
Exceed drop tail: 20%
Low drop tail: 10%
High drop tail: 0%
Highplus drop tail: 0%
Parameters
- percent
-
Specifies the percentage reduction from the MBS for a queue drop tail.
Platforms
All
percent-reduction-from-mbs
Syntax
percent-reduction-from-mbs percent
no percent-reduction-from-mbs
Context
[Tree] (config>qos>network-queue>queue>drop-tail>low percent-reduction-from-mbs)
Full Context
configure qos network-queue queue drop-tail low percent-reduction-from-mbs
Description
This command configures the ingress and egress network queue low drop tail as a percentage reduction from the MBS of the queue. For example, if a queue has an MBS of 600 kbytes and percent-reduction-from-mbs is configured to be 30% for the low drop tail, then the low drop tail will be at 420 kbytes and out-of-profile packets will not be accepted into the queue if its depth is greater than this value and will be discarded.
The exceed drop tail is not configurable for network queues, however, it is set to a value of 10% in addition to low drop tail and capped by the MBS.
Default
percent-reduction-from-mbs 10
Parameters
- percent
-
Specifies the percentage reduction from the MBS for a queue drop tail.
Platforms
All
percent-reduction-from-mbs
Syntax
percent-reduction-from-mbs percent
no percent-reduction-from-mbs
Context
[Tree] (config>qos>qgrps>ing>qgrp>queue>drop-tail>low percent-reduction-from-mbs)
Full Context
configure qos queue-group-templates ingress queue-group queue drop-tail low percent-reduction-from-mbs
Description
This command configures the ingress queue group queue low drop tail as a percentage reduction from the MBS of the queue. For example, if a queue has an MBS of 600 kbytes and the percentage reduction is configured to be 30% for the low drop tail, the low drop tail will be at 420 kbytes. Out-of-profile packets will not be accepted into the queue and will be discarded if the queue depth is greater than this value.
Default
10%
Parameters
- percent
-
Specifies the percentage reduction from the MBS for a queue drop tail.
Platforms
All
percent-reduction-from-mbs
Syntax
percent-reduction-from-mbs percent
no percent-reduction-from-mbs
Context
[Tree] (config>qos>qgrps>egr>qgrp>queue>drop-tail>low percent-reduction-from-mbs)
[Tree] (config>qos>qgrps>egr>qgrp>queue>drop-tail>exceed percent-reduction-from-mbs)
[Tree] (config>qos>qgrps>egr>qgrp>queue>drop-tail>high percent-reduction-from-mbs)
[Tree] (config>qos>qgrps>egr>qgrp>queue>drop-tail>highplus percent-reduction-from-mbs)
Full Context
configure qos queue-group-templates egress queue-group queue drop-tail low percent-reduction-from-mbs
configure qos queue-group-templates egress queue-group queue drop-tail exceed percent-reduction-from-mbs
configure qos queue-group-templates egress queue-group queue drop-tail high percent-reduction-from-mbs
configure qos queue-group-templates egress queue-group queue drop-tail highplus percent-reduction-from-mbs
Description
This command configures the egress queue group queue drop tails as a percentage reduction from the MBS of the queue. For example, if a queue has an MBS of 600 kbytes and the percentage reduction is configured to be 30% for the low drop tail, the low drop tail will be at 420 kbytes. Out-of-profile packets will not be accepted into the queue and will be discarded if the queue depth is greater than this value.
The drop tails apply to packets with the following profile states:
-
exceed drop tail: exceed-profile
-
high drop tail: in-profile
-
highplus drop tail: inplus-profile
-
low drop tail: out-of-profile
Default
exceed drop tail: 20%
low drop tail: 10%
high drop tail: 0%
highplus drop tail: 0%
Parameters
- percent
-
Specifies the percentage reduction from the MBS for a queue drop tail.
Platforms
All
percent-reduction-from-mbs
Syntax
percent-reduction-from-mbs percent
no percent-reduction-from-mbs
Context
[Tree] (config>qos>shared-queue>queue>drop-tail>low percent-reduction-from-mbs)
Full Context
configure qos shared-queue queue drop-tail low percent-reduction-from-mbs
Description
This command configures the ingress shared queue low drop tail as a percentage reduction from the MBS of the queue. For example, if a queue has an MBS of 600 kbytes and percent-reduction-from-mbs is configured to be 30% for the low drop tail, then the low drop tail will be at 420 kbytes and out-of-profile packets will not be accepted into the queue if its depth is greater than this value and will be discarded.
Default
percent-reduction-from-mbs 10
Parameters
- percent
-
Specifies the percentage reduction from the MBS for a queue drop tail.
Platforms
All
performance
performance
Syntax
performance
Context
[Tree] (config>isa>aa-grp>statistics performance)
Full Context
configure isa application-assurance-group statistics performance
Description
This command configures the ISA group to enable the aa-performance statistic record. This record contains information on the traffic load and resource consumption for each ISA in the group, to allow tracking of ISA load for long term capacity planning and short term anomalies. The user can configure the accounting policy to be used, and enables the record using the [no] collect-stats command.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
performance
Syntax
[no] performance
Context
[Tree] (config>test-oam>sath>svc-test>svc-stream>test-types performance)
Full Context
configure test-oam service-activation-testhead service-test service-stream test-types performance
Description
This command configures the performance test of the service stream.
The no form of this command removes the configured performance test.
Default
no performance
Platforms
7450 ESS, 7750 SR, 7750 SR-s, 7950 XRS
performance
Syntax
performance
Context
[Tree] (config>test-oam>service-activation-testhead>service-test>test-duration performance)
Full Context
configure test-oam service-activation-testhead service-test test-duration performance
Description
Commands in this context configure the duration for the performance test type.
Platforms
7450 ESS, 7750 SR, 7750 SR-s, 7950 XRS
period
period
Syntax
period milli-seconds
no period
Context
[Tree] (config>router>rsvp>msg-pacing period)
Full Context
configure router rsvp msg-pacing period
Description
This command specifies the time interval (in ms), when the router can send the specified number of RSVP messages which is specified in the max-burst command.
Default
period 100
Parameters
- milli-seconds
-
Specifies the time interval in increments of 10 ms.
Platforms
All
periodic
periodic
Syntax
periodic
Context
[Tree] (config>subscr-mgmt>shcv-policy periodic)
Full Context
configure subscriber-mgmt shcv-policy periodic
Description
Commands in this context configure periodic SHCV properties for the subscriber management group-interface. This tool periodically scans all known DHCP hosts only and perform unicast ARP/NS requests. The subscriber host connectivity verification maintains state (connected versus not-connected) for all hosts.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
periodic-sm
periodic-sm
Syntax
[no] periodic-sm
Context
[Tree] (debug>service>id>mrp periodic-sm)
Full Context
debug service id mrp periodic-sm
Description
This command enables debugging of the periodic state machine.
The no form of this command disables debugging of the periodic state machine.
Platforms
All
periodic-time
periodic-time
Syntax
periodic-time value
no periodic-time
Context
[Tree] (config>service>vpls>sap>mrp periodic-time)
[Tree] (config>service>vpls>mesh-sdp>mrp periodic-time)
[Tree] (config>service>vpls>spoke-sdp>mrp periodic-time)
Full Context
configure service vpls sap mrp periodic-time
configure service vpls mesh-sdp mrp periodic-time
configure service vpls spoke-sdp mrp periodic-time
Description
This command controls the frequency the Periodic Transmission state machine generates periodic events if the Periodic Transmission Timer is enabled. The timer is required on a per-Port basis. The Periodic Transmission Timer is set to one second when it is started.
Default
periodic-time 10
Parameters
- value
-
The frequency with which the Periodic Transmission state machine generates periodic events, in tenths of a second.
Platforms
All
periodic-timer
periodic-timer
Syntax
[no] periodic-timer
Context
[Tree] (config>service>vpls>spoke-sdp>mrp periodic-timer)
[Tree] (config>service>vpls>sap>mrp periodic-timer)
[Tree] (config>service>vpls>mesh-sdp>mrp periodic-timer)
Full Context
configure service vpls spoke-sdp mrp periodic-timer
configure service vpls sap mrp periodic-timer
configure service vpls mesh-sdp mrp periodic-timer
Description
This command enables or disables the Periodic Transmission Timer.
Default
no periodic-timer
Platforms
All
periodic-update
periodic-update
Syntax
periodic-update interval hours [rate-limit rate]
no periodic-update
Context
[Tree] (config>aaa>isa-radius-plcy periodic-update)
Full Context
configure aaa isa-radius-policy periodic-update
Description
This command enables periodic RADIUS logging of currently allocated port blocks for a NAT subscriber (NAT binding).
Default
no periodic-update (no Interim Update messages are sent)
Parameters
- interval hours
-
Specifies the interval at which RADIUS logging is refreshed. The log generation might delayed past the configured interval value if the message pacing (rate-limit) is enabled or when the number of un-acknowledged (pending) messages in SR OS has reached its upper limit. An increased number of pending Interim Update messages in SR OS is due to lack of adequate responsiveness of the RADIUS server.
- rate-limit rate
-
Specifies the pacing of the Interim Update messages related to refreshment of the currently allocated port blocks. By default, when this command is disabled, the messages are sent at a high rate determined by the processing capability of the SR OS. Such a high message rate can exceed the processing power of the logging server which can result in the loss of logging information. To overcome this, the Interim Update messages can be generated in a staggered manner at a configured interval that is accommodating toward the processing capabilities of the logging server.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
periodic-update-interval
periodic-update-interval
Syntax
periodic-update-interval [days days] [ hrs hours] [min minutes] [sec seconds]
Context
[Tree] (config>system>security>pki>ca-prof>auto-crl-update periodic-update-interval)
Full Context
configure system security pki ca-profile auto-crl-update periodic-update-interval
Description
This command specifies the interval for periodic updates. The minimal interval is 1 hour. The maximum interval is 366 days.
Default
periodic-update-interval days 1
Parameters
- days days
-
Specifies the number of days for periodic updates.
- hours
-
Specifies the number of hours for periodic updates.
- minutes
-
Specifies the number of minutes for periodic updates.
- seconds
-
Specifies the number of seconds for periodic updates.
Platforms
All
permit-empty-passwords
permit-empty-passwords
Syntax
[no] configure system security ssh permit-empty-passwords
Context
[Tree] (config>system>security>ssh permit-empty-passwords)
Full Context
configure system security ssh permit-empty-passwords
Description
This command configures the permission of users with empty password strings to log in.
The no form of this command prevents users with empty password strings from logging in.
Default
permit-empty-passwords
Platforms
All
persist
persist
Syntax
persist {on | off}
Context
[Tree] (bof persist)
Full Context
bof persist
Description
This command specifies whether the system will preserve system indexes when a save command is executed in classic or mixed configuration mode. During a subsequent boot, the index file is read along with the configuration file. As a result, a number of system indexes are preserved between reboots, including the interface index, LSP IDs, path IDs, and so on. This reduces resynchronizations of the Network Management System (NMS) with the affected network element.
This command is ignored in model-driven configuration mode. In model-driven mode, system indices are always saved and they are embedded in the configuration file.
In the event that persist is on and the reboot with the appropriate index file fails in classic or mixed configuration mode, SNMP is operationally shut down to prevent the management system from accessing and possibly synchronizing with a partially booted or incomplete network element. To enable SNMP access, enter the config>system>snmp>no shutdown command.
If persist is enabled and the admin save url command is executed with an FTP path used as the url parameter, two FTP sessions simultaneously open to the FTP server. The FTP server must be configured to allow multiple sessions from the same login, otherwise, the configuration and index files will not be saved correctly.
-
In classic or mixed configuration mode, persistency files (.ndx) are saved on the same disk as the configuration files and the image files.
-
When an operator sets the location for the persistency file in classic or mixed configuration mode, the system will check to ensure that the disk has enough free space. If there is not enough free space, the persistency will not become active and a trap will be generated. Then, it is up to the operator to free adequate disk space. In the meantime, the system will perform a space availability check every 30 seconds. As soon as the space is available the persistency will become active on the next (30 second) check.
Default
persist off
Parameters
- on
-
Enables the system index saves between reboots.
- off
-
Disables the system index saves between reboots.
Platforms
All
persistence
persistence
Syntax
persistence seconds
no persistence
Context
[Tree] (config>python>py-pol>cache>minimum-lifetimes persistence)
Full Context
configure python python-policy cache minimum-lifetimes persistence
Description
This command configures the minimum lifetime for a cache entry to be made persistent.
The no form of this command reverts to the default.
Parameters
- persistence
-
The minimum lifetime, in seconds.
Platforms
All
persistence
Syntax
[no] persistence
Context
[Tree] (config>python>py-pol>cache persistence)
Full Context
configure python python-policy cache persistence
Description
This command enables persistency support for the cached entries of the python-policy.
The no form of this command reverts to the default.
Platforms
All
persistence
Syntax
persistence
Context
[Tree] (config>system persistence)
Full Context
configure system persistence
Description
Commands in this context configure persistence parameters on the system.
The persistence feature enables state information learned through applications such as subscriber management, DHCP server, or application assurance to be retained across reboots.
Platforms
All
persistence
Syntax
persistence [persistence-client]
no persistence
Context
[Tree] (debug>system persistence)
Full Context
debug system persistence
Description
This command displays persistence debug information.
Parameters
- persistence-client
-
Displays persistence debug information.
Platforms
All
persistency-database
persistency-database
Syntax
[no] persistency-database
Context
[Tree] (config>service>vprn>gsmp>group persistency-database)
[Tree] (config>service>vpls>gsmp>group persistency-database)
Full Context
configure service vprn gsmp group persistency-database
configure service vpls gsmp group persistency-database
Description
This command enables the system to store DSL line information in memory. If the GSMP connection terminates, the DSL line information will remain in memory and accessible for RADIUS authentication and accounting.
The no form of this command reverts to the default.
Platforms
All
persistency-database
Syntax
[no] persistency-database
Context
[Tree] (config>service>vpls>gsmp persistency-database)
Full Context
configure service vpls gsmp persistency-database
Description
This command enables the system to store DSL line information in memory. If the GSMP connection terminates, the DSL line information will remain in memory and accessible for Radius authentication and accounting.
Default
no persistency-database
Platforms
All
persistency-database
Syntax
[no] persistency-database
Context
[Tree] (config>service>vprn>gsmp persistency-database)
Full Context
configure service vprn gsmp persistency-database
Description
This command enables the system to store DSL line information in memory. If the GSMP connection terminates, the DSL line information remains in memory and accessible for RADIUS authentication and accounting.
The no form of this command reverts to the default.
Default
no persistency-database
Platforms
All
persistent-subscriptions
persistent-subscriptions
Syntax
persistent-subscriptions
Context
[Tree] (config>system>telemetry persistent-subscriptions)
Full Context
configure system telemetry persistent-subscriptions
Description
Commands in this context configure persistent subscriptions.
Platforms
All
pfcp
pfcp
Syntax
pfcp
Context
[Tree] (config>service>vpls>sap pfcp)
Full Context
configure service vpls sap pfcp
Description
Commands in this context configure an active PFCP association for the VPLS capture SAP.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
pfcp
Syntax
pfcp
Context
[Tree] (debug>subscr-mgmt pfcp)
Full Context
debug subscriber-mgmt pfcp
Description
Commands in this context use debug commands associated with the PFCP protocol.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
pfcp-association
pfcp-association
Syntax
pfcp-association name [create]
no pfcp-association name
Context
[Tree] (config>subscr-mgmt pfcp-association)
Full Context
configure subscriber-mgmt pfcp-association
Description
This command creates a PFCP association towards a BNG CUPS CPF.
The no form of this command removes the association.
Parameters
- name
-
Specifies the name of the PFCP association, up to 32 characters.
- create
-
Keyword used to create the PFCP association.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
pfcp-li-shared-key
pfcp-li-shared-key
Syntax
pfcp-li-shared-key secretpfcp-li-shared-key secret hash2
no pfcp-li-shared-key
Context
[Tree] (config>li>sci pfcp-li-shared-key)
Full Context
configure li sci pfcp-li-shared-key
Description
This command configures the shared secret key that SR OS uses in its role as a user plane (UP) to the MAG-c. The SR OS UP uses the shared secret key to encrypt and decrypt the LI PFCP IEs it exchanges with the MAG-c. The SR OS UP and the MAG-c must use matching secret keys. The system only accepts a secret key configured as a printable string.
The no form of this command removes the configuration.
Parameters
- secret
-
Specifies the name of the shared secret key, up to 128 characters. The system only accepts a secret key configured as a printable string.
- hash2
-
Keyword used to apply hash2 to the shared key.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
pfcp-mappings
pfcp-mappings
Syntax
pfcp-mappings
Context
[Tree] (config>subscr-mgmt>sla-prof pfcp-mappings)
Full Context
configure subscriber-mgmt sla-profile pfcp-mappings
Description
Commands in this context configure the mapping of PFCP QoS IEs (such as QER GBR/MBR IEs), to local QoS overrides (such as queue and policer rates).
Platforms
7750 SR, 7750 SR-e, 7750 SR-s, VSR
pfs
pfs
Syntax
pfs [dh-group {1 | 2 | 5 | 14 | 15 | 19 | 20 | 21}]
no pfs
Context
[Tree] (config>ipsec>ike-policy pfs)
Full Context
configure ipsec ike-policy pfs
Description
This command enables perfect forward secrecy on the IPsec tunnel using this policy. PFS provides for a new Diffie-Hellman key exchange each time the SA key is renegotiated. After that SA expires, the key is forgotten and another key is generated (if the SA remains up). This means that an attacker who cracks part of the exchange can only read the part that used the key before the key changed. There is no advantage in cracking the other parts if they attacker has already cracked one.
The no form of this command disables PFS. If this it turned off during an active SA, when the SA expires and it is time to re-key the session, the original Diffie-Hellman primes will be used to generate the new keys.
Default
no pfs
Parameters
- dh-group {1 | 2 | 5 | 14 | 15 | 19 | 20 | 21}
-
Specifies which Diffie-Hellman group to use for calculating session keys. More bits provide a higher level of security, but require more processing. Three groups are supported with IKE-v1:
Group 1: 768 bits
Group 2: 1024 bits
Group 5: 1536 bits
Group 14: 2048 bits
Group 15: 3072 bits
Group 19: P-256 ECC Curve, 256 bits
Group 20: P-384 ECC Curve, 384 bits
Group 21: P-512 ECC Curve, 512 bits
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
pfs-dh-group
pfs-dh-group
Syntax
pfs-dh-group {1 | 2 | 5 | 14 | 15 | 19 | 20 | 21}
pfs-dh-group inherit
no pfs-dh-group
Context
[Tree] (config>ipsec>ipsec-transform pfs-dh-group)
Full Context
configure ipsec ipsec-transform pfs-dh-group
Description
This command specifies the Diffie-Hellman group to be used for Perfect Forward Secrecy (PFS) computation during CHILD_SA rekeying.
The no form of this command reverts to the default.
Default
pfs-dh-group inherit
Parameters
- {1 | 2 | 5 | 14 | 15 | 19 | 20 | 21}
-
Specifies the Diffie-Hellman group to achieve PFS.
- inherit
-
Specifies that the value of the DH group used by the system is inherited from the IPsec gateway or IPsec tunnel.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
pgw
pgw
Syntax
pgw
Context
[Tree] (config>subscr-mgmt>gtp>peer-profile pgw)
Full Context
configure subscriber-mgmt gtp peer-profile pgw
Description
Commands in this context configure communication with a Packet Data Network Gateway.
Platforms
7750 SR, 7750 SR-e, 7750 SR-s, VSR
phone
phone
Syntax
[no] phone phone-number
Context
[Tree] (config>service>cust phone)
Full Context
configure service customer phone
Description
This command adds telephone number information for a customer ID. The no form of this command removes the phone number value from the customer ID.
Parameters
- string
-
Specifies the customer phone number entered as an ASCII string up to 80 characters. If the string contains special characters (#, ?, space), the entire string must be enclosed within double quotes. Any printable, seven bit ASCII characters may be used within the string.
Platforms
All
physical-access-id
physical-access-id
Syntax
[no] physical-access-id
Context
[Tree] (config>subscr-mgmt>diam-appl-plcy>gx>include-avp physical-access-id)
Full Context
configure subscriber-mgmt diameter-application-policy gx include-avp physical-access-id
Description
This command includes the physical access ID.
The no form of this command reverts to the default.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
pid-pmt-unref
pid-pmt-unref
Syntax
[no] pat-syntax
Context
[Tree] (config>mcast-mgmt>mcast-info-plcy>bundle>channel>video>analyzer>alarms pid-pmt-unref)
[Tree] (config>mcast-mgmt>mcast-info-plcy>bundle>channel>source-override>video>analyzer>alarms pid-pmt-unref)
[Tree] (config>mcast-mgmt>mcast-info-plcy>bundle>video>analyzer>alarms pid-pmt-unref)
Full Context
configure mcast-management multicast-info-policy bundle channel video analyzer alarms pid-pmt-unref
configure mcast-management multicast-info-policy bundle channel source-override video analyzer alarms pid-pmt-unref
configure mcast-management multicast-info-policy bundle video analyzer alarms pid-pmt-unref
Description
This command configures the analyzer to check for unreferenced PIDs that have not been referred in the PMT.
Default
no pid-pmt-unref
Platforms
7450 ESS, 7750 SR, 7750 SR-s
pim
pim
Syntax
pim {asm | ssm} grp-ip-address
no pim
Context
[Tree] (config>service>vprn>mvpn>pt>inclusive pim)
Full Context
configure service vprn mvpn provider-tunnel inclusive pim
Description
This command specifies the PIM mode to use, ASM or SSM, for PIM-based inclusive provider tunnels and the multicast group address to use. Also enables the context for specifying parameters for PIM peering on the inclusive provider tunnel.
Auto-discovery must be enabled in order for SSM to operate.
The no form of this command removes the pim context including the statements under the context.
Default
no pim
Parameters
- asm
-
Specifies to use PIM ASM for inclusive provider tunnels.
- ssm
-
Specifies to u PIM SSM for inclusive provider tunnels.
- group-address
-
Specifies the multicast group address to use.
Platforms
All
pim
Syntax
[no] pim
Context
[Tree] (config>service>vprn pim)
Full Context
configure service vprn pim
Description
This command configures a Protocol Independent Multicast (PIM) instance in the VPRN service. When an PIM instance is created, the protocol is enabled. PIM is used for multicast routing within the network. Devices in the network can receive the multicast feed requested and non-participating routers can be pruned. The router supports PIM sparse mode (PIM-SM).
The no form of this command deletes the PIM protocol instance removing all associated configuration parameters.
Platforms
All
pim
Syntax
[no] pim
Context
[Tree] (config>router pim)
Full Context
configure router pim
Description
This command enables a Protocol Independent Multicast (PIM) instance.
PIM is used for multicast routing within the network. Devices in the network can receive the multicast feed requested and non-participating routers can be pruned. The router OS supports PIM sparse mode (PIM-SM).
The no form of this command disables the PIM instance.
Default
no pim
Platforms
All
pim
Syntax
pim [grp-address]
no pim
Context
[Tree] (debug>router>msdp pim)
Full Context
debug router msdp pim
Description
This command enables debugging for MSDP PIM.
The no form of this command disables MSDP PIM debugging.
Parameters
- grp-address
-
Debugs the IP multicast group address for which this entry contains information.
Platforms
All
pim-asm
pim-asm
Syntax
pim-asm {grp-ip-address/mask | grp-ip-address netmask}
no pim-asm
Context
[Tree] (config>service>vprn>mvpn>pt>selective pim-asm)
Full Context
configure service vprn mvpn provider-tunnel selective pim-asm
Description
This command specifies the range of PIM-ASM groups to use on the sender PE to setup ASM multicast tree for draft Rosen based Data MDT.
Parameters
- grp-ip-address
-
Specifies the multicast group address.
- mask
-
Specifies the mask of the multicast-ip-address.
- netmask
-
The subnet mask in dotted decimal notation.
Platforms
All
pim-policy
pim-policy
Syntax
pim-policy pim-policy-name [create]
no pim-policy pim-policy-name
Context
[Tree] (config>subscr-mgmt pim-policy)
Full Context
configure subscriber-mgmt pim-policy
Description
This command creates a PIM policy or enters the context to configure a PIM policy.
The no form of this command deletes the specified PIM policy.
Parameters
- pim-policy-name
-
Specifies the PIM policy name, up to 32 characters, composed of printable, 7-bit ASCII characters. If the string contains special characters (#, ?, space), the entire string must be enclosed within double quotes.
- create
-
Specifies the keyword used to create the PIM policy. The create keyword requirement can be enabled or disabled in the environment>create context.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
pim-policy
Syntax
pim-policy policy-name
no pim-policy policy-name
Context
[Tree] (config>subscr-mgmt>sub-prof pim-policy)
Full Context
configure subscriber-mgmt sub-profile pim-policy
Description
This command adds an existing PIM policy to this subscriber profile.
The no form of this command removes the specified PIM policy from this subscriber profile.
Parameters
- policy-name
-
Specifies the name of the PIM policy name, up to 32 characters, composed of printable, 7-bit ASCII characters. If the string contains special characters (#, ?, space), the entire string must be enclosed within double quotes.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
pim-snooping
pim-snooping
Syntax
pim-snooping [saps] [spoke-sdps]
no pim-snooping
Context
[Tree] (config>redundancy>multi-chassis>peer>sync pim-snooping)
Full Context
configure redundancy multi-chassis peer sync pim-snooping
Description
This command specifies whether PIM snooping for IPv4 information should be synchronized with a multi-chassis peer. Entering pim-snooping without any parameters results in the synchronization being applied only to SAPs.
Specifying the spoke-sdps parameter results in the synchronization being applied to manually configured spoke SDPs. Specifying both the saps and spoke-sdps parameters results in the synchronization being applied to both SAPs and manually configured spoke SDPs.
The synchronization of PIM snooping is only supported for manually configured spoke SDPs but is not supported for spoke SDPs configured within an endpoint. See PIM Snooping for IPv4 Synchronization for service support.
Default
no pim-snooping
Parameters
- saps
-
Specifies that SAPs are to be synchronized with the multi-chassis peer according to the synchronization tags configured on the port. This is the default when no parameters are specified.
- spoke-sdps
-
Specifies that spoke SDPs are to be synchronized with the multi-chassis peer according to the synchronization tags configured on spoke SDPs.
Platforms
All
pim-snooping
Syntax
pim-snooping
Context
[Tree] (config>service>vpls>spoke-sdp pim-snooping)
[Tree] (config>service>vpls pim-snooping)
[Tree] (config>service>vpls>sap pim-snooping)
Full Context
configure service vpls spoke-sdp pim-snooping
configure service vpls pim-snooping
configure service vpls sap pim-snooping
Description
This command enables PIM snooping for the VPLS service. When enabled, it is enabled for all SAPs except default SAPs. A default SAP is a SAP that has a wild card VLAN ID, such as sap 1/1/1:*.
The no form of this command removes the PIM snooping configuration.
Platforms
All
pim-snooping
Syntax
[no] pim-snooping
Context
[Tree] (debug>service>id pim-snooping)
Full Context
debug service id pim-snooping
Description
This command enables PIM-snooping debugging.
Platforms
All
pim-ssm
pim-ssm
Syntax
pim-ssm {grp-ip-address/mask | grp-ip-address netmask}
no pim-ssm
Context
[Tree] (config>service>vprn>mvpn>pt>selective pim-ssm)
Full Context
configure service vprn mvpn provider-tunnel selective pim-ssm
Description
This command specifies the PIM SSM groups to use for the selective provider tunnel.
Parameters
- group-address/mask
-
Specifies a multicast group address and netmask length.
Platforms
All
pim-ssm-scaling
pim-ssm-scaling
Syntax
[no] pim-ssm-scaling
Context
[Tree] (config>router>pim pim-ssm-scaling)
Full Context
configure router pim pim-ssm-scaling
Description
This command enables an increase of PIM SSM (S,G) scaling to a maximum of 256kper system. The per-complex (FP) multicast scaling limit is still in place, but multiple complexes can be used to achieve the 256k per-system (S,G) scaling.
The no form of this command disables the increase in PIM SSM scaling.
Default
no pim-ssm-scaling
Platforms
All
ping
ping
Syntax
ping ip-address | dns-name [bypass-routing | {interface interface-name} | {next-hop ip-address}] [{router router-or-service} | {router-instance router-instance} | {service-name service-name}] [source ip-address] [count requests] [detail | rapid] [do-not-fragment] [fc fc-name] [interval centisecs | secs] [pattern pattern] [size bytes] [timeout timeout] [tos type-of-service] [ttl time-to-live]
ping ipv4-address subscriber-id sub-ident-string [{router router-or-service} | {router-instance router-instance} | {service-name service-name}] [source ip-address] [count requests] [detail | rapid] [do-not-fragment] [fc fc-name] [interval centisecs | secs] [pattern pattern] [size bytes] [timeout timeout] [tos type-of-service] [ttl time-to-live]
ping srv6-policy color color endpoint ipv6-address [segment-list segment-list] [candidate-path protocol-owner static | bgp [preference preference] [distinguisher distinguisher]] [count requests] [detail | rapid] [do-not-fragment] [fc fc-name] [interval centisecs | secs] [pattern pattern] [size bytes] [timeout timeout] [tos type-of-service] [ttl time-to-live]
Context
[Tree] (ping)
Full Context
ping
Description
This command sends a ping to a destination to verify IP reachability.
Use the ping {ip-address | dns-name} [{bypass-routing | {interface interface-name} | {next-hop ip-address}}] command syntax to send a generic ping. This is the basic TCP/IP utility to verify IP reachability.
Use the ping ipv4-address subscriber-id sub-ident-string command syntax to send a ping to verify L2-Aware remote host reachability.
The L2-Aware form of this command can be initiated from the gateway IPv4 address in the inside routing context or from any IPv4 address in the outside routing context. If the gateway IPv4 address is used as the source address, it must be explicitly specified in conjunction with the L2-Aware syntax.
Any source address can be used for the ping to test the relevant NAT policy. If the source address refers to a policy that is not configured on the router, the message "MINOR: OAM #2160 router ID is not an outside router for this subscriber” is displayed. The source address does not need to belong to the system.
If the outside routing context is not specified, by default, the Base router is selected. If the specified or default Base router instance is not the outside routing context for the subscriber, the L2-Aware form of this command fails to execute, and the message "MINOR: OAM #2160 router ID is not an outside router for this subscriber” is displayed.
The NAT application shares query IDs between L2-Aware pings and ICMP or GRE traffic that has undergone NAT and is destined for a DMZ host. If there is query ID space exhaustion, ICMP or GRE flows destined for DMZ hosts are deleted, so their query IDs can be reused for the requested L2-Aware pings.
Use the ping srv6-policy color color endpoint ipv6-address command syntax to launch a ping for an SRv6 policy matching a specific color and endpoint. The ping probe may optionally be targeted at a specific segment list of the SRv6 policy. When the segment list is not specified, the ping probe is sent on the lowest available segment list.
Parameters
- bypass-routing
-
Specifies whether to send the ping request to a host on a directly attached network, bypassing the routing table.
- bytes
-
Specifies the request packet size in bytes, expressed as a decimal integer.
- candidate-path
-
Specifies a candidate path of the SRv6 policy to ping. The candidate path does not need to be the currently active candidate path.
- centiseconds
-
Sets the interval in centiseconds.
- detail
-
Displays detailed information.
- distinguisher
- Specifies the distinguisher of the SRv6 policy candidate path to send the ping probe on. This parameter must be configured if protocol-owner is configured to bgp.
- do-not-fragment
-
Sets the DF (Do Not Fragment) bit in the ICMP ping packet (does not apply to ICMPv6).
- dns-name
-
Specifies the DNS name of the far-end device on which to send the svc-ping request message, expressed as a character string.
- fc-name
-
Specifies the forwarding class of the MPLS echo request packets.
- interface-name
-
Specifies the name of an IP interface. The name must already exist in the configure router interface context.
- ip-address
-
Specifies the far-end IP address, in dotted decimal notation, on which to send the svc-ping request message.
- next-hop ip-address
-
Displays only static routes with the specified next hop IP address.
- pattern
-
Specifies that the date portion in a ping packet that is filled with the pattern value specified. If not specified, position information is filled instead.
- preference
- Specifies the preference of the SRv6 policy candidate path to send the ping probe on.
- protocol-owner
- Specifies the protocol owner of the SRv6 policy candidate path to ping.
- rapid
-
Specifies that packets be generated as fast as possible instead of the default 1 per second. Changes the units for the interval command from seconds to centiseconds.
- requests
-
Specifies the number of times to perform an OAM ping probe operation. Each OAM echo message request must either time out or receive a reply before the next message request is sent.
- router-instance
-
Specifies the preferred method for entering a service name. Stored as the service name. This is the only service-linking function allowed for both mixed-mode and model-driven configuration modes.
- router-or-service
-
Specifies the routing instance or service, by number. The router-instance parameter is preferred for specifying the router or service.
- seconds
-
Overrides the default timeout value and is the amount of time that the router waits for a message reply after sending the message request. Upon the expiration of the message time out, the requesting router assumes that the message response is not received. A request timeout message is displayed by the CLI for each message request sent that expires. Any response received after the request times out is silently discarded.
- secs
-
Sets the interval in seconds.
- service-name
-
Specifies the alias function that allows the service-name to be used, converted, and stored as a service ID.
- sub-ident-string
-
Specifies the L2-Aware NAT subscriber to which ICMP-ping is sent, up to 32 characters. The subscriber-id keyword serves as a differentiator between the subscribers with the same IP address in the same routing context (which is allowed in L2-Aware NAT). The subscriber-id keyword is mandatory for L2-Aware IPv4 ping, but optional in generic ping framework.
- source ip-address
-
Specifies the IP address to be used.
- timeout
-
Specifies the time out, in seconds.
- type-of-service
-
Specifies the service type.
- time-to-live
-
Specifies the TTL value for the MPLS label, expressed as a decimal integer.
- srv6-policy
- Keyword to specify that the ping probe is applied to an SRv6 policy.
- color-id
- Specifies the SRv6 policy color ID.
- endpoint ipv6-address
- Specifies an endpoint as the target of the ping.
- segment-list
- Specifies the segment list to trace.
Platforms
All
ping-reply
ping-reply
Syntax
[no] ping-reply
Context
[Tree] (config>service>ies>if>ipv6>vrrp ping-reply)
Full Context
configure service ies interface ipv6 vrrp ping-reply
Description
This command enables the non-owner master to reply to ICMP echo requests directed at the virtual router instances IP addresses. The ping request can be received on any routed interface.
Ping must not have been disabled at the management security level (either on the parental Ip interface or based on the ping source host address). when ping-reply is not enabled, icmp Echo Requests to non-owner master virtual IP addresses are silently discarded.
Non-owner backup virtual routers never respond to ICMP echo requests regardless of the setting of ping-reply configuration.
The ping-reply command is only available in non-owner vrrp virtual-router-id nodal context. If the ping-reply command is not executed, ICMP echo requests to the virtual router instance IP addresses will be silently discarded.
The no form of this command restores the default operation of discarding all ICMP echo request messages destined to the non-owner virtual router instance IP addresses.
Default
no ping-reply
Platforms
All
ping-reply
Syntax
[no] ping-reply
Context
[Tree] (config>service>ies>if>vrrp ping-reply)
Full Context
configure service ies interface vrrp ping-reply
Description
This command enables the non-owner master to reply to ICMP Echo Requests directed at the virtual router instances IP addresses. The ping request can be received on any routed interface.
Ping must not have been disabled at the management security level (either on the parental IP interface or based on the Ping source host address). When ping-reply is not enabled, ICMP Echo Requests to non-owner master virtual IP addresses are silently discarded.
Non-owner backup virtual routers never respond to ICMP Echo Requests regardless of the setting of ping-reply configuration.
The ping-reply command is only available in non-owner vrrp virtual-router-id nodal context. If the ping-reply command is not executed, ICMP Echo Requests to the virtual router instance IP addresses will be silently discarded.
The no form of this command restores the default operation of discarding all ICMP Echo Request messages destined to the non-owner virtual router instance IP addresses.
Default
no ping-reply
Platforms
All
ping-reply
Syntax
[no] ping-reply
Context
[Tree] (config>service>vprn>if>ipv6>vrrp ping-reply)
[Tree] (config>service>vprn>if>vrrp ping-reply)
Full Context
configure service vprn interface ipv6 vrrp ping-reply
configure service vprn interface vrrp ping-reply
Description
This command enables the non-owner master to reply to ICMP Echo Requests directed at the virtual router instances IP addresses. The ping request can be received on any routed interface.
Ping must not have been disabled at the management security level (either on the parental IP interface or based on the Ping source host address). When ping-reply is not enabled, ICMP Echo Requests to non-owner master virtual IP addresses are silently discarded.
Non-owner backup virtual routers never respond to ICMP Echo Requests regardless of the setting of ping-reply configuration.
The ping-reply command is only available in non-owner vrrp virtual-router-id nodal context. If the ping-reply command is not executed, ICMP Echo Requests to the virtual router instance IP addresses will be silently discarded.
The no form of this command restores the default operation of discarding all ICMP Echo Request messages destined to the non-owner virtual router instance IP addresses.
Default
no ping-reply
Platforms
All
ping-reply
Syntax
[no] ping-reply
Context
[Tree] (config>router>if>ipv6>vrrp ping-reply)
[Tree] (config>router>if>vrrp ping-reply)
Full Context
configure router interface ipv6 vrrp ping-reply
configure router interface vrrp ping-reply
Description
This command enables the non-owner master to reply to ICMP echo requests directed at the virtual router instances IP addresses.
Non-owner virtual router instances are limited by the VRRP specifications to responding to ARP requests destined to the virtual router IP addresses and routing IP packets not addressed to the virtual router IP addresses. Many network administrators find this limitation frustrating when troubleshooting VRRP connectivity issues.
SR OS allows this access limitation to be selectively lifted for certain applications. Ping, Telnet and SSH can be individually enabled or disabled on a per-virtual-router-instance basis.
The ping-reply command enables the non-owner master to reply to ICMP echo requests directed at the virtual router instances IP addresses. The Ping request can be received on any routed interface. Ping must not have been disabled at the management security level (either on the parental IP interface or based on the Ping source host address).
When ping-reply is not enabled, ICMP echo requests to non-owner master virtual IP addresses are silently discarded.
Non-owner backup virtual routers never respond to ICMP echo requests regardless of the ping-reply setting.
The ping-reply command is only available in non-owner vrrp nodal context.
By default, ICMP echo requests to the virtual router instance IP addresses are silently discarded.
The no form of the command configures discarding all ICMP echo request messages destined to the non-owner virtual router instance IP addresses.
Default
no ping-reply — ICMP echo requests to the virtual router instance IP addresses are discarded.
Platforms
All
ping-template
ping-template
Syntax
ping-template template-name [create]
no ping-template template-name
Context
[Tree] (config>test-oam>icmp ping-template)
Full Context
configure test-oam icmp ping-template
Description
This command creates a ping-template that can be assigned to a VPRN or IES service IP interface.
The no form of this command removes the template name from the configuration.
Parameters
- template-name
-
Specifies the name of the ping template, up to 64 characters.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
ping-template
Syntax
ping-template template-name
no ping-template
Context
[Tree] (config>service>ies>if ping-template)
[Tree] (config>service>vprn>if ping-template)
Full Context
configure service ies interface ping-template
configure service vprn interface ping-template
Description
This command maps a ping-template name to the service IP interface. The ping-template template-name is configured in the config>test-oam>icmp context and assigned to the service IP interface using this command.
The config>service>ies|vprn>if>ping-template must be shut down to remove or change the destination-address value.
The no form of this command removes the template name from the configuration.
Parameters
- template-name
-
Specifies the name of the ping template to be assigned to the IP interface, up to 64 characters.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
ping-test
ping-test
Syntax
[no] ping-test
Context
[Tree] (config>filter>redirect-policy>dest ping-test)
Full Context
configure filter redirect-policy destination ping-test
Description
This command configures parameters to perform connectivity ping tests to validate the ability for the destination to receive redirected traffic.
Default
no ping-test
Platforms
All
pip
pip
Syntax
pip
Context
[Tree] (config>mcast-mgmt>mcast-info-plcy>video-policy>video-if pip)
Full Context
configure mcast-management multicast-info-policy video-policy video-interface pip
Description
Commands in this context configure within a video interface policy the properties relating to requests received by the video interface for Picture-in-Picture (PIP) channel requests.
Platforms
7450 ESS, 7750 SR, 7750 SR-s
pir
pir
Syntax
pir pir-rate
pir max
no pir
Context
[Tree] (config>subscr-mgmt>cat-map>category>exh-lvl pir)
Full Context
configure subscriber-mgmt category-map category exhausted-credit-service-level pir
Description
This command configures the PIR which is enforced for all queues pertaining to this category.
The no form of this command reverts to the default.
Parameters
- pir-rate
-
Specifies the amount of bandwidth in kilobits per second.
- max
-
Specifies to use the maximum amount of bandwidth.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
pir
Syntax
pir congested-pir
no pir
Context
[Tree] (config>app-assure>group>policer>congestion-override pir)
Full Context
configure application-assurance group policer congestion-override pir
Description
This command provides a mechanism to configure the PIR for the congestion override policer. It is recommended that the PIR is configured larger than twice the maximum MTU for the traffic handled by the policer to allow for some burstiness of the traffic.
The no form of this command resets the PIR value to its default.
Default
pir max
Parameters
- congested-pir
-
Specifies an integer value defining size, in kbytes, for the PIR of the policer.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
pir
Syntax
pir pir-rate
no pir
Context
[Tree] (config>app-assure>group>pol>cng-ovrd-stg2 pir)
Full Context
configure application-assurance group policer congestion-override-stage2 pir
Description
This command provides a mechanism to configure the PIR for the congestion override policer. It is recommended that the PIR is configured larger than twice the maximum MTU for the traffic handled by the policer to allow for some burstiness of the traffic.
The no form of this command resets the PIR value to its default.
Default
pir max
Parameters
- congested-pir
-
Specifies an integer value defining size, in kbytes, for the PIR of the policer.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
pir-threshold
pir-threshold
Syntax
pir-threshold kbps
no pir-threshold
Context
[Tree] (config>test-oam>sath>accept-crit-tmpl pir-threshold)
Full Context
configure test-oam service-activation-testhead acceptance-criteria-template pir-threshold
Description
This command configures a PIR value that is compared to the measured results for the cir- pir, policing, and performance test types. If the measured value is greater than or equal to the configured value, the test passes; otherwise, it fails. For more information, see the m-factor command.
The no form of this command disables the comparison of the parameter with the measured value; the threshold value is ignored while declaring the test result.
Default
no pir-threshold
Parameters
- kbps
-
Specifies the value, in kb/s, for comparison with the measured value.
Platforms
7450 ESS, 7750 SR, 7750 SR-s, 7950 XRS
pki
pki
Syntax
pki
Context
[Tree] (config>system>security pki)
Full Context
configure system security pki
Description
Commands in this context configure PKI related parameters.
Platforms
All
pkt-too-big
pkt-too-big
Syntax
[no] pkt-too-big
Context
[Tree] (config>service>ies>if>ipsec>ipsec-tunnel>icmp6-gen pkt-too-big)
[Tree] (config>ipsec>tnl-temp>icmp6-gen pkt-too-big)
[Tree] (config>router>if>ipsec-tunnel>icmp-gen pkt-too-big)
[Tree] (config>service>vprn>if>ipsec>ipsec-tunnel>icmp6-gen pkt-too-big)
[Tree] (config>service>vprn>if>sap>ipsec-tun>icmp6-gen pkt-too-big)
Full Context
configure service ies interface ipsec ipsec-tunnel icmp6-generation pkt-too-big
configure ipsec tunnel-template icmp6-generation pkt-too-big
configure router interface ipsec-tunnel icmp-gen pkt-too-big
configure service vprn interface ipsec ipsec-tunnel icmp6-generation pkt-too-big
configure service vprn interface sap ipsec-tunnel icmp6-generation pkt-too-big
Description
This command enables the system to send ICMPv6 PTB (Packet Too Big) messages on the private side and optionally specifies the rate.
With this command configured, the system sends PTB back if it received an IPv6 packet on the private side that is bigger than 1280 bytes and also exceeds the private MTU of the tunnel.
The ip-mtu command (under ipsec-tunnel or tunnel-template) specifies the private MTU for the ipsec-tunnel or dynamic tunnel.
The no form of this command reverts interval and message-count values to their default values.
Platforms
VSR
- configure service vprn interface ipsec ipsec-tunnel icmp6-generation pkt-too-big
- configure service ies interface ipsec ipsec-tunnel icmp6-generation pkt-too-big
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
- configure ipsec tunnel-template icmp6-generation pkt-too-big
- configure service vprn interface sap ipsec-tunnel icmp6-generation pkt-too-big
platform-type
platform-type
Syntax
platform-type type
no platform type
Context
[Tree] (config>system>ned>profile platform-type)
Full Context
configure system network-element-discovery profile platform-type
Description
This command configures the platform name and chassis type to be advertised.
The no form of this command removes any explicitly defined type and the default type of "chassis-name, chassis-type" is used.
Default
no platform-type
Parameters
- type
-
Specifies the platform type to be associates with the profile, up to 255 characters.
Platforms
All
pm-tti
pm-tti
Syntax
pm-tti
Context
[Tree] (config>port>otu pm-tti)
Full Context
configure port otu pm-tti
Description
Commands in this context configure path monitoring trail trace identifier parameters.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
pmt-repetition
pmt-repetition
Syntax
pcr-repetition [tnc tnc-milli-seconds qos qos-milli-seconds poa poa-milli-seconds]
no pcr-repetition
Context
[Tree] (config>mcast-mgmt>mcast-info-plcy>bundle>channel>video>analyzer>alarms pmt-repetition)
[Tree] (config>mcast-mgmt>mcast-info-plcy>bundle>channel>source-override>video>analyzer>alarms pmt-repetition)
[Tree] (config>mcast-mgmt>mcast-info-plcy>bundle>video>analyzer>alarms pmt-repetition)
Full Context
configure mcast-management multicast-info-policy bundle channel video analyzer alarms pmt-repetition
configure mcast-management multicast-info-policy bundle channel source-override video analyzer alarms pmt-repetition
configure mcast-management multicast-info-policy bundle video analyzer alarms pmt-repetition
Description
This command configures the analyzer to check for the program map table (PMT). It is expected that the PMT arrives periodically within a certain interval range. It is possible to configure the type of alarm that is raised when the PMT fails to arrive within the specified interval. As the delay increases between two consecutive PMTs, the type of alarm raised becomes more critical, from TNC to POA.
Default
no pmt-repetition
Parameters
- tnc-milli-seconds
-
Specifies the time, in milliseconds, for which a TNC alarm is raised if the interval between two consecutive PMTs is greater than or equal to this configured value.
- qos-milli-seconds
-
Specifies the time, in milliseconds, for which a QoS alarm is raised if the interval between two consecutive PMTs is greater than or equal to this configured value.
- poa-milli-seconds
-
Specifies the time, in milliseconds, for which a POA alarm is raised if the interval between two consecutive PMTs is greater than or equal to this configured value.
Platforms
7450 ESS, 7750 SR, 7750 SR-s
pmt-syntax
pmt-syntax
Syntax
[no] pat-syntax
Context
[Tree] (config>mcast-mgmt>mcast-info-plcy>bundle>channel>source-override>video>analyzer>alarms pmt-syntax)
[Tree] (config>mcast-mgmt>mcast-info-plcy>bundle>channel>video>analyzer>alarms pmt-syntax)
[Tree] (config>mcast-mgmt>mcast-info-plcy>bundle>video>analyzer>alarms pmt-syntax)
Full Context
configure mcast-management multicast-info-policy bundle channel source-override video analyzer alarms pmt-syntax
configure mcast-management multicast-info-policy bundle channel video analyzer alarms pmt-syntax
configure mcast-management multicast-info-policy bundle video analyzer alarms pmt-syntax
Description
This command configures the analyzer to check for PMT syntax errors.
Default
no pmt-syntax
Platforms
7450 ESS, 7750 SR, 7750 SR-s
pmtu-discovery-aging
pmtu-discovery-aging
Syntax
pmtu-discovery-aging seconds
no pmtu-discovery-aging
Context
[Tree] (config>service>ies>if>sap>ip-tunnel pmtu-discovery-aging)
[Tree] (config>service>vprn>if>ipsec>ipsec-tunnel pmtu-discovery-aging)
[Tree] (config>service>vprn>if>sap>ip-tunnel pmtu-discovery-aging)
[Tree] (config>service>vprn>if>sap>ipsec-tunnel pmtu-discovery-aging)
[Tree] (config>ipsec>tnl-temp pmtu-discovery-aging)
[Tree] (config>router>if>ipsec>ipsec-tunnel pmtu-discovery-aging)
[Tree] (config>service>ies>if>ipsec>ipsec-tunnel pmtu-discovery-aging)
Full Context
configure service ies interface sap ip-tunnel pmtu-discovery-aging
configure service vprn interface ipsec ipsec-tunnel pmtu-discovery-aging
configure service vprn interface sap ip-tunnel pmtu-discovery-aging
configure service vprn interface sap ipsec-tunnel pmtu-discovery-aging
configure ipsec tunnel-template pmtu-discovery-aging
configure router interface ipsec ipsec-tunnel pmtu-discovery-aging
configure service ies interface ipsec ipsec-tunnel pmtu-discovery-aging
Description
This command configures the time used to age out the learned temporary MTU which is from the public network. The temporary MTU is used for MTU propagation.
The no form of of this command reverts to the default value.
Default
pmtu-discovery-aging 900
Parameters
- seconds
-
specifies the time, in seconds, used to age out the learned MTU
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
- configure service vprn interface sap ip-tunnel pmtu-discovery-aging
- configure service ies interface sap ip-tunnel pmtu-discovery-aging
- configure service vprn interface sap ipsec-tunnel pmtu-discovery-aging
- configure ipsec tunnel-template pmtu-discovery-aging
VSR
- configure service ies interface ipsec ipsec-tunnel pmtu-discovery-aging
- configure router interface ipsec ipsec-tunnel pmtu-discovery-aging
- configure service vprn interface ipsec ipsec-tunnel pmtu-discovery-aging
poi-tlv-enable
poi-tlv-enable
Syntax
[no] poi-tlv-enable
Context
[Tree] (config>service>vprn>isis poi-tlv-enable)
Full Context
configure service vprn isis poi-tlv-enable
Description
Enable use of Purge Originator Identification (POI) TLV for this IS-IS instance. The POI is added to purges and contains the system ID of the router that generated the purge, which simplifies troubleshooting and determining what caused the purge.
The no form of this command removes the POI functionality from the configuration.
Default
no poi-tlv-enable
Platforms
All
poi-tlv-enable
Syntax
[no] poi-tlv-enable
Context
[Tree] (config>router>isis poi-tlv-enable)
Full Context
configure router isis poi-tlv-enable
Description
Enable use of Purge Originator Identification (POI) TLV for this IS-IS instance. The POI is added to purges and contains the system ID of the router that generated the purge, which simplifies troubleshooting and determining what caused the purge.
The no form of this command removes the POI functionality from the configuration.
Default
no poi-tlv-enable
Platforms
All
policer
policer
Syntax
policer policer-id {ingress-only | egress-only | ingress-egress}
no policer policer-id
Context
[Tree] (config>subscr-mgmt>cat-map>category policer)
Full Context
configure subscriber-mgmt category-map category policer
Description
This command configures a policer in this category.
The no form of this command reverts to the default.
Parameters
- policer-id
-
Specifies an existing policer identifier.
- ingress-only
-
Specifies that ingress policers are defined in this category.
- egress-only
-
Specifies that egress policers are defined in this category.
- ingress-egress
-
Specifies that ingress and egress policers are defined in this category.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
policer
Syntax
[no] policer policer-id
Context
[Tree] (config>subscr-mgmt>sla-prof>csg>egress>policers policer)
Full Context
configure subscriber-mgmt sla-profile custom-statistics-group egress policers policer
Description
This command configures the IDs of the static policers to include for custom statistics for the group.
The no form of this command removes the configuration of the policer ID for custom statistics.
Parameters
- policer-id
-
Specifies the policer ID.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
policer
Syntax
[no] policer policer-id
Context
[Tree] (config>subscr-mgmt>sla-prof>egress>qos policer)
[Tree] (config>subscr-mgmt>sla-prof>ingress>qos policer)
Full Context
configure subscriber-mgmt sla-profile egress qos policer
configure subscriber-mgmt sla-profile ingress qos policer
Description
This command is used in the sap-ingress and sap-egress QoS policies to create, modify or delete a policer. Policers are created and used in a similar manner to queues. The policer ID space is separate from the queue ID space, allowing both a queue and a policer to share the same ID. The sap-ingress policy may have up to 32 policers (numbered 1 through 32) may be defined while the sap-egress QoS policy supports a maximum of 8 (numbered 1 through 8). While a policer may be defined within a QoS policy, it is not actually created on SAPs or subscribers associated with the policy until a forwarding class is mapped to the policer’s ID.
All policers must be created within the QoS policies. A default policer is not created when a sap-ingress or sap-egress QoS policy is created.
Once a policer is created, the policer's metering rate and profiling rates may be defined as well as the policer's maximum and committed burst sizes (MBS and CBS respectively). Unlike queues which have dedicated counters, policers allow various stat-mode settings that define the counters that is associated with the policer. Another supported feature—packet-byte-offset—provides a policer with the ability to modify the size of each packet based on a defined number of bytes.
Once a policer is created, it cannot be deleted from the QoS policy unless any forwarding classes that are mapped to the policer are first moved to other policers or queues.
The system will allow a policer to be created on a SAP QoS policy regardless of the ability to support policers on objects where the policy is currently applied. The system only scans the current objects for policer support and sufficient resources to create the policer when a forwarding class is first mapped to the policer ID. If the policer cannot be created due to one or more instances of the policy not supporting policing or having insufficient resources to create the policer, the forwarding class mapping will fail.
The no form of this command is used to delete a policer from a sap-ingress or sap-egress QoS policy. The specified policer cannot currently have any forwarding class mappings for the removal of the policer to succeed. It is not necessary to actually delete the policer ID for the policer instances to be removed from SAPs or subscribers associated with the QoS policy once all forwarding classes have been moved away from the policer. It is automatically deleted from each policing instance although it still appears in the QoS policy.
Parameters
- policer-id
-
Specifies the policer ID. The policer-id must be specified when executing the policer command. If the specified ID already exists, the system enters that policer's context to allow the policer’s parameters to be modified. If the ID does not exist and is within the allowed range for the QoS policy type, a context for the policer ID is created (depending on the system's current create keyword requirements which may require the create keyword to actually add the new policer ID to the QoS policy) and the system will enter that new policer’s context for possible parameter modification.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
policer
Syntax
policer policer-name
no policer
Context
[Tree] (config>service>ies>sub-if>grp-if>wlan-gw>ranges>range>vrgw>lanext>network policer)
[Tree] (config>service>vprn>sub-if>grp-if>wlan-gw>ranges>range>vrgw>lanext>network policer)
Full Context
configure service ies subscriber-interface group-interface wlan-gw vlan-tag-ranges range vrgw lanext network policer
configure service vprn subscriber-interface group-interface wlan-gw vlan-tag-ranges range vrgw lanext network policer
Description
This command configures an ISA policer for HLE network (such as DC) access facing connection traffic, per tunnel.
The no form of this command removes the policer name from the configuration.
Default
no policer
Parameters
- policer-name
-
Specifies the name of the policer, up to 32 characters.
Platforms
7750 SR, 7750 SR-e, 7750 SR-s, VSR
policer
Syntax
policer policer-name
no policer
Context
[Tree] (config>service>ies>sub-if>grp-if>wlan-gw>ranges>range>vrgw>lanext>access policer)
[Tree] (config>service>vprn>sub-if>grp-if>wlan-gw>ranges>range>vrgw>lanext>access policer)
Full Context
configure service ies subscriber-interface group-interface wlan-gw vlan-tag-ranges range vrgw lanext access policer
configure service vprn subscriber-interface group-interface wlan-gw vlan-tag-ranges range vrgw lanext access policer
Description
This command configures an ISA policer for HLE ingress (such as home) access facing connection traffic, per tunnel
The no form of this command removes the policer name from the configuration.
Default
no policer
Parameters
- policer-name
-
Specifies the name of the policer, up to 32 characters.
Platforms
7750 SR, 7750 SR-e, 7750 SR-s, VSR
policer
Syntax
policer policer-id [create]
no policer policer-id
Context
[Tree] (config>card>fp>ingress>network>qgrp>policer-over policer)
[Tree] (config>card>fp>ingress>access>qgrp>policer-over policer)
Full Context
configure card fp ingress network queue-group policer-override policer
configure card fp ingress access queue-group policer-override policer
Description
This command creates, modifies or deletes a policer. Policers are created and used in a similar manner to queues. The policer ID space is separate from the queue ID space, allowing both a queue and a policer to share the same ID. The sap-ingress policy may have up to 32 policers (numbered 1 through 32) may be defined while the sap-egress QoS policy supports a maximum of 8 (numbered 1 through 8). While a policer may be defined within a QoS policy, it is not actually created on SAPs or subscribers associated with the policy until a forwarding class is mapped to the policer’s ID.
All policers must be created within the QoS policies. A default policer is not created when a sap-ingress or sap-egress QoS policy is created.
Once a policer is created, the policer's metering rate and profiling rates may be defined as well as the policer's maximum and committed burst sizes (MBS and CBS respectively). Unlike queues which have dedicated counters, policers allow various stat-mode settings that define the counters that will be associated with the policer. Another supported feature—packet-byte-offset—provides a policer with the ability to modify the size of each packet based on a defined number of bytes.
Once a policer is created, it cannot be deleted from the QoS policy unless any forwarding classes that are mapped to the policer are first moved to other policers or queues.
The system will allow a policer to be created on a SAP QoS policy regardless of the ability to support policers on objects where the policy is currently applied. The system only scans the current objects for policer support and sufficient resources to create the policer when a forwarding class is first mapped to the policer ID. If the policer cannot be created due to one or more instances of the policy not supporting policing or having insufficient resources to create the policer, the forwarding class mapping fails.
The no form of this command deletes a policer from a sap-ingress or sap-egress QoS policy. The specified policer cannot currently have any forwarding class mappings for the removal of the policer to succeed. It is not necessary to actually delete the policer ID for the policer instances to be removed from SAPs or subscribers associated with the QoS policy once all forwarding classes have been moved away from the policer. It is automatically deleted from each policing instance although it still appears in the QoS policy.
Parameters
- policer-id
-
Specifies that the policer-id must be specified when executing the policer command. If the specified ID already exists, the system enters that policer's context to allow the policer’s parameters to be modified. If the ID does not exist and is within the allowed range for the QoS policy type, a context for the policer ID will be created (depending on the system's current create keyword requirements which may require the create keyword to actually add the new policer ID to the QoS policy) and the system will enter that new policer’s context for possible parameter modification.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer
Syntax
policer policer-id [create]
no policer policer-id
Context
[Tree] (config>service>ipipe>sap>ingress>policer-over policer)
[Tree] (config>service>epipe>sap>egress>policer-over policer)
[Tree] (config>service>ipipe>sap>egress>policer-over policer)
[Tree] (config>service>cpipe>sap>egress>policer-over policer)
[Tree] (config>service>cpipe>sap>ingress>policer-over policer)
Full Context
configure service ipipe sap ingress policer-override policer
configure service epipe sap egress policer-override policer
configure service ipipe sap egress policer-override policer
configure service cpipe sap egress policer-override policer
configure service cpipe sap ingress policer-override policer
Description
This command, within the SAP ingress or egress contexts, is used to create a CLI node for specific overrides to a specific policer created on the SAP through a sap-ingress or sap-egress QoS policy.
The no form of this command is used to remove any existing overrides for the specified policer-id.
Parameters
- policer-id
-
The policer-id parameter is required when executing the policer command within the policer-overrides context. The specified policer-id must exist within the sap-ingress or sap-egress QoS policy applied to the SAP. If the policer is not currently used by any forwarding class or forwarding type mappings, the policer will not actually exist on the SAP. This does not preclude creating an override context for the policer-id.
- create
-
The create keyword is required when a policer policer-id override node is being created and the system is configured to expect explicit confirmation that a new object is being created. When the system is not configured to expect explicit confirmation, the create keyword is not required.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
- configure service epipe sap egress policer-override policer
- configure service ipipe sap ingress policer-override policer
- configure service ipipe sap egress policer-override policer
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS
- configure service cpipe sap egress policer-override policer
- configure service cpipe sap ingress policer-override policer
policer
Syntax
policer policer-id [create]
no policer policer-id
Context
[Tree] (config>service>vpls>sap>egress>policer-override policer)
[Tree] (config>service>vpls>sap>ingress>policer-override policer)
Full Context
configure service vpls sap egress policer-override policer
configure service vpls sap ingress policer-override policer
Description
This command, within the SAP ingress or egress contexts, is used to create a CLI node for specific overrides to a specific policer created on the SAP through a sap-ingress or sap-egress QoS policy.
The no form of this command is used to remove any existing overrides for the specified policer-id.
Parameters
- policer-id
-
The policer-id parameter is required when executing the policer command within the policer-overrides context. The specified policer-id must exist within the sap-ingress or sap-egress QoS policy applied to the SAP. If the policer is not currently used by any forwarding class or forwarding type mappings, the policer will not actually exist on the SAP. This does not preclude creating an override context for the policer-id.
- create
-
The create keyword is required when a policer policer-id override node is being created and the system is configured to expect explicit confirmation that a new object is being created. When the system is not configured to expect explicit confirmation, the create keyword is not required.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer
Syntax
policer policer-id [create]
no policer policer-id
Context
[Tree] (config>service>ies>if>sap>egress>policer-override policer)
[Tree] (config>service>ies>if>sap>ingress>policer-override policer)
Full Context
configure service ies interface sap egress policer-override policer
configure service ies interface sap ingress policer-override policer
Description
This command, within the SAP ingress or egress contexts, is used to create a CLI node for specific overrides to a specific policer created on the SAP through a sap-ingress or sap-egress QoS policy.
The no form of this command is used to remove any existing overrides for the specified policer-id.
Parameters
- policer-id
-
This parameter is required when executing the policer command within the policer-override context. The specified policer-id must exist within the sap-ingress or sap-egress QoS policy applied to the SAP. If the policer is not currently used by any forwarding class or forwarding type mappings, the policer will not actually exist on the SAP. This does not preclude creating an override context for the policer-id.
- create
-
The create keyword is required when a policer override node is being created and the system is configured to expect explicit confirmation that a new object is being created. When the system is not configured to expect explicit configuration, the create keyword is not required.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer
Syntax
policer policer-id [create]
no policer policer-id
Context
[Tree] (config>service>vprn>if>sap>egress>policer-override policer)
[Tree] (config>service>vprn>if>sap>ingress>policer-override policer)
Full Context
configure service vprn interface sap egress policer-override policer
configure service vprn interface sap ingress policer-override policer
Description
This command, within the SAP ingress or egress contexts, is used to create a CLI node for specific overrides to a specific policer created on the SAP through a sap-ingress or sap-egress QoS policy.
The no form of this command is used to remove any existing overrides for the specified policer-id.
Parameters
- policer-id
-
This parameter is required when executing the policer command within the policer-override context. The specified policer-id must exist within the sap-ingress or sap-egress QoS policy applied to the SAP. If the policer is not currently used by any forwarding class or forwarding type mappings, the policer will not actually exist on the SAP. This does not preclude creating an override context for the policer-id.
- create
-
The create keyword is required when a policer override node is being created and the system is configured to expect explicit confirmation that a new object is being created. When the system is not configured to expect explicit configuration, the create keyword is not required.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer
Syntax
policer policer-name type type granularity granularity [create]
policer policer-name
no policer policer-name
Context
[Tree] (config>app-assure>group policer)
Full Context
configure application-assurance group policer
Description
This command creates application assurance policer profile of a specified type. Policers can be bandwidth or flow limiting and can have a system scope (limits traffic entering AA ISA for all or a subset of AA subscribers), subscriber scope or granularity (limits apply to each AA subscriber traffic).
The policer type and granularity can only be configured during creation. They cannot be modified. The policer profile must be removed from all AQPs in order to be removed. Changes to policer profile parameters take effect immediately for policers instantiated as result of AQP actions using this profile.
The no form of this command deletes the specified policer from the configuration.
Parameters
- policer-name
-
Specifies a string of up to 32 characters that identifies the policer.
- type
-
Specifies the policer type.
- granularity
-
Specifies the granularity type.
- create
-
Keyword used to create the policer name and parameters.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
policer
Syntax
policer policer-name direction direction [create]
no policer policer-name direction direction
Context
[Tree] (config>app-assure>group>statistics>tca policer)
Full Context
configure application-assurance group statistics threshold-crossing-alert policer
Description
This command configures a TCA for the counter capturing drops or admit events due to the specified flow policer. A policer TCA can be created for traffic generated from the subscriber side of AA ( from-sub) or for traffic generated from the network toward the AA subscriber (to-sub). The create keyword is mandatory when creating a policer TCA.
Parameters
- policer-name
-
Specifies the name of the flow policer, up to 32 characters
- direction
-
Specifies the traffic direction.
- create
-
Keyword used to create the TCA.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
policer
Syntax
policer policer-id [fp-redirect-group]
no policer
Context
[Tree] (config>qos>sap-ingress>fc policer)
Full Context
configure qos sap-ingress fc policer
Description
Within a sap-ingress QoS policy forwarding class context, the policer command is used to map packets that match the forwarding class and are considered unicast in nature to the specified policer-id. The specified policer-id must already exist within the sap-ingress QoS policy. While the system is determining the forwarding class of a packet, it is also looking up its forwarding destination. If ingress forwarding logic has resolved a unicast destination (the packet does not need to be sent to multiple destinations), it is considered to be a unicast packet and will be mapped to either an ingress queue (using the queue queue-id or queue queue-id group ingress-queue-group commands) or an ingress policer ( policer policer-id). The queue and policer commands within the forwarding class context are mutually exclusive. By default, the unicast forwarding type is mapped to the SAP ingress default queue (queue 1). If the policer policer-id command is executed, any previous policer mapping or queue mapping for the unicast forwarding type within the forwarding class is overridden if the policer mapping is successful.
A policer defined within the sap-ingress policy is not actually created on an ingress SAP or a subscriber using an sla-profile where the policy is applied until at least one forwarding type (unicast, broadcast, unknown, or multicast) from one of the forwarding classes is mapped to the policer. If insufficient policer resources exist to create the policer for a SAP or subscriber or multiservice site or ingress policing is not supported on the port associated with the SAP or subscriber or multiservice site, the initial forwarding class forwarding type mapping will fail.
When the unicast forwarding type within a forwarding class is mapped to a policer, the unicast packets classified to the subclasses within the forwarding class are also mapped to the policer.
The no form of this command is used to restore the mapping of the unicast forwarding type within the forwarding class to the default queue. If all forwarding class forwarding types had been removed from the default queue, the queue will not exist on the SAPs or subscriber or multiservice sites associated with the QoS policy and the no policer command will cause the system to attempt to create the default queue on each object. If the system cannot create the default queue in each instance, the no policer command will fail and the unicast forwarding type within the forwarding class will continue its mapping to the existing policer-id. If the no policer command results in a policer without any current mappings, the policer will be removed from the SAPs and subscribers associated with the QoS policy. All statistics associated with the policer on each SAP and subscriber will be lost.
Parameters
- policer-id
-
When the forwarding class policer command is executed, a valid policer-id must be specified. The parameter policer-id references a policer-id that has already been created within the sap-ingress QoS policy.
- fp-redirect-group
-
Redirects a forwarding class to a forwarding plane queue-group as specified in a SAP QoS policy.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer
Syntax
policer policer-id [create]
no policer policer-id
Context
[Tree] (config>qos>sap-ingress policer)
Full Context
configure qos sap-ingress policer
Description
This command is used in the sap-ingress and sap-egress QoS policies to create, modify, or delete a policer. Policers are created and used in a similar manner to queues. The policer ID space is separate from the queue ID space, allowing both a queue and a policer to share the same ID. The sap-ingress policy may be defined to have up to 63 policers (numbered 1 through 63) while the sap-egress QoS policy supports a maximum of 8 (numbered 1 through 8). While a policer may be defined within a QoS policy, it is not actually created on SAPs or subscribers or multiservice sites associated with the policy until a forwarding class is mapped to the policer’s ID.
All policers must be created within the QoS policies. A default policer is not created when a sap-ingress or sap-egress QoS policy is created.
When a policer is created, the policer's metering rate and profiling rates may be defined as well as the policer's maximum and committed burst sizes (MBS and CBS, respectively). Unlike queues that have dedicated counters, policers allow various stat-mode settings that define the counters that will be associated with the policer. Another supported feature—packet-byte-offset—provides a policer with the ability to modify the size of each packet, based on a defined number of bytes.
When a policer is created, it cannot be deleted from the QoS policy unless any forwarding classes that are mapped to the policer are first moved to other policers or queues.
The system will allow a policer to be created on a SAP QoS policy regardless of the ability to support policers on objects where the policy is currently applied. The system only scans the current objects for policer support and sufficient resources to create the policer when a forwarding class is first mapped to the policer ID. If the policer cannot be created due to one or more instances of the policy not supporting policing or having insufficient resources to create the policer, the forwarding class mapping will fail.
The no form of this command is used to delete a policer from a sap-ingress or sap-egress QoS policy. The specified policer cannot currently have any forwarding class mappings for the removal of the policer to succeed. It is not necessary to actually delete the policer ID for the policer instances to be removed from SAPs or subscriber or multiservice sites associated with the QoS policy when all forwarding classes have been moved away from the policer. It is automatically deleted from each policing instance although it still appears in the QoS policy.
Parameters
- policer-id
-
The policer-id must be specified when executing the policer command. If the specified ID already exists, the system enters that policer's context to allow the policer’s parameters to be modified. If the ID does not exist and is within the allowed range for the QoS policy type, a context for the policer ID will be created (depending on the system's current create keyword requirements, which may require the create keyword to actually add the new policer ID to the QoS policy) and the system will enter that new policer’s context for possible parameter modification.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer
Syntax
policer policer-id [{[port-redirect-group-queue] [queue queue-id] | group group-name [instance instance-id] [queue queue-id]}]
no policer
Context
[Tree] (config>qos>sap-egress>fc policer)
Full Context
configure qos sap-egress fc policer
Description
Within a sap-egress QoS policy forwarding class context, the policer command is used to map packets that match the forwarding class to the specified policer-id. The specified policer-id must already exist within the sap-egress QoS policy. The forwarding class of the packet is first discovered at ingress, based on the ingress classification rules. When the packet arrives at egress, the sap-egress QoS policy may match a forwarding class reclassification rule that overrides the ingress derived forwarding class. The forwarding class context within the sap-egress QoS policy is then used to map the packet to an egress queue (using the queue queue-id, or port-redirect-group queue queue-id, or group queue-group-name instance instance-id queue queue-id commands) or an egress policer (policer policer-id). The queue and policer commands within the forwarding class context are mutually exclusive. By default, the forwarding class is mapped to the SAP egress default queue (queue 1). If the policer policer- id command is executed, any previous policer mapping or queue mapping for the forwarding class is overridden if the policer mapping is successful.
A policer defined within the sap-egress policy is not actually created on an egress SAP, or a subscriber using an SLA profile where the policy is applied, until at least one forwarding class is mapped to the policer. If insufficient policer resources exist to create the policer for a SAP or subscriber, or egress policing is not supported on the port associated with the SAP or subscriber, the initial forwarding class mapping will fail.
Packets that are mapped to an egress policer that are not discarded by the policer must be placed into a default queue on the packet’s destination port. The system uses egress port queue groups for this purpose. An egress queue group named policer-output-queues is automatically created on each port that supports egress policers. By default, the system uses the forwarding class mappings within this queue group to decide which queue within the group will receive each packet output from the policer. This default policer output queuing behavior may be overridden for non-subscriber packets by redirection to a queue group. The name and instance of the queue group to redirect to is either specified in the QoS policy, or the fact that a forwarding class must be redirected is identified in the QoS policy and the specific queue group instance is only identified at the time the QoS policy is applied:
-
If the policer policer-id command is successfully executed, the default egress queuing is performed for the forwarding class using the policer-output-queues queue group and the queue-id within the group based on the forwarding class map from the group template.
-
If the policer policer-id queue queue-id command is successfully executed, the specified SAP queue-id within the egress QoS policy is used instead of the default policer output queues.
-
If the policer policer-id port-redirect-group-queue keyword is successfully executed, the system will map the forwarding class to the queue within the egress queue group instance specified at the time the QoS policy is applied to the SAP, using the forwarding class map from the queue group template.
-
If the policer policer-id port-redirect-group queue queue-id command is successfully executed, the system will map the forwarding class to the configured queue-id within the egress queue group instance that is specified at the time the QoS policy is applied to the SAP (ignoring using the forwarding class map from the queue group template).
-
If the policer policer-id group queue-group-name instance instance-id command is successfully executed, the system will map the forwarding class to the queue within the specified egress queue group instance using the forwarding class map from the group template.
-
If the policer policer-id group queue-group-name instance instance-id queue queue-id command is successfully executed, the system will map the forwarding class to the specified queue-id within the specified egress queue group instance (ignoring the forwarding class map in the group template).
If the specified group group-name is not defined as an egress queue-group-template, the policer command will fail. Also, if the specified group does not exist on the port for the SAPs or subscribers associated with the sap-egress QoS policy, the policer command will fail. While a group queue-group-name is specified in a sap-egress QoS policy, the groups corresponding egress template cannot be deleted. While a port egress queue group is associated with a policer instance, the port queue group cannot be deleted.
If the specified queue queue-id is not defined in the egress queue-group-template queue-group- name, the policer command will fail. While a queue-id within an egress queue group template is referenced by a sap-egress QoS policy forwarding class policer command, the queue cannot be deleted from the queue group template.
If an egress policed packet is discarded by the egress port queue group queue, the source policer discard stats are incremented. This means that the discard counters for the policer represent both the policer discard events and the destination queue drop tail events associated with the policer.
The no form of this command is used to restore the mapping of the forwarding class to the default queue. If all forwarding classes have been removed from the default queue, the queue will not exist on the SAPs or subscribers associated with the QoS policy and the no policer command will cause the system to attempt to create the default queue on each object. If the system cannot create the default queue in each instance, the no policer command will fail and the forwarding class will continue its mapping to the existing policer-id. If the no policer command results in a policer without any current mappings, the policer will be removed from the SAPs and subscribers associated with the QoS policy. All statistics associated with the policer on each SAP and subscribers will be lost.
Default
no policer
Parameters
- policer-id
-
When the forwarding class policer command is executed, a valid policer-id must be specified. The parameter policer-id references a policer-id that has already been created within the sap-egress QoS policy.
- port-redirect-group-queue
-
Used to override the forwarding class default egress queue destination to an egress port queue group. The specific egress queue group instance to use is specified at the time the QoS policy is applied to the SAP. Therefore, this parameter is only valid if SAP-based redirection is required.
- queue queue-id
-
This parameter overrides the forwarding class default egress queue destination to a specified queue-id. If port-redirect-group is not configured, this will be a local SAP queue of that queue-id. A queue of ID queue-id must exist within the egress QoS policy. If port-redirect-group-queue is configured, the queue queue-id in the egress port queue group instance is used.
- group group-name
-
The group queue-group-name is optional and is used to override the forwarding class's default egress queue destination. If the queue group-queue-id parameter is not specified, the forwarding class map within the specified group's template is used to derive which queue within the group will receive the forwarding class's packets. An egress queue group template must exist for the specified queue-group-name or the policer command will fail. The specified queue-group-name must also exist as an egress queue group on the ports where SAPs and subscribers associated with the sap-egress policy are applied or the policer command will fail.
- queue queue-id
-
The queue group-queue-id is optional when the group queue-group-name parameter is specified and is used to override the forwarding class mapping within the group's egress queue group template. The specified group-queue-id must exist within the group's egress queue group template or the policer command will fail.
- instance instance-id
-
This parameter is used to specify the specific instance of a queue group with template queue-group-name to which this queue should be redirected. This parameter is only valid for queue groups on egress ports where policy-based redirection is required.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer
Syntax
policer policer-id [create]
no policer
Context
[Tree] (config>qos>sap-egress policer)
Full Context
configure qos sap-egress policer
Description
A policer defined within the sap-egress policy is not actually created on an egress SAP, or a subscriber using an SLA profile where the policy is applied, until at least one forwarding class is mapped to the policer. If insufficient policer resources exist to create the policer for a SAP or subscriber, or egress policing is not supported on the port associated with the SAP or subscriber, the initial forwarding class mapping will fail.
Packets that are mapped to an egress policer that are not discarded by the policer must be placed into a default queue on the packet’s destination port. The system uses egress port queue groups for this purpose. An egress queue group named policer-output-queues is automatically created on each port that supports egress policers. By default, the system uses the forwarding class mappings within this queue group to decide which queue within the group will receive each packet output from the policer. This default policer output queuing behavior may be overridden for non-subscriber packets by redirection to a queue group. The name and instance of the queue group to redirect to is either specified in the QoS policy, or the fact that a forwarding class must be redirected is identified in the QoS policy and the specific queue group instance is only identified at the time the QoS policy is applied:
-
If the policer policer-id command is successfully executed, the default egress queuing is performed for the forwarding class using the policer-output-queues queue group and the queue-id within the group based on the forwarding class map from the group template.
-
If the policer policer-id queue queue-id command is successfully executed, the specified SAP queue-id within the egress QoS policy is used instead of the default policer output queues.
-
If the policer policer-id port-redirect-group-queue keyword is successfully executed, the system will map the forwarding class to the queue within the egress queue group instance specified at the time the QoS policy is applied to the SAP, using the forwarding class map from the queue group template.
-
If the policer policer-id port-redirect-group queue queue-id command is successfully executed, the system will map the forwarding class to the configured queue-id within the egress queue group instance that is specified at the time the QoS policy is applied to the SAP (ignoring using the forwarding class map from the queue group template).
-
If the policer policer-id group queue-group-name instance instance-id command is successfully executed, the system will map the forwarding class to the queue within the specified egress queue group instance using the forwarding class map from the group template.
-
If the policer policer-id group queue-group-name instance instance-id queue queue-id command is successfully executed, the system will map the forwarding class to the specified queue-id within the specified egress queue group instance (ignoring the forwarding class map in the group template).
If the specified group group-name is not defined as an egress queue-group-template, the policer command will fail. Also, if the specified group does not exist on the port for the SAPs or subscribers associated with the sap-egress QoS policy, the policer command will fail. While a group queue-group-name is specified in a sap-egress QoS policy, the groups corresponding egress template cannot be deleted. While a port egress queue group is associated with a policer instance, the port queue group cannot be deleted.
If the specified queue queue-id is not defined in the egress queue-group-template queue-group- name, the policer command will fail. While a queue-id within an egress queue group template is referenced by a sap-egress QoS policy forwarding class policer command, the queue cannot be deleted from the queue group template.
If an egress policed packet is discarded by the egress port queue group queue, the source policer discard stats are incremented. This means that the discard counters for the policer represent both the policer discard events and the destination queue drop tail events associated with the policer.
The no form of this command is used to restore the mapping of the forwarding class to the default queue. If all forwarding classes have been removed from the default queue, the queue will not exist on the SAPs or subscribers associated with the QoS policy and the no policer command will cause the system to attempt to create the default queue on each object. If the system cannot create the default queue in each instance, the no policer command will fail and the forwarding class will continue its mapping to the existing policer-id. If the no policer command results in a policer without any current mappings, the policer will be removed from the SAPs and subscribers associated with the QoS policy. All statistics associated with the policer on each SAP and subscribers will be lost.
Default
no policer
Parameters
- policer-id
-
When the forwarding class policer command is executed, a valid policer-id must be specified. The parameter policer-id references a policer-id that has already been created within the sap-egress QoS policy.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer
Syntax
policer policer-id [create]
no policer policer-id
Context
[Tree] (cfg>qos>qgrps>egr>queue-group policer)
[Tree] (config>qos>qgrps>ing>queue-group policer)
Full Context
configure qos queue-group-templates egress queue-group policer
configure qos queue-group-templates ingress queue-group policer
Description
This command is used in ingress and egress queue-group templates to create, modify, or delete a policer.
Policers are created and used in a similar manner to queues. The policer ID space is separate from the queue ID space, allowing both a queue and a policer to share the same ID. While a policer may be defined in a queue-group template, it is not actually created until the queue-group template is instantiated on the ingress context of a forwarding plane or on the egress context of a port.
When a policer is created, the policer's metering rate and profiling rates may be defined, as well as the policer's maximum and committed burst sizes (MBS and CBS, respectively). Unlike queues that have dedicated counters, policers allow various stat-mode settings that define the counters that will be associated with the policer. Another supported feature—packet-byte-offset—provides a policer with the ability to modify the size of each packet based on a defined number of bytes.
When a policer is created, it cannot be deleted from the queue-group template unless any forwarding classes that are redirected to the policer are first removed.
The no version of this command deletes the policer.
Parameters
- policer-id
-
The policer-id must be specified when executing the policer command. If the specified ID already exists, the system enters that policer's context to allow the policer’s parameters to be modified. If the ID does not exist and is within the allowed range for the QoS policy type, a context for the policer ID will be created (depending on the system's current create keyword requirements, which may require the create keyword to actually add the new policer ID to the QoS policy) and the system enters that new policer’s context for possible parameter modification.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer
Syntax
[no] policer policer-id
Context
[Tree] (config>log>acct-policy>cr policer)
Full Context
configure log accounting-policy custom-record policer
Description
This command creates a policer context for which counters should be included in the custom-record.
The no form of this command deletes the policer and its counters from the custom-record.
Parameters
- policer-id
-
Specifies the policer for which counters should be included in or deleted from the custom-record.
Platforms
All
policer
Syntax
[no] policer policer-id
Context
[Tree] (config>router>policy-acct-template policer)
Full Context
configure router policy-acct-template policer
Description
Commands in this context configure policer index information. Each policy accounting template supports up to 63 policers.
Policing by action of a policy accounting template is only supported by FP4 cards and systems.
The no form of this command deletes the policer ID from the configuration.
Parameters
- policer-id
-
Specifies the policer index.
Platforms
7450 ESS, 7750 SR, 7750 SR-s, 7950 XRS
policer-control-override
policer-control-override
Syntax
policer-control-override [create]
no policer-control-override
Context
[Tree] (config>card>fp>ingress>access>queue-group policer-control-override)
[Tree] (config>card>fp>ingress>network>queue-group policer-control-override)
Full Context
configure card fp ingress access queue-group policer-control-override
configure card fp ingress network queue-group policer-control-override
Description
This command configures policer control overrides.
Parameters
- create
-
Keyword required to create a new policer control override instance.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer-control-override
Syntax
policer-control-override [create]
no policer-control-override
Context
[Tree] (config>service>cpipe>sap>egress policer-control-override)
[Tree] (config>service>cpipe>sap>ingress policer-control-override)
[Tree] (config>service>ipipe>sap>egress policer-control-override)
[Tree] (config>service>epipe>sap>egress policer-control-override)
[Tree] (config>service>epipe>sap>ingress policer-control-override)
[Tree] (config>service>ipipe>sap>ingress policer-control-override)
Full Context
configure service cpipe sap egress policer-control-override
configure service cpipe sap ingress policer-control-override
configure service ipipe sap egress policer-control-override
configure service epipe sap egress policer-control-override
configure service epipe sap ingress policer-control-override
configure service ipipe sap ingress policer-control-override
Description
This command, within the SAP ingress or egress contexts, creates a CLI node for specific overrides to the applied policer-control-policy. A policy must be applied for a policer-control-overrides node to be created. If the policer-control-policy is removed or changed, the policer-control-overrides node is automatically deleted from the SAP.
The no form of this command removes any existing policer-control-policy overrides and the policer-control-overrides node from the SAP.
Default
no policer-control-override
Parameters
- create
-
The create keyword is required when the policer-control-overrides node is being created and the system is configured to expect explicit confirmation that a new object is being created. When the system is not configured to expect explicit confirmation, the create keyword is not required.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS
- configure service cpipe sap egress policer-control-override
- configure service cpipe sap ingress policer-control-override
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
- configure service epipe sap egress policer-control-override
- configure service ipipe sap ingress policer-control-override
- configure service epipe sap ingress policer-control-override
- configure service ipipe sap egress policer-control-override
policer-control-override
Syntax
policer-control-override [create]
no policer-control-override
Context
[Tree] (config>service>vpls>sap>egress policer-control-override)
[Tree] (config>service>vpls>sap>ingress policer-control-override)
Full Context
configure service vpls sap egress policer-control-override
configure service vpls sap ingress policer-control-override
Description
This command, within the SAP ingress or egress contexts, creates a CLI node for specific overrides to the applied policer-control-policy. A policy must be applied for a policer-control-overrides node to be created. If the policer-control-policy is removed or changed, the policer-control-overrides node is automatically deleted from the SAP.
The no form of this command removes any existing policer-control-policy overrides and the policer-control-overrides node from the SAP.
Default
no policer-control-override
Parameters
- create
-
The create keyword is required when the policer-control-overrides node is being created and the system is configured to expect explicit confirmation that a new object is being created. When the system is not configured to expect explicit confirmation, the create keyword is not required.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer-control-override
Syntax
policer-control-override [create]
no policer-control-override
Context
[Tree] (config>service>ies>if>sap>egress policer-control-override)
[Tree] (config>service>ies>if>sap>ingress policer-control-override)
Full Context
configure service ies interface sap egress policer-control-override
configure service ies interface sap ingress policer-control-override
Description
This command, within the SAP ingress or egress contexts, creates a CLI node for specific overrides to the applied policer-control-policy. A policy must be applied for a policer-control-overrides node to be created. If the policer-control-policy is removed or changed, the policer-control-overrides node is automatically deleted from the SAP.
The no form of this command removes any existing policer-control-policy overrides and the policer-control-overrides node from the SAP.
Default
no policer-control-override
Parameters
- create
-
The create keyword is required when the policer-control-overrides node is being created and the system is configured to expect explicit confirmation that a new object is being created. When the system is not configured to expect explicit confirmation, the create keyword is not required.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer-control-override
Syntax
policer-control-override [create]
no policer-control-override
Context
[Tree] (config>service>vprn>if>sap>egress policer-control-override)
[Tree] (config>service>vprn>if>sap>ingress policer-control-override)
Full Context
configure service vprn interface sap egress policer-control-override
configure service vprn interface sap ingress policer-control-override
Description
This command, within the SAP ingress or egress contexts, creates a CLI node for specific overrides to the applied policer-control-policy. A policy must be applied for a policer-control-overrides node to be created. If the policer-control-policy is removed or changed, the policer-control-overrides node is automatically deleted from the SAP.
The no form of this command removes any existing policer-control-policy overrides and the policer-control-overrides node from the SAP.
Default
no policer-control-override
Parameters
- create
-
The create keyword is required when the policer-control-overrides node is being created and the system is configured to expect explicit confirmation that a new object is being created. When the system is not configured to expect explicit confirmation, the create keyword is not required.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer-control-policy
policer-control-policy
Syntax
policer-control-policy policy-name [create]
no policer-control-policy
Context
[Tree] (config>subscr-mgmt>sub-prof>ingress policer-control-policy)
[Tree] (config>subscr-mgmt>sub-prof>egress policer-control-policy)
Full Context
configure subscriber-mgmt sub-profile ingress policer-control-policy
configure subscriber-mgmt sub-profile egress policer-control-policy
Description
This command is used to create, delete, or modify policer control policies. The policer-control-policy controls the aggregate bandwidth available to a set of child policers. Once created, the policy can be applied to ingress or egress SAPs. The policy can also be applied to the ingress or egress context of a sub-profile.
The no form of this command reverts to the default.
Parameters
- policy-name
-
Specifies the policer control policy name. Each policer-control-policy must be created with a unique policy name. The name given as policy-name must adhere to the system policy ASCII naming requirements. If the defined policy-name already exists, the system will enter that policy’s context for editing purposes. If policy-name does not exist, the system will attempt to create a policy with the specified name. Creating a policy may require use of the create parameter when the system is configured for explicit object creation mode.
- create
-
The create keyword is required when a new policy is being created and the system is configured for explicit object creation mode.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
policer-control-policy
Syntax
policer-control-policy policy-name
no policer-control-policy
Context
[Tree] (config>service>ies>sub-if>grp-if>sap>ingress policer-control-policy)
[Tree] (config>service>vprn>sub-if>grp-if>sap>egress policer-control-policy)
[Tree] (config>service>ies>sub-if>grp-if>sap>egress policer-control-policy)
Full Context
configure service ies subscriber-interface group-interface sap ingress policer-control-policy
configure service vprn subscriber-interface group-interface sap egress policer-control-policy
configure service ies subscriber-interface group-interface sap egress policer-control-policy
Description
This command is used to create, delete, or modify policer control policies. The policer-control-policy controls the aggregate bandwidth available to a set of child policers. Once created, the policy can be applied to ingress or egress SAPs. The policy can also be applied to the ingress or egress context of a sub-profile.
The no form of this command resets the command to the default setting.
Parameters
- policy-name
-
Specifies the policer control policy name. Each policer control policy name must be unique and adhere to the system policy ASCII naming requirements. If the defined policy name already exists, the system enters that policy’s context for editing purposes. If policy-name does not exist, the system attempts to create a policy with the specified name.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
policer-control-policy
Syntax
policer-control-policy policer-control-policy-name
no policer-control-policy
Context
[Tree] (config>card>fp>ingress>network>queue-group policer-control-policy)
[Tree] (config>card>fp>ingress>access>queue-group policer-control-policy)
Full Context
configure card fp ingress network queue-group policer-control-policy
configure card fp ingress access queue-group policer-control-policy
Description
This command configures an policer-control policy that can apply to a queue-group on the forwarding plane.
The no form of this command removes the policer-control policy association from the queue-group.
Default
no policer-control-policy
Parameters
- policer-control-policy-name
-
Specifies the name of the policer-control policy to use for the queue-group. The name can be up to 32 characters long.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer-control-policy
Syntax
policer-control-policy policy-name
no policer-control-policy
Context
[Tree] (config>port>ethernet>network>egress>queue-group>policer-control-policy policer-control-policy)
Full Context
configure port ethernet network egress queue-group policer-control-policy policer-control-policy
Description
This command configures the policer control policy for the QoS egress queue-group.
Parameters
- policy-name
-
Specifies the name of the policer control policy, up to 32 characters.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer-control-policy
Syntax
policer-control-policy policy-name
no policer-control-policy
Context
[Tree] (config>service>cpipe>sap>ingress policer-control-policy)
[Tree] (config>service>ipipe>sap>ingress policer-control-policy)
[Tree] (config>service>cpipe>sap>egress policer-control-policy)
[Tree] (config>service>epipe>sap>ingress policer-control-policy)
[Tree] (config>service>epipe>sap>egress policer-control-policy)
[Tree] (config>service>ipipe>sap>egress policer-control-policy)
Full Context
configure service cpipe sap ingress policer-control-policy
configure service ipipe sap ingress policer-control-policy
configure service cpipe sap egress policer-control-policy
configure service epipe sap ingress policer-control-policy
configure service epipe sap egress policer-control-policy
configure service ipipe sap egress policer-control-policy
Description
This command, within the QoS CLI node, is used to create, delete or modify policer control policies. A policer control policy is very similar to the scheduler-policy which is used to manage a set of queues by defining a hierarchy of virtual schedulers and specifying how the virtual schedulers interact to provide an aggregate SLA. In a similar fashion, the policer-control-policy controls the aggregate bandwidth available to a set of child policers. Once created, the policy can be applied to ingress or egress SAPs.
Policer Control Policy Instances
On the SAP side, an instance of a policy is created each time a policy is applied.
When applied to a sub-profile on a 7450 ESS and 7750 SR, an instance of the policy is created each time a subscriber successfully maps one or more hosts to the profile per ingress SAP.
Each instance of the policer-control-policy manages the policers associated with the object that owns the policy instance (SAP or subscriber). If a policer on the object is parented to an appropriate arbiter name that exists within the policy, the policer will be managed by the instance. If a policer is not parented or is parented to a non-existent arbiter, the policer will be orphaned and will not be subject to bandwidth control by the policy instance.
Maximum Rate and Root Arbiter
The policer-control-policy supports an overall maximum rate (max-rate) that defines the total amount of bandwidth that may be distributed to all associated child policers. By default, that rate is set to max which provides an unlimited amount of bandwidth to the policers. Once the policy is created, an actual rate should be configured in order for the policy instances to be effective. At the SAP level, the maximum rate may be overridden on a per instance basis.
For subscribers, the maximum rate may only be overridden on the subscriber profile which will then be applied to all instances associated with the profile.
The maximum rate is defined within the context of the root arbiter which is always present in a policer-control-policy. The system creates a parent policer which polices the output of all child policers attached to the policy instance to the configured rate. Child policers may be parented directly to the root arbiter (parent root) or parented to one of the tiered arbiters (parent arbiter-name). Since each tiered arbiter must be parented to either another tiered arbiter or the root arbiter (default), every parented child policer is associated with the root arbiter and therefore the root arbiter’s parent policer.
Parent Policer PIR Leaky Bucket Operation
The parent policer is a single leaky bucket that monitors the aggregate throughput rate of the associated child policers. Forwarded packets increment the bucket by the size of each packet. The rate of the parent policer is implemented as a bucket decrement function which attempts to drain the bucket. If the rate of the packets flowing through the bucket is less than the decrement rate, the bucket does not accumulate depth. Each packet that flows through the bucket is accompanied by a derived discard threshold. If the current depth of the bucket is less than the discard threshold, the packet is allowed to pass through, retaining the colors derived from the packet’s child policer. If the current depth is equal to or greater than the threshold value, the packet is colored red and the bucket depth is not incremented by the packet size. Also, any increased bucket depths in the child policer are canceled making any discard event an atomic function between the child and the parent.
Due to the fact that multiple thresholds are supported by the parent policer, the policer control policy is able to protect the throughput of higher priority child policers from the throughput of the lower priority child policers within the aggregate rate.
Tier 1 and Tier 2 Arbiters
As previously stated, each child is attached either to the always available root arbiter or to an explicitly created tier 1 or tier 2 arbiter. Unlike the hardware parent policer based root arbiter, the arbiters at tier 1 and tier 2 are only represented in software and are meant to provide an arbitrary hierarchical bandwidth distribution capability. An arbiter created on tier 2 must parent to either to an arbiter on tier 1 or to the root arbiter. Arbiters created on tier 1 always parent to the root arbiter. In this manner, every arbiter ultimately is parented or grand-parented by the root arbiter.
Each tiered arbiter supports an optional rate parameter that defines a rate limit for all child arbiters or child policers associated with the arbiter. Child arbiters and policers attached to the arbiter have a level attribute that defines the strict level at which the child is given bandwidth by the arbiter. Level 8 is the highest and 1 is the lowest. Also a weight attribute defines each child’s weight at that strict level in order to determine how bandwidth is distributed to multiple children at that level when insufficient bandwidth is available to meet each child’s required bandwidth.
Fair and Unfair Bandwidth Control
Each child policer supports three leaky buckets. The PIR bucket manages the policer’s peak rate and maximum burst size, the CIR leaky bucket manages the policer’s committed rate and committed burst size. The third leaky bucket is used by the policer control policy instance to manage the child policer’s fair rate (FIR). When multiple child policers are attached to the root arbiter at the same priority level, the policy instance uses each child’s FIR bucket rate to control how much of the traffic forwarded by the policer is fair and how much is unfair.
In the simplest case where all the child policers in the same priority level are directly attached to the root arbiter, each child’s FIR rate is set according to the child’s weight divided by the sum of the active children’s weights multiplied by the available bandwidth at the priority level. The result is that the FIR bucket will mark the appropriate amount of traffic for each child as fair-based on the weighted fair output of the policy instance.
The fair/unfair forwarding control in the root parent policer is accomplished by implementing two different discard thresholds for the priority. The first threshold is discard-unfair and the second is discard-all for packet associated with the priority level. As the parent policer PIR bucket fills (due the aggregate forwarded rate being greater than the parent policers PIR decrement rate) and the bucket depth reaches the first threshold, all unfair packets within the priority are discarded. This leaves room in the bucket for the fair packets to be forwarded.
In the more complex case where one or more tiered arbiters are attached at the priority level, the policer control policy instance must consider more than just the child policer weights associated with the attached arbiter. If the arbiter is configured with an aggregate rate limit that its children cannot exceed, the policer control policy instance will switch to calculating the rate each child serviced by the arbiter should receive and enforces that rate using each child policers PIR leaky bucket.
When the child policer PIR leaky bucket is used to limit the bandwidth for the child policer and the child’s PIR bucket discard threshold is reached, packets associated with the child policer are discarded. The child policer’s discarded packets do not consume depth in the child policer’s CIR or FIR buckets. The child policers discarded packets are also prevented from impacting the parent policer and will not consume the aggregate bandwidth managed by the parent policer.
Parent Policer Priority Level Thresholds
As stated in the Tier 1 and Tier 2 Arbiter subsection, each child policer is attached either to the root arbiter or explicitly to one of the tier 1 or tier 2 arbiters. When attached directly to the root arbiter, its priority relative to all other child policers is indicated by the parenting level parameter. When attached through one of the tiered arbiters, the parenting hierarchy of the arbiters must be traced through to the ultimate attachment to the root arbiter. The parenting level parameter of the arbiter parented to the root arbiter defines the child policer’s priority level within the parent policer.
The priority level is important since it defines the parent policer discard thresholds that will be applied at the parent policer. The parent policer has 8 levels of strict priority and each priority level has its own discard-unfair and discard-all thresholds. Each priority’s thresholds are larger than the thresholds of the lower priority levels. This ensures that when the parent policer is discarding, it will be priority sensitive.
To visualize the behavior of the parent policer, picture that when the aggregate forwarding rate of all child policers is currently above the decrement rate of the parent PIR leaky bucket, the bucket depth will increase over time. As the bucket depth increases, it will eventually cross the lowest priority’s discard-unfair threshold. If this amount of discard sufficiently lowers the remaining aggregate child policer rate, the parent PIR bucket will hover around this bucket depth. If however, the remaining aggregate child rate is still greater than the decrement rate, the bucket will continue to rise and eventually reach the lowest priority’s discard-all threshold which will cause all packets associated with the priority level to be discarded (fair and unfair). Again, if the remaining aggregate child rate is less than or equal to the bucket decrement rate, the parent PIR bucket will hover around this higher bucket depth. If the remaining aggregate child rate is still higher than the decrement rate, the bucket will continue to rise through the remaining priority level discards until equilibrium is achieved.
Each child’s rate feeding into the parent policer is governed by the child policer’s PIR bucket decrement rate. The amount of bandwidth the child policer offers to the parent policer will not exceed the child policer’s configured maximum rate.
Root Arbiter’s Parent Policer’s Priority Aggregate Thresholds
Each policer-control-policy root arbiter supports configurable aggregate priority thresholds which are used to control burst tolerance within each priority level. Two values are maintained per priority level; the shared-portion and the fair-portion. The shared-portion represents the amount of parent PIR bucket depth that is allowed to be consumed by both fair and unfair child packets at the priority level. The fair-portion represents the amount of parent PIR bucket depth that only the fair child policer packets may consume within the priority level. It should be noted that the fair and unfair child packets associated with a higher parent policer priority level may also consume the bucket depth set aside for this priority.
While the policy maintains a parent policer default or explicit configurable values for shared-portion and fair-portion within each priority level, it is possible that some priority levels will not be used within the parent policer. Most parent policer use cases require fewer than eight strict priority levels.
To derive the actual priority level discard-unfair and discard-all thresholds while only accounting for the actual in-use priority levels, the system maintains a child policer to parent policer association counter per priority level for each policer control policy instance. As a child policer is parented to either the root or a tiered arbiter, the system determines the parent policer priority level for the child policer and increments the association counter for that priority level on the parent policer instance.
The shared-portion for each priority level is affected by the parent policer global min-thresh-separation parameter that defines the minimum separation between any in-use discard thresholds. When more than one child policer is associated with a parent policer priority level, the shared-portion for that priority level will be the current value of min-thresh-separation. When only a single child policer is associated, the priority level’s shared-portion is zero since all packets from the child will be marked fair and the discard-unfair threshold is meaningless. When the association counter is zero, both the shared-portion and the fair-portion for that priority level are zero since neither discard thresholds will be used. Whenever the association counter is greater than 0, the fair-portion for that priority level will be derived from the current value of the priority’s mbs-contribution parameter and the global min-thresh-separation parameter.
Each priority level’s discard-unfair and discard-all thresholds are calculated based on an accumulation of lower priorities shared-portions and fair-portions and the priority level’s own shared-portion and fair-portion. The base threshold value for each priority level is equal to the sum of all lower priority level’s shared-portions and fair-portions. The discard-unfair threshold is the priority level’s base threshold plus the priority level’s shared-portion. The discard-all threshold for the priority level is the priority level’s base threshold plus both the shared-portion and fair-portion values of the priority. As can be seen, an in-use priority level’s thresholds are always greater than the thresholds of lower priority levels.
Policer Control Policy Application
A policer-control-policy may be applied on any Ethernet ingress or egress SAP that is associated with a port (or ports in the case of LAG).
The no form of this command removes a non-associated policer control policy from the system. The command will not execute when policer-name is currently associated with any SAP context.
Parameters
- policy-name
-
Each policer-control-policy must be created with a unique policy name. The name given as policy-name must adhere to the system policy ASCII naming requirements. If the defined policy-name already exists, the system will enter that policy’s context for editing purposes. If policy-name does not exist, the system will attempt to create a policy with the specified name. Creating a policy may require use of the create parameter when the system is configured for explicit object creation mode.
- create
-
The keyword is required when a new policy is being created and the system is configured for explicit object creation mode.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS
- configure service cpipe sap ingress policer-control-policy
- configure service cpipe sap egress policer-control-policy
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
- configure service ipipe sap ingress policer-control-policy
- configure service epipe sap ingress policer-control-policy
- configure service epipe sap egress policer-control-policy
- configure service ipipe sap egress policer-control-policy
policer-control-policy
Syntax
policer-control-policy policy-name
no policer-control-policy
Context
[Tree] (config>service>template>vpls-sap-template>ingress policer-control-policy)
[Tree] (config>service>template>vpls-sap-template>egress policer-control-policy)
[Tree] (config>service>vpls>sap>egress policer-control-policy)
[Tree] (config>service>vpls>sap>ingress policer-control-policy)
Full Context
configure service template vpls-sap-template ingress policer-control-policy
configure service template vpls-sap-template egress policer-control-policy
configure service vpls sap egress policer-control-policy
configure service vpls sap ingress policer-control-policy
Description
This command, within the qos CLI node, is used to create, delete or modify policer control policies. A policer control policy is very similar to the scheduler-policy which is used to manage a set of queues by defining a hierarchy of virtual schedulers and specifying how the virtual schedulers interact to provide an aggregate SLA. In a similar fashion, the policer-control-policy controls the aggregate bandwidth available to a set of child policers. Once created, the policy can be applied to ingress or egress SAPs. The policy may also be applied to the ingress or egress context of a sub-profile.
Policer Control Policy Instances
On the SAP side, an instance of a policy is created each time a policy is applied. When applied to a sub-profile, an instance of the policy is created each time a subscriber successfully maps one or more hosts to the profile per ingress SAP.
Each instance of the policer-control-policy manages the policers associated with the object that owns the policy instance (SAP or subscriber). If a policer on the object is parented to an appropriate arbiter name that exists within the policy, the policer will be managed by the instance. If a policer is not parented or is parented to a non-existent arbiter, the policer will be orphaned and will not be subject to bandwidth control by the policy instance.
Maximum Rate and Root Arbiter
The policer-control-policy supports an overall maximum rate (max-rate) that defines the total amount of bandwidth that may be distributed to all associated child policers. By default, that rate is set to max which provides an unlimited amount of bandwidth to the policers. Once the policy is created, an actual rate should be configured in order for the policy instances to be effective. At the SAP level, the maximum rate may be overridden on a per instance basis. For subscribers, the maximum rate may only be overridden on the subscriber profile which will then be applied to all instances associated with the profile.
The maximum rate is defined within the context of the root arbiter which is always present in a policer-control-policy. The system creates a parent policer which polices the output of all child policers attached to the policy instance to the configured rate. Child policers may be parented directly to the root arbiter (parent root) or parented to one of the tiered arbiters (parent arbiter-name). Since each tiered arbiter must be parented to either another tiered arbiter or the root arbiter (default), every parented child policer is associated with the root arbiter and therefore the root arbiter’s parent policer.
Parent Policer PIR Leaky Bucket Operation
The parent policer is a single leaky bucket that monitors the aggregate throughput rate of the associated child policers. Forwarded packets increment the bucket by the size of each packet. The rate of the parent policer is implemented as a bucket decrement function which attempts to drain the bucket. If the rate of the packets flowing through the bucket is less than the decrement rate, the bucket does not accumulate depth. Each packet that flows through the bucket is accompanied by a derived discard threshold. If the current depth of the bucket is less than the discard threshold, the packet is allowed to pass through, retaining the colors derived from the packet’s child policer. If the current depth is equal to or greater than the threshold value, the packet is colored red and the bucket depth is not incremented by the packet size. Also, any increased bucket depths in the child policer are canceled making any discard event an atomic function between the child and the parent.
Due to the fact that multiple thresholds are supported by the parent policer, the policer control policy is able to protect the throughput of higher priority child policers from the throughput of the lower priority child policers within the aggregate rate.
Tier 1 and Tier 2 Arbiters
As stated above, each child is attached either to the always available root arbiter or to an explicitly created tier 1 or tier 2 arbiter. Unlike the hardware parent policer based root arbiter, the arbiters at tier 1 and tier 2 are only represented in software and are meant to provide an arbitrary hierarchical bandwidth distribution capability. An arbiter created on tier 2 must parent to either to an arbiter on tier 1 or to the root arbiter. Arbiters created on tier 1 always parent to the root arbiter. In this manner, every arbiter ultimately is parented or grand-parented by the root arbiter.
Each tiered arbiter supports an optional rate parameter that defines a rate limit for all child arbiters or child policers associated with the arbiter. Child arbiters and policers attached to the arbiter have a level attribute that defines the strict level at which the child is given bandwidth by the arbiter. Level 8 is the highest and 1 is the lowest. Also a weight attribute defines each child’s weight at that strict level in order to determine how bandwidth is distributed to multiple children at that level when insufficient bandwidth is available to meet each child’s required bandwidth.
Fair and Unfair Bandwidth Control
Each child policer supports three leaky buckets. The PIR bucket manages the policer’s peak rate and maximum burst size, the CIR leaky bucket manages the policer’s committed rate and committed burst size. The third leaky bucket is used by the policer control policy instance to manage the child policer’s fair rate (FIR). When multiple child policers are attached to the root arbiter at the same priority level, the policy instance uses each child’s FIR bucket rate to control how much of the traffic forwarded by the policer is fair and how much is unfair.
In the simplest case where all the child policers in the same priority level are directly attached to the root arbiter, each child’s FIR rate is set according to the child’s weight divided by the sum of the active children’s weights multiplied by the available bandwidth at the priority level. The result is that the FIR bucket will mark the appropriate amount of traffic for each child as fair-based on the weighted fair output of the policy instance.
The fair/unfair forwarding control in the root parent policer is accomplished by implementing two different discard thresholds for the priority. The first threshold is discard-unfair and the second is discard-all for packet associated with the priority level. As the parent policer PIR bucket fills (due the aggregate forwarded rate being greater than the parent policers PIR decrement rate) and the bucket depth reaches the first threshold, all unfair packets within the priority are discarded. This leaves room in the bucket for the fair packets to be forwarded.
In the more complex case where one or more tiered arbiters are attached at the priority level, the policer control policy instance must consider more than just the child policer weights associated with the attached arbiter. If the arbiter is configured with an aggregate rate limit that its children cannot exceed, the policer control policy instance will switch to calculating the rate each child serviced by the arbiter should receive and enforces that rate using each child policers PIR leaky bucket.
When the child policer PIR leaky bucket is used to limit the bandwidth for the child policer and the child’s PIR bucket discard threshold is reached, packets associated with the child policer are discarded. The child policer’s discarded packets do not consume depth in the child policer’s CIR or FIR buckets. The child policers discarded packets are also prevented from impacting the parent policer and will not consume the aggregate bandwidth managed by the parent policer.
Parent Policer Priority Level Thresholds
As stated above, each child policer is attached either to the root arbiter or explicitly to one of the tier 1 or tier 2 arbiters. When attached directly to the root arbiter, its priority relative to all other child policers is indicated by the parenting level parameter. When attached through one of the tiered arbiters, the parenting hierarchy of the arbiters must be traced through to the ultimate attachment to the root arbiter. The parenting level parameter of the arbiter parented to the root arbiter defines the child policer’s priority level within the parent policer.
The priority level is important since it defines the parent policer discard thresholds that will be applied at the parent policer. The parent policer has 8 levels of strict priority and each priority level has its own discard-unfair and discard-all thresholds. Each priority’s thresholds are larger than the thresholds of the lower priority levels. This ensures that when the parent policer is discarding, it will be priority sensitive.
To visualize the behavior of the parent policer, picture that when the aggregate forwarding rate of all child policers is currently above the decrement rate of the parent PIR leaky bucket, the bucket depth will increase over time. As the bucket depth increases, it will eventually cross the lowest priority’s discard-unfair threshold. If this amount of discard sufficiently lowers the remaining aggregate child policer rate, the parent PIR bucket will hover around this bucket depth. If however, the remaining aggregate child rate is still greater than the decrement rate, the bucket will continue to rise and eventually reach the lowest priority’s discard-all threshold which will cause all packets associated with the priority level to be discarded (fair and unfair). Again, if the remaining aggregate child rate is less than or equal to the bucket decrement rate, the parent PIR bucket will hover around this higher bucket depth. If the remaining aggregate child rate is still higher than the decrement rate, the bucket will continue to rise through the remaining priority level discards until equilibrium is achieved.
As noted above, each child’s rate feeding into the parent policer is governed by the child policer’s PIR bucket decrement rate. The amount of bandwidth the child policer offers to the parent policer will not exceed the child policer’s configured maximum rate.
Root Arbiter’s Parent Policer’s Priority Aggregate Thresholds
Each policer-control-policy root arbiter supports configurable aggregate priority thresholds which are used to control burst tolerance within each priority level. Two values are maintained per priority level; the shared-portion and the fair-portion. The shared-portion represents the amount of parent PIR bucket depth that is allowed to be consumed by both fair and unfair child packets at the priority level. The fair-portion represents the amount of parent PIR bucket depth that only the fair child policer packets may consume within the priority level. It should be noted that the fair and unfair child packets associated with a higher parent policer priority level may also consume the bucket depth set aside for this priority.
While the policy maintains a parent policer default or explicit configurable values for shared-portion and fair-portion within each priority level, it is possible that some priority levels will not be used within the parent policer. Most parent policer use cases require fewer than eight strict priority levels.
To derive the actual priority level discard-unfair and discard-all thresholds while only accounting for the actual in-use priority levels, the system maintains a child policer to parent policer association counter per priority level for each policer control policy instance. As a child policer is parented to either the root or a tiered arbiter, the system determines the parent policer priority level for the child policer and increments the association counter for that priority level on the parent policer instance.
The shared-portion for each priority level is affected by the parent policer global min-thresh-separation parameter that defines the minimum separation between any in-use discard thresholds. When more than one child policer is associated with a parent policer priority level, the shared-portion for that priority level will be the current value of min-thresh-separation. When only a single child policer is associated, the priority level’s shared-portion is zero since all packets from the child will be marked fair and the discard-unfair threshold is meaningless. When the association counter is zero, both the shared-portion and the fair-portion for that priority level are zero since neither discard thresholds will be used. Whenever the association counter is greater than 0, the fair-portion for that priority level will be derived from the current value of the priority’s mbs-contribution parameter and the global min-thresh-separation parameter.
Each priority level’s discard-unfair and discard-all thresholds are calculated based on an accumulation of lower priorities shared-portions and fair-portions and the priority level’s own shared-portion and fair-portion. The base threshold value for each priority level is equal to the sum of all lower priority level’s shared-portions and fair-portions. The discard-unfair threshold is the priority level’s base threshold plus the priority level’s shared-portion. The discard-all threshold for the priority level is the priority level’s base threshold plus both the shared-portion and fair-portion values of the priority. As can be seen, an in-use priority level’s thresholds are always greater than the thresholds of lower priority levels.
Policer Control Policy Application
A policer-control-policy may be applied on any Ethernet ingress or egress SAP that is associated with a port (or ports in the case of LAG).
The no form of this command removes a non-associated policer control policy from the system. The command will not execute when policer-name is currently associated with any SAP or subscriber management sub-profile context.
Parameters
- policy-name
-
Specifies the policy name. Each policer-control-policy must be created with a unique policy name. The name must be given as policy-name must adhere to the system policy ASCII naming requirements. If the defined policy-name already exists, the system will enter that policy’s context for editing purposes. If policy-name does not exist, the system will attempt to create a policy with the specified name. Creating a policy may require use of the create parameter when the system is configured for explicit object creation mode.
- create
-
The keyword is required when a new policy is being created and the system is configured for explicit object creation mode.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer-control-policy
Syntax
policer-control-policy policy-name
no policer-control-policy
Context
[Tree] (config>service>ies>if>sap>egress policer-control-policy)
[Tree] (config>service>ies>if>sap>ingress policer-control-policy)
Full Context
configure service ies interface sap egress policer-control-policy
configure service ies interface sap ingress policer-control-policy
Description
This command, within the qos CLI node, is used to create, delete or modify policer control policies. A policer control policy is very similar to the scheduler-policy which is used to manage a set of queues by defining a hierarchy of virtual schedulers and specifying how the virtual schedulers interact to provide an aggregate SLA. In a similar fashion, the policer-control-policy controls the aggregate bandwidth available to a set of child policers. Once created, the policy can be applied to ingress or egress SAPs. The policy may also be applied to the ingress or egress context of a sub-profile.
Policer Control Policy Instances
On the SAP side, an instance of a policy is created each time a policy is applied. When applied to a sub-profile, an instance of the policy is created each time a subscriber successfully maps one or more hosts to the profile per ingress SAP.
Each instance of the policer-control-policy manages the policers associated with the object that owns the policy instance (SAP or subscriber). If a policer on the object is parented to an appropriate arbiter name that exists within the policy, the policer will be managed by the instance. If a policer is not parented or is parented to a non-existent arbiter, the policer will be orphaned and will not be subject to bandwidth control by the policy instance.
Maximum Rate and Root Arbiter
The policer-control-policy supports an overall maximum rate (max-rate) that defines the total amount of bandwidth that may be distributed to all associated child policers. By default, that rate is set to max which provides an unlimited amount of bandwidth to the policers. Once the policy is created, an actual rate should be configured in order for the policy instances to be effective. At the SAP level, the maximum rate may be overridden on a per instance basis. For subscribers, the maximum rate may only be overridden on the subscriber profile which will then be applied to all instances associated with the profile.
The maximum rate is defined within the context of the root arbiter which is always present in a policer-control-policy. The system creates a parent policer which polices the output of all child policers attached to the policy instance to the configured rate. Child policers may be parented directly to the root arbiter (parent root) or parented to one of the tiered arbiters (parent arbiter-name). Since each tiered arbiter must be parented to either another tiered arbiter or the root arbiter (default), every parented child policer is associated with the root arbiter and therefore the root arbiter’s parent policer.
Parent Policer PIR Leaky Bucket Operation
The parent policer is a single leaky bucket that monitors the aggregate throughput rate of the associated child policers. Forwarded packets increment the bucket by the size of each packet. The rate of the parent policer is implemented as a bucket decrement function which attempts to drain the bucket. If the rate of the packets flowing through the bucket is less than the decrement rate, the bucket does not accumulate depth. Each packet that flows through the bucket is accompanied by a derived discard threshold. If the current depth of the bucket is less than the discard threshold, the packet is allowed to pass through, retaining the colors derived from the packet’s child policer. If the current depth is equal to or greater than the threshold value, the packet is colored red and the bucket depth is not incremented by the packet size. Also, any increased bucket depths in the child policer are canceled making any discard event an atomic function between the child and the parent.
Due to the fact that multiple thresholds are supported by the parent policer, the policer control policy is able to protect the throughput of higher priority child policers from the throughput of the lower priority child policers within the aggregate rate.
Tier 1 and Tier 2 Arbiters
As stated above, each child is attached either to the always available root arbiter or to an explicitly created tier 1 or tier 2 arbiter. Unlike the hardware parent policer based root arbiter, the arbiters at tier 1 and tier 2 are only represented in software and are meant to provide an arbitrary hierarchical bandwidth distribution capability. An arbiter created on tier 2 must parent to either to an arbiter on tier 1 or to the root arbiter. Arbiters created on tier 1 always parent to the root arbiter. In this manner, every arbiter ultimately is parented or grand-parented by the root arbiter.
Each tiered arbiter supports an optional rate parameter that defines a rate limit for all child arbiters or child policers associated with the arbiter. Child arbiters and policers attached to the arbiter have a level attribute that defines the strict level at which the child is given bandwidth by the arbiter. Level 8 is the highest and 1 is the lowest. Also a weight attribute defines each child’s weight at that strict level in order to determine how bandwidth is distributed to multiple children at that level when insufficient bandwidth is available to meet each child’s required bandwidth.
Fair and Unfair Bandwidth Control
Each child policer supports three leaky buckets. The PIR bucket manages the policer’s peak rate and maximum burst size, the CIR leaky bucket manages the policer’s committed rate and committed burst size. The third leaky bucket is used by the policer control policy instance to manage the child policer’s fair rate (FIR). When multiple child policers are attached to the root arbiter at the same priority level, the policy instance uses each child’s FIR bucket rate to control how much of the traffic forwarded by the policer is fair and how much is unfair.
In the simplest case where all the child policers in the same priority level are directly attached to the root arbiter, each child’s FIR rate is set according to the child’s weight divided by the sum of the active children’s weights multiplied by the available bandwidth at the priority level. The result is that the FIR bucket will mark the appropriate amount of traffic for each child as fair-based on the weighted fair output of the policy instance.
The fair/unfair forwarding control in the root parent policer is accomplished by implementing two different discard thresholds for the priority. The first threshold is discard-unfair and the second is discard-all for packet associated with the priority level. As the parent policer PIR bucket fills (due the aggregate forwarded rate being greater than the parent policers PIR decrement rate) and the bucket depth reaches the first threshold, all unfair packets within the priority are discarded. This leaves room in the bucket for the fair packets to be forwarded.
In the more complex case where one or more tiered arbiters are attached at the priority level, the policer control policy instance must consider more than just the child policer weights associated with the attached arbiter. If the arbiter is configured with an aggregate rate limit that its children cannot exceed, the policer control policy instance will switch to calculating the rate each child serviced by the arbiter should receive and enforces that rate using each child policers PIR leaky bucket.
When the child policer PIR leaky bucket is used to limit the bandwidth for the child policer and the child’s PIR bucket discard threshold is reached, packets associated with the child policer are discarded. The child policer’s discarded packets do not consume depth in the child policer’s CIR or FIR buckets. The child policers discarded packets are also prevented from impacting the parent policer and will not consume the aggregate bandwidth managed by the parent policer.
Parent Policer Priority Level Thresholds
As stated above, each child policer is attached either to the root arbiter or explicitly to one of the tier 1 or tier 2 arbiters. When attached directly to the root arbiter, its priority relative to all other child policers is indicated by the parenting level parameter. When attached through one of the tiered arbiters, the parenting hierarchy of the arbiters must be traced through to the ultimate attachment to the root arbiter. The parenting level parameter of the arbiter parented to the root arbiter defines the child policer’s priority level within the parent policer.
The priority level is important since it defines the parent policer discard thresholds that will be applied at the parent policer. The parent policer has 8 levels of strict priority and each priority level has its own discard-unfair and discard-all thresholds. Each priority’s thresholds are larger than the thresholds of the lower priority levels. This ensures that when the parent policer is discarding, it will be priority sensitive.
To visualize the behavior of the parent policer, picture that when the aggregate forwarding rate of all child policers is currently above the decrement rate of the parent PIR leaky bucket, the bucket depth will increase over time. As the bucket depth increases, it will eventually cross the lowest priority’s discard-unfair threshold. If this amount of discard sufficiently lowers the remaining aggregate child policer rate, the parent PIR bucket will hover around this bucket depth. If however, the remaining aggregate child rate is still greater than the decrement rate, the bucket will continue to rise and eventually reach the lowest priority’s discard-all threshold which will cause all packets associated with the priority level to be discarded (fair and unfair). Again, if the remaining aggregate child rate is less than or equal to the bucket decrement rate, the parent PIR bucket will hover around this higher bucket depth. If the remaining aggregate child rate is still higher than the decrement rate, the bucket will continue to rise through the remaining priority level discards until equilibrium is achieved.
As noted above, each child’s rate feeding into the parent policer is governed by the child policer’s PIR bucket decrement rate. The amount of bandwidth the child policer offers to the parent policer will not exceed the child policer’s configured maximum rate.
Root Arbiter’s Parent Policer’s Priority Aggregate Thresholds
Each policer-control-policy root arbiter supports configurable aggregate priority thresholds which are used to control burst tolerance within each priority level. Two values are maintained per priority level; the shared-portion and the fair-portion. The shared-portion represents the amount of parent PIR bucket depth that is allowed to be consumed by both fair and unfair child packets at the priority level. The fair-portion represents the amount of parent PIR bucket depth that only the fair child policer packets may consume within the priority level. It should be noted that the fair and unfair child packets associated with a higher parent policer priority level may also consume the bucket depth set aside for this priority.
While the policy maintains a parent policer default or explicit configurable values for shared-portion and fair-portion within each priority level, it is possible that some priority levels will not be used within the parent policer. Most parent policer use cases require fewer than eight strict priority levels.
To derive the actual priority level discard-unfair and discard-all thresholds while only accounting for the actual in-use priority levels, the system maintains a child policer to parent policer association counter per priority level for each policer control policy instance. As a child policer is parented to either the root or a tiered arbiter, the system determines the parent policer priority level for the child policer and increments the association counter for that priority level on the parent policer instance.
The shared-portion for each priority level is affected by the parent policer global min-thresh-separation parameter that defines the minimum separation between any in-use discard thresholds. When more than one child policer is associated with a parent policer priority level, the shared-portion for that priority level will be the current value of min-thresh-separation. When only a single child policer is associated, the priority level’s shared-portion is zero since all packets from the child will be marked fair and the discard-unfair threshold is meaningless. When the association counter is zero, both the shared-portion and the fair-portion for that priority level are zero since neither discard thresholds will be used. Whenever the association counter is greater than 0, the fair-portion for that priority level will be derived from the current value of the priority’s mbs-contribution parameter and the global min-thresh-separation parameter.
Each priority level’s discard-unfair and discard-all thresholds are calculated based on an accumulation of lower priorities shared-portions and fair-portions and the priority level’s own shared-portion and fair-portion. The base threshold value for each priority level is equal to the sum of all lower priority level’s shared-portions and fair-portions. The discard-unfair threshold is the priority level’s base threshold plus the priority level’s shared-portion. The discard-all threshold for the priority level is the priority level’s base threshold plus both the shared-portion and fair-portion values of the priority. As can be seen, an in-use priority level’s thresholds are always greater than the thresholds of lower priority levels.
Policer Control Policy Application
A policer-control-policy may be applied on any Ethernet ingress or egress SAP that is associated with a port (or ports in the case of LAG).
The no form of this command removes a non-associated policer control policy from the system. The command will not execute when policer-name is currently associated with any SAP or subscriber management sub-profile context.
Parameters
- policy-name
-
Specifies the policy name. Each policer-control-policy must be created with a unique policy name. The name must be given as policy-name must adhere to the system policy ASCII naming requirements. If the defined policy-name already exists, the system will enter that policy’s context for editing purposes. If policy-name does not exist, the system will attempt to create a policy with the specified name. Creating a policy may require use of the create parameter when the system is configured for explicit object creation mode.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer-control-policy
Syntax
policer-control-policy policy-name
no policer-control-policy
Context
[Tree] (config>service>vprn>if>sap>ingress policer-control-policy)
[Tree] (config>service>vprn>if>sap>egress policer-control-policy)
Full Context
configure service vprn interface sap ingress policer-control-policy
configure service vprn interface sap egress policer-control-policy
Description
This command, within the qos CLI node, is used to create, delete or modify policer control policies. A policer control policy is very similar to the scheduler-policy which is used to manage a set of queues by defining a hierarchy of virtual schedulers and specifying how the virtual schedulers interact to provide an aggregate SLA. In a similar fashion, the policer-control-policy controls the aggregate bandwidth available to a set of child policers. Once created, the policy can be applied to ingress or egress SAPs. The policy may also be applied to the ingress or egress context of a sub-profile.
Policer Control Policy Instances
On the SAP side, an instance of a policy is created each time a policy is applied. When applied to a sub-profile, an instance of the policy is created each time a subscriber successfully maps one or more hosts to the profile per ingress SAP.
Each instance of the policer-control-policy manages the policers associated with the object that owns the policy instance (SAP or subscriber). If a policer on the object is parented to an appropriate arbiter name that exists within the policy, the policer will be managed by the instance. If a policer is not parented or is parented to a non-existent arbiter, the policer will be orphaned and will not be subject to bandwidth control by the policy instance.
Maximum Rate and Root Arbiter
The policer-control-policy supports an overall maximum rate (max-rate) that defines the total amount of bandwidth that may be distributed to all associated child policers. By default, that rate is set to max which provides an unlimited amount of bandwidth to the policers. Once the policy is created, an actual rate should be configured in order for the policy instances to be effective. At the SAP level, the maximum rate may be overridden on a per instance basis. For subscribers, the maximum rate may only be overridden on the subscriber profile which will then be applied to all instances associated with the profile.
The maximum rate is defined within the context of the root arbiter which is always present in a policer-control-policy. The system creates a parent policer which polices the output of all child policers attached to the policy instance to the configured rate. Child policers may be parented directly to the root arbiter (parent root) or parented to one of the tiered arbiters (parent arbiter-name). Since each tiered arbiter must be parented to either another tiered arbiter or the root arbiter (default), every parented child policer is associated with the root arbiter and therefore the root arbiter’s parent policer.
Parent Policer PIR Leaky Bucket Operation
The parent policer is a single leaky bucket that monitors the aggregate throughput rate of the associated child policers. Forwarded packets increment the bucket by the size of each packet. The rate of the parent policer is implemented as a bucket decrement function which attempts to drain the bucket. If the rate of the packets flowing through the bucket is less than the decrement rate, the bucket does not accumulate depth. Each packet that flows through the bucket is accompanied by a derived discard threshold. If the current depth of the bucket is less than the discard threshold, the packet is allowed to pass through, retaining the colors derived from the packet’s child policer. If the current depth is equal to or greater than the threshold value, the packet is colored red and the bucket depth is not incremented by the packet size. Also, any increased bucket depths in the child policer are canceled making any discard event an atomic function between the child and the parent.
Due to the fact that multiple thresholds are supported by the parent policer, the policer control policy is able to protect the throughput of higher priority child policers from the throughput of the lower priority child policers within the aggregate rate.
Tier 1 and Tier 2 Arbiters
As stated above, each child is attached either to the always available root arbiter or to an explicitly created tier 1 or tier 2 arbiter. Unlike the hardware parent policer based root arbiter, the arbiters at tier 1 and tier 2 are only represented in software and are meant to provide an arbitrary hierarchical bandwidth distribution capability. An arbiter created on tier 2 must parent to either to an arbiter on tier 1 or to the root arbiter. Arbiters created on tier 1 always parent to the root arbiter. In this manner, every arbiter ultimately is parented or grand-parented by the root arbiter.
Each tiered arbiter supports an optional rate parameter that defines a rate limit for all child arbiters or child policers associated with the arbiter. Child arbiters and policers attached to the arbiter have a level attribute that defines the strict level at which the child is given bandwidth by the arbiter. Level 8 is the highest and 1 is the lowest. Also a weight attribute defines each child’s weight at that strict level in order to determine how bandwidth is distributed to multiple children at that level when insufficient bandwidth is available to meet each child’s required bandwidth.
Fair and Unfair Bandwidth Control
Each child policer supports three leaky buckets. The PIR bucket manages the policer’s peak rate and maximum burst size, the CIR leaky bucket manages the policer’s committed rate and committed burst size. The third leaky bucket is used by the policer control policy instance to manage the child policer’s fair rate (FIR). When multiple child policers are attached to the root arbiter at the same priority level, the policy instance uses each child’s FIR bucket rate to control how much of the traffic forwarded by the policer is fair and how much is unfair.
In the simplest case where all the child policers in the same priority level are directly attached to the root arbiter, each child’s FIR rate is set according to the child’s weight divided by the sum of the active children’s weights multiplied by the available bandwidth at the priority level. The result is that the FIR bucket will mark the appropriate amount of traffic for each child as fair-based on the weighted fair output of the policy instance.
The fair/unfair forwarding control in the root parent policer is accomplished by implementing two different discard thresholds for the priority. The first threshold is discard-unfair and the second is discard-all for packet associated with the priority level. As the parent policer PIR bucket fills (due the aggregate forwarded rate being greater than the parent policers PIR decrement rate) and the bucket depth reaches the first threshold, all unfair packets within the priority are discarded. This leaves room in the bucket for the fair packets to be forwarded.
In the more complex case where one or more tiered arbiters are attached at the priority level, the policer control policy instance must consider more than just the child policer weights associated with the attached arbiter. If the arbiter is configured with an aggregate rate limit that its children cannot exceed, the policer control policy instance will switch to calculating the rate each child serviced by the arbiter should receive and enforces that rate using each child policers PIR leaky bucket.
When the child policer PIR leaky bucket is used to limit the bandwidth for the child policer and the child’s PIR bucket discard threshold is reached, packets associated with the child policer are discarded. The child policer’s discarded packets do not consume depth in the child policer’s CIR or FIR buckets. The child policers discarded packets are also prevented from impacting the parent policer and will not consume the aggregate bandwidth managed by the parent policer.
Parent Policer Priority Level Thresholds
As stated above, each child policer is attached either to the root arbiter or explicitly to one of the tier 1 or tier 2 arbiters. When attached directly to the root arbiter, its priority relative to all other child policers is indicated by the parenting level parameter. When attached through one of the tiered arbiters, the parenting hierarchy of the arbiters must be traced through to the ultimate attachment to the root arbiter. The parenting level parameter of the arbiter parented to the root arbiter defines the child policer’s priority level within the parent policer.
The priority level is important since it defines the parent policer discard thresholds that will be applied at the parent policer. The parent policer has 8 levels of strict priority and each priority level has its own discard-unfair and discard-all thresholds. Each priority’s thresholds are larger than the thresholds of the lower priority levels. This ensures that when the parent policer is discarding, it will be priority sensitive.
To visualize the behavior of the parent policer, picture that when the aggregate forwarding rate of all child policers is currently above the decrement rate of the parent PIR leaky bucket, the bucket depth will increase over time. As the bucket depth increases, it will eventually cross the lowest priority’s discard-unfair threshold. If this amount of discard sufficiently lowers the remaining aggregate child policer rate, the parent PIR bucket will hover around this bucket depth. If however, the remaining aggregate child rate is still greater than the decrement rate, the bucket will continue to rise and eventually reach the lowest priority’s discard-all threshold which will cause all packets associated with the priority level to be discarded (fair and unfair). Again, if the remaining aggregate child rate is less than or equal to the bucket decrement rate, the parent PIR bucket will hover around this higher bucket depth. If the remaining aggregate child rate is still higher than the decrement rate, the bucket will continue to rise through the remaining priority level discards until equilibrium is achieved.
As noted above, each child’s rate feeding into the parent policer is governed by the child policer’s PIR bucket decrement rate. The amount of bandwidth the child policer offers to the parent policer will not exceed the child policer’s configured maximum rate.
Root Arbiter’s Parent Policer’s Priority Aggregate Thresholds
Each policer-control-policy root arbiter supports configurable aggregate priority thresholds which are used to control burst tolerance within each priority level. Two values are maintained per priority level; the shared-portion and the fair-portion. The shared-portion represents the amount of parent PIR bucket depth that is allowed to be consumed by both fair and unfair child packets at the priority level. The fair-portion represents the amount of parent PIR bucket depth that only the fair child policer packets may consume within the priority level. It should be noted that the fair and unfair child packets associated with a higher parent policer priority level may also consume the bucket depth set aside for this priority.
While the policy maintains a parent policer default or explicit configurable values for shared-portion and fair-portion within each priority level, it is possible that some priority levels will not be used within the parent policer. Most parent policer use cases require fewer than eight strict priority levels.
To derive the actual priority level discard-unfair and discard-all thresholds while only accounting for the actual in-use priority levels, the system maintains a child policer to parent policer association counter per priority level for each policer control policy instance. As a child policer is parented to either the root or a tiered arbiter, the system determines the parent policer priority level for the child policer and increments the association counter for that priority level on the parent policer instance.
The shared-portion for each priority level is affected by the parent policer global min-thresh-separation parameter that defines the minimum separation between any in-use discard thresholds. When more than one child policer is associated with a parent policer priority level, the shared-portion for that priority level will be the current value of min-thresh-separation. When only a single child policer is associated, the priority level’s shared-portion is zero since all packets from the child will be marked fair and the discard-unfair threshold is meaningless. When the association counter is zero, both the shared-portion and the fair-portion for that priority level are zero since neither discard thresholds will be used. Whenever the association counter is greater than 0, the fair-portion for that priority level will be derived from the current value of the priority’s mbs-contribution parameter and the global min-thresh-separation parameter.
Each priority level’s discard-unfair and discard-all thresholds are calculated based on an accumulation of lower priorities shared-portions and fair-portions and the priority level’s own shared-portion and fair-portion. The base threshold value for each priority level is equal to the sum of all lower priority level’s shared-portions and fair-portions. The discard-unfair threshold is the priority level’s base threshold plus the priority level’s shared-portion. The discard-all threshold for the priority level is the priority level’s base threshold plus both the shared-portion and fair-portion values of the priority. As can be seen, an in-use priority level’s thresholds are always greater than the thresholds of lower priority levels.
Policer Control Policy Application
A policer-control-policy may be applied on any Ethernet ingress or egress SAP that is associated with a port (or ports in the case of LAG).
The no form of this command removes a non-associated policer control policy from the system. The command will not execute when policer-name is currently associated with any SAP or subscriber management sub-profile context.
Parameters
- policy-name
-
Specifies the policy name. Each policer-control-policy must be created with a unique policy name. The name must be given as policy-name must adhere to the system policy ASCII naming requirements. If the defined policy-name already exists, the system will enter that policy’s context for editing purposes. If policy-name does not exist, the system will attempt to create a policy with the specified name. Creating a policy may require use of the create parameter when the system is configured for explicit object creation mode.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer-control-policy
Syntax
policer-control-policy policy-name [create]
no policer-control-policy policy-name
Context
[Tree] (config>qos policer-control-policy)
Full Context
configure qos policer-control-policy
Description
This command is used to create, delete, or modify policer control policies. The policer-control-policy controls the aggregate bandwidth available to a set of child policers. When created, the policy can be applied to ingress or egress SAPs. The policy can also be applied to the ingress or egress context of a sub-profile.
Parameters
- policy-name
-
Each policer-control-policy must be created with a unique policy name. The policy-name must adhere to the system policy ASCII naming requirements. If the defined policy-name already exists, the system enters that policy’s context for editing purposes. If policy-name does not exist, the system attempts to create a policy with the specified name. Creating a policy may require use of the create parameter when the system is configured for explicit object creation mode.
- create
-
The create keyword is required when a new policy is being created and the system is configured for explicit object creation mode.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer-control-policy
Syntax
policer-control-policy policy-name
no policer-control-policy
Context
[Tree] (config>service>cust>multi-service-site>egress policer-control-policy)
[Tree] (config>service>cust>multi-service-site>ingress policer-control-policy)
Full Context
configure service customer multi-service-site egress policer-control-policy
configure service customer multi-service-site ingress policer-control-policy
Description
This command, within the QoS CLI node, is used to create, delete or modify policer control policies. A policer control policy is very similar to the scheduler-policy which is used to manage a set of queues by defining a hierarchy of virtual schedulers and specifying how the virtual schedulers interact to provide an aggregate SLA. In a similar fashion, the policer-control-policy controls the aggregate bandwidth available to a set of child policers. Once created, the policy can be applied to ingress or egress SAPs.
Policer Control Policy Instances
On the SAP side, an instance of a policy is created each time a policy is applied. When applied to a 7750 SR or 7450 ESS sub-profile, an instance of the policy is created each time a subscriber successfully maps one or more hosts to the profile per ingress SAP.
Each instance of the policer-control-policy manages the policers associated with the object that owns the policy instance (SAP or subscriber). If a policer on the object is parented to an appropriate arbiter name that exists within the policy, the policer will be managed by the instance. If a policer is not parented or is parented to a non-existent arbiter, the policer will be orphaned and not subject to bandwidth control by the policy instance.
Maximum Rate and Root Arbiter
The policer-control-policy supports an overall maximum rate (max-rate) that defines the total amount of bandwidth that may be distributed to all associated child policers. By default, that rate is set to max which provides an unlimited amount of bandwidth to the policers. Once the policy is created, an actual rate should be configured in order for the policy instances to be effective. At the SAP level, the maximum rate may be overridden on a per instance basis. For 7750 SR or 7450 ESS subscribers, the maximum rate may only be overridden on the subscriber profile which will then be applied to all instances associated with the profile.
The maximum rate is defined within the context of the root arbiter which is always present in a policer-control-policy. The system creates a parent policer which polices the output of all child policers attached to the policy instance to the configured rate. Child policers may be parented directly to the root arbiter (parent root) or parented to one of the tiered arbiters (parent arbiter-name). Since each tiered arbiter must be parented to either another tiered arbiter or the root arbiter (default), every parented child policer is associated with the root arbiter and thus the root arbiter’s parent policer.
Parent Policer PIR Leaky Bucket Operation
The parent policer is a single leaky bucket that monitors the aggregate throughput rate of the associated child policers. Forwarded packets increment the bucket by the size of each packet. The rate of the parent policer is implemented as a bucket decrement function which attempts to drain the bucket. If the rate of the packets flowing through the bucket is less than the decrement rate, the bucket does not accumulate depth. Each packet that flows through the bucket is accompanied by a derived discard threshold. If the current depth of the bucket is less than the discard threshold, the packet is allowed to pass through, retaining the colors derived from the packet’s child policer. If the current depth is equal to or greater than the threshold value, the packet is colored red and the bucket depth is not incremented by the packet size. Also, any increased bucket depths in the child policer are canceled making any discard event an atomic function between the child and the parent.
Due to the fact that multiple thresholds are supported by the parent policer, the policer control policy is able to protect the throughput of higher priority child policers from the throughput of the lower priority child policers within the aggregate rate.
Tier 1 and Tier 2 Arbiters
As stated above, each child is attached either to the always available root arbiter or to an explicitly created tier 1 or tier 2 arbiter. Unlike the hardware parent policer based root arbiter, the arbiters at tier 1 and tier 2 are only represented in software and are meant to provide an arbitrary hierarchical bandwidth distribution capability. An arbiter created on tier 2 must parent to either to an arbiter on tier 1 or to the root arbiter. Arbiters created on tier 1 always parent to the root arbiter. In this manner, every arbiter ultimately is parented or grand-parented by the root arbiter.
Each tiered arbiter supports an optional rate parameter that defines a rate limit for all child arbiters or child policers associated with the arbiter. Child arbiters and policers attached to the arbiter have a level attribute that defines the strict level at which the child is given bandwidth by the arbiter. Level 8 is the highest and 1 is the lowest. Also a weight attribute defines each child’s weight at that strict level in order to determine how bandwidth is distributed to multiple children at that level when insufficient bandwidth is available to meet each child’s required bandwidth.
Fair and Unfair Bandwidth Control
Each child policer supports three leaky buckets. The PIR bucket manages the policer’s peak rate and maximum burst size, the CIR leaky bucket manages the policer’s committed rate and committed burst size. The third leaky bucket is used by the policer control policy instance to manage the child policer’s fair rate (FIR). When multiple child policers are attached to the root arbiter at the same priority level, the policy instance uses each child’s FIR bucket rate to control how much of the traffic forwarded by the policer is fair and how much is unfair.
In the simplest case where all the child policers in the same priority level are directly attached to the root arbiter, each child’s FIR rate is set according to the child’s weight divided by the sum of the active children’s weights multiplied by the available bandwidth at the priority level. The result is that the FIR bucket will mark the appropriate amount of traffic for each child as fair based on the weighted fair output of the policy instance.
The fair/unfair forwarding control in the root parent policer is accomplished by implementing two different discard thresholds for the priority. The first threshold is discard-unfair and the second is discard-all for packet associated with the priority level. As the parent policer PIR bucket fills (due the aggregate forwarded rate being greater than the parent policers PIR decrement rate) and the bucket depth reaches the first threshold, all unfair packets within the priority are discarded. This leaves room in the bucket for the fair packets to be forwarded.
In the more complex case where one or more tiered arbiters are attached at the priority level, the policer control policy instance must consider more than just the child policer weights associated with the attached arbiter. If the arbiter is configured with an aggregate rate limit that its children cannot exceed, the policer control policy instance will switch to calculating the rate each child serviced by the arbiter should receive and enforces that rate using each child policers PIR leaky bucket.
When the child policer PIR leaky bucket is used to limit the bandwidth for the child policer and the child’s PIR bucket discard threshold is reached, packets associated with the child policer are discarded. The child policer’s discarded packets do not consume depth in the child policer’s CIR or FIR buckets. The child policers discarded packets are also prevented from impacting the parent policer and will not consume the aggregate bandwidth managed by the parent policer.
Parent Policer Priority Level Thresholds
As stated above, each child policer is attached either to the root arbiter or explicitly to one of the tier 1 or tier 2 arbiters. When attached directly to the root arbiter, its priority relative to all other child policers is indicated by the parenting level parameter. When attached through one of the tiered arbiters, the parenting hierarchy of the arbiters must be traced through to the ultimate attachment to the root arbiter. The parenting level parameter of the arbiter parented to the root arbiter defines the child policer’s priority level within the parent policer.
The priority level is important since it defines the parent policer discard thresholds that will be applied at the parent policer. The parent policer has 8 levels of strict priority and each priority level has its own discard-unfair and discard-all thresholds. Each priority’s thresholds are larger than the thresholds of the lower priority levels. This ensures that when the parent policer is discarding, it will be priority sensitive.
To visualize the behavior of the parent policer, picture that when the aggregate forwarding rate of all child policers is currently above the decrement rate of the parent PIR leaky bucket, the bucket depth will increase over time. As the bucket depth increases, it will eventually cross the lowest priority’s discard-unfair threshold. If this amount of discard sufficiently lowers the remaining aggregate child policer rate, the parent PIR bucket will hover around this bucket depth. If however, the remaining aggregate child rate is still greater than the decrement rate, the bucket will continue to rise and eventually reach the lowest priority’s discard-all threshold which will cause all packets associated with the priority level to be discarded (fair and unfair). Again, if the remaining aggregate child rate is less than or equal to the bucket decrement rate, the parent PIR bucket will hover around this higher bucket depth. If the remaining aggregate child rate is still higher than the decrement rate, the bucket will continue to rise through the remaining priority level discards until equilibrium is achieved.
As noted above, each child’s rate feeding into the parent policer is governed by the child policer’s PIR bucket decrement rate. The amount of bandwidth the child policer offers to the parent policer will not exceed the child policer’s configured maximum rate.
Root Arbiter’s Parent Policer’s Priority Aggregate Thresholds
Each policer-control-policy root arbiter supports configurable aggregate priority thresholds which are used to control burst tolerance within each priority level. Two values are maintained per priority level; the shared-portion and the fair-portion. The shared-portion represents the amount of parent PIR bucket depth that is allowed to be consumed by both fair and unfair child packets at the priority level. The fair-portion represents the amount of parent PIR bucket depth that only the fair child policer packets may consume within the priority level. It should be noted that the fair and unfair child packets associated with a higher parent policer priority level may also consume the bucket depth set aside for this priority.
While the policy maintains a parent policer default or explicit configurable values for shared-portion and fair-portion within each priority level, it is possible that some priority levels will not be used within the parent policer. Most parent policer use cases require fewer than eight strict priority levels.
In order to derive the actual priority level discard-unfair and discard-all thresholds while only accounting for the actual in-use priority levels, the system maintains a child policer to parent policer association counter per priority level for each policer control policy instance. As a child policer is parented to either the root or a tiered arbiter, the system determines the parent policer priority level for the child policer and increments the association counter for that priority level on the parent policer instance.
The shared-portion for each priority level is affected by the parent policer global min-thresh-separation parameter that defines the minimum separation between any in-use discard thresholds. When more than one child policer is associated with a parent policer priority level, the shared-portion for that priority level will be the current value of min-thresh-separation. When only a single child policer is associated, the priority level’s shared-portion is zero since all packets from the child will be marked fair and the discard-unfair threshold is meaningless. When the association counter is zero, both the shared-portion and the fair-portion for that priority level are zero since neither discard thresholds will be used. Whenever the association counter is greater than 0, the fair-portion for that priority level will be derived from the current value of the priority’s mbs-contribution parameter and the global min-thresh-separation parameter.
Each priority level’s discard-unfair and discard-all thresholds are calculated based on an accumulation of lower priorities shared-portions and fair-portions and the priority level’s own shared-portion and fair-portion. The base threshold value for each priority level is equal to the sum of all lower priority level’s shared-portions and fair-portions. The discard-unfair threshold is the priority level’s base threshold plus the priority level’s shared-portion. The discard-all threshold for the priority level is the priority level’s base threshold plus both the shared-portion and fair-portion values of the priority. As can be seen, an in-use priority level’s thresholds are always greater than the thresholds of lower priority levels.
Policer Control Policy Application
A policer-control-policy may be applied on any Ethernet ingress or egress SAP that is associated with a port (or ports in the case of LAG).
The no form of the command removes a non-associated policer control policy from the system. The command will not execute when policer-name is currently associated with any SAP context.
Parameters
- policy-name
-
Specifies the policy name up to 32 characters in length. Each policer-control-policy must be created with a unique policy name. The name must adhere to the system policy ASCII naming requirements. If the defined policy name already exists, the system will enter that policy’s context for editing purposes. If policy name does not exist, the system will attempt to create a policy with the specified name.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer-control-policy
Syntax
policer-control-policy src-name dst-name [ overwrite]
Context
[Tree] (config>qos>copy policer-control-policy)
Full Context
configure qos copy policer-control-policy
Description
This command copies an existing policer-control-policy to another policer-control-policy. The copy command is a configuration level maintenance tool used to create new entries using an existing profile ID. If overwrite is not specified, an error occurs if the destination policy exists.
Parameters
- src-name
-
Specifies the existing source policer-control-policy, up to 32 characters, from which the copy command attempts to copy.
- dst-name
-
Specifies the destination policer-control-policy dst-name, up to 32 characters, to which the copy command attempts to copy.
- overwrite
-
Use this parameter when the policer-control-policy dst-name already exists. If it does, everything in the existing destination policer-control-policy dst-name is completely overwritten with the contents of the policer-control-policy src-name. The overwrite parameter must be specified or else the following error message is returned:
MINOR: CLI Destination "pcp-name2" exists - use {overwrite}.
If overwrite is specified, the function of copying from source to destination occurs in a "break before make” manner and therefore should be handled with care.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer-override
policer-override
Syntax
[no] policer-override
Context
[Tree] (config>card>fp>ingress>network>queue-group policer-override)
[Tree] (config>card>fp>ingress>access>queue-group policer-override)
Full Context
configure card fp ingress network queue-group policer-override
configure card fp ingress access queue-group policer-override
Description
This command, within the SAP ingress or egress contexts, is used to create a CLI node for specific overrides to one or more policers created on the SAP through the sap-ingress or sap-egress QoS policies.
The no form of this command removes any existing policer overrides.
Default
no policer-override
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer-override
Syntax
[no] policer-override
Context
[Tree] (config>service>epipe>sap>ingress policer-override)
[Tree] (config>service>epipe>sap>egress policer-override)
[Tree] (config>service>cpipe>sap>egress policer-override)
[Tree] (config>service>ipipe>sap>ingress policer-override)
[Tree] (config>service>ipipe>sap>egress policer-override)
[Tree] (config>service>cpipe>sap>ingress policer-override)
Full Context
configure service epipe sap ingress policer-override
configure service epipe sap egress policer-override
configure service cpipe sap egress policer-override
configure service ipipe sap ingress policer-override
configure service ipipe sap egress policer-override
configure service cpipe sap ingress policer-override
Description
This command, within the SAP ingress or egress contexts, is used to create a CLI node for specific overrides to one or more policers created on the SAP through the sap-ingress or sap-egress QoS policies.
The no form of this command is used to remove any existing policer overrides.
Default
no policer-overrides
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
- configure service epipe sap egress policer-override
- configure service ipipe sap ingress policer-override
- configure service epipe sap ingress policer-override
- configure service ipipe sap egress policer-override
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS
- configure service cpipe sap egress policer-override
- configure service cpipe sap ingress policer-override
policer-override
Syntax
[no] policer-override
Context
[Tree] (config>service>vpls>sap>ingress policer-override)
[Tree] (config>service>vpls>sap>egress policer-override)
Full Context
configure service vpls sap ingress policer-override
configure service vpls sap egress policer-override
Description
This command, within the SAP ingress or egress contexts, is used to create a CLI node for specific overrides to one or more policers created on the SAP through the sap-ingress or sap-egress QoS policies.
The no form of this command is used to remove any existing policer overrides.
Default
no policer-overrides
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer-override
Syntax
[no] policer-override
Context
[Tree] (config>service>ies>if>sap>ingress policer-override)
[Tree] (config>service>ies>if>sap>egress policer-override)
Full Context
configure service ies interface sap ingress policer-override
configure service ies interface sap egress policer-override
Description
This command, within the SAP ingress or egress contexts, is used to create a CLI node for specific overrides to one or more policers created on the SAP through the sap-ingress or sap-egress QoS policies.
The no form of this command is used to remove any existing policer overrides.
Default
no policer-override
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer-override
Syntax
[no] policer-override
Context
[Tree] (config>service>vprn>if>sap>ingress policer-override)
[Tree] (config>service>vprn>if>sap>egress policer-override)
Full Context
configure service vprn interface sap ingress policer-override
configure service vprn interface sap egress policer-override
Description
This command, within the SAP ingress or egress contexts, is used to create a CLI node for specific overrides to one or more policers created on the SAP through the sap-ingress or sap-egress QoS policies.
The no form of this command is used to remove any existing policer overrides.
Default
no policer-override
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer-stats
policer-stats
Syntax
[no] policer-stats
Context
[Tree] (config>app-assure>group>statistics>aa-admit-deny policer-stats)
Full Context
configure application-assurance group statistics aa-admit-deny policer-stats
Description
This command configures whether to include or exclude system and subscriber-level flow count and flow-setup rate policer admit-deny statistics in accounting records.
Default
no policer-stats
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
policer-stats-resources
policer-stats-resources
Syntax
[no] policer-stats-resources
Context
[Tree] (config>app-assure>group>statistics>aa-admit-deny policer-stats-resources)
Full Context
configure application-assurance group statistics aa-admit-deny policer-stats-resources
Description
This command allows the operator to allocate or deallocate AA partition resources for policer admit-deny statistics.
Default
no policer-stats-resources
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
policers
policers
Syntax
policers policy-limit
no policers
Context
[Tree] (config>card>fp>ingress>policy-accounting policers)
Full Context
configure card fp ingress policy-accounting policers
Description
This command configures the number of policer resources for an policy accounting. Policy accounting can be used to collect statistics about the amount of traffic matching particular routes and, on FP4 cards and systems only, it can also be used to police traffic associated with certain routes as destinations of the traffic.
Using only statistics (policing is not performed) requires the reservation of policer statistics index resources on each FP receiving the traffic to be counted. Every policy-accounting interface on a card or FP uses one of these resources for every source and destination class index listed in the template referenced by the interface. The total reservation at the FP level is set using the configure card slot-number fp fp-number policy-accounting command.
Using FP4 policing requires the above resource, and in addition, policer index resources. Every policy-accounting interface on a card or FP uses one of these resources for every destination class associated with a policer in the template referenced by the interface. The total reservation of this second resource at the FP level is set using the configure card slot-number fp fp-number ingress policy-accounting policers command.
The total number of the above resources, per FP, must be less than or equal to 128000. In addition, the second resource pool size must be less than or equal to the size of the first resource pool.
It is possible to increase or decrease the size of either resource sub pool at any time. A decrease can cause some interfaces (randomly selected) to immediately lose their resources and stop counting or policing some traffic that was previously being counted or policed.
If the policy accounting is enabled on a spoke SDP or R-VPLS interface all FPs in the system should have a reservation for each of the above resources, otherwise the show router interface policy-accounting command output reports that statistics are possibly incomplete.
Default
no policers
Parameters
- policy-limit
-
Specifies the number of policer resources for policy accounting.
Platforms
7450 ESS, 7750 SR, 7750 SR-s, 7950 XRS
policers
Syntax
policers [all-dynamic | all-static]
Context
[Tree] (config>subscr-mgmt>sla-prof>aggregate-qos-stats>egress policers)
Full Context
configure subscriber-mgmt sla-profile aggregate-qos-stats egress policers
Description
This command configures which types of policers are used to calculate the total egress aggregate statistics. This can include all static policers that are configured in a QoS SAP-egress policy, or all dynamic policers that are created on demand, according to the session needs.
Default
policers all-static
Parameters
- all-dynamic
- Keyword that specifies to select all dynamic policers for aggregate QoS egress statistics calculation.
- all-static
- Keyword that specifies to select all static policers for aggregate QoS egress statistics calculation.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
policers
Syntax
[no] policers
Context
[Tree] (config>subscr-mgmt>sla-prof>csg>egress policers)
Full Context
configure subscriber-mgmt sla-profile custom-statistics-group egress policers
Description
Commands in this context configure policers for the aggregate custom statistics group.
The no form of this command disables custom statistics collection for all dynamic and static policers for the group.
Default
no policers
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
policers-hqos-manageable
policers-hqos-manageable
Syntax
[no] policers-hqos-manageable
Context
[Tree] (config>qos>sap-egress policers-hqos-manageable)
Full Context
configure qos sap-egress policers-hqos-manageable
Description
This command enables Hierarchical QoS (HQoS) management of the policiers within the SAP egress policy, when the policy is applied to either the egress SAP configuration or the egress SLA profile, with multiservice sites (MSS) supported for SAPs. When enabled, the system can manage egress policers and queues together in the same HQoS hierarchy.
To be managed by HQoS, egress policers within a SAP egress QoS policy must be configured with either a scheduler-parent or port-parent command or be orphaned to an egress port scheduler applied on a Vport or port.
The policers-hqos-manageable command and parent-location sla or policers with enable-exceed-pir or stat-mode no-stats within a SAP egress QoS policy are mutually exclusive.
To prevent HQoS from measuring the traffic through both a policer managed by HQoS, then again through a post-policer access egress queue group queue, configure post-policer access egress queue groups with no queues-hqos-manageable so their queues are not managed by HQoS.
A post-policer local queue is not supported with HQoS managed policers, nor are those mapped by the use-fc-mapped-queue parameter in a criteria action statement. The policers-hqos-manageable command is not supported for SAP egress dynamic policers or on a 7950 XRS.
The no form of this command rdisables HQoS management of policers within the SAP QoS egress policy.
Default
no policers-hqos-manageable
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-1s, 7750 SR-1se, 7750 SR-2s, 7750 SR-2se, 7750 SR-7s, VSR
policers-hqos-manageable
Syntax
[no] policers-hqos-manageable
Context
[Tree] (config>qos>sap-ingress policers-hqos-manageable)
Full Context
configure qos sap-ingress policers-hqos-manageable
Description
This command specifies that the policers within this SAP ingress policy are to be managed by the Hierarchical QoS (HQoS) process when the policy is applied to either the ingress part of a SAP configuration or the ingress part of an SLA profile, with multiservice sites (MSS) supported for SAPs. When enabled, ingress policers and queues can be managed together in the same HQoS hierarchy.
To be managed by HQoS, ingress policers within a SAP ingress QoS policy must be configured with either a scheduler-parent or parent command or be orphaned to an ingress port scheduler applied on a Vport or port. The scheduler-parent and parent commands are mutually exclusive.
The policers-hqos-manageable command and the stat-mode no-stats command within a SAP ingress QoS policy are mutually exclusive.
The no form of this command results in policers within this SAP QoS ingress policy being non-HQoS-manageable.
Default
no policers-hqos-manageable
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-1s, 7750 SR-1se, 7750 SR-2s, 7750 SR-2se, 7750 SR-7s
policing
policing
Syntax
[no] policing
Context
[Tree] (config>test-oam>sath>svc-test>svc-stream>test-types policing)
Full Context
configure test-oam service-activation-testhead service-test service-stream test-types policing
Description
This command configures the policing test on the service stream.
The no form of this command removes the configured policing test.
Default
no policing
Platforms
7450 ESS, 7750 SR, 7750 SR-s, 7950 XRS
policing
Syntax
policing
Context
[Tree] (config>test-oam>service-activation-testhead>service-test>test-duration policing)
Full Context
configure test-oam service-activation-testhead service-test test-duration policing
Description
Commands in this context configure the duration for the policing test type.
Platforms
7450 ESS, 7750 SR, 7750 SR-s, 7950 XRS
policy
policy
Syntax
policy msap-policy-name
no policy
Context
[Tree] (config>subscr-mgmt>loc-user-db>ipoe>host>msap-defaults policy)
[Tree] (config>subscr-mgmt>loc-user-db>ppp>host>msap-defaults policy)
Full Context
configure subscriber-mgmt local-user-db ipoe host msap-defaults policy
configure subscriber-mgmt local-user-db ppp host msap-defaults policy
Description
This command configures the MSAP policy.
The no form of this command removes the MSAP policy name from the configuration.
Parameters
- msap-policy-name
-
Specifies the policy name, up to 32 characters.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
policy
Syntax
policy ppp-policy-name
no policy
Context
[Tree] (config>service>ies>sub-if>grp-if>pppoe policy)
[Tree] (config>service>vprn>sub-if>grp-if>pppoe policy)
Full Context
configure service ies subscriber-interface group-interface pppoe policy
configure service vprn subscriber-interface group-interface pppoe policy
Description
This command specifies the PPPoE policy on this interface.
The no form of this command reverts to the default.
Default
policy "default”
Parameters
- ppp-policy-name
-
Specifies the PPP policy name, up to 32 characters.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
policy
Syntax
policy policy-name
no policy
Context
[Tree] (config>subscr-mgmt>msap-policy>vpls-only>igmp-snp>mcac policy)
Full Context
configure subscriber-mgmt msap-policy vpls-only-sap-parameters igmp-snooping mcac policy
Description
This command configures the multicast CAC policy name.
The no form of this command reverts to the default.
Parameters
- policy-name
-
The multicast CAC policy name. Allowed values are any string up to 32 characters long composed of printable, 7-bit ASCII characters. If the string contains special characters (#, ?, space), the entire string must be enclosed within double quotes.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
policy
Syntax
policy name1 [name2] [ name3] [name4] [name5]
no policy
Context
[Tree] (config>subscr-mgmt>sub-prof>rad-acct policy)
Full Context
configure subscriber-mgmt sub-profile radius-accounting policy
Description
This command specifies the RADIUS accounting policy for the subscriber that is using this subscriber profile. This command allows the configuration of up to five RADIUS accounting policies. The RADIUS accounting policies function according to their respective configuration, including the individual accounting mode, their own included attributes, and the update interval.
Parameters
- name1
-
Specifies the name of the RADIUS accounting policy, up to 32 characters, to be used for the subscriber profile.
- name2
-
Specifies the name of the second RADIUS accounting policy, up to 32 characters, to be used for the subscriber profile.
- name3
-
Specifies the name of the third RADIUS accounting policy, up to 32 characters, to be used for the subscriber profile.
- name4
-
Specifies the name of the fourth RADIUS accounting policy, up to 32 characters, to be used for the subscriber profile.
- name5
-
Specifies the name of the fifth RADIUS accounting policy, up to 32 characters, to be used for the subscriber profile.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
policy
Syntax
policy vrrp-policy-id
no policy[vrrp-policy-id]
Context
[Tree] (config>service>vprn>sub-if>grp-if>srrp policy)
[Tree] (config>service>ies>sub-if>grp-if>srrp policy)
Full Context
configure service vprn subscriber-interface group-interface srrp policy
configure service ies subscriber-interface group-interface srrp policy
Description
This command associates one or more VRRP policies with the SRRP instance. A VRRP policy is a collection of connectivity and verification tests used to manipulate the in-use priorities of VRRP and SRRP instances. A VRRP policy can test the link state of ports, ping IP hosts, discover the existence of routes in the routing table or the ability to reach Layer 2 hosts. When one or more of these tests fail, the VRRP policy has the option of decrementing or setting an explicit value for the in-use priority of an SRRP instance.
More than one VRRP policy may be associated with an SRRP instance. When more than one VRRP policy is associated with an SRRP instance the delta decrement of the in-use priority is cumulative unless one or more test fail that have explicit priority values. When one or more explicit tests fail, the lowest priority value event takes effect for the SRRP instance. When the highest delta-in-use-limit is used to manage the lowest delta derived in-use priority for the SRRP instance.
VRRP policy associations may be added and removed at any time. A maximum of two VRRP policies can be associated with a single SRRP instance.
The no form of this command removes the association with the vrrp-policy-id from the SRRP instance.
Parameters
- vrrp-policy-id
-
Specifies one or more VRRP policies with the SRRP instance.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
policy
Syntax
[no] policy policy-name
Context
[Tree] (debug>diam>application policy)
Full Context
debug diameter application policy
Description
This command debugs Diameter applications for a particular application policy.
Parameters
- policy-name
-
Specifies the policy name, up to 32 characters.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
policy
Syntax
policy msap-policy-name
no policy
Context
[Tree] (config>service>vpls>sap>msap-defaults policy)
Full Context
configure service vpls sap msap-defaults policy
Description
This command sets default msap-policy for all subscribers created based on trigger packets received on the specified capture-sap in case the corresponding VSA is not included in the RADIUS authentication response. This command is applicable to capture SAP only.
Default
no policy
Platforms
All
policy
Syntax
policy policy-name
no policy
Context
[Tree] (config>service>pw-template>igmp-snooping>mcac policy)
[Tree] (config>service>vpls>mesh-sdp>igmp-snooping>mcac policy)
[Tree] (config>service>vpls>spoke-sdp>mld-snooping>mcac policy)
[Tree] (config>service>vpls>sap>igmp-snooping>mcac policy)
[Tree] (config>service>vpls>sap>mld-snooping>mcac policy)
[Tree] (config>service>vpls>spoke-sdp>igmp-snooping>mcac policy)
[Tree] (config>service>vpls>mesh-sdp>mld-snooping>mcac policy)
Full Context
configure service pw-template igmp-snooping mcac policy
configure service vpls mesh-sdp igmp-snooping mcac policy
configure service vpls spoke-sdp mld-snooping mcac policy
configure service vpls sap igmp-snooping mcac policy
configure service vpls sap mld-snooping mcac policy
configure service vpls spoke-sdp igmp-snooping mcac policy
configure service vpls mesh-sdp mld-snooping mcac policy
Description
This command configures the multicast CAC policy name. MCAC policy is not supported with MLD-snooping, therefore executing the command in the mld-snooping contexts will return an error.
Parameters
- policy-name
-
Specifies the multicast CAC policy name. Allowed values are any string up to 32 characters long composed of printable, 7-bit ASCII characters. If the string contains special characters (#, ?, space), the entire string must be enclosed within double quotes.
Platforms
All
policy
Syntax
policy vrrp-policy-id
no policy
Context
[Tree] (config>service>ies>if>ipv6>vrrp policy)
Full Context
configure service ies interface ipv6 vrrp policy
Description
This command creates VRRP control policies. The VRRP policy ID must be created by the policy command prior to association with the virtual router instance.
The policy command provides the ability to associate a VRRP priority control policy to a virtual router instance. The policy may be associated with more than one virtual router instance. The priority events within the policy either override or diminish the base-priority dynamically affecting the in-use priority. As priority events clear in the policy, the in-use priority may eventually be restored to the base-priority value.
The policy command is only available in the non-owner vrrp virtual-router-id nodal context. The priority of owner virtual router instances is permanently set to 255 and cannot be changed by VRRP priority control policies. For non-owner virtual router instances, if the policy command is not executed, the base-priority will be used as the in-use priority.
The no form of this command removes any existing VRRP priority control policy association from the virtual router instance. All such associations must be removed prior to the policy being deleted from the system.
Parameters
- vrrp-policy-id
-
The vrrp-policy-id parameter associated the corresponding VRRP priority control policy-id with the virtual router instance. The vrrp-policy-id must already exist in the system for the policy command to be successful.
Platforms
All
policy
Syntax
policy vrrp-policy-id
no policy
Context
[Tree] (config>service>ies>if>vrrp policy)
Full Context
configure service ies interface vrrp policy
Description
This command creates VRRP control policies. The VRRP policy ID must be created by the policy command prior to association with the virtual router instance.
The policy command provides the ability to associate a VRRP priority control policy to a virtual router instance. The policy may be associated with more than one virtual router instance. The priority events within the policy either override or diminish the base-priority dynamically affecting the in-use priority. As priority events clear in the policy, the in-use priority may eventually be restored to the base-priority value.
The policy command is only available in the non-owner vrrp virtual-router-id nodal context. The priority of owner virtual router instances is permanently set to 255 and cannot be changed by VRRP priority control policies. For non-owner virtual router instances, if the policy command is not executed, the base-priority will be used as the in-use priority.
The no form of this command removes any existing VRRP priority control policy association from the virtual router instance. All such associations must be removed prior to the policy being deleted from the system.
Parameters
- vrrp-policy-id
-
The vrrp-policy-id parameter associated the corresponding VRRP priority control policy-id with the virtual router instance. The vrrp-policy-id must already exist in the system for the policy command to be successful.
Platforms
All
policy
Syntax
policy policy-name
no policy
Context
[Tree] (config>service>vprn>bgp>next-hop-res policy)
Full Context
configure service vprn bgp next-hop-resolution policy
Description
This command specifies the name of a policy statement to use with the BGP next-hop resolution process. The policy controls which IP routes in RTM are eligible to resolve the BGP next-hop addresses of IPv4 and IPv6 routes. The policy has no effect on the resolution of BGP next-hops to MPLS tunnels. If a BGP next-hop of an IPv4 or IPv6 route R is resolved in RTM and the longest matching route for the next-hop address is an IP route N that is rejected by the policy then route R is unresolved; if the route N is accepted by the policy then it becomes the resolving route for R.
The default next-hop resolution policy (when the no policy command is configured) is to use the longest matching active route in RTM that is not a BGP route (unless use-bgp-routes is configured), an aggregate route or a subscriber management route.
Default
no policy
Parameters
- policy-name
-
Specifies the route policy name. Allowed values are any string up to 32 characters composed of printable, 7-bit ASCII characters. If the string contains special characters (#, ?, space), the entire string must be enclosed between double quotes. Route policies are configured in the config>router>policy-options context.
Platforms
All
policy
Syntax
policy policy-name
no policy
Context
[Tree] (config>service>vprn>igmp>if>mcac policy)
[Tree] (config>service>vprn>pim>if>mcac policy)
[Tree] (config>service>vprn>mld>grp-if>mcac policy)
[Tree] (config>service>vprn>igmp>grp-if>mcac policy)
Full Context
configure service vprn igmp interface mcac policy
configure service vprn pim interface mcac policy
configure service vprn mld group-interface mcac policy
configure service vprn igmp group-interface mcac policy
Description
This command references the global channel bandwidth definition policy that is used for HMCAC and HQoS Adjust.
HQoS Adjustment is supported with redirection enabled or per-host-replication disabled. In other words, the policy from the redirected interface is used for HQoS Adjustment.
Hierarchical MCAC (HMCAC) is supported with redirection enabled or per-host-replication disabled. In HMCAC, the subscriber is checked first against its bandwidth limits followed by the check on the redirected interface against the bandwidth limits defined under the redirected interface. In the HMCAC case, the channel definition policy must be referenced under the redirected interface level.
Parameters
- policy-name
-
Specifies the name of the global MCAC channel definition policy defined under the hierarchy config>router>mcac>policy. Allowed values are any string up to 32 characters composed of printable, 7-bit ASCII characters. If the string contains special characters (#, ?, space), the entire string must be enclosed between double quotes.
Platforms
All
- configure service vprn pim interface mcac policy
- configure service vprn igmp interface mcac policy
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
- configure service vprn igmp group-interface mcac policy
- configure service vprn mld group-interface mcac policy
policy
Syntax
policy vrrp-policy-id
no policy
Context
[Tree] (config>service>vprn>if>ipv6>vrrp policy)
[Tree] (config>service>vprn>if>vrrp policy)
Full Context
configure service vprn interface ipv6 vrrp policy
configure service vprn interface vrrp policy
Description
This command associates a VRRP priority control policy with the virtual router instance (non-owner context only).
Parameters
- vrrp-policy-id
-
Specifies a VRRP priority control policy.
Platforms
All
policy
Syntax
policy
Context
[Tree] (config>app-assure>group policy)
Full Context
configure application-assurance group policy
Description
Commands in this context configure parameters for application assurance policy. To edit any policy content begin command must be executed first to enter editing mode. The editing mode is left when the abort or commit commands are issued.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
policy
Syntax
policy aa-sub {sap sap-id | spoke-sdp sdp-id:vc-id | transit transit-aasub-name} [create]
no policy aa-sub {sap sap-id | spoke-sdp sdp-id:vc-id | transit transit-aasub-name}
Context
[Tree] (config>app-assure>group>policy-override policy)
Full Context
configure application-assurance group policy-override policy
Description
This command specifies a given SAP or SDP to be used for a static policy override.
The no form of this command removes the policy override.
Parameters
- sap-id
-
Specifies the physical port identifier portion of the SAP definition.
- sdp-id:vc-id
-
Specifies the spoke SDP ID and VC ID.
- transit-aasub-name
-
Specifies an existing transit subscriber name, up to 32 characters.
- create
-
Keyword used to create the policy override.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
policy
Syntax
policy policy-name
no policy
Context
[Tree] (config>router>igmp>interface>mcac policy)
[Tree] (config>router>pim>interface policy)
[Tree] (config>router>mcac policy)
[Tree] (config>router>igmp>grp-if>mcac policy)
[Tree] (config>router>mld>interface policy)
[Tree] (config>router>mld>group-interface policy)
Full Context
configure router igmp interface mcac policy
configure router pim interface policy
configure router mcac policy
configure router igmp group-interface mcac policy
configure router mld interface policy
configure router mld group-interface policy
Description
This command references the global channel bandwidth definition policy that is used for (H)MCAC and HQoS adjustment.
Within the scope of HQoS adjustment, the channel definition policy under the group-interface is used if redirection is disabled. In this case, the HQoS adjustment can be applied to IPoE subscribers in per-SAP replication mode.
If redirection is enabled, the channel bandwidth definition policy applied under the Layer 3 redirected interface is in effect.
Hierarchical MCAC (HMCAC) is supported on two levels simultaneously:
-
subscriber level and redirected interface in case that redirection is enabled
-
subscriber level and group-interface level in case that redirection is disabled
In HMCAC, the subscriber is first checked against its bandwidth limits followed by the check on the redirected interface (or group-interface) against the bandwidth limits there.
In the case that the redirection is enabled but the policy is referenced only under the group-interface, no admission control will be executed (HMCAC or MCAC).
Parameters
- policy-name
-
Specifies the name of the global MCAC channel definition policy, up to 32 characters, defined under the hierarchy config>router>mcac>policy.
Platforms
All
- configure router mld interface policy
- configure router pim interface policy
- configure router igmp interface mcac policy
- configure router mcac policy
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
- configure router igmp group-interface mcac policy
- configure router mld group-interface policy
policy
Syntax
policy vrrp-policy-id
no policy
Context
[Tree] (config>router>if>ipv6>vrrp policy)
[Tree] (config>router>if>vrrp policy)
Full Context
configure router interface ipv6 vrrp policy
configure router interface vrrp policy
Description
This command adds a VRRP priority control policy association with the virtual router instance.
To further augment the virtual router instance base priority, VRRP priority control policies can be used to override or adjust the base priority value depending on events or conditions within the chassis.
The policy can be associated with more than one virtual router instance. The priority events within the policy either override or diminish the base priority set with the priority command dynamically affecting the in-use priority. As priority events clear in the policy, the in-use priority can eventually be restored to the base priority value.
The policy command is only available in the non-owner vrrp nodal context. The priority of owner virtual router instances is permanently set to 255 and cannot be changed by VRRP priority control policies. For non-owner virtual router instances, if the policy command is not executed, the base priority is used as the in-use priority.
The no form of the command removes existing VRRP priority control policy associations from the virtual router instance. All associations must be removed prior to deleting the policy from the system.
Default
no policy — No VRRP priority control policy is associated with the virtual router instance.
Parameters
- vrrp-policy-id
-
The policy ID of the VRRP priority control expressed as a decimal integer. The vrrp-policy-id must already exist for the command to function.
Platforms
All
policy
Syntax
policy policy-id context context-value
policy policy-id context name name
no policy policy-id
Context
[Tree] (config>vrrp policy)
Full Context
configure vrrp policy
Description
This command creates the context to configure a VRRP priority control policy which is used to control the VRRP in-use priority based on priority control events. It is a parental node for the various VRRP priority control policy commands that define the policy parameters and priority event conditions.
The virtual router instance priority command defines the initial or base value to be used by non-owner virtual routers. This value can be modified by assigning a VRRP priority control policy to the virtual router instance. The VRRP priority control policy can override or diminish the base priority setting to establish the actual in-use priority of the virtual router instance.
The policy policy-id command must be created first, before it can be associated with a virtual router instance.
Because VRRP priority control policies define conditions and events that must be maintained, they can be resource intensive. The number of policies is limited to 1000.
The policy-id do not have to be consecutive integers. The range of available policy identifiers is from 1 to 9999.
The no form of the command deletes the specific policy-id from the system. The policy-id must be removed first from all virtual router instances before the no policy command can be issued. If the policy-id is associated with a virtual router instance, the command will fail.
Parameters
- policy-id
-
The VRRP priority control ID expressed as a decimal integer that uniquely identifies this policy from any other VRRP priority control policy defined on the system. Up to 1000 policies can be defined.
- context-value
-
Specifies the service ID to which this policy applies. A value of zero (0) means that this policy does not apply to a service but applies to the base router instance.
Platforms
All
policy
Syntax
policy cpu-protection-policy-id [create]
no policy cpu-protection-policy-id
Context
[Tree] (config>sys>security>cpu-protection policy)
Full Context
configure system security cpu-protection policy
Description
This command configures CPU protection policies.
The no form of this command deletes the specified policy from the configuration.
Policies 254 and 255 are reserved as the default access and network interface policies, and cannot de deleted. The parameters within these policies can be modified. An event will be logged (warning) when the default policies are modified.
Default
Policy 254 (default access interface policy):
-
per-source-rate: max (no limit)
-
overall-rate: 6000
-
out-profile–rate: 6000
-
alarm
Policy 255 (default network interface policy):
-
per-source-rate: max (no limit)
-
overall-rate: max (no limit)
-
out-profile-rate: 3000
-
alarm
Parameters
- cpu-protection-policy-id
-
Assigns a policy ID to the specific CPU protection policy.
- create
-
Keyword used to create CPU protection policy. The create keyword requirement can be enabled/disabled in the environment>create context.
Platforms
7450 ESS, 7750 SR-7/12/12e, 7750 SR-7s, 7750 SR-14s, 7950 XRS
policy
Syntax
policy policy-name [create] [type {access-network | port}]
no policy policy-name
Context
[Tree] (config>sys>security>dist-cpu-protection policy)
Full Context
configure system security dist-cpu-protection policy
Description
This command configures one of the maximum 18 Distributed CPU Protection (DCP) policies. These policies can be applied to objects such as SAPs, network interfaces or ports.
Parameters
- policy-name
-
Specifies the name of the policy, up to 32 characters.
- create
-
Keyword used to create a new policy.
- type
-
Specifies the Distributed CPU protection type for the policy.
Platforms
All
policy
Syntax
policy policy-name
no policy
Context
[Tree] (config>router>bgp>next-hop-resolution policy)
Full Context
configure router bgp next-hop-resolution policy
Description
This command specifies the policy statement name to use with the BGP next-hop resolution process. The policy determines the eligibility of IP routes in the RTM to resolve the BGP next-hop addresses of IPv4 and IPv6 routes. The policy has no effect on the resolution of BGP next hops to MPLS tunnels.
For example, if a BGP next hop of an IPv4 or IPv6 route R is resolved in RTM and the longest matching route for the next-hop address is an IP route N that is rejected by the policy then route R is unresolved. If the route N is accepted by the policy, it becomes the resolving route for R.
The no form of this command reverts to the default next-hop resolution policy, which uses the longest matching active route in RTM that is not a BGP route (unless use-bgp-routes is configured), an aggregate route or a subscriber management route.
Default
no policy
Parameters
- policy-name
-
Specifies the route policy name. Allowed values are any string up to 64 characters long composed of printable, 7-bit ASCII characters. If the string contains special characters (#, ?, space), the entire string must be enclosed within double quotes. Route policies are configured in the config>router>policy-options context.
Platforms
All
policy
Syntax
policy plcy-or-long-expr
no policy
Context
[Tree] (config>router>policy-options>policy-statement>entry>from policy)
Full Context
configure router policy-options policy-statement entry from policy
Description
This command is used to call another policy by name and evaluate it as a subroutine, or to evaluate a logical expression of subroutine policies.
If the result of the subroutine evaluation is an 'accept', then the route is considered to match the entry in the parent policy that called the subroutine. If the result of the subroutine evaluation is a 'reject’, then the route is considered a non-match of the entry in the parent policy that called the subroutine.
Up to 3 levels of subroutine calls are supported. If a subroutine at maximum depth has this command, it is automatically considered a non-match of all routes.
The no form of this command removes the policy statement as a match criterion.
Default
no policy
Parameters
- plcy-or-long-expr
-
Specifies the name of a single policy-statement (up to 64 characters in length) or a policy logical expression (up to 255 characters in length) consisting of policy-statement names (enclosed in square brackets), logical operations ('and’, 'or’, 'not’), and parentheses for grouping.
Platforms
All
policy
Syntax
policy plcy-or-long-expr
no policy
Context
[Tree] (config>router>policy-options>policy-statement>entry>action policy)
Full Context
configure router policy-options policy-statement entry action policy
Description
This command configures a nested policy statement as a match criterion for the route policy entry.
Policy statements are configured at the global route policy level (config>router>policy-options policy-statement).
The command is used to call another policy by name and evaluate it as a subroutine. If the result of the subroutine evaluation is an 'accept', then the route is considered to match the entry in the parent policy that called the subroutine. If the result of the subroutine evaluation is a 'reject’, then the route is considered a non-match of the entry in the parent policy that called the subroutine. Up to 3 levels of subroutine calls are supported. If a subroutine at maximum depth has this command, it is automatically considered a non-match of all routes.
The no form of this command removes the policy statement as a match criterion.
Default
no policy
Parameters
- plcy-or-long-expr
-
Specifies the route policy name (up to 64 characters long) or a policy logical expression (up to 255 characters). Allowed values are any string up to 255 characters long composed of printable, 7-bit ASCII characters. If the string contains special characters (#, ?, space), the entire string must be enclosed within double quotes.
Platforms
All
policy
Syntax
[no] policy association-name
Context
[Tree] (config>router>pcep>pcc>pce-assoc policy)
Full Context
configure router pcep pcc pce-associations policy
Description
This command creates a named PCE policy association from which the parameters for specified policy association are configured.
The no form of the command deletes the specified policy association.
Parameters
- association-name
-
Specifies the name of the policy association, up to 32 characters.
Platforms
All
policy
Syntax
[no] policy policy-assoc-name
Context
[Tree] (config>router>mpls>lsp>pce-assoc policy)
[Tree] (config>router>mpls>lsp-template>pce-assoc policy)
Full Context
configure router mpls lsp pce-associations policy
configure router mpls lsp-template pce-associations policy
Description
This command binds the LSP to a named policy association. The policy association name must exist under the PCC. Up to five policy associations can be configured per LSP.
The no form of the command removes the LSP binding from the specified policy association.
Parameters
- policy-assoc-name
-
Specifies the name of an existing policy association, up to 32 characters.
Platforms
All
policy-accounting
policy-accounting
Syntax
policy-accounting
Context
[Tree] (config>card>fp>ingress policy-accounting)
Full Context
configure card fp ingress policy-accounting
Description
Commands in this context configure policy accounting FP information.
Platforms
7450 ESS, 7750 SR, 7750 SR-s, 7950 XRS
policy-accounting
Syntax
policy-accounting template-name
no policy-accounting
Context
[Tree] (config>service>vprn>sub-if>grp-if>ingress policy-accounting)
Full Context
configure service vprn subscriber-interface group-interface ingress policy-accounting
Description
This command configures the specified policy accounting template.
The no form of this command disables the policy accounting template.
Parameters
- template-name
-
Specifies the template name, up to 32 characters.
Platforms
7450 ESS, 7750 SR, 7750 SR-s
policy-accounting
Syntax
policy-accounting <template-name>
no policy-accounting
Context
[Tree] (config>service>vprn>if>ingress policy-accounting)
Full Context
configure service vprn interface ingress policy-accounting
Description
This command configures the service VPRN interface ingress policy accounting
Parameters
- template-name
-
Specifies the template name, up to 32 characters.
Platforms
7450 ESS, 7750 SR, 7750 SR-s, 7950 XRS
policy-accounting
Syntax
policy-accounting <template-name>
no policy-accounting
Context
[Tree] (config>service>ies>if>ingress policy-accounting)
Full Context
configure service ies interface ingress policy-accounting
Description
This command configures the service IES interface ingress policy accounting
Parameters
- template-name
-
Specifies the template name, up to 32 characters.
Platforms
7450 ESS, 7750 SR, 7750 SR-s, 7950 XRS
policy-accounting
Syntax
policy-accounting template-name
no policy-accounting
Context
[Tree] (config>router>if>ingress policy-accounting)
Full Context
configure router interface ingress policy-accounting
Description
This command applies a policy accounting template to the associated interface.
The no form of this command removes the policy accounting template.
Parameters
- template-name
-
Specifies the template name, up to 32 characters.
Platforms
7450 ESS, 7750 SR, 7750 SR-s, 7950 XRS
policy-acct-template
policy-acct-template
Syntax
[no] policy-acct-template template-name
Context
[Tree] (config>router policy-acct-template)
Full Context
configure router policy-acct-template
Description
This command configures a policy accounting template.
The no form of this command deletes the specified policy accounting template.
Parameters
- template-name
-
Specifies the template name, up to 32 characters.
Platforms
7450 ESS, 7750 SR, 7750 SR-s, 7950 XRS
policy-control
policy-control
Syntax
policy-control diameter-policy-name
no policy-control
Context
[Tree] (config>service>vprn>sub-if>grp-if policy-control)
[Tree] (config>service>ies>sub-if>grp-if policy-control)
Full Context
configure service vprn subscriber-interface group-interface policy-control
configure service ies subscriber-interface group-interface policy-control
Description
This command configures a policy-control policy for the interface.
The no form of this command reverts to the default.
Parameters
- diameter-policy-name
-
Specifies the name of an existing diameter policy, up to 32 characters.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
policy-options
policy-options
Syntax
[no] policy-options
Context
[Tree] (config>router policy-options)
Full Context
configure router policy-options
Description
Commands in this context configure route policies. Route policies are applied to the routing protocol.
The no form of this command deletes the route policy configuration.
Platforms
All
policy-override
policy-override
Syntax
policy-override
Context
[Tree] (config>app-assure>group policy-override)
Full Context
configure application-assurance group policy-override
Description
Commands in this context configure policy override parameters.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
policy-reference-checks
policy-reference-checks
Syntax
[no] policy-reference-checks
Context
[Tree] (config>router policy-reference-checks)
Full Context
configure router policy-reference-checks
Description
This command checks policy references to ensure that a policy exists and displays a CLI error if the policy does not exist. Enabling this option protects against accidentally referencing a missing or misspelled policy, that can lead to unexpected results when the policy is evaluated.
The no version of this command disables policy reference checks and allows policies that do not exist to be referenced.
Default
no policy-reference-checks
Platforms
All
policy-statement
policy-statement
Syntax
policy-statement policy-name [policy-name]
no policy-statement
Context
[Tree] (config>test-oam>ldp-treetrace>path-discovery policy-statement)
Full Context
configure test-oam ldp-treetrace path-discovery policy-statement
Description
This command configures the FEC policy to determine which routes are imported from the LDP FEC database to discover its paths and probing them.
If no policy is specified, the ingress LER imports the full list of FECs from the LDP FEC database. New FECs are added to the discovery list at the next path discovery and not when they are learned and added into the FEC database. The maximum number of FECs to be discovered with path discovery is limited to 500.
The user can configure FECs to include or exclude.
Policies are configured in the config>router>policy-options context. A maximum of five policy names can be specified.
The no form of this command removes the policy from the configuration.
Default
no policy-statement
Parameters
- policy-name
-
Specifies up to five route policy names to filter LDP imported address FECs. Allowed values are any string up to 32 characters composed of printable, 7-bit ASCII characters. If the string contains special characters (#, ?, space), the entire string must be enclosed within double quotes. The specified policy name(s) must already be defined.
Platforms
All
policy-statement
Syntax
[no] policy-statement name
Context
[Tree] (config>router>policy-options policy-statement)
Full Context
configure router policy-options policy-statement
Description
This command creates the context to configure a route policy statement.
Route policy statements control the flow of routing information to and from a specific protocol, set of protocols, or to a specific BGP neighbor.
The policy-statement is a logical grouping of match and action criteria. A single policy-statement can affect routing in one or more protocols and/or one or more protocols peers/neighbors. A single policy-statement can also affect both the import and export of routing information.
The no form of this command deletes the policy statement.
Default
no policy-statement
Parameters
- name
-
Specifies the route policy statement name. Allowed values are any string up to 64 characters long composed of printable, 7-bit ASCII characters. If the string contains special characters (#, ?, space), the entire string must be enclosed within double quotes.
Platforms
All
policy-variables
policy-variables
Syntax
policy-variables
Context
[Tree] (config>router>policy-options>policy-statement>entry>from policy-variables)
Full Context
configure router policy-options policy-statement entry from policy-variables
Description
Commands in this context configure policy-variables parameters.
The no form of this command removes all policy variables.
Platforms
All
poll
poll
Syntax
poll ca ca-profile-name
Context
[Tree] (admin>certificate>cmpv2 poll)
Full Context
admin certificate cmpv2 poll
Description
This command polls the status of the pending CMPv2 request toward the specified CA.
If the response is ready, this command will resume the CMPv2 protocol exchange with server as the original command would do. The requests could be also still be pending as a result, then this command could be used again to poll the status.
SR OS allows only one pending CMP request per CA, which means no new request is allowed when a pending request is present.
Parameters
- ca-profile-name
-
Specifies a ca-profile name up to 32 characters.
Platforms
All
poll-interval
poll-interval
Syntax
poll-interval seconds
no poll-interval
Context
[Tree] (config>service>vprn>ospf3>area>if poll-interval)
[Tree] (config>service>vprn>ospf>area>if poll-interval)
Full Context
configure service vprn ospf3 area interface poll-interval
configure service vprn ospf area interface poll-interval
Description
This command configures the poll interval, in seconds. The poll interval is the time between two Hello packets to a dead (non-adjacent) OSPF NBMA neighbor. The default value of the poll interval timer is higher than the hello interval timer to avoid wasting bandwidth on non-broadcast networks, since OSPF messages are unicast to each configured neighbor. The poll interval timer is used only on non-broadcast interface types and has no effect if configured on other interface types.
The no form of this command removes the poll-interval configuration.
Default
120
Parameters
- seconds
-
Specifies the poll interval, in seconds.
Platforms
All
poll-interval
Syntax
poll-interval seconds
no poll-interval
Context
[Tree] (config>router>ospf3>area>interface poll-interval)
[Tree] (config>router>ospf>area>interface poll-interval)
Full Context
configure router ospf3 area interface poll-interval
configure router ospf area interface poll-interval
Description
This command configures the poll interval, in seconds. The poll interval is the time between two Hello packets to a dead (non-adjacent) OSPF NBMA neighbor. The default value of the poll interval timer is higher than the hello interval timer to avoid wasting bandwidth on non-broadcast networks, since OSPF messages are unicast to each configured neighbor. The poll interval timer is used only on non-broadcast interface types and has no effect if configured on other interface types.
The no form of this command removes the poll-interval configuration.
Default
120
Parameters
- seconds
-
Specifies the poll interval, in seconds.
Platforms
All
pool
pool
Syntax
pool pool-name [create]
no pool pool-name
Context
[Tree] (config>router>dhcp>server pool)
[Tree] (config>service>vprn>dhcp>server pool)
[Tree] (config>router>dhcp6>server pool)
[Tree] (config>service>vprn>dhcp6>server pool)
Full Context
configure router dhcp local-dhcp-server pool
configure service vprn dhcp local-dhcp-server pool
configure router dhcp6 local-dhcp-server pool
configure service vprn dhcp6 local-dhcp-server pool
Description
This command configures a DHCP address pool on the router.
The no form of this command removes the pool name from the configuration.
Parameters
- pool name
-
Specifies the name of this IP address pool. Allowed values are any string, up to 32 characters.
- create
-
Keyword used to create the pool. The create keyword requirement can be enabled or disabled in the environment>create context.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
pool
Syntax
pool pool-name router router-instance [create]
no pool pool-name router router-instance
Context
[Tree] (config>subscr-mgmt>isa-svc-chain>evpn>export>ip-advertise-routes pool)
Full Context
configure subscriber-mgmt isa-service-chaining evpn export ip-advertise-routes pool
Description
This command configures NAT pools that are advertised in EVPN type 5 routes to the peer participating in service chaining.
The no form of this command removes the parameters from the configuration.
Parameters
- pool-name
-
Specifies the name of the NAT pool up, to 32 characters.
- router-instance
-
Specifies the router instance belonging to the pool.
- create
-
Keyword used to create a pool instance. The create keyword requirement can be enabled or disabled in the environment>create context.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
pool
Syntax
pool [name]
Context
[Tree] (config>port>network>egress pool)
[Tree] (config>port>access>ingress pool)
[Tree] (config>port>access>egress pool)
Full Context
configure port network egress pool
configure port access ingress pool
configure port access egress pool
Description
This command configures pool policies.
On the MDA level, access and network egress and access ingress pools are only allocated on channelized MDAs. Network ingress pools are allocated on the FP level for non-channelized MDAs.
Default
pool default
Parameters
- name
-
If specified, the name must be default.
Platforms
All
pool
Syntax
pool [name]
Context
[Tree] (config>card>fp>ingress>network pool)
Full Context
configure card fp ingress network pool
Description
This command configures the per-FP network ingress pool.
Default
pool default
Parameters
- name
-
If specified, the name must be default.
Platforms
All
pool
Syntax
pool nat-pool-name [nat-group nat-group-id type pool-type [ applications applications] [create]
no pool nat-pool-name
Context
[Tree] (config>service>vprn>nat>outside pool)
Full Context
configure service vprn nat outside pool
Description
This command configures a NAT pool.
Parameters
- nat-pool-name
-
Specifies the NAT pool name.
- nat-group-id
-
Specifies the NAT group ID.
- create
-
This parameter must be specified to create the instance.
- pool-type
-
Specifies the pool type.
- applications
-
Specifies the application.
- create
-
Keyword used to create the pool.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
pool
Syntax
pool nat-pool-name nat-group nat-group-id type pool-type [applications applications] [create]
no pool nat-pool-name
Context
[Tree] (config>router>nat>outside pool)
Full Context
configure router nat outside pool
Description
This command creates a NAT pool in the outside routing context. The NAT pool defines the parameters that will be used for IP address and port translation within the pool.
Parameters
- nat-pool-name
-
Specifies the NAT pool name, up to 32 characters.
- nat-group-id
-
Specifies the NAT group ID.
- create
-
Creates the instance.
- pool-type
-
Species the pool type.
- applications
-
This creation-time parameter configures the NAT pool for protocol agnostic operation. The IP addresses are translated in 1:1 fashion regardless of the protocol. No ports are translated for TCP or UDP traffic. Traffic through the pool can be initiated from inside or outside. When nat-pool is configured in agnostic mode, certain parameters in the pool are pre-set and cannot be changed:
-
mode one-to-one
-
port-forwarding-range 0
-
port-reservation blocks 1
-
subscriber-limit 1
-
deterministic port-reservation 65536.
This pool is used to configure static 1:1 NAT, where the operator have the control of the mapping between the inside and outside IP addresses. The static IP address mapping is using CLI constructs used in deterministic NAT (prefix and map deterministic NAT commands in the inside routing context).
ALG for TCP/UDP is supported in the protocol agnostic pool.
-
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
pool
Syntax
pool [name]
no pool
Context
[Tree] (config>isa>aa-grp>qos>egress>to-subscriber pool)
[Tree] (config>isa>aa-grp>qos>egress>from-subscriber pool)
Full Context
configure isa application-assurance-group qos egress to-subscriber pool
configure isa application-assurance-group qos egress from-subscriber pool
Description
Commands in this context configure an IOM pool as applicable to the specific application assurance group traffic. The user can configure resv-cbs (as percentage) values and slope-policy similarly to other IOM pool commands.
Default
pool default
Parameters
- name
-
If specified, the name must be default.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
pool
Syntax
pool nat-pool-name service-name service-name
pool nat-pool-name router router-instance
no pool
Context
[Tree] (config>service>nat>nat-policy pool)
Full Context
configure service nat nat-policy pool
Description
This command configures the NAT pool of this policy.
Parameters
- nat-pool-name
-
Specifies the name of the NAT pool, up to 32 characters.
- router-instance
-
Specifies the router instance the pool belongs to, either by router name or service ID.
- service-name
-
Specifies the name of the service, up to 64 characters.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR