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.

Values

1 to 4294967295

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.

Values

1 to 65535

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.

Values

1 to 4294967295

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.

Values

1 to 32767

1 to 4294967295

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.

Values

1 to 16

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.

Values

0 to 50

Default

0 (The maximum number of discovered peers supported by the system).

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.

Values

0 to 512

Default

1 (The maximum number of discovered peers supported by the system.)

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.

Note:

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.

Note:

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.

Values

ipv6-address:

ipv6-address - x:x:x:x:x:x:x:x (eight 16-bit pieces)

x:x:x:x:x:x:d.d.d.d

x - [0..FFFF]H

d - [0..255]D

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.

Values

1 to 4096

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.

Values

1 to 12

chassis-id

Specifies chassis ID for the router chassis.

Values

1, 2

Default

1

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.

Values

apeq-ac-4400, apeq-ac-3000, apeq-dc-2000, apeq-dc-2200-2800, apeq-dc-4275, apeq-hvdc-3000

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.

Values

1 to 65535, max (max indicates no limit)

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.

Values

0.01 to 100.00

cir-percent

Specifies the CIR as a percentage.

Values

0.00 to 100.00

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.

Values

0.01 to 100.00

Default

100.00

cir-percent

Specifies the policer’s CIR as a percentage of the policers’s parent arbiter rate.

Values

0.00 to 100.00

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.

Values

0.01 to 100.00

Default

100.00

cir-percent

Specifies the queue’s CIR as a percentage dependent on the use of the port-limit or local-limit.

Values

0.00 to 100.00

Default

100.00

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.

Values

0.01 to 100.00

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.

Values

0.01 to 100.00

Default

100.00

cir-percent

Specifies the policer's CIR as a percentage of the policers' parent arbiter rate.

Values

0.00 to 100.00

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.

Values

0.01 to 100.00

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.

Values

0.01 to 100.00

Default

100.00

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.

Values

0.00 to 100.00

Default

100.00

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.

Values

0.01 to 100.00

Default

100.00

cir-percent

Specifies the policer's CIR as a percentage of the policers's parent arbiter rate.

Values

0.00 to 100.00

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.

Values

0.01 to 100.00

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.

Values

0.01 to 100.00

Default

100.00

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.

Values

0.00 to 100.00

Default

100.00

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.

Values

0.01 to 100.00

Default

100.00

cir-percent

Specifies the policer's CIR as a percentage of the policers's parent arbiter rate.

Values

0.00 to 100.00

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.

Values

0.01 to 100.00

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.

Values

0.01 to 100.00

Default

100.00

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.

Values

0.00 to 100.00

Default

100.00

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.

Values

0.01 to 100.00

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.

Values

Percentage ranging from 0.01 to 100.00

Default

100.00

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.

Values

Percentage ranging from 0.00 to 100.00

Default

100.00

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.

Values

0.01 to 100.00

Default

100.00

cir-percent

Specifies the queue's CIR as a percentage dependent on the use of the port-limit or local-limit.

Values

0.00 to 100.00

Default

100.00

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.

Values

0.00 to 100.00

Default

100.00

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.

Values

0.01 to 100.00

Default

100.00

cir-percent

Specifies the queue’s CIR as a percentage dependent on the use of the port-limit or local-limit.

Values

0.00 to 100.00

Default

100.00

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.

Values

0.01 to 100.00

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.

Values

0.01 to 100.00

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.

Values

0.01 to 100.00

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.

Values

0.00 to 100.00, sum

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.

Values

0.01 to 100.00

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.

Values

0.00 to 100.00, sum

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.

Values

0.01 to 100.00

Default

100.00

cir-percent

Specifies the queue's CIR as a percentage dependent on the use of the port-limit or local-limit.

Values

0.00 to 100.00

Default

100.00

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.

Values

0.00 to 100.00

Default

100.00

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.

Values

0.01 to 100.00 percent

Default

100.0

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.

Values

0.01 to 100.00 percent

Default

100.0

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.

Values

0.01 to 100.00

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.

Values

0.00 to 100.00, sum

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.

Values

Percentage ranging from 0.01 to 100.00.

Default

100.00

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.

Values

Percentage ranging from 0.00 to 100.00.

Default

100.00

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.

Values

0 to 100, default

0 specifies that the MBS and low drop-tail thresholds be set to the same value resulting in high- and low-congestion priority packets being treated equally.

100 specifies that the low drop-tail threshold is set to 0, resulting in all low-congestion priority packets being discarded.

Values between 0 and 100 result in a corresponding differential between the MBS and the low drop-tail threshold values.

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.

Values

0 to 100, default

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.

Values

0 to 100, default

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.

Values

0 to 100, default

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.

Values

0 to 100, default

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.

Values

0 to 100, default

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.

Values

0 to 100, default

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.

Values

0 to 100, default

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.

Values

0 to 100, default

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.

Values

0 to 100, default

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.

Values

0 to 100, default

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.

Values

100 to 1000

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.

Values

10 to 100

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.

Values

1 to 72

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.

Default

1 to 100000 messages per second

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.

Values

0 to 366

hours

Specifies the number of hours for periodic updates.

Values

0 to 23

minutes

Specifies the number of minutes for periodic updates.

Values

0 to 59

seconds

Specifies the number of seconds for periodic updates.

Values

0 to 59

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.

Note:

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

Values

1 to 600

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.

Values

ancp

ANCP

application-assurance

application-assurance

dhcp-server

local DHCP server

nat-fwds

NAT port forwarding

python-policy-cache

Python Cache

submgt

subscriber management

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 secret

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

Values

4 to 32

netmask

The subnet mask in dotted decimal notation.

Values

0.0.0.0 to 255.255.255.255 (network bits all 1 and host bits all 0)

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.

Values

0 to 16384

Default

56

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.

Values

1 to 10000 centiseconds if rapid is selected.

Default

1 centisecond if rapid is selected.

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

1 to 4294967295

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.

Values

be, l2, af, l1, h2, ef, h1, nc

Default

nc

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.

Values

ipv4-address:

a.b.c.d

ipv6-address:

x:x:x:x:x:x:x:x[-interface]

x:x:x:x:x:x:d.d.d.d[-interface]

x:

[0 to FFFF]H

d:

[0 to 255]D

interface:

up to 32 characters, mandatory for link local addresses

next-hop ip-address

Displays only static routes with the specified next hop IP address.

Values

ipv4-address:

a.b.c.d (host bits must be 0)

ipv6-address:

x:x:x:x:x:x:x:x (eight 16-bit pieces)

x:x:x:x:x:x:d.d.d.d

x:

[0 to FFFF]H

d:

[0 to 255]

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.

Values

0 to 65535

Default

system-generated sequential pattern

preference
Specifies the preference of the SRv6 policy candidate path to send the ping probe on.
Values

0 to 4294967295

Default

100

protocol-owner
Specifies the protocol owner of the SRv6 policy candidate path to ping.
Values

bgp — Specifies a BGP SRv6 policy.

static — Specifies a locally configured static SRv6 policy.

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.

Values

1 to 100000

Default

5

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.

Values

router-name: Base, management, cpm-vr-name, vpls-management

vprn-svc-name: The service name, up to 64 characters

cpm-vr-name: The CPM VR name, up to 32 characters

router-or-service

Specifies the routing instance or service, by number. The router-instance parameter is preferred for specifying the router or service.

Values

router-name: Base, management, vpls-management

vprn-svc-id: 1 to 2147483647

Default

Base

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.

Default

5

Values

1 to 10

secs

Sets the interval in seconds.

Values

1 to 1000 seconds if secs is selected.

Default

1 second if secs is selected.

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.

Values

ipv4-address:

a.b.c.d

ipv6-address:

x:x:x:x:x:x:x:x

x:x:x:x:x:x:d.d.d.d

x:

[0 to FFFF]H

d:

[0 to 255]D

timeout

Specifies the time out, in seconds.

Values

1 to 10

Default

5

type-of-service

Specifies the service type.

Values

0 to 255

Default

0

time-to-live

Specifies the TTL value for the MPLS label, expressed as a decimal integer.

Values

1 to 128

Default

64

srv6-policy
Keyword to specify that the ping probe is applied to an SRv6 policy.
color-id
Specifies the SRv6 policy color ID.
Values

0 to 4294967295

endpoint ipv6-address
Specifies an endpoint as the target of the ping.
Values

ipv6-address:

x:x:x:x:x:x:x:x

x:x:x:x:x:x:d.d.d.d

x:

[0 to FFFF]H

d:

[0 to 255]D

segment-list
Specifies the segment list to trace.
Values

1 to 32

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.

Values

1 to 100000000

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.

Values

0 to 100000000, max

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.

Values

0 to 100000000, max

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.

Values

1 to 400,000,000

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.

Values

100 to 4800 in multiples of 100 only

Default

400

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.

Values

200 to 4900 in multiples of 100 only and higher than the tnc-milli-seconds value

Default

800

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.

Values

300 to 5000 in multiples of 100 only and higher than the qos-milli-seconds value

Default

2000

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

Values

900 to 3600

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.

Values

1 to 63

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.

Values

1 to 63

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.

Values

1 to 63

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.

Values

1 to 32

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.

Values

single-bucket-bandwidth — Creates a profile for a single bucket (PIR) bandwidth limiting policer.

dual-bucket-bandwidth — Creates profile for a dual bucket (PIR, CIR) bandwidth limiting policer.

flow-rate-limit — Creates profile for a policer limiting rate of flow set-ups.

flow-count-limit — Creates profile for a policer limiting total flow count.

granularity

Specifies the granularity type.

Values

system — Creates a system policer profile for a policer that limits the traffic in the scope of all or a subset of AA subscribers on a given AA ISA.

subscriber — Creates a policer profile for a policer for each AA subscriber that limits the traffic in the scope of that subscriber.

access-network-location — Creates a policer profile for a policer instance for each ANL that limits traffic bandwidth in the scope of that ANL. For ANL, only single-bucket bandwidth policers can be configured.

flow — Creates a policer profile for a policer instance for each IP flow that limits the traffic in the scope of an individual flow. Only single-bucket bandwidth policers with the permit-deny or monitor actions can be configured.

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.

Values

from-sub, to-sub

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.

Values

1 to 63

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.

Values

1 to 63

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.

Values

1 to 63

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.

Values

1 to 8

Default

Derived from forwarding class assignment in queue-group definition.

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.

Values

Any qualifying egress queue group name

Default

policer-output-queues

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.

Values

1 to 8

Default

Derived from forwarding class assignment in queue-group definition

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.

Values

1 to 40960

Default

1

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.

Values

1 to 63

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.

Values

ingress

all platforms

1 to 32

egress VSR 1 to 8

egress

all other platforms

1 to 16

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.

Values

1 to 63

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.

Values

1 to 63

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.

Values

1 to 64000

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.

Values

1 to 9999

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.

Values

1 to 9999

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.

Values

1 to 9999

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.

Values

1 to 9999

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.

Values

1 to 32767

1 to 4294967295

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.

Values

1 to 9999

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.

Values

1 to 9999

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.

Values

1 to 2147483647

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.

Values

1 to 255

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.

Values

access-network — Specifies this is a distributed CPU protection policy for access or network interfaces.

port — Specifies this is a distributed CPU protection policy for ports.

Default

access-network

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.

Values

0 to 4294967295

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.

Values

0 to 4294967295

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.

Values

router-name | vprn-svc-id

router-name: Base, management, cpm-vr-name, vpls-management Default - Base

vprn-svc-id: [1 to 2147483647]

cpm-vr-name: [up to 32 characters]

service-name: [up to 64 characters]

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.

Values

32 chars max

nat-group-id

Specifies the NAT group ID.

Values

1 to 4

create

This parameter must be specified to create the instance.

pool-type

Specifies the pool type.

Values

large-scale, l2-aware, wlan-gw-anchor

applications

Specifies the application.

Values

agnostic

flexible-port-allocation

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.

Values

1 to 4

create

Creates the instance.

pool-type

Species the pool type.

Values

large-scale, l2-aware, wlan-gw-anchor

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.

Values

agnostic

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.

Values

1 to 2147483647 svc-name — a string up to 64 characters.

Values

router-name: "Base” | "management”

Default

Base

service-name

Specifies the name of the service, up to 64 characters.

Platforms

7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR