p Commands – Part II

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

7705 SAR Gen 2

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

7705 SAR Gen 2

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

7705 SAR Gen 2

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

7705 SAR Gen 2

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

7705 SAR Gen 2

ping-reply

Syntax

[no] ping-reply

Context

[Tree] (config>router>if>vrrp ping-reply)

[Tree] (config>router>if>ipv6>vrrp ping-reply)

Full Context

configure router interface vrrp ping-reply

configure router 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.

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

7705 SAR Gen 2

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

7705 SAR Gen 2

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

7705 SAR Gen 2

pkt-too-big

Syntax

[no] pkt-too-big

Context

[Tree] (config>service>vprn>if>ipsec>ipsec-tunnel>icmp6-gen pkt-too-big)

[Tree] (config>ipsec>tnl-temp>icmp6-gen pkt-too-big)

[Tree] (config>service>ies>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 vprn interface ipsec ipsec-tunnel icmp6-generation pkt-too-big

configure ipsec tunnel-template icmp6-generation pkt-too-big

configure service ies 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

7705 SAR Gen 2

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

7705 SAR Gen 2

pmtu-discovery-aging

Syntax

pmtu-discovery-aging seconds

no pmtu-discovery-aging

Context

[Tree] (config>service>vprn>if>sap>ip-tunnel pmtu-discovery-aging)

[Tree] (config>service>ies>if>ipsec>ipsec-tunnel pmtu-discovery-aging)

[Tree] (config>service>vprn>if>sap>ipsec-tunnel pmtu-discovery-aging)

[Tree] (config>router>if>ipsec>ipsec-tunnel pmtu-discovery-aging)

[Tree] (config>ipsec>tnl-temp pmtu-discovery-aging)

[Tree] (config>service>vprn>if>ipsec>ipsec-tunnel pmtu-discovery-aging)

[Tree] (config>service>ies>if>sap>ip-tunnel pmtu-discovery-aging)

Full Context

configure service vprn interface sap ip-tunnel pmtu-discovery-aging

configure service ies interface ipsec ipsec-tunnel pmtu-discovery-aging

configure service vprn interface sap ipsec-tunnel pmtu-discovery-aging

configure router interface ipsec ipsec-tunnel pmtu-discovery-aging

configure ipsec tunnel-template pmtu-discovery-aging

configure service vprn interface ipsec ipsec-tunnel pmtu-discovery-aging

configure service ies interface sap ip-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

7705 SAR Gen 2

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

7705 SAR Gen 2

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

7705 SAR Gen 2

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

7705 SAR Gen 2

policer

Syntax

policer policer-id [create]

no policer policer-id

Context

[Tree] (config>service>epipe>sap>egress>policer-over policer)

Full Context

configure service epipe sap egress 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

7705 SAR Gen 2

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

7705 SAR Gen 2

policer

Syntax

policer policer-id [create]

no policer policer-id

Context

[Tree] (config>service>ies>if>sap>ingress>policer-override policer)

[Tree] (config>service>ies>if>sap>egress>policer-override policer)

Full Context

configure service ies interface sap ingress policer-override policer

configure service ies interface sap egress 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

7705 SAR Gen 2

policer

Syntax

policer policer-id [create]

no policer policer-id

Context

[Tree] (config>service>vprn>if>sap>ingress>policer-override policer)

[Tree] (config>service>vprn>if>sap>egress>policer-override policer)

Full Context

configure service vprn interface sap ingress policer-override policer

configure service vprn interface sap egress 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

7705 SAR Gen 2

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

7705 SAR Gen 2

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

7705 SAR Gen 2

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

7705 SAR Gen 2

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

7705 SAR Gen 2

policer

Syntax

policer policer-id [create]

no policer policer-id

Context

[Tree] (config>qos>qgrps>ing>queue-group policer)

[Tree] (cfg>qos>qgrps>egr>queue-group policer)

Full Context

configure qos queue-group-templates ingress queue-group policer

configure qos queue-group-templates egress 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	all other platforms	1 to 16

Platforms

7705 SAR Gen 2

policer

Syntax

[no] policerpolicer-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

7705 SAR Gen 2

policer-control-override

Syntax

policer-control-override [create]

no policer-control-override

Context

[Tree] (config>card>fp>ingress>network>queue-group policer-control-override)

[Tree] (config>card>fp>ingress>access>queue-group policer-control-override)

Full Context

configure card fp ingress network queue-group policer-control-override

configure card fp ingress access 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

7705 SAR Gen 2

policer-control-override

Syntax

policer-control-override [create]

no policer-control-override

Context

[Tree] (config>service>epipe>sap>ingress policer-control-override)

[Tree] (config>service>epipe>sap>egress policer-control-override)

Full Context

configure service epipe sap ingress policer-control-override

configure service epipe sap egress 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

7705 SAR Gen 2

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

7705 SAR Gen 2

policer-control-override

Syntax

policer-control-override [create]

no policer-control-override

Context

[Tree] (config>service>ies>if>sap>ingress policer-control-override)

[Tree] (config>service>ies>if>sap>egress policer-control-override)

Full Context

configure service ies interface sap ingress policer-control-override

configure service ies interface sap egress 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

7705 SAR Gen 2

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

7705 SAR Gen 2

policer-control-policy

Syntax

policer-control-policy policer-control-policy-name

no policer-control-policy

Context

[Tree] (config>card>fp>ingress>access>queue-group policer-control-policy)

[Tree] (config>card>fp>ingress>network>queue-group policer-control-policy)

Full Context

configure card fp ingress access queue-group policer-control-policy

configure card fp ingress network 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

7705 SAR Gen 2

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)

Full Context

configure port ethernet network egress queue-group 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

7705 SAR Gen 2

policer-control-policy

Syntax

policer-control-policy policy-name

no policer-control-policy

Context

[Tree] (config>service>epipe>sap>egress policer-control-policy)

[Tree] (config>service>epipe>sap>ingress policer-control-policy)

Full Context

configure service epipe sap egress policer-control-policy

configure service epipe 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.

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

7705 SAR Gen 2

policer-control-policy

Syntax

policer-control-policy policy-name

no policer-control-policy

Context

[Tree] (config>service>template>vpls-sap-template>egress policer-control-policy)

[Tree] (config>service>template>vpls-sap-template>ingress policer-control-policy)

[Tree] (config>service>vpls>sap>ingress policer-control-policy)

[Tree] (config>service>vpls>sap>egress policer-control-policy)

Full Context

configure service template vpls-sap-template egress policer-control-policy

configure service template vpls-sap-template ingress policer-control-policy

configure service vpls sap ingress policer-control-policy

configure service vpls 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.

create: The keyword is required when a new policy is being created and the system is configured for explicit object creation mode.

Platforms

7705 SAR Gen 2

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