p Commands – Part I
p2mp
p2mp
Syntax
p2mp {enable | disable}
Context
[Tree] (config>router>ldp>session-params>peer>fec-type-capability p2mp)
Full Context
configure router ldp session-parameters peer fec-type-capability p2mp
Description
This command enables or disables P2MP FEC capability for the session.
Platforms
All
p2mp-id
p2mp-id
Syntax
p2mp-id id
Context
[Tree] (config>router>mpls>lsp p2mp-id)
Full Context
configure router mpls lsp p2mp-id
Description
This command configures the identifier of an RSVP P2MP LSP. An RSVP P2MP LSP is fully identified by the combination of: <P2MP ID, tunnel ID, extended tunnel ID> part of the P2MP session object, and <tunnel sender address, LSP ID> fields in the p2mp sender_template object.
The p2mp-id is a 32-bit identifier used in the session object that remains constant over the life of the P2MP tunnel. It is unique within the scope of the ingress LER.
The no form restores the default value of this parameter.
This command is not supported on the 7450 ESS.
Default
0
Parameters
- id
-
Specifies a P2MP identifier.
Platforms
All
p2mp-ipv4
p2mp-ipv4
Syntax
p2mp {enable | disable}
Context
[Tree] (config>router>ldp>if-params>if>ipv4>fec-type-capability p2mp-ipv4)
[Tree] (config>router>ldp>if-params>if>ipv6>fec-type-capability p2mp-ipv4)
[Tree] (config>router>ldp>session-params>peer>fec-cap p2mp-ipv4)
Full Context
configure router ldp interface-parameters interface ipv4 fec-type-capability p2mp-ipv4
configure router ldp interface-parameters interface ipv6 fec-type-capability p2mp-ipv4
configure router ldp session-parameters peer fec-type-capability p2mp-ipv4
Description
This command enables or disables IPv4 P2MP FEC capability on the interface.
The config>router>ldp>if-params>if>ipv6>fec-type-capability>p2mp-ipv4 command is not supported on the 7450 ESS.
Platforms
All
p2mp-ipv6
p2mp-ipv6
Syntax
p2mp {enable | disable}
Context
[Tree] (config>router>ldp>session-params>peer>fec-cap p2mp-ipv6)
[Tree] (config>router>ldp>if-params>if>ipv4>fec-type-capability p2mp-ipv6)
[Tree] (config>router>ldp>if-params>if>ipv6>fec-type-capability p2mp-ipv6)
Full Context
configure router ldp session-parameters peer fec-type-capability p2mp-ipv6-address
configure router ldp interface-parameters interface ipv4 fec-type-capability p2mp-ipv6
configure router ldp interface-parameters interface ipv6 fec-type-capability p2mp-ipv6
Description
This command enables or disables IPv6 P2MP FEC capability on the interface.
This command is not supported on the 7450 ESS.
Platforms
All
p2mp-ldp-tree-join
p2mp-ldp-tree-join
Syntax
p2mp-ldp-tree-join
p2mp-ldp-tree-join ipv4
p2mp-ldp-tree-join ipv6
p2mp-ldp-tree-join ipv4 ipv6
no p2mp-ldp-tree-join [ipv4] [ipv6]
Context
[Tree] (config>service>vprn>pim>if p2mp-ldp-tree-join)
Full Context
configure service vprn pim interface p2mp-ldp-tree-join
Description
This command configures the option to join P2MP LDP tree toward the multicast source for the VPRN service. If p2mp-ldp-tree-join is enabled, a PIM multicast join received on an interface is processed to join P2MP LDP LSP using the in-band signaled P2MP tree for the same multicast flow. LDP P2MP tree is setup toward the multicast source. Route to source of the multicast node is looked up from the RTM. The next-hop address for the route to source is set as the root of LDP P2MP tree.
The no form of command disables joining P2MP LDP tree for IPv4 or IPv6 or both (if both or none is specified).
Default
no p2mp-ldp-tree-join
Parameters
- ipv4
-
Enables dynamic mLDP in-band signaling for IPv4 PIM joins. IPv4 multicast must be enabled; see ipv4-multicast-disable. For backward compatibility p2mp-ldp-tree-join is equivalent to p2mp-ldp-tree-join ipv4.
- ipv6
-
Enables dynamic mLDP in-band signaling for IPv6 PIM joins. IPv6 multicast must be enabled; see ipv6-multicast-disable.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
p2mp-ldp-tree-join
Syntax
[no] p2mp-ldp-tree-join [ipv4] [ipv6]
Context
[Tree] (config>router>pim>interface p2mp-ldp-tree-join)
Full Context
configure router pim interface p2mp-ldp-tree-join
Description
This command configures the option to join the P2MP LDP tree toward the multicast source. If p2mp-ldp-tree-join is enabled, a PIM multicast join received on an interface is processed to join the P2MP LDP LSP, using the in-band signaled P2MP tree for the same multicast flow. LDP P2MP tree is set up toward the multicast source. The route to the multicast node source is looked up from the RTM. The next-hop address for the route to source is set as the root of LDP P2MP tree.
The no form of this command disables joining the P2MP LDP tree for IPv4 or IPv6 or for both (if both or none is specified).
Default
no p2mp-ldp-tree-join
Parameters
- ipv4
-
Enables dynamic MLDP in-band signaling for IPv4 PIM joins. IPv4 multicast must be enabled. For backward compatibility p2mp-ldp-tree-join is equivalent to p2mp-ldp-tree-join ipv4.
- ipv6
-
Enables dynamic MLDP in-band signaling for IPv6 PIM joins. IPv6 multicast must be enabled.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
p2mp-lsp-ping
p2mp-lsp-ping
Syntax
p2mp-lsp-ping lsp-name [p2mp-instance instance-name [s2l-dest-address ipv4-address [ipv4-address (...up to 5 max)]] [ttl label-ttl]
p2mp-lsp-ping ldp p2mp-identifier [vpn-recursive-fec] [sender-addr ipv4-address] [leaf-addr ipv4-address (...up to 5 max)]
p2mp-lsp-ping ldp-ssm source ip-address group ip-address [{router router-instance | service-name service-name}] [sender-addr ipv4-address] [leaf-addr ipv4-address (...up to 5 max)]
p2mp-lsp-ping p2mp-policy root-address ipv4-address root-tree-id tree-id [{instance-id instance-id [sender-addr ipv4-address] [leaf-addr ipv4-address (...up to 5 max)]
NOTE: Options common to all p2mp-lsp-ping cases: [ fc fc-name [profile {in | out}]] [size octets] [timeout timeout] [detail]
Context
[Tree] (oam p2mp-lsp-ping)
Full Context
oam p2mp-lsp-ping
Description
This command performs an in-band connectivity test for an RSVP P2MP LSP. The Echo Request message is sent on the active P2MP instance and replicated in the datapath over all branches of the P2MP LSP instance. By default, all egress LER nodes that are leaves of the P2MP LSP instance reply to the Echo Request message.
Use the LDP P2MP generic identifier, along with source IP address of the head-end node, to uniquely identify the LDP P2MP LSP in a 7750 SR or 7950 XRS network. Use the LDP p2mp-identifier mandatory parameter to test LSP ping. A user must use the LDP P2MP identifier specified to configure a tunnel interface on the head-end node as p2mp-identifier to test a specific LSP.
Use the P2MP-policy option, along with the root-address tree ID and instance ID to identify a tree SID candidate path and instance to send an in-band Echo Request to all the leaves and bud nodes on that P2MP policy tree.
To reduce the scope of the Echo Reply messages, explicitly enter a list of addresses for the egress LER nodes that are required to reply. A maximum of five addresses can be specified in a single run of the p2mp-lsp-ping command. An LER node can parse the list of egress LER addresses and, if its address is included in the list, send back an Echo Reply message.
The output of the command without the detail keyword provides a high-level summary of received error codes and success codes. The output of the command with the detail keyword shows a line for each replying node, as in the output of the LSP ping for a P2P LSP.
The display is delayed until all responses are received or the timer configured in the timeout parameter expires. No other CLI commands can be entered while waiting for the display. Entering A ^C aborts the ping operation.
The timestamp format to be sent, and to be expected when received in a PDU, is as configured by the configure test-oam mpls-time-stamp-format command. If RFC 4379 (obsoleted by RFC 8029) is selected, the timestamp is in seconds and microseconds since 1900; otherwise, it is in seconds and microseconds since 1970.
Parameters
- detail
-
Displays detailed P2MP LSP information.
- fc-name
-
Specifies the fc and profile parameters used to indicate the forwarding class and profile of the MPLS echo request packet.
When an MPLS echo request packet is generated in CPM and is forwarded to the outgoing interface, the packet is queued in the egress network queue corresponding to the specified FC and profile parameter values. The marking of the EXP of the packet is dictated by the LSP-EXP mappings on the outgoing interface.
When the MPLS echo request packet is received on the responding node, the fc and profile parameter values are dictated by the LSP-EXP mappings of the incoming interface.
When an MPLS echo reply packet is generated in CPM and forwarded to the outgoing interface, the packet is queued in an egress network queue. This queue is selected according to the fc and profile parameter values determined by the classification of the echo request packet that is being replied to at the incoming interface. The marking of the EXP of the packet is dictated by the LSP-EXP mappings on the outgoing interface. The ToS byte is not modified. The following table describes this behavior.
Table 1. p2mp-lsp-ping Request Packet and Behavior Request Packet
Behavior
CPM (sender node)
Echo request packet:
-
packet {tos=1, fc1, profile1}
-
fc1 and profile1 are as entered by the user in the OAM command or default values
-
tos1 as per mapping of {fc1, profile1} to IP precedence in network egress QoS policy of outgoing interface
Outgoing interface (sender node)
Echo request packet:
-
packet queued as {fc1, profile1}
-
ToS field=tos1 not remarked
-
EXP=exp1, as per mapping of {fc1, profile1} to EXP in network egress QoS policy of outgoing interface
Incoming interface (responder node)
Echo request packet:
-
packet {tos1, exp1}
-
exp1 mapped to {fc2, profile2} as per classification in network QoS policy of incoming interface
CPM (responder node)
Echo reply packet:
-
packet {tos=1, fc2, profile2}
Outgoing interface (responder node)
Echo reply packet:
-
packet queued as {fc2, profile2}
-
ToS filed= tos1 not remarked (reply inband or out-of-band)
-
EXP=exp2, if reply is inband, remarked as per mapping of {fc2, profile2} to EXP in network egress QoS policy of outgoing interface
Incoming interface (sender node)
Echo reply packet:
-
packet {tos1, exp2}
-
exp2 mapped to {fc1, profile1} as per classification in network QoS policy of incoming interface
-
- instance-id
- Specifies the path instance ID on the root.
- instance-name
-
Specifies the name, up to 32 characters, of the specific instance of the P2MP LSP to send the echo request.
- label-ttl
-
Specifies the TTL value for the MPLS label, expressed as a decimal integer.
- leaf-addr ipv4-address
-
Specifies up to five egress LER system addresses that are required to reply to the LSP ping Echo Request message as defined in RFC 6425 (applies to the 7750 SR and 7950 XRS only).
- lsp-name
-
Specifies the name, up to 64 characters, that identifies an P2MP LSP to ping.
- ldp-ssm
-
Specifies a specific multicast stream to be tested when using dynamic multicast in mLDP. The source and group addresses correspond to the <S,G> being advertised by this mLDP FEC.
- p2mp-identifier
-
Specifies the identifier for an LDP P2MP LSP to ping (applies to the 7750 SR and 7950 XRS only).
- profile {in | out}
-
Specifies the profile of the LSP ping Echo Request message.
- octets
-
Specifies the size of the MPLS echo request packet in octets, expressed as a decimal integer, including the IP header but not the label stack. The request payload is padded with zeros to the specified size.
Note: An OAM command is not failed if the user enters a size lower than the minimum required to build the packet for the Echo Request message. The payload is automatically padded to meet the minimum size.
- root-address ipv4-address
- Specifies the IPv4 identifier of the root.Note: IPv6 is not supported.
- root-tree-id tree-id
- Specifies the tree identifier of the P2MP LSP on the root.
- s2l-dest-addr ipv4-address
-
Specifies up to five egress LER system addresses that are required to reply to the LSP ping Echo Request message.
- sender-addr ipv4-address
-
Specifies the IPv4 address used in the ICMP packet configured as the source IP of the UDP ICMP packet and used for the echo reply destination IP address (applies to the 7750 SR and 7950 XRS only).Note: By default, the source IP address of the ICMP packet is set to the root address. When the sender address is set this source address is changed to the sender address.
- timeout
-
Specifies the time, in seconds, that is used to override the default timeout value and is the amount of time that the router waits for an Echo Reply message from all leaves of the P2MP LSP after sending the message request message. After the expiration of the message time out, the requesting router no longer waits for reply messages. Any Echo Reply message received after the request times out is silently discarded.
- vpn-recursive-fec
-
Specifies a VPN recursive FEC element to the launched packet (useful for pinging a VPN BGP inter-AS Option B leaf). This parameter issues an OAM p2mp-lsp-ping with RFC 6512 VPN recursive opaque FEC type 8.
See the "OAM” subsection of the "Label Distribution Protocol" chapter in the 7450 ESS, 7750 SR, 7950 XRS, and VSR MPLS Guide for more information.
Platforms
All
p2mp-lsp-trace
p2mp-lsp-trace
Syntax
p2mp-lsp-trace lsp-name p2mp-instance instance-name s2l-dest-address ip-address [fc fc-name [profile {in | out}]] [size octets] [max-fail no-response-count] [probe-count probes-per-hop] [min-ttl min-label-ttl] [ max-ttl max-label-ttl] [timeout timeout] [interval interval] [detail]
Context
[Tree] (oam p2mp-lsp-trace)
Full Context
oam p2mp-lsp-trace
Description
This command discovers and displays the hop-by-hop path for a source-to-leaf (S2L) sub-LSP of an RSVP P2MP LSP.
The LSP trace capability allows the user to trace the path of a single S2L path of a P2MP LSP. Its operation is like p2mp-lsp-ping, but the sender of the echo reply request message includes the downstream mapping TLV to request the downstream branch information from a branch LSR or bud LSR. The branch LSR or bud LSR also includes the downstream mapping TLV to report the information about the downstream branches of the P2MP LSP. An egress LER does not include this TLV in the echo response message.
The parameter probe-count operates in the same way as in LSP Trace on a P2P LSP. It represents the maximum number of probes sent per TTL value before stops waiting for Echo Reply messages. If a response is received from the traced node before reaching maximum number of probes, then no more probes are sent for the same TTL. The sender of the echo request then increments the TTL and uses the information it received in the downstream mapping TLV to start sending probes to the node downstream of the last node which replied. This continues until the egress LER for the traced S2L path replies.
Like p2mp-lsp-ping, an LSP trace probe reports on all egress LER nodes that eventually receive the Echo Request message, but only the traced egress LER node replies to the last probe.
Any branch LSR node or bud LSR node in the P2MP LSP tree may receive a copy of the Echo Request message with the TTL in the outer label expiring at this node. However, only a branch LSR or bud LSR that has a downstream branch over which the traced egress LER is reachable responds.
When a branch LSR or bud LSR responds, it sets the global return code in the echo response message to RC=14 - "See DDMAP TLV for Return Code and Return Sub-Code” and the return code in the DDMAP TLV corresponding to the outgoing interface of the branch used by the traced S2L path to RC=8 - "Label switched at stack-depth <RSC>”. Note that p2mp-lsp-trace is not supported in a VPLS/B-VPLS PMSI context.
The timestamp format to be sent, and to be expected when received in a PDU, is as configured by the config>test-oam>mpls-time-stamp-format command. If RFC 4379 (obsoleted by RFC 8029) is selected, then the timestamp is in seconds and microseconds since 1900, otherwise it is in seconds and microseconds since 1970.
Parameters
- lsp-name
-
Specifies the name that identifies an P2MP LSP, up to 64 characters, to ping.
- instance-name
-
Specifies the name, up to 32 characters, of the specific instance of the P2MP LSP to send the echo request.
- ip-address
-
Specifies the egress LER system address of the S2L sub-LSP path which is being traced.
- fc-name
-
Specifies the fc and profile parameters are used to indicate the forwarding class and profile of the MPLS echo request packet.
When an MPLS echo request packet is generated in CPM and is forwarded to the outgoing interface, the packet is queued in the egress network queue corresponding to the specified FC and profile parameter values. The marking of the packet's EXP is dictated by the LSP-EXP mappings on the outgoing interface.
When the MPLS echo request packet is received on the responding node, the fc and profile parameter values are dictated by the LSP-EXP mappings of the incoming interface.
When an MPLS echo reply packet is generated in CPM and is forwarded to the outgoing interface, the packet is queued in an egress network queue. The egress network queue is selected according to the fc and profile parameter values determined by the classification of the echo request packet that is being replied to at the incoming interface. The marking of the packet's EXP is dictated by the LSP-EXP mappings on the outgoing interface. The ToS byte is not modified. p2mp-lsp-trace Request Packet and Behavior summarizes this behavior.
Table 2. p2mp-lsp-trace Request Packet and Behavior Request Packet
Behavior
CPM (sender node)
Echo request packet:
-
packet {tos=1, fc1, profile1}
-
fc1 and profile1 are as entered by user in OAM command or default values
-
tos1 as per mapping of {fc1, profile1} to IP precedence in network egress QoS policy of outgoing interface
Outgoing interface (sender node)
Echo request packet:
-
packet queued as {fc1, profile1}
-
ToS field=tos1 not remarked
-
EXP=exp1, as per mapping of {fc1, profile1} to EXP in network egress QoS policy of outgoing interface
Incoming interface (responder node)
Echo request packet:
-
packet {tos1, exp1}
-
exp1 mapped to {fc2, profile2} as per classification in network QoS policy of incoming interface
CPM (responder node)
Echo reply packet:
-
packet {tos=1, fc2, profile2}
Outgoing interface (responder node)
Echo reply packet:
-
packet queued as {fc2, profile2}
-
ToS filed= tos1 not remarked (reply inband or out-of-band)
-
EXP=exp2, if reply is inband, remarked as per mapping of {fc2, profile2} to EXP in network egress QoS policy of outgoing interface
Incoming interface (sender node)
Echo reply packet:
-
packet{tos1, exp2}
-
exp2 mapped to {fc1, profile1} as per classification in network QoS policy of incoming interface
-
- profile {in | out}
-
Specifies the profile of the LSP trace echo request message.
- octets
-
Specifies the size in octets, expressed as a decimal integer, of the MPLS echo request packet, including the IP header but not the label stack. The request payload is padded with zeros to the specified size. Note that an OAM command is not failed if the user enters a size lower than the minimum required to build the packet for the echo request message. The payload is automatically padded to meet the minimum size.
- no-response-count
-
Specifies the maximum number of consecutive MPLS echo requests, expressed as a decimal integer that do not receive a reply before the trace operation fails for a given TTL.
- probes-per-hop
-
Specifies the number of LSP trace echo request messages to send per TTL value.
- min-label-ttl
-
Specifies the minimum TTL value in the MPLS label for the LSP trace test, expressed as a decimal integer.
- max-label-ttl
-
Specifies the maximum TTL value in the MPLS label for the LSP trace test, expressed as a decimal integer.
- timeout
-
Specifies the time, in seconds, used to override the default timeout value and is the amount of time that the router waits for an echo reply message from all leaves of the P2MP LSP after sending the message request message. Upon the expiration of the message time out, the requesting router no longer waits for reply messages. Any echo reply message received after the request times out is silently discarded.
- interval
-
Specifies the time, in seconds, used to override the default echo request message send interval and defines the minimum amount of time that must expire before the next echo request message is sent.
If the interval is set to 1 second, and the timeout value is set to 10 seconds, then the maximum time between message requests is 10 seconds and the minimum is 1 second. This depends upon the receipt of an echo reply message corresponding to the outstanding message request.
Platforms
All
Output
The following output is an example of p2mp-lsp-trace information.
Output Example*A:Dut-C# oam p2mp-lsp-trace "p2mp_1" p2mp-instance "1" s2l-dest-address 10.20.1.
10.20.1.4 10.20.1.5 10.20.1.6
*A:Dut-C# oam p2mp-lsp-trace "p2mp_1" p2mp-instance "1" s2l-dest-
address 10.20.1.5 detail
P2MP LSP p2mp_1: 132 bytes MPLS payload
P2MP Instance 1, S2L Egress 10.20.1.5
1 10.20.1.1 rtt=3.78 ms rc=8(DSRtrMatchLabel)
DS 1: ipaddr 10.20.1.2 iftype 'ipv4Unnumbered' ifaddr 2 MRU=1500 label=131060
proto=4(RSVP-TE) B/E flags:0/0
2 10.20.1.2 rtt=3.54 ms rc=8(DSRtrMatchLabel)
DS 1: ipaddr 10.20.1.4 iftype 'ipv4Unnumbered' ifaddr 3 MRU=1500 label=131061
proto=4(RSVP-TE) B/E flags:0/0
3 10.20.1.5 rtt=5.30 ms rc=5(DSMappingMismatched)
Probe returned multiple responses. Result may be inconsistent.
*A:Dut-C#
p2mp-merge-point-abort-timer
p2mp-merge-point-abort-timer
Syntax
p2mp-merge-point-abort-timer seconds
no p2mp-merge-point-abort-timer
Context
[Tree] (config>router>rsvp p2mp-merge-point-abort-timer)
Full Context
configure router rsvp p2mp-merge-point-abort-timer
Description
This command configures a timer to abort Merge-Point (MP) node procedures for an S2L of a P2MP LSP instance. When a value higher than zero is configured for this timer, it enters into effect anytime this node activates Merge-Point procedures for one or more P2MP LSP S2L paths. As soon an ingress interface goes operationally down, the Merge-Point node starts the abort timer. Upon expiry of the timer, MPLS cleans up all P2MP LSP S2L paths which ILM is on the failed interface and which have not already received a Path refresh over the bypass LSP.
The no form of this command disables the timer.
Default
no p2mp-merge-point-abort-timer
Parameters
- seconds
-
Specifies the length of the abort timer in seconds
Platforms
All
p2mp-policy
p2mp-policy
Syntax
[no] p2mp-policy policy-name
Context
[Tree] (config>router>p2mp-sr-tree p2mp-policy)
Full Context
configure router p2mp-sr-tree p2mp-policy
Description
This command creates a P2MP policy entry for the P2MP SR tree.
The no form of this command deletes the specified policy entry.
Parameters
- policy-name
-
Specifies the policy name, up to 32 characters.
Platforms
All
p2mp-policy-mpls
p2mp-policy-mpls
Syntax
[no] p2mp-policy-mpls
Context
[Tree] (config>service>vprn>mvpn>pt>inclusive>p2mp-sr p2mp-policy-mpls)
[Tree] (config>service>vprn>mvpn>pt>selective>p2mp-sr p2mp-policy-mpls)
[Tree] (config>service>vprn>mvpn>pt>selective>multistream-spmsi p2mp-policy-mpls)
Full Context
configure service vprn mvpn provider-tunnel inclusive p2mp-sr p2mp-policy-mpls
configure service vprn mvpn provider-tunnel selective p2mp-sr p2mp-policy-mpls
configure service vprn mvpn provider-tunnel selective multistream-spmsi p2mp-policy-mpls
Description
This command enables a P2MP policy for the MVPN provider tunnel.
The no form of this command disables the P2MP policy.
Platforms
All
p2mp-resignal-timer
p2mp-resignal-timer
Syntax
p2mp-resignal-timer minutes
no p2mp-resignal-timer
Context
[Tree] (config>router>mpls p2mp-resignal-timer)
Full Context
configure router mpls p2mp-resignal-timer
Description
This command configures the re-signal timer for a P2MP LSP instance. MPLS requests CSPF to re-compute the whole set of S2L paths of a given active P2MP instance each time the P2MP re-signal timer expires. The P2MP re-signal timer is configured separately from the P2P LSP parameter. MPLS performs a global MBB and moves each S2L sub-LSP in the instance into its new path using a new P2MP LSP ID if the global MBB is successful, regardless of the cost of the new S2L path.
This command is supported on the 7750 SR, 7950 XRS, and with VPLS only on the 7450 ESS.
The no form of this command disables the timer-based re-signaling of P2MP LSPs on this system.
Parameters
- minutes
-
Specifies the time MPLS waits before attempting to re-signal the P2MP LSP instance.
Platforms
All
p2mp-s2l-fast-retry
p2mp-s2l-fast-retry
Syntax
p2mp-s2-fast-retry seconds
no p2mp-s2l-fast-retry
Context
[Tree] (config>router>mpls p2mp-s2l-fast-retry)
[Tree] (config>router>rsvp p2mp-s2l-fast-retry)
Full Context
configure router mpls p2mp-s2l-fast-retry
configure router rsvp p2mp-s2l-fast-retry
Description
This command configures a global parameter to allow the user to apply a shorter retry timer for the first try after an active LSP path went down due to a local failure or the receipt of a ResvTear. This timer is used only in the first try. Subsequent retries will continue to be governed by the existing LSP level retry-timer.
The config>router>mpls>p2mp-s2l-fast-retry command is supported on the 7750 SR, 7950 XRS, and with VPLS only on the 7450 ESS.
The no form of this command disables the timer.
Default
no p2mp-s2l-fast-retry
Parameters
- seconds
-
Specifies the length of time for retry timer, in seconds
Platforms
All
p2mp-sr
p2mp-sr
Syntax
[no] p2mp-sr
Context
[Tree] (config>service>vprn>mvpn>pt>inclusive p2mp-sr)
[Tree] (config>service>vprn>mvpn>pt>selective p2mp-sr)
Full Context
configure service vprn mvpn provider-tunnel inclusive p2mp-sr
configure service vprn mvpn provider-tunnel selective p2mp-sr
Description
This command enables P2MP SR for the MVPN provider tunnel.
The no form of this command disables P2MP SR.
Default
no p2mp-sr
Platforms
All
p2mp-sr-tree
p2mp-sr-tree
Syntax
[no] p2mp-sr-tree
Context
[Tree] (config>router p2mp-sr-tree)
Full Context
configure router p2mp-sr-tree
Description
Commands in this context configure P2MP SR parameters.
Default
no p2mp-sr-tree
Platforms
All
p2mp-template-lsp
p2mp-template-lsp
Syntax
[no] p2mp-template-lsp rsvp-session-name SessionNameString sender sender-address
Context
[Tree] (config>router>mpls>ingress-stats p2mp-template-lsp)
Full Context
configure router mpls ingress-statistics p2mp-template-lsp
Description
This command configures an ingress statistics context matching on the RSVP session name for a RSVP P2MP LSP at the egress LER.
This command is supported on the 7750 SR, 7950 XRS, and with VPLS only on the 7450 ESS.
When the ingress LER signals the path of the S2L sub-LSP, it includes the name of the LSP and that of the path in the Session Name field of the Session Attribute object in the Path message. The encoding is as follows:
Session Name: <lsp-name::path-name>, where lsp-name component is encoded as follows:
-
P2MP LSP through the user configuration for L3 multicast in global routing instance: "LspNameFromConfig”
-
P2MP LSP as I-PMSI or S-PMSI in L3 mVPN: templateName-SvcId-mTTmIndex
-
P2MP LSP as I-PMSI in VPLS/B-VPLS: templateName-SvcId-mTTmIndex
The ingress statistics CLI configuration allows the user to match either on the exact name of the P2MP LSP as configured at the ingress LER or on a context that matches on the template name and the service-id as configured at the ingress LER.
When the matching is performed on a context, the user must enter the RSVP session name string in the format "templateName-svcId” to include the LSP template name as well as the mVPN VPLS/B-VPLS service ID as configured at the ingress LER. In this case, one or more P2MP LSP instances signaled by the same ingress LER could be associated with the ingress statistics configuration and the user is provided with CLI parameter max-stats to limit the maximum number of stat indexes that can be assigned to this context. If the context matches more than this value, the additional request for stat indices from this context is rejected. A background tasks monitors the ingress statistics templates which have one or more matching LSP instances with unassigned stat index and assigns one to them as they are freed.
Note the following rules when configuring an ingress statistics context based on template matching:
-
max-stats, after allocated, can be increased but not decreased unless the entire ingress statistics context matching a template name is deleted.
-
To delete ingress statistics context matching a template name, a shutdown is required.
-
An accounting policy cannot be configured or de-configured until the ingress statistics context matching a template name is shut down.
-
After deleting an accounting policy from an ingress statistics context matching a template name, the policy is not removed from the log until a "no shut” is performed on the ingress statistics context.
If there are no stat indexes available at the time the session of the P2MP LSP matching a template context is signaled and the session state installed by the egress LER, no stats are allocated to the session.
Furthermore, the assignment of stat indexes to the LSP names that match the context will also be not deterministic. The latter is due to the fact that a stat index is assigned and released following the dynamics of the LSP creation or deletion by the ingress LER. For example, a multicast stream crosses the rate threshold and is moved to a newly signaled S-PMSI dedicated to this stream. Later on, the same steam crosses the threshold downwards and is moved back to the shared I-PMSI and the P2MP LSP corresponding to the S-PMSI is deleted by the ingress LER.
The no form deletes the ingress statistics context matching on the RSVP session name.
Parameters
- rsvp-session-name SessionNameString
-
Specifies the name of the RSVP P2MP session in the format of "templateName-svcId”. This field can hold up to 64 characters.
- sender sender-address
-
Specifies a string of 15 characters representing the IP address of the ingress LER for the LSP.
Platforms
All
p2mp-ttl-propagate
p2mp-ttl-propagate
Syntax
[no] p2mp-ttl-propagate
Context
[Tree] (config>router>mpls p2mp-ttl-propagate)
Full Context
configure router mpls p2mp-ttl-propagate
Description
This command configures the uniform mode of operation for RSVP P2MP LSPs.
The no form of this command configures the pipe mode of operation for P2MP LSPs.
When the mode of operation is modified, the new configuration applies to future P2MP LSPs only and the existing operational LSPs are not affected.
Default
p2mp-ttl-propagate
Platforms
All
p2p-active-path-fast-retry
p2p-active-path-fast-retry
Syntax
p2p-active-path-fast-retry seconds
no p2p-active-path-fast-retry
Context
[Tree] (config>router>mpls p2p-active-path-fast-retry)
Full Context
configure router mpls p2p-active-path-fast-retry
Description
This command configures a global parameter to allow the user to apply a shorter retry timer for the first try after an active LSP path went down due to a local failure or the receipt of a ResvTear. This timer is used only in the first try. Subsequent retries will continue to be governed by the existing LSP level retry-timer.
The no form of this command disables the timer.
Default
no p2p-active-path-fast-retry
Parameters
- seconds
-
Specifies the length of time for retry timer, in seconds
Platforms
All
p2p-merge-point-abort-timer
p2p-merge-point-abort-timer
Syntax
p2p-merge-point-abort-timer seconds
no p2p-merge-point-abort-timer
Context
[Tree] (config>router>rsvp p2p-merge-point-abort-timer)
Full Context
configure router rsvp p2p-merge-point-abort-timer
Description
This command configures a timer to abort Merge-Point (MP) node procedures for a P2P LSP path. When a value higher than zero is configured for this timer, it will enter into effect anytime this node activates Merge-Point procedures for one or more P2P LSP paths. As soon an ingress interface goes operationally down, the Merge-Point node starts the abort timer. Upon expiry of the timer, MPLS will clean up all P2P LSP paths which ILM is on the failed interface and which have not already received a Path refresh over the bypass LSP.
The no form of this command disables the timer.
Default
no p2p-merge-point-abort-timer
Parameters
- seconds
-
Specifies the length of the abort timer in seconds
Platforms
All
p2p-template-lsp
p2p-template-lsp
Syntax
[no] p2p-template-lsp rsvp-session-name SessionNameString sender sender-address
Context
[Tree] (config>router>mpls>ingress-stats p2p-template-lsp)
Full Context
configure router mpls ingress-statistics p2p-template-lsp
Description
This command configures an ingress statistics context matching on the RSVP session name for a RSVP P2P auto-LSP at the egress LER.
When the ingress LER signals the path of a template based one-hop-p2p or mesh-p2p auto-lsp, it includes the name of the LSP and that of the path in the Session Name field of the Session Attribute object in the Path message. The encoding is as follows:
Session Name: lsp-name::path-name, where lsp-name component is encoded as follows:
P2MP LSP through the user configuration for Layer 3 multicast in global routing instance: "LspNameFromConfig”
-
P2MP LSP as I-PMSI or S-PMSI in L3 mVPN: templateName-SvcId-mTTmIndex
-
P2MP LSP as I-PMSI in VPLS/B-VPLS: templateName-SvcId-mTTmIndex.
The ingress statistics CLI configuration allows the user to match either on the exact name of the P2P auto-LSP or on a context that matches on the template name and the destination of the LSP at the ingress LER.
When the matching is performed on a context, the user must enter the RSVP session name string in the format "templateName-svcId” to include the LSP template name as well as the mVPN VPLS/B-VPLS service ID as configured at the ingress LER. In this case, one or more P2MP LSP instances signaled by the same ingress LER could be associated with the ingress statistics configuration. The user is provided with CLI parameter max-stats to limit the maximum number of stat indices which can be assigned to this context. If the context matches more than this value, the additional request for stat indices from this context is rejected.
Note the following rules when configuring an ingress statistics context based on template matching:
-
max-stats, once allocated, can be increased but not decreased unless the entire ingress statistics context matching a template name is deleted.
-
To delete ingress statistics context matching a template name, a shutdown is required.
-
An accounting policy cannot be configured or de-configured until the ingress statistics context matching a template name is shut down.
-
After deleting an accounting policy from an ingress statistics context matching a template name, the policy is not removed from the log until a no shut is performed on the ingress statistics context.
If there are no stat indexes available at the time the session of the P2P LSP matching a template context is signaled and the session state installed by the egress LER, no stats are allocated to the session.
Furthermore, the assignment of stat indexes to the LSP names that match the context is not deterministic. The latter is because a stat index is assigned and released following the dynamics of the LSP creation or deletion by the ingress LER. For example, a multicast stream crosses the rate threshold and is moved to a newly signaled S-PMSI dedicated to this stream. Later on, the same steam crosses the threshold downwards and is moved back to the shared I-PMSI and the P2MP LSP corresponding to the S-PMSI is deleted by the ingress LER.
The no form deletes the ingress statistics context matching on the RSVP session name.
Parameters
- rsvp-session-name SessionNameString
-
Specifies the name of the RSVP P2MP session in the format of "templateName-svcId”. This field can hold up to 64 characters.
- sender sender-address
-
Specifies a string of 15 characters representing the IP address of the ingress LER for the LSP.
Platforms
All
packet
packet
Syntax
packet detail-level {high | low}
packet mode {all | dropped}
no packet
Context
[Tree] (debug>gtp packet)
Full Context
debug gtp packet
Description
This command enables debugging of GTP packets sent or received by the system’s control plane.
The no form of this command disables debugging of GTP packets.
Parameters
- detail-level {high | low}
-
Specifies how much detail is to be displayed when debugging a GTP packet.
- mode {all | dropped}
-
Specifies which packets is debugged.
Platforms
7750 SR, 7750 SR-e, 7750 SR-s, VSR
packet
Syntax
[no] packet
Context
[Tree] (debug>router>l2tp packet)
[Tree] (debug>router>l2tp>group packet)
[Tree] (debug>router>l2tp>peer packet)
[Tree] (debug>router>l2tp>assignment-id packet)
Full Context
debug router l2tp packet
debug router l2tp group packet
debug router l2tp peer packet
debug router l2tp assignment-id packet
Description
This command enables packet debugging.
The no form of this command disables packet debugging.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
packet
Syntax
[no] packet
Context
[Tree] (debug>service>id>ppp packet)
Full Context
debug service id ppp packet
Description
This command enables debugging for specific PPPoE packets.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
packet
packet
Syntax
packet jitter-buffer milliseconds [payload-size bytes]
packet payload-size bytes
no packet
Context
[Tree] (config>service>cpipe>sap>cem packet)
[Tree] (config>service>epipe>sap>cem packet)
Full Context
configure service cpipe sap cem packet
configure service epipe sap cem packet
Description
This command specifies the jitter buffer size, in milliseconds, and payload size, in bytes.
Default
The default value depends on the CEM SAP endpoint type, and if applicable, the number of timeslots as shown in Packet CEM SAP Endpoint Types.
Endpoint Type |
Timeslots |
Default Jitter Buffer (in ms) |
---|---|---|
unstructuredE1 |
— |
5 |
unstructuredT1 |
— |
5 |
nxDS0 (E1/T1) |
— |
32 |
N = 1 |
16 |
|
N = 2 to 4 |
8 |
|
N = 5 to 15 |
5 |
|
nxDS0WithCas (E1) |
N |
8 |
nxDS0WithCas (T1) |
N |
12 |
Parameters
- milliseconds
-
Specifies the jitter buffer size in milliseconds (ms).
Configuring the payload size and jitter buffer to values that result in less than 2 packet buffers or greater than 32 packet buffers is not allowed. Setting the jitter butter value to 0 sets it back to the default value.
- payload-size bytes
-
Specifies the payload size (in bytes) of packets transmitted to the packet service network (PSN) by the CEM SAP. This determines the size of the data that will be transmitted over the service. If the size of the data received is not consistent with the payload size then the packet is considered malformed.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
- configure service cpipe sap cem packet
7450 ESS, 7750 SR-7/12/12e, 7750 SR-a, 7750 SR-e
- configure service epipe sap cem packet
packet
Syntax
packet [hello | jp]
packet [hello | jp] evpn-mpls
packet [hello | jp] [ sap sap-id]
packet [hello | jp] [ sdp sdp-id:vc-id]
packet [hello | jp] vxlan vtep ip-address vni vni-id
no packet
Context
[Tree] (debug>service>id>pim-snooping packet)
Full Context
debug service id pim-snooping packet
Description
This command enables or disables debugging for PIM packets.
Parameters
- hello | jp
-
PIM packet types
- sap-id
-
Debugs packets associated with the specified SAP
- sdp-id:vc-id
-
Debugs packets associated with the specified SDP
- evpn-mpls
-
Debugs PIM snooping statistics for EVPN-MPLS destinations
Platforms
All
packet
Syntax
packet [query | v1-report | v2-report | v3-report | v2-leave] [ip-int-name | ip-address] [ mode {dropped-only | ingr-and-dropped | egr-ingr-and-dropped}]
packet [query | v1-report | v2-report | v3-report | v2-leave] [mode { dropped-only | ingr-and-dropped | egr-ingr-and-dropped}] group-interface ip-int-name
packet [query | v1-report | v2-report | v3-report | v2-leave] host ip-address [mode {dropped-only | ingr-and-dropped | egr-ingr-and-dropped}]
no packet [query | v1-report | v2-report | v3-report | v2-leave] [ip-int-name | ip-address]
no packet [query | v1-report | v2-report | v3-report | v2-leave] group-interface ip-int-name
no packet [query | v1-report | v2-report | v3-report | v2-leave] host ip-address
Context
[Tree] (debug>router>igmp packet)
Full Context
debug router igmp packet
Description
This command enables/disables debugging for IGMP packets.
Parameters
- query
-
Specifies to log the IGMP group- and source-specific queries transmitted and received on this interface.
- v1-report
-
Specifies to debug IGMP V1 reports transmitted and received on this interface.
- v2-report
-
Specifies to debug IGMP V2 reports transmitted and received on this interface.
- v3-report
-
Specifies to debug IGMP V3 reports transmitted and received on this interface.
- v2-leave
-
Specifies to debug the IGMP Leaves transmitted and received on this interface.
- ip-int-name
-
Debugs the information associated with the specified IP interface name.
- ip-address
-
Debugs the information associated with the specified IP address.
Platforms
All
packet
Syntax
packet [detail]
no packet
Context
[Tree] (debug>router>ldp>if packet)
[Tree] (debug>router>ldp>peer packet)
Full Context
debug router ldp interface packet
debug router ldp peer packet
Description
This command enables debugging for specific LDP packets.
The no form of the command disables the debugging output.
Parameters
- detail
-
Displays detailed information.
Platforms
All
packet
Syntax
[no] packet
Context
[Tree] (debug>router>rsvp packet)
Full Context
debug router rsvp packet
Description
Commands in this context debug packets.
Platforms
All
packet
Syntax
packet [pkt-type] [peer ip-address]
no packet
Context
[Tree] (debug>router>msdp packet)
Full Context
debug router msdp packet
Description
This command enables debugging for MSDP packets.
The no form of this command disables MSDP packet debugging.
Parameters
- pkt-type
-
Debugs information associated with the specified packet type.
- ip-address
-
Debugs information associated with the specified peer IP address.
Platforms
All
packet
Syntax
packet [hello | register | register-stop | jp | bsr | assert | crp | mdt-tlv | auto-rp-announcement | auto-rp-mapping | graft | graft-ack] [ip-int-name | mt-int-name | int-ip-address | mpls-if-name] [family {ipv4 | ipv6}] [ send | receive]
no packet
Context
[Tree] (debug>router>pim packet)
Full Context
debug router pim packet
Description
This command enables debugging for PIM packets.
The no form of this command disables debugging for PIM packets.
Parameters
- hello | register | register-stop | jp | bsr | assert | crp | mdt-tlv | auto-rp-announcement | auto-rp-mapping | graft | graft-ack
-
Specifies PIM packet types.
- ip-int-name
-
Debugs the information associated with the specified IP interface name, up to 32 characters.
- mt-int-name
-
Debugs the information associated with the specified VPRN ID and group address.
- int-ip-address
-
Debugs the information associated with the specified IP address.
- ipv4
-
Specifies to display IPv4 packets.
- ipv6
-
Specifies to display IPv6 packets.
- mpls-if-name
-
Debugs the information associated with the specified MPLS interface.
- receive
-
Specifies to display received packets.
- send
-
Specifies to display sent packets.
- family
-
Debugs database packet information.
Platforms
All
packet
Syntax
packet jitter-buffer milliseconds [payload-size bytes]
packet payload-size bytes
no packet
Context
[Tree] (config>mirror>mirror-dest>sap>cem packet)
Full Context
configure mirror mirror-dest sap cem packet
Description
This command specifies the jitter buffer size, in milliseconds, and payload size, in bytes.
Default
The default value depends on the CEM SAP endpoint type, and if applicable, the number of timeslots.
Endpoint Type |
Timeslots |
Default Jitter Buffer (in ms) |
---|---|---|
unstructuredE1 |
n/a |
5 |
unstructuredT1 |
n/a |
5 |
unstructuredE3 |
n/a |
5 |
unstructuredT3 |
n/a |
5 |
nxDS0 (E1/T1) |
N = 1 |
32 |
N = 2 to 4 |
16 |
|
N = 5 to 15 |
8 |
|
N >= 16 |
5 |
|
nxDS0WithCas (E1) |
N |
8 |
nxDS0WithCas (T1) |
N |
12 |
Parameters
- milliseconds
-
Specifies the jitter buffer size in milliseconds (ms).
Configuring the payload size and jitter buffer to values that result in less than 2 packet buffers or greater than 32 packet buffers is not allowed.
Setting the jitter butter value to 0 sets it back to the default value.
- bytes
-
Specifies the payload size (in bytes) of packets transmitted to the packet service network (PSN) by the CEM SAP. This determines the size of the data that will be transmitted over the service. If the size of the data received is not consistent with the payload size then the packet is considered malformed.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
packet
Syntax
packet packet-number [create]
no packet packet-number
Context
[Tree] (debug>oam>build-packet packet)
Full Context
debug oam build-packet packet
Description
This command configures a packet to be launched by the OAM find-egress tool.
The no form of this command removes the packet number value.
Parameters
- packet-number
-
Specifies a packet to be launched by the OAM find-egress tool.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
packet
Syntax
packet all
packet cfm-opcode opcode [opcode]
no packet
Context
[Tree] (debug>eth-cfm>mep packet)
[Tree] (debug>eth-cfm>mip packet)
Full Context
debug eth-cfm mep packet
debug eth-cfm mip packet
Description
This command defines the ETH-CFM opcodes of interest to be debugged.
The no form of this command stops packet debugging and the collection of PDUs.
Parameters
- all
-
Specifies that debugging is enabled for all ETH-CFM packets.
- opcode
-
Specifies a standard numerical reference or common three-letter acronym (TLA) that identifies the CFM PDU type. Up to five opcodes can be specified, and a combination of both numbers and TLAs can be used.
MEPs support all opcodes.
MIPs support 2 (LBR), 3 (LBM), 4 (LTR), and 5 (LTM).
Unknown or unsupported opcodes in TLA form are rejected. The applicable numerical opcode can be used instead. When numerical references are used, they are converted to a known TLA or left in numerical form if the TLA is unknown.
Re-entering the packet command overwrites the previous opcode entries for the MEP or MIP.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
packet
Syntax
packet [{ip-int-name | ip-address}] [headers] [ protocol-id]
no packet [{ip-int-name | ip-address}]
Context
[Tree] (debug>router>ip packet)
Full Context
debug router ip packet
Description
This command enables debugging for IP packets.
Parameters
- ip-int-name
-
Only displays the interface information associated with the specified IP interface name.
- ip-address
-
Only displays the interface information associated with the specified IP address.
- headers
-
Only displays information associated with the packet header.
- protocol-id
-
Specifies the decimal value representing the IP protocol to debug. Well-known protocol numbers include ICMP(1), TCP(6), UDP(17). The no form the command removes the protocol from the criteria.
Platforms
All
packet
Syntax
[no] packet
Context
[Tree] (debug>router>pcp>pcp-server packet)
Full Context
debug router pcp pcp-server packet
Description
This command enables packet debugging.
The no form of this command disables packet debugging.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
packet
Syntax
[no] packet [{query | request | response}]
Context
[Tree] (debug>router>mtrace packet)
Full Context
debug router mtrace packet
Description
This command enables debugging for mtrace packets.
Platforms
All
packet
Syntax
[no] packet [{query | request | reply}]
Context
[Tree] (debug>router>mtrace2 packet)
Full Context
debug router mtrace2 packet
Description
This command enables debugging for mtrace2 packets.
Platforms
All
packet
Syntax
[no] packet
Context
[Tree] (debug>router>rpki-session packet)
Full Context
debug router rpki-session packet
Description
This command enables debugging for specific RPKI packets.
The no form of this command disables debugging for specific RPKI packets.
Platforms
All
packet
Syntax
packet [packet-type] [ip-int-name | ip-address] [ detail]
Context
[Tree] (debug>router>isis packet)
Full Context
debug router isis packet
Description
This command enables debugging for IS-IS packets.
The no form of the command disables debugging.
Parameters
- ip-address
-
When specified, only packets with the specified interface address are debugged.
- ip-int-name
-
When specified, only packets with the specified interface name are debugged.
- packet-type
-
When specified, only packets of the specified type are debugged.
- detail
-
All output is displayed in the detailed format.
Platforms
All
packet
Syntax
packet [packet-type] [interface-name] [ingress | egress] [detail]
packet [packet-type] [interface-name] [ingress | egress | drop] [ detail]
no packet
Context
[Tree] (debug>router>ospf3 packet)
[Tree] (debug>router>ospf packet)
Full Context
debug router ospf3 packet
debug router ospf packet
Description
This command enables debugging for OSPF packets.
Parameters
- packet-type
-
Specifies the OSPF packet type to debug.
- interface-name
-
Specifies the interface to debug, up to 32 characters.
- ingress
-
Specifies to display ingress packets.
- egress
-
Specifies to display egress packets.
- drop
-
Specifies to display dropped packets.
Platforms
All
packet
Syntax
packet [high-detail] [dropped-only]
no packet
Context
[Tree] (debug>subscr-mgmt>pfcp packet)
Full Context
debug subscriber-mgmt pfcp packet
Description
This command debugs PFCP packets that are received or sent. The no form of this command disables any PFCP packet debugging.
Parameters
- high-detail
-
Specifies to provide a full packet dump; without this parameter only basic packet information is provided.
- dropped-only
-
Specifies to only debug dropped packets.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
packet
Syntax
packet packet-type [detail]
no packet packet-type
Context
[Tree] (debug>router>pcep>pcc packet)
[Tree] (debug>router>pcep>pcc>conn packet)
Full Context
debug router pcep pcc packet
debug router pcep pcc connection packet
Description
This command enables debugging for PCEP PCC or connection packets.
The no form of this command disables debugging.
Parameters
- packet-type
-
Specifies only packets of the specified type are debugged.
- detail
-
Keyword used to specify detailed output.
Platforms
All
packet
Syntax
packet packet-type [detail]
no packet packet-type
Context
[Tree] (debug>router>pcep>pce>conn packet)
[Tree] (debug>router>pcep>pce packet)
Full Context
debug router pcep pce connection packet
debug router pcep pce packet
Description
This command enables debugging for PCEP PCE or connection packets.
The no form of this command disables debugging.
Parameters
- packet-type
-
Specifies only packets of the specified type are debugged.
- detail
-
Keyword used to specify detailed output.
Platforms
VSR-NRC
packet-byte-offset
packet-byte-offset
Syntax
packet-byte-offset add bytes
packet-byte-offset subtract sub-bytes
no packet-byte-offset
Context
[Tree] (config>qos>sap-egress>dynamic-queue packet-byte-offset)
Full Context
configure qos sap-egress dynamic-queue packet-byte-offset
Description
This command configures the packet-byte offset the system uses to modify the size of the input packets handled by the queue, by adding or subtracting the specified number of bytes. This also applies to any charging statistics. The actual packet size is not modified, only the size used to determine the egress scheduling and profiling is changed.
Parameters
- add bytes
-
Specifies the packet byte offset. The add keyword is mutually exclusive to the subtract keyword. Either add or subtract must be specified. When add is defined the corresponding bytes parameter specifies the number of bytes that is added to the size each packet.
- subtract bytes
-
Specifies the packet byte offset. The subtract keyword is mutually exclusive to the add keyword. Either add or subtract must be specified. When defined, the corresponding bytes parameter specifies the number of bytes that is subtracted from the size of each packet.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
packet-byte-offset
Syntax
packet-byte-offset{add bytes | subtract bytes}
no packet-byte-offset
Context
[Tree] (config>subscr-mgmt>sla-prof>ingress>qos>policer packet-byte-offset)
[Tree] (config>subscr-mgmt>sla-prof>egress>qos>policer packet-byte-offset)
Full Context
configure subscriber-mgmt sla-profile ingress qos policer packet-byte-offset
configure subscriber-mgmt sla-profile egress qos policer packet-byte-offset
Description
This command is used to modify the size of each packet handled by the policer by adding or subtracting a number of bytes. The actual packet size is not modified; only the size used to determine the bucket depth impact is changed. The packet-byte-offset command is meant to be an arbitrary mechanism the can be used to either add downstream frame encapsulation or remove portions of packet headers. Both the policing metering and profiling throughput is affected by the offset as well as the stats associated with the policer.
When child policers are adding to or subtracting from the size of each packet, the parent policer’s min-thresh-separation value should also need to be modified by the same amount.
The policer’s packet-byte-offset defined in the QoS policy may be overridden on an sla-profile or SAP where the policy is applied. Packet byte offset settings are not included in the applied rate when (queue) frame based accounting is configured and the policer is managed by HQoS, however the offsets are applied to the statistics.
The no form of this command removes the per packet size modifications from the policer.
Parameters
- add bytes
-
Specifies the packet byte offset. The add keyword is mutually exclusive to the subtract keyword. Either add or subtract must be specified. When add is defined the corresponding bytes parameter specifies the number of bytes that is added to the size each packet associated with the policer for rate metering, profiling and accounting purposes. From the policer’s perspective, the maximum packet size is increased by the amount being added to the size of each packet.
- subtract bytes
-
Specifies the packet byte offset. The subtract keyword is mutually exclusive to the add keyword. Either add or subtract must be specified. When b is defined the corresponding bytes parameter specifies the number of bytes that is subtracted from the size of each packet associated with the policer for rate metering, profiling and accounting purposes. From the policer’s perspective, the maximum packet size is reduced by the amount being subtracted from the size of each packet.
Note:The minimum resulting packet size used by the system is 1 byte.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
packet-byte-offset
Syntax
packet-byte-offset {add add-bytes | subtract sub-bytes}
no packet-byte-offset
Context
[Tree] (config>card>fp>ingress>network>qgrp>policer-over>plcr packet-byte-offset)
[Tree] (config>card>fp>ingress>access>qgrp>policer-over>plcr packet-byte-offset)
Full Context
configure card fp ingress network queue-group policer-override policer packet-byte-offset
configure card fp ingress access queue-group policer-override policer packet-byte-offset
Description
This command modifies the size of each packet handled by the policer by adding or subtracting a number of bytes. The actual packet size is not modified; only the size used to determine the bucket depth impact is changed. The packet-byte-offset command is meant to be an arbitrary mechanism the can be used to either add downstream frame encapsulation or remove portions of packet headers. Both the policing metering and profiling throughput is affected by the offset as well as the stats associated with the policer.
When child policers are adding to or subtracting from the size of each packet, the parent policer’s min-thresh-separation value should also need to be modified by the same amount.
The policer’s packet-byte-offset defined in the QoS policy may be overridden on an sla-profile or SAP where the policy is applied.
The no form of this command removes per packet size modifications from the policer.
Parameters
- add-bytes
-
The add keyword is mutually exclusive to the subtract keyword. Either add or subtract must be specified. When add is defined the corresponding bytes parameter specifies the number of bytes that is added to the size each packet associated with the policer for rate metering, profiling and accounting purposes. From the policer’s perspective, the maximum packet size is increased by the amount being added to the size of each packet.
- sub-bytes
-
The subtract keyword is mutually exclusive to the add keyword. Either add or subtract must be specified. When b is defined the corresponding bytes parameter specifies the number of bytes that is subtracted from the size of each packet associated with the policer for rate metering, profiling and accounting purposes. From the policer’s perspective, the maximum packet size is reduced by the amount being subtracted from the size of each packet. Note that the minimum resulting packet size used by the system is 1 byte.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
packet-byte-offset
Syntax
packet-byte-offset {add add-bytes | subtract sub-bytes}
no packet-byte-offset
Context
[Tree] (config>service>ipipe>sap>ingress>policer-over>plcr packet-byte-offset)
[Tree] (config>service>cpipe>sap>egress>policer-over>plcr packet-byte-offset)
[Tree] (config>service>ipipe>sap>egress>policer-over>plcr packet-byte-offset)
[Tree] (config>service>epipe>sap>ingress>policer-over>plcr packet-byte-offset)
[Tree] (config>service>cpipe>sap>ingress>policer-over>plcr packet-byte-offset)
[Tree] (config>service>epipe>sap>egress>policer-over>plcr packet-byte-offset)
Full Context
configure service ipipe sap ingress policer-override policer packet-byte-offset
configure service cpipe sap egress policer-override policer packet-byte-offset
configure service ipipe sap egress policer-override policer packet-byte-offset
configure service epipe sap ingress policer-override policer packet-byte-offset
configure service cpipe sap ingress policer-override policer packet-byte-offset
configure service epipe sap egress policer-override policer packet-byte-offset
Description
This command, within the SAP ingress and egress policer-overrides contexts, is used to override the sap-ingress and sap-egress QoS policy configured packet-byte-offset parameter for the specified policer-id. Packet byte offset settings are not included in the applied rate when (queue) frame based accounting is configured; however, the offsets are applied to the statistics.
The no packet-byte-offset command is used to restore the policer’s packet-byte-offset setting to the policy defined value.
Default
no packet-byte-offset
Parameters
- add-bytes
-
Specifies the number of bytes that are added to the size each packet associated with the policer for rate metering, profiling and accounting purposes. From the policer’s perspective, the maximum packet size is increased by the amount being added to the size of each packet.
- sub-bytes
-
Specifies the number of bytes that are subtracted from the size of each packet associated with the policer for rate metering, profiling and accounting purposes. From the policer’s perspective, the maximum packet size is reduced by the amount being subtracted from the size of each packet.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
- configure service epipe sap egress policer-override policer packet-byte-offset
- configure service epipe sap ingress policer-override policer packet-byte-offset
- configure service ipipe sap ingress policer-override policer packet-byte-offset
- configure service ipipe sap egress policer-override policer packet-byte-offset
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS
- configure service cpipe sap ingress policer-override policer packet-byte-offset
- configure service cpipe sap egress policer-override policer packet-byte-offset
packet-byte-offset
Syntax
packet-byte-offset {add add-bytes | subtract sub-bytes}
no packet-byte-offset
Context
[Tree] (config>service>vpls>sap>ingress>policer-override>plcr packet-byte-offset)
[Tree] (config>service>vpls>sap>egress>policer-override>plcr packet-byte-offset)
Full Context
configure service vpls sap ingress policer-override policer packet-byte-offset
configure service vpls sap egress policer-override policer packet-byte-offset
Description
This command, within the SAP ingress and egress policer-overrides contexts, is used to override the sap-ingress and sap-egress QoS policy configured packet-byte-offset parameter for the specified policer-id. Packet byte offset settings are not included in the applied rate when (queue) frame based accounting is configured, however the offsets are applied to the statistics.
The no form of this command restores the policer’s packet-byte-offset setting to the policy defined value.
Default
no packet-byte-offset
Parameters
- add-bytes
-
The add keyword is mutually exclusive to the subtract keyword. Either add or subtract must be specified. When add is defined the corresponding bytes parameter specifies the number of bytes that is added to the size each packet associated with the policer for rate metering, profiling and accounting purposes. From the policer’s perspective, the maximum packet size is increased by the amount being added to the size of each packet.
- sub-bytes
-
The subtract keyword is mutually exclusive to the add keyword. Either add or subtract must be specified. When subtract is defined the corresponding bytes parameter specifies the number of bytes that is subtracted from the size of each packet associated with the policer for rate metering, profiling and accounting purposes. From the policer’s perspective, the maximum packet size is reduced by the amount being subtracted from the size of each packet.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
packet-byte-offset
Syntax
packet-byte-offset {add add-bytes | subtract sub-bytes}
no packet-byte-offset
Context
[Tree] (config>service>ies>if>sap>egress>policer-override>plcr packet-byte-offset)
[Tree] (config>service>ies>if>sap>ingress>policer-override>plcr packet-byte-offset)
Full Context
configure service ies interface sap egress policer-override policer packet-byte-offset
configure service ies interface sap ingress policer-override policer packet-byte-offset
Description
This command, within the SAP ingress and egress policer-overrides contexts, is used to override the sap-ingress and sap-egress QoS policy configured packet-byte-offset parameter for the specified policer-id. Packet byte offset settings are not included in the applied rate when (queue) frame based accounting is configured, however the offsets are applied to the statistics.
The no form of this command restores the policer’s packet-byte-offset setting to the policy defined value.
Default
no packet-byte-offset
Parameters
- add add-bytes
-
The add keyword is mutually exclusive to the subtract keyword. Either add or subtract must be specified. When add is defined, the corresponding bytes parameter specifies the number of bytes that is added to the size each packet associated with the policer for rate metering, profiling and accounting purposes. From the policer’s perspective, the maximum packet size is increased by the amount being added to the size of each packet.
- subtract sub-bytes
-
The subtract keyword is mutually exclusive to the add keyword. Either add or subtract must be specified. When subtract is defined, the corresponding bytes parameter specifies the number of bytes that is subtracted from the size of each packet associated with the policer for rate metering, profiling and accounting purposes. From the policer’s perspective, the maximum packet size is reduced by the amount being subtracted from the size of each packet.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
packet-byte-offset
Syntax
packet-byte-offset add add-bytes
packet-byte-offset subtract sub-bytes
no packet-byte-offset
Context
[Tree] (config>service>vprn>if>sap>ingress>policer-override>plcr packet-byte-offset)
[Tree] (config>service>vprn>if>sap>egress>policer-override>plcr packet-byte-offset)
Full Context
configure service vprn interface sap ingress policer-override policer packet-byte-offset
configure service vprn interface sap egress policer-override policer packet-byte-offset
Description
This command, within the SAP ingress and egress policer-overrides contexts, is used to override the sap-ingress and sap-egress QoS policy configured packet-byte-offset parameter for the specified policer-id. Packet byte offset settings are not included in the applied rate when (queue) frame based accounting is configured, however the offsets are applied to the statistics.
The no form of this command restores the policer’s packet-byte-offset setting to the policy defined value.
Default
no packet-byte-offset
Parameters
- add add-bytes
-
The add keyword is mutually exclusive to the subtract keyword. Either add or subtract must be specified. When add is defined, the corresponding bytes parameter specifies the number of bytes that is added to the size each packet associated with the policer for rate metering, profiling and accounting purposes. From the policer’s perspective, the maximum packet size is increased by the amount being added to the size of each packet.
- subtract sub-bytes
-
The subtract keyword is mutually exclusive to the add keyword. Either add or subtract must be specified. When subtract is defined, the corresponding bytes parameter specifies the number of bytes that is subtracted from the size of each packet associated with the policer for rate metering, profiling and accounting purposes. From the policer’s perspective, the maximum packet size is reduced by the amount being subtracted from the size of each packet.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
packet-byte-offset
Syntax
packet-byte-offset {add add-bytes | subtract sub- bytes}
no packet-byte-offset
Context
[Tree] (config>qos>sap-ingress>dyn-policer packet-byte-offset)
[Tree] (config>qos>sap-egress>dyn-policer packet-byte-offset)
[Tree] (config>qos>sap-egress>policer packet-byte-offset)
[Tree] (config>qos>sap-ingress>policer packet-byte-offset)
Full Context
configure qos sap-ingress dynamic-policer packet-byte-offset
configure qos sap-egress dynamic-policer packet-byte-offset
configure qos sap-egress policer packet-byte-offset
configure qos sap-ingress policer packet-byte-offset
Description
This command is used to modify the size of each packet handled by the policer by adding or subtracting a number of bytes. The actual packet size is not modified; only the size used to determine the bucket depth impact is changed. The packet-byte-offset command is meant to be an arbitrary mechanism that can be used to either add downstream frame encapsulation or remove portions of packet headers. Both the policing metering and profiling throughput is affected by the offset as well as the stats associated with the policer.
When child policers are adding to or subtracting from the size of each packet, the parent policer’s min-thresh-separation value should also need to be modified by the same amount.
The policer’s packet-byte-offset defined in the QoS policy may be overridden on an sla-profile or SAP where the policy is applied. Packet byte offset settings are not included in the applied rate when (queue) frame-based accounting is configured and the policer is managed by HQoS; however, the offsets are applied to the statistics.
The no form of this command is used to remove per packet size modifications from the policer.
Parameters
- add add-bytes
-
The add keyword is mutually exclusive to the subtract keyword. Either add or subtract must be specified. When add is defined, the corresponding bytes parameter specifies the number of bytes that is added to the size of each packet associated with the policer for rate metering, profiling, and accounting purposes. From the policer’s perspective, the maximum packet size is increased by the amount being added to the size of each packet.
- subtract sub-bytes
-
The subtract keyword is mutually exclusive to the add keyword. Either add or subtract must be specified. When subtract is defined, the corresponding bytes parameter specifies the number of bytes that is subtracted from the size of each packet associated with the policer for rate metering, profiling, and accounting purposes. From the policer’s perspective, the maximum packet size is reduced by the amount being subtracted from the size of each packet. The minimum resulting packet size used by the system is 1 byte.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
- configure qos sap-egress dynamic-policer packet-byte-offset
- configure qos sap-ingress dynamic-policer packet-byte-offset
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
- configure qos sap-egress policer packet-byte-offset
- configure qos sap-ingress policer packet-byte-offset
packet-byte-offset
Syntax
packet-byte-offset {add add-bytes | subtract sub-bytes}
no packet-byte-offset
Context
[Tree] (config>qos>sap-ingress>queue packet-byte-offset)
Full Context
configure qos sap-ingress queue packet-byte-offset
Description
This command modifies the size of each packet handled by the queue by adding or subtracting the specified number of bytes. The actual packet size is not modified, only the size used to determine the ingress scheduling and profiling is changed. The packet-byte-offset command is an arbitrary mechanism that can be used to either add downstream frame encapsulation or remove portions of packet headers. Both the scheduling and profiling throughput is affected by the offset as well as the statistics (accounting) associated with the queue. The packet-byte-offset does not apply to drop statistics, received valid statistics, or the offered managed and unmanaged statistics used by Ingress Multicast Path Management.
The no form of this command removes per-packet size modifications from the queue.
Parameters
- add-bytes
-
Specifies the number of bytes added to the size of each packet associated with the queue for scheduling, profiling, and accounting purposes. From the queue’s perspective, the packet size is increased by the amount specified.
- sub-bytes
-
Specifies the number of bytes subtracted from the size of each packet associated with the queue for scheduling, profiling, and accounting purposes. From the queue’s perspective, the packet size is reduced by the amount specified. The minimum resulting packet size used by the system is 1 byte.
Platforms
All
packet-byte-offset
Syntax
packet-byte-offset {add add-bytes | subtract sub-bytes}
no packet-byte-offset
Context
[Tree] (config>qos>sap-egress>queue packet-byte-offset)
Full Context
configure qos sap-egress queue packet-byte-offset
Description
This command is used to modify the size of each packet handled by the queue by adding or subtracting a number of bytes. The actual packet size is not modified; only the size used to determine the bucket depth impact is changed.
The packet-byte-offset command is meant to be an arbitrary mechanism the can be used to either add downstream frame encapsulation or remove portions of packet headers.
When a packet-byte-offset value is applied to a queue instance, it adjusts the immediate packet size. This means that the queue rates, in other words, operational PIR and CIR, and queue bucket updates use the adjusted packet size. In addition, the queue statistics also reflects the adjusted packet size. Scheduler policy rates, which are data rates, uses the adjusted packet size.
The port scheduler max-rate and the priority level rates and weights, if a Weighted Scheduler Group is used, are always on-the-wire rates and uses the actual frame size. The same applies for the agg-rate-limit on a SAP, a subscriber, or a multiservice Site (MSS) when the queue is port-parented.
When the user enables frame-based-accounting in a scheduler policy or queue-frame-based-accounting with agg-rate-limit in a port scheduler policy, the queue rate will be capped to a user-configured on-the-wire rate and the packet-byte-offset is not included. However, the offsets are applied to the statistics.
The no form of this command is used to remove per packet size modifications from the queue.
Parameters
- add-bytes
-
The add keyword is mutually exclusive to the subtract keyword. Either parameter must be specified. When add is defined, the corresponding bytes parameter specifies the number of bytes that is added to the size of each packet associated with the queue for scheduling and accounting purposes.
- sub-bytes
-
The subtract keyword is mutually exclusive to the add keyword. Either parameter must be specified. When subtract is defined, the corresponding bytes parameter specifies the number of bytes that is subtracted from the size of each packet associated with the queue for scheduling and accounting purposes. The minimum resulting packet size used by the system is 1 byte.
Platforms
All
packet-byte-offset
Syntax
packet-byte-offset {add add-bytes | subtract sub-bytes}
no packet-byte-offset
Context
[Tree] (config>qos>qgrps>ing>qgrp>policer packet-byte-offset)
Full Context
configure qos queue-group-templates ingress queue-group policer packet-byte-offset
Description
This command configures a packet byte offset for the QoS ingress queue-group policer.
Default
no packet-byte-offset
Parameters
- add-bytes
-
Specifies the number of bytes to add as the offset amount.
- sub-bytes
-
Specifies the number of bytes to add as the offset amount.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
packet-byte-offset
Syntax
packet-byte-offset {add add-bytes | subtract sub-bytes}
no packet-byte-offset
Context
[Tree] (config>qos>qgrps>ing>qgrp>queue packet-byte-offset)
Full Context
configure qos queue-group-templates ingress queue-group queue packet-byte-offset
Description
This command is used to modify the size of each packet handled by the queue by adding or subtracting a number of bytes. The actual packet size is not modified; only the size used to determine the ingress scheduling and profiling is changed. The packet-byte-offset command is meant to be an arbitrary mechanism that can be used to either add downstream frame encapsulation or remove portions of packet headers. Both the scheduling and profiling throughput is affected by the offset as well as the stats (accounting) associated with the queue. The packet-byte-offset does not apply to drop statistics, received valid statistics, or the offered managed and unmanaged statistics used by Ingress Multicast Path Management.
The no form of this command is used to remove per packet size modifications from the queue.
Parameters
- add-bytes
-
The add keyword is mutually exclusive to the subtract keyword. Either add or subtract must be specified. When add is defined, the corresponding bytes parameter specifies the number of bytes that is added to the size each packet associated with the queue for scheduling, profiling and accounting purposes. From the queue’s perspective, the packet size is increased by the amount being added to the size of each packet.
- sub-bytes
-
The subtract keyword is mutually exclusive to the add keyword. Either add or subtract must be specified. When subtract is defined, the corresponding bytes parameter specifies the number of bytes that is subtracted from the size of each packet associated with the queue for scheduling, profiling and accounting purposes. From the queue’s perspective, the packet size is reduced by the amount being subtracted from the size of each packet. The minimum resulting packet size used by the system is 1 byte.
Platforms
All
packet-byte-offset
Syntax
packet-byte-offset {add add-bytes | subtract sub-bytes}
no packet-byte-offset
Context
[Tree] (config>qos>qgrps>egr>qgrp>policer packet-byte-offset)
[Tree] (config>qos>qgrps>egr>qgrp>queue packet-byte-offset)
Full Context
configure qos queue-group-templates egress queue-group policer packet-byte-offset
configure qos queue-group-templates egress queue-group queue packet-byte-offset
Description
This command is used to modify the size of each packet handled by the queue by adding or subtracting a number of bytes. The actual packet size is not modified; only the size used to determine the bucket depth impact is changed.
The packet-byte-offset command is meant to be an arbitrary mechanism that can be used to either add downstream frame encapsulation or remove portions of packet headers.
When a packet-byte-offset value is applied to a queue or policer instance, it adjusts the immediate packet size. This means that the queue rates (in other words, operational PIR and CIR) and policer or queue bucket updates use the adjusted packet size. In addition, the statistics also reflect the adjusted packet size. Scheduler policy rates, which are data rates, will use the adjusted packet size.
The port scheduler max-rate and the priority level rates and weights, if a Weighted Scheduler Group is used, are always on-the-wire rates and uses the actual frame size. The same applies for the agg-rate-limit on a SAP, a subscriber, or a Multiservice Site (MSS) when the queue is port-parented.
When the user enables frame-based-accounting in a scheduler policy or queue-frame-based-accounting with agg-rate-limit in a port scheduler policy, the policer or queue rate is capped to a user-configured on-the-wire rate and the packet-byte-offset is not included; however, the offsets are applied to the statistics.
The no form of this command is used to remove per packet size modifications from the queue.
Parameters
- add-bytes
-
Specifies that the corresponding bytes parameter specifies the number of bytes that is added to the size of each packet associated with the queue for scheduling and accounting purposes.
- sub-bytes
-
Specifies that the corresponding bytes parameter specifies the number of bytes that is subtracted from the size of each packet associated with the queue for scheduling and accounting purposes. The minimum resulting packet size used by the system is 1 byte.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
- configure qos queue-group-templates egress queue-group policer packet-byte-offset
All
- configure qos queue-group-templates egress queue-group queue packet-byte-offset
packet-length
packet-length
Syntax
packet-length {lt | gt | eq} packet-length-value
packet-length range packet-length-value packet-length-value
packet-length ip-packet-length-list pkt-len-list-name
no packet-length
Context
[Tree] (config>filter>ip-filter>entry>match packet-length)
Full Context
configure filter ip-filter entry match packet-length
Description
This command configures the IPv4 packet length value match criterion. The IPv4 packet length represents the total packet length including the IPv4 header and the payload.
The no form of this command deletes the match criterion.
Default
no packet-length
Parameters
- lt
-
Specifies "less than”. The lt parameter cannot be used with the lowest possible numerical value for the parameter.
- gt
-
Specifies "greater than”. The gt parameter cannot be used with the highest possible numerical value for the parameter.
- eq
-
Specifies "equal to”.
- packet-length-value
-
Specifies the packet length value.
- range
-
Specifies an inclusive range. When range is used, the beginning of the range must have a value less than the second value of the range.
- pkt-len-list-name
-
Specifies the name of the packet length list.
Platforms
All
packet-length
Syntax
packet-length {lt | gt | eq} packet-length-value
packet-length range packet-length-value packet-length-value
packet-length ip-packet-length-list pkt-len-list-name
no packet-length
Context
[Tree] (config>filter>ipv6-filter>entry>match packet-length)
Full Context
configure filter ipv6-filter entry match packet-length
Description
This command configures the IPv6 packet length value match criterion. The IPv6 packet length represents the total packet length including the IPv6 header and the payload.
The no form of this command deletes the match criterion.
Default
no packet-length
Parameters
- lt
-
Specifies "less than”. The lt parameter cannot be used with the lowest possible numerical value for the parameter.
- gt
-
Specifies "greater than”. The gt parameter cannot be used with the highest possible numerical value for the parameter.
- eq
-
Specifies "equal to”.
- packet-length-value
-
Specifies the packet length value.
- range
-
Specifies an inclusive range. When range is used, the beginning of the range must have a value less than the second value of the range.
- pkt-len-list-name
-
Specifies the name of the packet length list.
Platforms
All
packet-length
Syntax
[no] packet-length packet-length-value
[no] packet-length range packet-length-value-lower-bound packet-length-value-upper-bound
Context
[Tree] (config>filter>match-list>ip-pkt-len-list packet-length)
[Tree] (config>filter>match-list>ipv6-pkt-len-list packet-length)
Full Context
configure filter match-list ip-packet-length-list packet-length
configure filter match-list ipv6-packet-length-list packet-length
Description
This command adds a length value or length range to the list.
The no form of this command deletes the length value or the length range from the list.
Parameters
- packet-length-value-lower-bound
-
Specifies the lower bound of the packet length range.
- packet-length-value-upper-bound
-
Specifies the upper bound of the packet length range.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
packet-rate-high-wmark
packet-rate-high-wmark
Syntax
packet-rate-high-wmark high-watermark
Context
[Tree] (config>app-assure packet-rate-high-wmark)
Full Context
configure application-assurance packet-rate-high-wmark
Description
This command configures the packet rate on the ISA-AA when a packet rate alarm will be raised by the agent.
Default
packet-rate-high-wmark max
Parameters
- high-watermark
-
Specifies the high watermark for packet rate alarms. The value must be larger than or equal to the packet-rate-low-wmark low-watermark value.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
packet-rate-low-wmark
packet-rate-low-wmark
Syntax
packet-rate-low-wmark low-watermark
no packet-rate-low-wmark
Context
[Tree] (config>app-assure packet-rate-low-wmark)
Full Context
configure application-assurance packet-rate-low-wmark
Description
This command configures the packet rate on the ISA-AA when a packet rate alarm will be cleared by the agent.
The no form of this command reverts to the default.
Default
packet-rate-low-wmark 0
Parameters
- low-watermark
-
Specifies the low watermark for packet rate alarms. The value must be lower than or equal to the packet-rate-high-wmark high-watermark value.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
packet-rx
packet-rx
Syntax
packet-rx [client client-ip [ source-port src-port]] [fcc-join] [ fcc-leave] [ret-nack]
no packet-rx
Context
[Tree] (debug>service>id>video-interface packet-rx)
Full Context
debug service id video-interface packet-rx
Description
This command enables debugging of received RTCP messages. The options for this command allow the user to filter only certain types of messages to appear in the debug traces.
Parameters
- client client-ip
-
Specifies the client IP address.
- source-port src-port
-
Specifies the source port.
- fcc-join
-
Enables debugging for FCC joins.
- fcc-leave
-
Enables debugging for FCC leaves.
- ret-nack
-
Enables debugging for retransmission nack packets.
Platforms
7450 ESS, 7750 SR, 7750 SR-s
packet-sanity
packet-sanity
Syntax
packet-sanity direction direction [create]
no packet-sanity direction direction
Context
[Tree] (config>app-assure>group>statistics>tca>sctp-filter packet-sanity)
Full Context
configure application-assurance group statistics threshold-crossing-alert sctp-filter packet-sanity
Description
This command configures a TCA for the counter capturing packet sanity hits for the specified SCTP filter. A packet sanity 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 TCA.
Parameters
- direction
-
Specifies the traffic direction.
- create
-
Keyword used to create the TCA.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
packet-size
packet-size
Syntax
packet-size bytes
no packet-size
Context
[Tree] (config>system>snmp packet-size)
Full Context
configure system snmp packet-size
Description
This command configures the maximum SNMP packet size generated by this node.
The no form of this command restores the default value.
Default
packet-size 1500
Parameters
- bytes
-
Specifies the SNMP packet size in bytes.
Platforms
All
packet-too-big
packet-too-big
Syntax
packet-too-big [number seconds]
no packet-too-big
Context
[Tree] (config>service>ies>if>ipv6>icmp6 packet-too-big)
Full Context
configure service ies interface ipv6 icmp6 packet-too-big
Description
This command specifies whether packet-too-big ICMP messages should be sent. When enabled, ICMPv6 packet-too-big messages are generated by this interface.
The no form of this command disables the sending of ICMPv6 packet-too-big messages.
Default
packet-too-big 100 10
Parameters
- number
-
Specifies the number of ICMP messages that are too large to send in the time frame specified by the seconds parameter.
- seconds
-
Specifies the time frame, in seconds, that is used to limit the number of "packet-too-big” ICMP messages issued.
Platforms
All
packet-too-big
Syntax
packet-too-big [number seconds]
no packet-too-big
Context
[Tree] (config>service>vprn>if>ipv6>icmp6 packet-too-big)
Full Context
configure service vprn interface ipv6 icmp6 packet-too-big
Description
This command configures the rate for Internet Control Message Protocol version 6 (ICMPv6) packet-too-big messages.
Parameters
- number
-
Specifies the number of packet-too-big messages to send in the time frame specified by the seconds parameter.
- seconds
-
Specifies the time frame, in seconds, that is used to limit the number of packet-too-big messages issued.
Platforms
All
packet-too-big
Syntax
packet-too-big
packet-too-big number [10..1000] seconds [ 1..60]
no packet-too-big
Context
[Tree] (config>service>vprn>if>sap>ip-tunnel>icmp6-gen packet-too-big)
Full Context
configure service vprn interface sap ip-tunnel icmp6-generation packet-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
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
packet-too-big
Syntax
packet-too-big [number seconds]
no packet-too-big
Context
[Tree] (config>router>if>ipv6>icmp6 packet-too-big)
Full Context
configure router interface ipv6 icmp6 packet-too-big
Description
This command configures the rate for ICMPv6 packet-too-big messages.
Parameters
- number
-
Limits the number of packet-too-big messages issued per time frame specified in the seconds parameter.
- seconds
-
Determines the time frame, in seconds, that is used to limit the number of packet-too-big messages issued per time frame.
Platforms
All
packet-tx
packet-tx
Syntax
packet-tx [group grp-addr [ source srcAddr]] [ret-nack]
no packet-tx
Context
[Tree] (debug>service>id>video-interface packet-tx)
Full Context
debug service id video-interface packet-tx
Description
This command enables debugging transmitted RTCP packets.
Parameters
- client client-ip
-
Specifies the client IP address.
- source src-srcAddr
-
Specifies the source port’s IP address.
Platforms
7450 ESS, 7750 SR, 7750 SR-s
packet-type
packet-type
Syntax
packet-type [authentication] [accounting] [ coa]
no packet-type
Context
[Tree] (debug>router>radius packet-type)
Full Context
debug router radius packet-type
Description
This command specifies the RADIUS packet type filter of command debug router radius.
Default
authentication accounting coa
Parameters
- authentication
-
Specifies the RADIUS authentication packet.
- accounting
-
Specifies the RADIUS accounting packet.
- coa
-
Specifies the RADIUS change of authorization packet.
Platforms
All
packets
packets
Syntax
[no] packets [interface ip-int-name]
Context
[Tree] (debug>router>srrp packets)
Full Context
debug router srrp packets
Description
This command enables debugging for SRRP packets.
The no form of this command disables debugging.
Platforms
All
packets
Syntax
[no] packets
[no] packets interface ip-int-name [vrid virtual-router-id]
[no] packets interface ip-int-name vrid virtual-router-id ipv6
Context
[Tree] (debug>router>vrrp packets)
Full Context
debug router vrrp packets
Description
This command enables or disables debugging for VRRP packets.
Parameters
- ip-int-name
-
Specifies the interface name, up to 32 characters.
- virtual-router-id
-
Specifies the router ID.
- ipv6
-
Debugs the specified IPv6 VRRP interface.
Platforms
All
packets
Syntax
packets [neighbor ip-address | group name]
no packets
Context
[Tree] (debug>router>bgp packets)
Full Context
debug router bgp packets
Description
This command decodes and logs all sent and received BGP packets in the debug log.
The no form of this command disables debugging.
Parameters
- neighbor ip-address
-
Debugs only events affecting the specified BGP neighbor.
- group name
-
Debugs only events affecting the specified peer group name, up to 64 characters, and associated neighbors.
Platforms
All
packets
Syntax
packets [station station-name]
no packets
Context
[Tree] (debug>router>bmp packets)
Full Context
debug router bmp packets
Description
This command enables debugging for all BMP packets.
The no form of the command disables debugging for all BMP packets.
Parameters
- station-name
-
Specifies the station name of the BMP monitoring station, up to 32 characters.
Platforms
All
packets
Syntax
[no] packets [neighbor ip-int-name | ip-addr]
Context
[Tree] (debug>router>rip packets)
Full Context
debug router rip packets
Description
This command enables debugging for RIP packets.
Parameters
- ip-int-name | ip-address
-
Debugs the RIP packets sent on the neighbor IP address or interface.
Platforms
All
packets
Syntax
[no] packets [neighbor ip-int-name | ipv6-address]
Context
[Tree] (debug>router>ripng packets)
Full Context
debug router ripng packets
Description
This command enables debugging for RIPng packets.
Parameters
- ip-int-name| ipv6-address
-
Debugs the RIPng packets sent on the neighbor IP address or interface.
Platforms
All
packets-admitted-count
packets-admitted-count
Syntax
[no] packets-admitted-count
Context
[Tree] (config>log>acct-policy>cr>aa>aa-to-sub-cntr packets-admitted-count)
[Tree] (config>log>acct-policy>cr>aa>aa-from-sub-cntr packets-admitted-count)
Full Context
configure log accounting-policy custom-record aa-specific to-aa-sub-counters packets-admitted-count
configure log accounting-policy custom-record aa-specific from-aa-sub-counters packets-admitted-count
Description
This command includes the admitted packet count in the AA subscriber's custom record and only applies to the 7750 SR.
The no form of this command excludes the admitted packet count.
Default
no packets-admitted-count
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
packets-denied-count
packets-denied-count
Syntax
[no] packets-denied-count
Context
[Tree] (config>log>acct-policy>cr>aa>aa-from-sub-cntr packets-denied-count)
[Tree] (config>log>acct-policy>cr>aa>aa-to-sub-cntr packets-denied-count)
Full Context
configure log accounting-policy custom-record aa-specific from-aa-sub-counters packets-denied-count
configure log accounting-policy custom-record aa-specific to-aa-sub-counters packets-denied-count
Description
This command includes the denied packet count in the AA subscriber's custom record and only applies to the 7750 SR.
The no form of this command excludes the denied packet count.
Default
no packets-denied-count
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
pad-size
pad-size
Syntax
pad-size octets
no pad-size
Context
[Tree] (config>oam-pm>session>ip>twamp-light pad-size)
Full Context
configure oam-pm session ip twamp-light pad-size
Description
This command defines the amount by which the TWAMP Light packet is padded. TWAMP session controller packets are 27 bytes smaller than TWAMP session reflector packets. If symmetrical packet sizes in the forward and backward direction are required, the pad size must be configured to a minimum of 27 bytes.
The no form of this command removes all padding.
Default
pad-size 0
Parameters
- octets
-
Specifies the value, in octets, to pad the TWAMP Light packet.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
pad-tlv-size
pad-tlv-size
Syntax
pad-tlv-size octets
no pad-tlv-size
Context
[Tree] (config>oam-pm>session>mpls>dm pad-tlv-size)
Full Context
configure oam-pm session mpls dm pad-tlv-size
Description
This command allows the operator to add an optional Pad TLV to PDU and increase the frame on the wire by the specified amount. Note that this command only configures the size of the padding added to the PDU, and does not configure the total size of the frame on the wire. Since the bit count for the length is a maximum of 255 (8bits) the maximum pad per pad-tlv is between 0, 2 and 257 (type 1B, Length 1B, Length 255). Only a single pad-tlv can be added.
The no form of this command removes the optional TLV.
Parameters
- octets
-
Specifies the overall length of the pad-tlv.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
pad-tlv-size
Syntax
pad-tlv-size octets
Context
[Tree] (config>test-oam>link-meas>template>twl pad-tlv-size)
Full Context
configure test-oam link-measurement measurement-template twamp-light pad-tlv-size
Description
This command configures an optional pad TLV size that allows a STAMP PDU to include the PAD TLV. This increases the size of the STAMP PDU by the size of the added TLV. The PAD TLV includes an all zeros pattern.
Parameters
- octets
-
Specifies the length of the pad-tlv.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
pad-tlv-size
Syntax
pad-tlv-size octets [create]
no pad-tlv-size
Context
[Tree] (config>oam-pm>session>ip>twamp-light pad-tlv-size)
Full Context
configure oam-pm session ip twamp-light pad-tlv-size
Description
This command configures the PAD TLV to be included in the STAMP test packet with a total byte count equivalent to the value of this leaf.
TWAMP Light does not support TLVs. To pad the size of the TWAMP Light test packet the user must configure the pad-size command. STAMP test packets (the standard form of TWAMP Light) introduces TLVs for padding. Therefore, STAMP test packets must use the pad-tlv-size value.
The no form of this command removes the TWAMP Light test function from the OAM-PM session.
Parameters
- test-id
-
Specifies the value of the 4-byte local test identifier not sent in the TWAMP Light packets.
- create
-
Creates the test.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
padding-size
padding-size
Syntax
padding-size padding-size
no padding-size
Context
[Tree] (config>service>vprn>static-route-entry>indirect>cpe-check padding-size)
[Tree] (config>service>vprn>static-route-entry>next-hop>cpe-check padding-size)
Full Context
configure service vprn static-route-entry indirect cpe-check padding-size
configure service vprn static-route-entry next-hop cpe-check padding-size
Description
This optional parameter specifies the amount of padding to add to the ICMP packet in bytes. The parameter is only applicable when the cpe-check option is used with the associated static route.
Default
padding-size 56
Parameters
- padding-size
-
An integer value.
Platforms
All
padding-size
Syntax
padding-size padding-size
no padding-size
Context
[Tree] (config>router>static-route-entry>indirect>cpe-check padding-size)
[Tree] (config>router>static-route-entry>next-hop>cpe-check padding-size)
Full Context
configure router static-route-entry indirect cpe-check padding-size
configure router static-route-entry next-hop cpe-check padding-size
Description
This command specifies the amount of padding to add to the ICMP packet in bytes. The parameter is only applicable when the cpe-check option is used with the associated static route.
Default
padding-size 56
Parameters
- padding-size
-
Specifies the integer value.
Platforms
All
padding-size
Syntax
padding-size padding-size
no padding-size
Context
[Tree] (config>service>vprn>sub-if>grp-if>sap>static-host>managed-routes>route-entry>cpe-check padding-size)
[Tree] (config>service>ies>sub-if>grp-if>sap>static-host>managed-routes>route-entry>cpe-check padding-size)
Full Context
configure service vprn subscriber-interface group-interface sap static-host managed-routes route-entry cpe-check padding-size
configure service ies subscriber-interface group-interface sap static-host managed-routes route-entry cpe-check padding-size
Description
This command configures the padding size for the ICMP ping test packet of the CPE connectivity check.
Default
padding-size 56
Parameters
- padding-size
-
Specifies the padding size value.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
padding-size
Syntax
padding-size size
no padding-size
Context
[Tree] (config>vrrp>policy>priority-event>host-unreachable padding-size)
Full Context
configure vrrp policy priority-event host-unreachable padding-size
Description
This command allows the operator to increase the size of IP packet by padding the PDU.
The no form of the command reverts to the default.
Default
padding-size 0
Parameters
- size
-
Specifies amount of increase to the ICMP PDU.
Platforms
All
padi-auth-policy
padi-auth-policy
Syntax
padi-auth-policy policy-name
no padi-auth-policy
Context
[Tree] (config>subscr-mgmt>loc-user-db>ppp>host padi-auth-policy)
Full Context
configure subscriber-mgmt local-user-db ppp host padi-auth-policy
Description
This command configures the PADI authentication policy of this host.
Parameters
- policy-name
-
Specifies the authentication policy name, up to 32 characters.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
pado-ac-name
pado-ac-name
Syntax
pado-ac-name name
no pado-ac-name
Context
[Tree] (config>subscr-mgmt>ppp-policy pado-ac-name)
Full Context
configure subscriber-mgmt ppp-policy pado-ac-name
Description
This command configures the Access Concentrator name that is used in the PPPoE PADO message.
By default, the system name or if not configured, the chassis Serial Number is used.
Parameters
- name
-
Specifies the string up to 128 characters to be used as AC name in the PPPoE PADO message.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
pado-delay
pado-delay
Syntax
pado-delay deci-seconds
no pado-delay
Context
[Tree] (config>subscr-mgmt>loc-user-db>ppp>host pado-delay)
Full Context
configure subscriber-mgmt local-user-db ppp host pado-delay
Description
This command configures the delay timeout before sending a PPPoE Active Discovery Offer (PADO).
Parameters
- deci-seconds
-
Specifies the delay timeout before sending a PADO.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
pado-delay
Syntax
pado-delay deci-seconds
no pado-delay
Context
[Tree] (config>subscr-mgmt>ppp-policy pado-delay)
Full Context
configure subscriber-mgmt ppp-policy pado-delay
Description
This command configures the delay timeout before sending a PPP Active Discovery Offer (PADO) packet.
Parameters
- deci-seconds
-
Specifies the delay timeout before sending a PADO.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
pairing-button
pairing-button
Syntax
pairing-button admin-state
Context
[Tree] (config>system>bluetooth pairing-button)
Full Context
configure system bluetooth pairing-button
Description
This command is used to allow or block the function of the pairing button. This command can be used to block the accidental triggering of a pairing operation while there is already a paired device.
The actual behavior of the Bluetooth pairing is dependent on both this command and the power command.
If normal operation is to use the pairing button on the router and on the external device to initiate the Bluetooth connection, then set:
config>system>bluetooth>power enabled-manual
config>system>bluetooth>pairing-button enable
If normal operation is to only require the external device to initiate the pairing, then set:
config>system>bluetooth>power enabled-automatic
config>system>bluetooth>pairing-button disable
If normal operation is to not allow the local operator to connect without permission from the central management location, then set:
config>system>bluetooth>power enabled-manual
config>system>bluetooth>pairing-button disable
Then when a connection is wanted, the central management station must change the configuration to one of the two options shown above for the time the local operator is connecting. The central management station can change the setting back to block local access after the operations is complete.
Default
pairing-button disable
Parameters
- admin-state
-
Specifies the administrative state.
Platforms
7750 SR-1, 7750 SR-s, 7950 XRS-20e
parallel
parallel
Syntax
parallel [no-advertise]
no parallel
Context
[Tree] (config>router>ospf>segm-rtng>adjacency-set parallel)
[Tree] (config>router>isis>segm-rtng>adjacency-set parallel)
Full Context
configure router ospf segment-routing adjacency-set parallel
configure router isis segment-routing adjacency-set parallel
Description
This command indicates that all members of the adjacency set must terminate on the same neighboring node. The system raises a trap if a user attempts to add an adjacency terminating on a neighboring node that differs from the existing members of the adjacency set. In addition, the system stops advertising the adjacency set in IS-IS or OSPF and locally deprograms it.
By default, parallel adjacency sets are advertised in the IGP. The no-advertise option prevents an adjacency set from being advertised in the IGP. It is only allowed in CLI and SNMP if the parallel command is configured.
The no form of this command indicates that the adjacency set can include adjacencies to different next hop nodes.
Default
parallel
Platforms
All
param-problem
param-problem
Syntax
param-problem [number seconds]
no param-problem
Context
[Tree] (config>service>vprn>sub-if>grp-if>icmp param-problem)
[Tree] (config>service>ies>if>icmp param-problem)
[Tree] (config>service>ies>sub-if>grp-if>icmp param-problem)
[Tree] (config>service>ies>if>ipv6>icmp6 param-problem)
Full Context
configure service vprn subscriber-interface group-interface icmp param-problem
configure service ies interface icmp param-problem
configure service ies subscriber-interface group-interface icmp param-problem
configure service ies interface ipv6 icmp6 param-problem
Description
This command specifies whether parameter-problem ICMP/ICMPv6 messages should be sent. When enabled, parameter-problem ICMP/ICMPv6 messages are generated by this interface.
The no form of this command disables the sending of parameter-problem ICMP/ICMPv6 messages.
Default
param-problem 100 10
Parameters
- number
-
Specifies the number of parameter-problem ICMPv6 messages to send in the time frame specified by the seconds parameter.
- seconds
-
Specifies the time frame, in seconds, that is used to limit the number of parameter-problem ICMPv6 messages issued.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
- configure service vprn subscriber-interface group-interface icmp param-problem
- configure service ies subscriber-interface group-interface icmp param-problem
All
- configure service ies interface ipv6 icmp6 param-problem
- configure service ies interface icmp param-problem
param-problem
Syntax
param-problem [number number] [ seconds seconds]
no param-problem
Context
[Tree] (config>subscr-mgmt>git>ipv4>icmp param-problem)
Full Context
configure subscriber-mgmt group-interface-template ipv4 icmp param-problem
Description
This command configures the parameter-problem ICMPv4 messages that are generated by this interface.
The no form of this command disables the sending of parameter-problem ICMPv4 messages.
Default
param-problem number 100 seconds 10
Parameters
- number
-
Specifies the number of parameter-problem ICMPv4 messages sent in the time specified by the seconds parameter.
- seconds
-
Specifies the time, in seconds, that is used to limit the number of parameter-problem ICMPv4 messages issued.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
param-problem
Syntax
param-problem number seconds
no param-problem [number seconds]
Context
[Tree] (config>service>vprn>if>ipv6>icmp6 param-problem)
[Tree] (config>service>vprn>nw-if>icmp param-problem)
[Tree] (config>service>vprn>if>icmp param-problem)
Full Context
configure service vprn interface ipv6 icmp6 param-problem
configure service vprn network-interface icmp param-problem
configure service vprn interface icmp param-problem
Description
This command specifies whether parameter-problem ICMP messages should be sent. When enabled, parameter-problem ICMP messages are generated by this interface. The no form of this command disables the sending of parameter-problem ICMP messages.
Parameters
- number
-
Specifies the number of parameter-problem ICMP messages to send in the time frame specified by the seconds parameter.
- seconds
-
Specifies the time frame, in seconds, that is used to limit the number of parameter-problem ICMP messages issued.
Platforms
All
param-problem
Syntax
param-problem [number seconds]
no param-problem
Context
[Tree] (config>router>if>icmp param-problem)
Full Context
configure router interface icmp param-problem
Description
This command specifies whether parameter-problem ICMP messages should be sent. When enabled, parameter-problem ICMP messages are generated by this interface.
The no form of this command disables the sending of parameter-problem ICMP messages.
Parameters
- number
-
Specifies the number of parameter-problem ICMP messages to send in the time frame specified by the seconds parameter.
- seconds
-
Specifies the time frame, in seconds, that is used to limit the number of parameter-problem ICMP messages issued.
Platforms
All
param-problem
Syntax
param-problem [number seconds]
no param-problem
Context
[Tree] (config>router>if>ipv6>icmp6 param-problem)
Full Context
configure router interface ipv6 icmp6 param-problem
Description
This command specifies whether parameter-problem ICMPv6 messages should be sent. When enabled, parameter-problem ICMPv6 messages are generated by this interface.
The no form of this command disables the sending of parameter-problem ICMPv6 messages.
Parameters
- number
-
Specifies the number of parameter-problem ICMPv6 messages to send in the time frame specified by the seconds parameter.
- seconds
-
Specifies the time frame, in seconds, that is used to limit the number of parameter-problem ICMPv6 messages issued.
Platforms
All
parent
parent
Syntax
parent [weight weight] [ cir-weight cir-weight]
no parent
Context
[Tree] (config>port>ethernet>access>egr>qgrp>qover>q parent)
Full Context
configure port ethernet access egress queue-group queue-overrides queue parent
Description
This command, when used in the queue-overrides context for a queue group queue, defines an optional weight and cir-weight for the queue treatment by the parent scheduler that further governs the available bandwidth for the queue aside from the queue PIR setting. When multiple schedulers and or queues share a child status with the parent scheduler, the weight or level parameters define how this queue contends with the other children for the parent bandwidth.
Parameters
- weight
-
Specifies the relative weight of this queue in comparison to other child schedulers and queues while vying for bandwidth on the parent scheduler-name. Any queues or schedulers defined as weighted receive no parental bandwidth until all strict queues and schedulers on the parent have reached their maximum bandwidth or are idle. In this manner, weighted children are considered to be the lowest priority.
- cir-weight
-
Specifies the weight the queue uses at the within-cir port priority level. The weight is specified as an integer value from 0 to 100 with 100 being the highest weight. When the cir-weight parameter is set to a value of 0 (the default value), the queue or scheduler does not receive bandwidth during the port schedulers within-cir pass and the cir-level parameter is ignored. If the cir-weight parameter is 1 or greater, the cir-level parameter comes into play.
Platforms
All
parent
Syntax
parent [weight weight] [ cir-weight cir-weight]
no parent
Context
[Tree] (config>port>ethernet>access>egr>qgrp>sched-override>scheduler parent)
[Tree] (config>port>ethernet>access>ing>qgrp>sched-override>scheduler parent)
Full Context
configure port ethernet access egress queue-group scheduler-override scheduler parent
configure port ethernet access ingress queue-group scheduler-override scheduler parent
Description
This command can be used to override the scheduler's parent weight and CIR weight. The weights apply to the associated level/cir-level configured in the applied scheduler policy. The scheduler name must exist in the applied scheduler policy.
The override weights are ignored if the scheduler does not have a parent command configured in the scheduler policy - this allows the parent of the scheduler to be removed from the scheduler policy without having to remove all of the queue group overrides. If the parent scheduler does not exist, causing the configured scheduler to be fostered on an egress port scheduler, the override weights will be ignored and the default values used; this avoids having non-default weightings for fostered schedulers.
The no form of this command returns the scheduler's parent weight and cir-weight to the value configured in the applied scheduler policy.
Default
no parent
Parameters
- weight
-
Specifies the relative weight of this scheduler in comparison to other child schedulers and queues at the same strict level defined by the level parameter in the applied scheduler policy. Within the level, all weight values from active children at that level are summed and the ratio of each active child's weight to the total distributes the available bandwidth at that level. A weight is considered to be active when the queue or scheduler the weight pertains to has not reached its maximum rate and still has packets to transmit.
A 0 (zero) weight value signifies that the child scheduler will receive bandwidth only after bandwidth is distributed to all other non-zero weighted children in the strict level.
- cir-weight
-
Specifies the relative weight of this scheduler in comparison to other child schedulers and queues at the same cir-level defined by the cir-level parameter in the applied scheduler policy. Within the strict cir-level, all cir-weight values from active children at that level are summed and the ratio of each active child's cir-weight to the total distributes the available bandwidth at that level. A cir-weight is considered to be active when the policer, queue, or scheduler that the cir-weight pertains to has not reached the CIR and still has packets to transmit.
A 0 (zero) cir-weight value signifies that the child scheduler will receive bandwidth only after bandwidth is distributed to all other non-zero weighted children in the strict cir-level.
Platforms
All
parent
Syntax
parent scheduler-name [weight weight] [level level] [cir-weight cir-weight] [cir-level cir-level]
no parent
Context
[Tree] (config>qos>sap-egress>dynamic-queue parent)
Full Context
configure qos sap-egress dynamic-queue parent
Description
This command configures the queue treatment by the parent scheduler that governs the available bandwidth for the queue. When multiple schedulers share a child status with the parent scheduler, the weight and level options define how this queue contends with the other children for the above-CIR parent bandwidth. The cir-weight and cir-level options specify the weight the queue uses at the within-CIR port priority level.
Parameters
- scheduler-name
-
Specifies the name of the scheduler parent, up to 32 characters.
- weight
-
Specifies the relative weight of this queue in comparison to other child schedulers and queues while vying for above-CIR priority level bandwidth on the parent scheduler. Any queues or schedulers defined as weighted receive no parental bandwidth, until all strict queues and schedulers on the parent have reached their maximum bandwidth or are idle. In this manner, weighted children are considered to be the lowest priority.
- level
-
Specifies the priority level of the queue (as compared to other competing schedulers and queues) used to feed to the parent, for above-CIR offered load bandwidth passes.
- cir-weight
-
Specifies the weight the queue uses at the within-cir priority level. The weight is specified as an integer value from 0 to 100, with 100 being the highest weight. When the cir-weight parameter is set to 0 (the default value), the queue or scheduler does not receive bandwidth during the port schedulers within-cir pass and the cir-level parameter is ignored. If the cir-weight parameter is 1 or greater, the cir-level parameter comes into play.
- cir-level
-
Specifies the priority level of the queue (as compared to other competing schedulers and queues) used to fed to the parent, for within-CIR offered load bandwidth passes.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
parent
Syntax
parent {[weight weight] [cir-weight cir-weight]}
no parent
Context
[Tree] (config>service>cpipe>sap>ingress>queue-override>queue parent)
[Tree] (config>service>ipipe>sap>egress>queue-override>queue parent)
[Tree] (config>service>epipe>sap>ingress>queue-override>queue parent)
[Tree] (config>service>epipe>sap>egress>queue-override>queue parent)
[Tree] (config>service>ipipe>sap>ingress>queue-override>queue parent)
[Tree] (config>service>cpipe>sap>egress>queue-override>queue parent)
Full Context
configure service cpipe sap ingress queue-override queue parent
configure service ipipe sap egress queue-override queue parent
configure service epipe sap ingress queue-override queue parent
configure service epipe sap egress queue-override queue parent
configure service ipipe sap ingress queue-override queue parent
configure service cpipe sap egress queue-override queue parent
Description
This command defines an optional parent scheduler that further governs the available bandwidth given the queue aside from the queue’s PIR setting. When multiple schedulers and/or queues share a child status with the parent scheduler, the weight or level parameters define how this queue contends with the other children for the parent’s bandwidth.
Checks are not performed to see if a scheduler-name exists when the parent command is defined on the queue. Scheduler names are configured in the config>qos>scheduler-policy>tier level context. Multiple schedulers can exist with the scheduler-name and the association pertains to a scheduler that should exist on the egress SAP as the policy is applied and the queue created. When the queue is created on the egress SAP, the existence of the scheduler-name is dependent on a scheduler policy containing the scheduler-name being directly or indirectly applied (through a multi-service customer site) to the egress SAP. If the scheduler-name does not exist, the queue is placed in the orphaned operational state. The queue will accept packets but will not be bandwidth limited by a virtual scheduler or the scheduler hierarchy applied to the SAP. The orphaned state must generate a log entry and a trap message. The SAP which the queue belongs to must also depict an orphan queue status. The orphaned state of the queue is automatically cleared when the scheduler-name becomes available on the egress SAP.
The parent scheduler can be made unavailable due to the removal of a scheduler policy or scheduler. When an existing parent scheduler is removed or inoperative, the queue enters the orphaned state and automatically returns to normal operation when the parent scheduler is available again.
When a parent scheduler is defined without specifying weight or strict parameters, the default bandwidth access method is weight with a value of 1.
The no form of this command removes a child association with a parent scheduler. If a parent association does not currently exist, the command has no effect and returns without an error. Once a parent association has been removed, the former child queue attempts to operate based on its configured rate parameter. Removing the parent association on the queue within the policy takes effect immediately on all queues using the SAP egress QoS policy.
Parameters
- weight
-
These optional keywords are mutually exclusive to the level keyword. Specifies the relative weight of this queue in comparison to other child schedulers, policers, and queues while vying for bandwidth on the parent scheduler-name. Any policers, queues, or schedulers defined as weighted receive no parental bandwidth until all policers, queues, and schedulers with a higher (numerically larger) priority on the parent have reached their maximum bandwidth or are idle.
All weight values from all weighted active policers, queues, and schedulers with a common parent scheduler are added together. Then, each individual active weight is divided by the total, deriving the percentage of remaining bandwidth provided to the policer, queue, or scheduler. A weight is considered to be active when the pertaining policer, queue, or scheduler has not reached its maximum rate and still has packets to transmit. All child policers, queues, and schedulers with a weight of 0 are considered to have the lowest priority level and are not serviced until all non-zero weighted policers, queues, and schedulers at that level are operating at the maximum bandwidth or are idle.
- cir-weight
-
Specifies the weight the queue or scheduler will use at the within-cir port priority level (defined by the cir-level parameter). The weight is specified as an integer value from 0 to 100 with 100 being the highest weight. When the cir-weight parameter is set to a value of 0 (the default value), the policer, queue, or scheduler does not receive bandwidth during the port schedulers within-cir pass and the cir-level parameter is ignored. If the cir-weight parameter is 1 or greater, the cir-level parameter comes into play.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
- configure service cpipe sap egress queue-override queue parent
- configure service cpipe sap ingress queue-override queue parent
All
- configure service epipe sap ingress queue-override queue parent
- configure service ipipe sap egress queue-override queue parent
- configure service epipe sap egress queue-override queue parent
- configure service ipipe sap ingress queue-override queue parent
parent
Syntax
parent [weight weight] [cir-weight cir-weight]
no parent
Context
[Tree] (config>service>cpipe>sap>egress>sched-override>scheduler parent)
[Tree] (config>service>epipe>sap>ingress>sched-override>scheduler parent)
[Tree] (config>service>ipipe>sap>egress>sched-override>scheduler parent)
[Tree] (config>service>cpipe>sap>ingress>sched-override>scheduler parent)
[Tree] (config>service>epipe>sap>egress>sched-override>scheduler parent)
[Tree] (config>service>ipipe>sap>ingress>sched-override>scheduler parent)
Full Context
configure service cpipe sap egress scheduler-override scheduler parent
configure service epipe sap ingress scheduler-override scheduler parent
configure service ipipe sap egress scheduler-override scheduler parent
configure service cpipe sap ingress scheduler-override scheduler parent
configure service epipe sap egress scheduler-override scheduler parent
configure service ipipe sap ingress scheduler-override scheduler parent
Description
This command can be used to override the scheduler’s parent weight and cir-weight information. The weights apply to the associated level/cir-level configured in the applied scheduler policy. The scheduler name must exist in the scheduler policy applied to the ingress or egress of the SAP or multi-service site.
The override weights are ignored if the scheduler does not have a parent command configured in the scheduler policy – this allows the parent of the scheduler to be removed from the scheduler policy without having to remove all of the SAP/MSS overrides. If the parent scheduler does not exist causing the configured scheduler to be fostered on an egress port scheduler, the override weights will be ignored and the default values used; this avoids having non-default weightings for fostered schedulers.
The no form of this command returns the scheduler’s parent weight and cir-weight to the value configured in the applied scheduler policy.
Default
no parent
Parameters
- weight
-
Specifies the relative weight of this scheduler in comparison to other child schedulers, policers, and queues at the same strict level defined by the level parameter in the applied scheduler policy. Within the level, all weight values from active children at that level are summed and the ratio of each active child’s weight to the total is used to distribute the available bandwidth at that level. A weight is considered to be active when the policer, queue, or scheduler the weight pertains to has not reached its maximum rate and still has packets to transmit.
A 0 (zero) weight value signifies that the child scheduler will receive bandwidth only after bandwidth is distributed to all other non-zero weighted children in the strict level.
- cir-weight
-
Specifies the relative weight of this scheduler in comparison to other child schedulers, policers, and queues at the same cir-level defined by the cir-level parameter in the applied scheduler policy. Within the strict cir-level, all cir-weight values from active children at that level are summed and the ratio of each active child’s cir-weight to the total is used to distribute the available bandwidth at that level. A cir-weight is considered to be active when the policer, queue, or scheduler that the cir-weight pertains to has not reached the CIR and still has packets to transmit.
A 0 (zero) cir-weight value signifies that the child scheduler will receive bandwidth only after bandwidth is distributed to all other non-zero weighted children in the strict cir-level.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
- configure service cpipe sap egress scheduler-override scheduler parent
- configure service cpipe sap ingress scheduler-override scheduler parent
All
- configure service ipipe sap egress scheduler-override scheduler parent
- configure service epipe sap ingress scheduler-override scheduler parent
- configure service epipe sap egress scheduler-override scheduler parent
- configure service ipipe sap ingress scheduler-override scheduler parent
parent
Syntax
parent [weight weight] [cir-weight cir-weight]
no parent
Context
[Tree] (config>service>vpls>sap>egress>queue-override>queue parent)
[Tree] (config>service>vpls>sap>ingress>queue-override>queue parent)
Full Context
configure service vpls sap egress queue-override queue parent
configure service vpls sap ingress queue-override queue parent
Description
This command defines an optional parent scheduler that further governs the available bandwidth given the queue aside from the queue’s PIR setting. When multiple schedulers and/or queues share a child status with the parent scheduler, the weight or level parameters define how this queue contends with the other children for the parent’s bandwidth.
Checks are not performed to see if a scheduler-name exists when the parent command is defined on the queue. Scheduler names are configured in the config>qos>scheduler-policy>tier level context. Multiple schedulers can exist with the scheduler-name and the association pertains to a scheduler that should exist on the egress SAP as the policy is applied and the queue created. When the queue is created on the egress SAP, the existence of the scheduler-name is dependent on a scheduler policy containing the scheduler-name being directly or indirectly applied (through a multi-service customer site) to the egress SAP. If the scheduler-name does not exist, the queue is placed in the orphaned operational state. The queue will accept packets but will not be bandwidth limited by a virtual scheduler or the scheduler hierarchy applied to the SAP. The orphaned state must generate a log entry and a trap message. The SAP which the queue belongs to must also depict an orphan queue status. The orphaned state of the queue is automatically cleared when the scheduler-name becomes available on the egress SAP.
The parent scheduler can be made unavailable due to the removal of a scheduler policy or scheduler. When an existing parent scheduler is removed or inoperative, the queue enters the orphaned state mentioned above and automatically return to normal operation when the parent scheduler is available again.
When a parent scheduler is defined without specifying weight or strict parameters, the default bandwidth access method is weight with a value of 1.
The no form of this command removes a child association with a parent scheduler. If a parent association does not currently exist, the command has no effect and returns without an error. Once a parent association has been removed, the former child queue attempts to operate based on its configured rate parameter. Removing the parent association on the queue within the policy takes effect immediately on all queues using the SAP egress QoS policy.
Parameters
- weight
-
These optional keywords are mutually exclusive to the level keyword. The weight defines the relative weight of this queue in comparison to other child schedulers, policers, and queues while vying for bandwidth on the parent scheduler-name. Any policers, queues, or schedulers defined as weighted receive no parental bandwidth until all policers, queues, and schedulers with a higher (numerically larger) priority on the parent have reached their maximum bandwidth or are idle.
All weight values from all weighted active policers, queues, and schedulers with a common parent scheduler are added together. Then, each individual active weight is divided by the total, deriving the percentage of remaining bandwidth provided to the policer, queue, or scheduler. A weight is considered to be active when the pertaining policer, queue, or scheduler has not reached its maximum rate and still has packets to transmit. All child policers, queues, and schedulers with a weight of 0 are considered to have the lowest priority level and are not serviced until all non-zero weighted policers, queues, and schedulers at that level are operating at the maximum bandwidth or are idle.
- cir-weight
-
Specifies the weight the queue or scheduler will use at the within-cir port priority level (defined by the cir-level parameter). The weight is specified as an integer value from 0 to 100 with 100 being the highest weight. When the cir-weight parameter is set to a value of 0 (the default value), the policer, queue, or scheduler does not receive bandwidth during the port schedulers within-cir pass and the cir-level parameter is ignored. If the cir-weight parameter is 1 or greater, the cir-level parameter comes into play.
Platforms
All
parent
Syntax
parent [weight weight] [cir-weight cir-weight]
no parent
Context
[Tree] (config>service>vpls>sap>egress>sched-override>scheduler parent)
[Tree] (config>service>vpls>sap>ingress>sched-override>scheduler parent)
Full Context
configure service vpls sap egress scheduler-override scheduler parent
configure service vpls sap ingress scheduler-override scheduler parent
Description
This command can be used to override the scheduler’s parent weight and cir-weight information. The weights apply to the associated level/cir-level configured in the applied scheduler policy. The scheduler name must exist in the scheduler policy applied to the ingress or egress of the SAP or multi-service site.
The override weights are ignored if the scheduler does not have a parent command configured in the scheduler policy – this allows the parent of the scheduler to be removed from the scheduler policy without having to remove all of the SAP/MSS overrides. If the parent scheduler does not exist causing the configured scheduler to be fostered on an egress port scheduler, the override weights will be ignored and the default values used; this avoids having non-default weightings for fostered schedulers.
The no form of this command returns the scheduler’s parent weight and cir-weight to the value configured in the applied scheduler policy.
Default
no parent
Parameters
- weight
-
Specifies the relative weight of this scheduler in comparison to other child schedulers and queues at the same strict level defined by the level parameter in the applied scheduler policy. Within the level, all weight values from active children at that level are summed and the ratio of each active child’s weight to the total is used to distribute the available bandwidth at that level. A weight is considered to be active when the policer, queue, or scheduler the weight pertains to has not reached its maximum rate and still has packets to transmit.
A 0 (zero) weight value signifies that the child scheduler will receive bandwidth only after bandwidth is distributed to all other non-zero weighted children in the strict level.
- cir-weight
-
Specifies the relative weight of this scheduler in comparison to other child schedulers and queues at the same cir-level defined by the cir-level parameter in the applied scheduler policy. Within the strict cir-level, all cir-weight values from active children at that level are summed and the ratio of each active child’s cir-weight to the total is used to distribute the available bandwidth at that level. A cir-weight is considered to be active when the policer, queue, or scheduler that the cir-weight pertains to has not reached the CIR and still has packets to transmit.
A 0 (zero) cir-weight value signifies that the child scheduler will receive bandwidth only after bandwidth is distributed to all other non-zero weighted children in the strict cir-level.
Platforms
All
parent
Syntax
parent [weight weight] [ cir-weight cir-weight]
Context
[Tree] (config>service>ies>if>sap>egress>queue-override>queue parent)
[Tree] (config>service>ies>if>sap>egress>sched-override>scheduler parent)
[Tree] (config>service>ies>if>sap>ingress>queue-override>queue parent)
[Tree] (config>service>ies>if>sap>ingress>sched-override>scheduler parent)
Full Context
configure service ies interface sap egress queue-override queue parent
configure service ies interface sap egress scheduler-override scheduler parent
configure service ies interface sap ingress queue-override queue parent
configure service ies interface sap ingress scheduler-override scheduler parent
Description
This command can be used to override the scheduler’s parent weight and cir-weight information. The weights apply to the associated level/cir-level configured in the applied scheduler policy. The scheduler name must exist in the scheduler policy applied to the ingress or egress of the SAP or multi-service site.
The override weights are ignored if the scheduler does not have a parent command configured in the scheduler policy – this allows the parent of the scheduler to be removed from the scheduler policy without having to remove all of the SAP/MSS overrides. If the parent scheduler does not exist causing the configured scheduler to be fostered on an egress port scheduler, the override weights will be ignored and the default values used; this avoids having non default weightings for fostered schedulers.
The no form of this command returns the scheduler’s parent weight and cir-weight to the value configured in the applied scheduler policy.
Default
no parent
Parameters
- weight weight
-
Specifies the relative weight of this scheduler in comparison to other child schedulers and queues at the same strict level defined by the level parameter in the applied scheduler policy. Within the level, all weight values from active children at that level are summed and the ratio of each active child’s weight to the total is used to distribute the available bandwidth at that level. A weight is considered to be active when the queue or scheduler the weight pertains to has not reached its maximum rate and still has packets to transmit.
A 0 (zero) weight value signifies that the child scheduler will receive bandwidth only after bandwidth is distributed to all other non-zero weighted children in the strict level.
- cir-weight cir-weight
-
Specifies the relative weight of this scheduler in comparison to other child schedulers and queues at the same cir-level defined by the cir-level parameter in the applied scheduler policy. Within the strict cir-level, all cir-weight values from active children at that level are summed and the ratio of each active child’s cir-weight to the total is used to distribute the available bandwidth at that level. A cir-weight is considered to be active when the policer, queue, or scheduler that the cir-weight pertains to has not reached the CIR and still has packets to transmit.
A 0 (zero) cir-weight value signifies that the child scheduler will receive bandwidth only after bandwidth is distributed to all other non-zero weighted children in the strict cir-level.
Platforms
All
parent
Syntax
parent [weight weight] [ cir-weight cir-weight]
no parent
Context
[Tree] (config>service>vprn>if>sap>egress>queue-override>queue parent)
[Tree] (config>service>vprn>if>sap>ingress>queue-override>queue parent)
Full Context
configure service vprn interface sap egress queue-override queue parent
configure service vprn interface sap ingress queue-override queue parent
Description
This command can be used to override the scheduler’s parent weight and cir-weight information. The weights apply to the associated level/cir-level configured in the applied scheduler policy. The scheduler name must exist in the scheduler policy applied to the ingress or egress of the SAP or multi-service site.
The override weights are ignored if the scheduler does not have a parent command configured in the scheduler policy – this allows the parent of the scheduler to be removed from the scheduler policy without having to remove all of the SAP/MSS overrides. If the parent scheduler does not exist causing the configured scheduler to be fostered on an egress port scheduler, the override weights will be ignored and the default values used; this avoids having non default weightings for fostered schedulers.
The no form of this command returns the scheduler’s parent weight and cir-weight to the value configured in the applied scheduler policy.
Default
no parent
Parameters
- weight weight
-
Specifes the relative weight of this scheduler in comparison to other child schedulers and queues at the same strict level defined by the level parameter in the applied scheduler policy. Within the level, all weight values from active children at that level are summed and the ratio of each active child’s weight to the total is used to distribute the available bandwidth at that level. A weight is considered to be active when the queue or scheduler the weight pertains to has not reached its maximum rate and still has packets to transmit.
A 0 (zero) weight value signifies that the child scheduler will receive bandwidth only after bandwidth is distributed to all other non-zero weighted children in the strict level.
- cir-weight cir-weight
-
Specifies the relative weight of this scheduler in comparison to other child schedulers and queues at the same cir-level defined by the cir-level parameter in the applied scheduler policy. Within the strict cir-level, all cir-weight values from active children at that level are summed and the ratio of each active child’s cir-weight to the total is used to distribute the available bandwidth at that level. A cir-weight is considered to be active when the policer, queue, or scheduler that the cir-weight pertains to has not reached the CIR and still has packets to transmit.
A 0 (zero) cir-weight value signifies that the child scheduler will receive bandwidth only after bandwidth is distributed to all other non-zero weighted children in the strict cir-level.
Platforms
All
parent
Syntax
parent [weight weight] [ cir-weight cir-weight]
no parent
Context
[Tree] (config>service>vprn>if>sap>ingress>sched-override>scheduler parent)
[Tree] (config>service>vprn>if>sap>egress>sched-override>scheduler parent)
Full Context
configure service vprn interface sap ingress scheduler-override scheduler parent
configure service vprn interface sap egress scheduler-override scheduler parent
Description
This command can be used to override the scheduler’s parent weight and cir-weight information. The weights apply to the associated level/cir-level configured in the applied scheduler policy. The scheduler name must exist in the scheduler policy applied to the ingress or egress of the SAP or multi-service site.
The override weights are ignored if the scheduler does not have a parent command configured in the scheduler policy – this allows the parent of the scheduler to be removed from the scheduler policy without having to remove all of the SAP/MSS overrides. If the parent scheduler does not exist causing the configured scheduler to be fostered on an egress port scheduler, the override weights will be ignored and the default values used; this avoids having non default weightings for fostered schedulers.
The no form of this command returns the scheduler’s parent weight and cir-weight to the value configured in the applied scheduler policy.
Default
no parent
Parameters
- weight weight
-
Specifies the relative weight of this scheduler in comparison to other child schedulers and queues at the same strict level defined by the level parameter in the applied scheduler policy. Within the level, all weight values from active children at that level are summed and the ratio of each active child’s weight to the total is used to distribute the available bandwidth at that level. A weight is considered to be active when the policer, queue, or scheduler the weight pertains to has not reached its maximum rate and still has packets to transmit.
A 0 (zero) weight value signifies that the child scheduler will receive bandwidth only after bandwidth is distributed to all other non-zero weighted children in the strict level.
- cir-weight cir-weight
-
Specifies the relative weight of this scheduler in comparison to other child schedulers and queues at the same cir-level defined by the cir-level parameter in the applied scheduler policy. Within the strict cir-level, all cir-weight values from active children at that level are summed and the ratio of each active child’s cir-weight to the total is used to distribute the available bandwidth at that level. A cir-weight is considered to be active when the policer, queue, or scheduler that the cir-weight pertains to has not reached the CIR and still has packets to transmit.
A 0 (zero) cir-weight value signifies that the child scheduler will receive bandwidth only after bandwidth is distributed to all other non-zero weighted children in the strict cir-level.
Platforms
All
parent
Syntax
parent {root | arbiter-name} [ level priority-level] [weight weight-within-level]
no parent
Context
[Tree] (config>qos>plcr-ctrl-plcy>tier>arbiter parent)
Full Context
configure qos policer-control-policy tier arbiter parent
Description
This command is used to define from where the tiered arbiter receives bandwidth. Both tier 1 and tier 2 arbiters default to parenting to the root arbiter. Tier 2 arbiters may be modified to parent to a tier 1 arbiter. The tier 1 arbiter parent cannot be changed.
The no form of this command is used to return the tiered arbiter to the default parenting behavior.
Default
parent root level 1 weight 1
Parameters
- root
-
In tier 1, arbiter-name is not allowed and only root is accepted. When root is specified, the arbiter will receive all bandwidth directly from the root arbiter. This is the default parent for tiered arbiters.
- arbiter-name
-
In tier 1, arbiter-name is not allowed and only root is accepted. The specified arbiter-name must exist within the policer-control-policy at tier 1 or the parent command will fail. When a tiered arbiter is acting as a parent for another tiered arbiter, the parent arbiter cannot be removed from the policy. The child arbiter will receive all bandwidth directly from its parent arbiter (that receives bandwidth from the root arbiter).
- priority-level
-
Each child arbiter attaches to its parent on one of the parent’s eight strict levels. Level 1 is the lowest and 8 is the highest. The level attribute is used to define which level the child arbiter uses on its parent. The parent distributes its available bandwidth based on strict priority starting with priority level 8 and proceeding towards level 1.
- weight-within-level
-
The weight attribute is used to define how multiple children at the same parent strict level compete when insufficient bandwidth exists on the parent for that level. Each child's weight is divided by the sum of the active children's weights and the result is multiplied by the available bandwidth. If a child cannot receive its entire weighted fair share of bandwidth due to a defined child rate limit, the remainder of its bandwidth is distributed between the other children based on their weights.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
parent
Syntax
parent arbiter-name [weight weight-within-level] [level level]
no parent
Context
[Tree] (config>qos>sap-ingress>policer parent)
[Tree] (config>qos>sap-egress>policer parent)
[Tree] (config>qos>sap-egress>dyn-policer parent)
[Tree] (config>qos>sap-ingress>dyn-policer parent)
Full Context
configure qos sap-ingress policer parent
configure qos sap-egress policer parent
configure qos sap-egress dynamic-policer parent
configure qos sap-ingress dynamic-policer parent
Description
This command is used to create a child-to-parent mapping between each instance of the policer and either the root arbiter or a specific tiered arbiter on the object where the policy is applied. Defining a parent association for the policer causes the policer to compete for the parent policer’s available bandwidth with other child policers mapped to the policer control hierarchy.
Policer control hierarchies may be created on SAPs or on a subscriber or multiservice site context. To create a policer control hierarchy on an ingress or egress SAP context, a policer-control-policy must be applied to the SAP. When applied, the system will create a parent policer that is bandwidth limited by the policy’s max-rate value under the root arbiter. The root arbiter in the policy also provides the information used to determine the various priority-level discard-unfair and discard-all thresholds. Besides the root arbiter, the policy may also contain user-defined tiered arbiters that provide arbitrary bandwidth control for subsets of child policers that are either directly or indirectly parented by the arbiter.
When the QoS policy containing the policer with a parent mapping to an arbiter name exists on the SAP, the system will scan the available arbiters on the SAP. If an arbiter exists with the appropriate name, the policer to arbiter association is created. If the specified arbiter does not exist either because a policer-control-policy is not currently applied to the SAP or the arbiter name does not exist within the applied policy, the policer is placed in an orphan state. Orphan policers operate as if they are not parented and are not subject to any bandwidth constraints other than their own PIR. When a policer enters the orphan state, it is flagged as operationally degraded due to the fact that it is not operating as intended and a trap is generated. Whenever a policer-control-policy is added to the SAP or the existing policy is modified, the SAP's policer's parenting configurations must be reevaluated. If an orphan policer becomes parented, the degraded flag is cleared, and a resulting trap is generated.
For subscribers, the policer control hierarchy is created through the policer-control-policy applied to the sub-profile used by the subscriber. A unique policer control hierarchy is created for each subscriber associated with the sub-profile. The QoS policy containing the policer with the parenting command comes into play through the subscriber sla-profile, which references the QoS policy. The combining of the sub-profile and the sla-profile at the subscriber level provides the system with the proper information to create the policer control hierarchy instance for the subscriber. This functionality is available only for the 7450 ESS and 7750 SR.
Executing the parent command will fail if:
-
The policer’s stat-mode in the QoS policy is set to no-stats
-
A stat-mode no-stats override exists on an instance of the policer on a SAP or subscriber or multiservice site context
A policer with a parent command applied cannot be configured with stat-mode no-stats in either the QoS policy or as an override on an instance of the policer.
When a policer is successfully parented to an arbiter, the parent commands level and weight parameters are used to determine at what priority level and at which weight in the priority level that the child policer competes with other children (policers or other arbiters) for bandwidth.
The no form of this command is used to remove the parent association from all instances of the policer.
Parameters
- {root | arbiter-name}
-
When the parent command is executed, either the keyword root or an arbiter-name must be specified.
- root
-
Specifies that the policer is intended to become a child to the root arbiter where an instance of the policer is created. If the root arbiter does not exist, the policer will be placed in the orphan state.
- arbiter-name
-
Specifies that the policer is intended to become a child to one of the tiered arbiters with the given arbiter-name where an instance of the policer is created. If the specified arbiter-name does not exist, the policer will be placed in the orphan state.
- weight weight-within-level
-
The weight weight-within-level keyword and parameter are optional when executing the parent command. When weight is not specified, a default level of 1 is used in the parent arbiter’s priority level. When weight is specified, the weight-within-level parameter must be specified as an integer value from 1 through 100.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
- configure qos sap-egress policer parent
- configure qos sap-ingress policer parent
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
- configure qos sap-ingress dynamic-policer parent
- configure qos sap-egress dynamic-policer parent
parent
Syntax
parent scheduler-name [weight weight] [level level] [cir-weight cir-weight] [cir-level cir-level]
no parent
Context
[Tree] (config>qos>sap-egress>queue parent)
[Tree] (config>qos>sap-ingress>queue parent)
Full Context
configure qos sap-egress queue parent
configure qos sap-ingress queue parent
Description
This command defines an optional parent scheduler that further governs the available bandwidth given the queue aside from the queue’s PIR setting. When multiple schedulers, policers (at egress only), and/or queues share a child status with the parent scheduler, the weight or level parameters define how this queue contends with the other children for the parent’s bandwidth.
Checks are not performed to see if a scheduler-name exists when the parent command is defined on the queue. Scheduler names are configured in the config>qos>scheduler-policy>tier level context. Multiple schedulers can exist with the scheduler-name and the association pertains to a scheduler that should exist on the egress SAP as the policy is applied and the queue created. When the queue is created on the egress SAP, the existence of the scheduler-name is dependent on a scheduler policy containing the scheduler-name being directly or indirectly applied (through a multiservice customer site) to the egress SAP. If the scheduler-name does not exist, the queue is placed in the orphaned operational state. The queue will accept packets but will not be bandwidth limited by a virtual scheduler or the scheduler hierarchy applied to the SAP. The SAP that the queue belongs to also depicts an orphan queue status. The orphaned state of the queue is automatically cleared when the scheduler-name becomes available on the egress SAP.
The parent scheduler can be made unavailable due to the removal of a scheduler policy or scheduler. When an existing parent scheduler is removed or inoperative, the queue enters the orphaned state and automatically returns to normal operation when the parent scheduler is available again.
When a parent scheduler is defined without specifying the weight parameter, the default is a weight of 1.
The no form of this command removes a child association with a parent scheduler. If a parent association does not currently exist, the command has no effect and returns without an error. When a parent association has been removed, the former child queue attempts to operate based on its configured rate parameter. Removing the parent association on the queue within the policy takes effect immediately on all queues using the SAP egress QoS policy.
Parameters
- scheduler-name
-
The defined scheduler-name conforms to the same input criteria as the schedulers defined within a scheduler policy. Scheduler names are configured in the config>qos>scheduler-policy>tier level context. There are no checks performed at the time of definition to ensure that the scheduler-name exists within an existing scheduler policy. For the queue to use the defined scheduler-name, the scheduler exists on each egress SAP that the queue is eventually created on. For the duration where scheduler-name does not exist on the egress SAP, the queue operates in an orphaned state.
- weight
-
Specifies the relative weight of this queue in comparison to other child schedulers, policers, and queues, while vying for bandwidth on the parent scheduler-name. Any queues, policers, or schedulers defined as weighted receive no parental bandwidth until all policers, queues, and schedulers with a higher (numerically larger) priority on the parent have reached their maximum bandwidth or are idle.
All weight values from all weighted active queues, policers, and schedulers with a common parent scheduler are added together. Then, each individual active weight is divided by the total, deriving the percentage of remaining bandwidth provided to the queue, policer, or scheduler. A weight is considered to be active when the pertaining queue, policer, or scheduler has not reached its maximum rate and still has packets to transmit. All child queues, policers, and schedulers with a weight of 0 are considered to have the lowest priority level and are not serviced until all non-zero weighted queues, policers, and schedulers at that level are operating at the maximum bandwidth or are idle.
- level
-
The optional level parameter defines the level of hierarchy when compared to other schedulers and queues competing for bandwidth on the parent scheduler-name. Queues or schedulers will not receive parental bandwidth until all queues, policers, and schedulers with a higher (numerically larger) priority on the parent have reached their maximum bandwidth or are idle.
Children of the parent scheduler with a lower strict priority will not receive bandwidth until all children with a higher strict priority have either reached their maximum bandwidth or are idle. Children with the same strict level are serviced in relation to their relative weights.
- cir-weight
-
Specifies the weight that the queue or scheduler uses at the within-CIR port priority level (defined by the cir-level parameter). The weight is specified as an integer value from 0 to 100 with 100 being the highest weight. When the cir-weight parameter is set to a value of 0 (the default value), the queue or scheduler does not receive bandwidth during the port schedulers within-CIR pass and the cir-level parameter is ignored. If the cir-weight parameter is 1 or greater, the cir-level parameter comes into play.
- cir-level
-
Specifies the port priority that the queue or scheduler will use to receive bandwidth for its within-CIR offered-load. If the cir-weight parameter is set to a value of 0 (the default value), the queue or scheduler does not receive bandwidth during the port schedulers within-CIR pass and the cir-level parameter is ignored. If the cir-weight parameter is 1 or greater, the cir-level parameter comes into play.
Platforms
All
parent
Syntax
parent {root | arbiter-name} [ level level] [weight weight-within-level]
no parent
Context
[Tree] (config>qos>qgrps>egr>qgrp>policer parent)
[Tree] (config>qos>qgrps>ing>qgrp>policer parent)
Full Context
configure qos queue-group-templates egress queue-group policer parent
configure qos queue-group-templates ingress queue-group policer parent
Description
This command is used to create a child-to-parent mapping between each instance of the policer and either the root arbiter or a specific tiered arbiter on the object where the policy is applied. Defining a parent association for the policer causes the policer to compete for the parent policer’s available bandwidth with other child policers mapped to the policer control hierarchy.
Policer control hierarchies may be created on SAPs or on a subscriber or multiservice site context. To create a policer control hierarchy on an ingress or egress SAP context, a policer-control-policy must be applied to the SAP. When applied, the system will create a parent policer that is bandwidth limited by the policy’s max-rate value under the root arbiter. The root arbiter in the policy also provides the information used to determine the various priority level discard-unfair and discard-all thresholds. Besides the root arbiter, the policy may also contain user-defined tiered arbiters that provide arbitrary bandwidth control for subsets of child policers that are either directly or indirectly parented by the arbiter.
When the QoS policy containing the policer with a parent mapping to an arbiter name exists on the SAP, the system will scan the available arbiters on the SAP. If an arbiter exists with the appropriate name, the policer to arbiter association is created. If the specified arbiter does not exist either because a policer-control-policy is not currently applied to the SAP or the arbiter name does not exist within the applied policy, the policer is placed in an orphan state. Orphan policers operate as if they are not parented and are not subject to any bandwidth constraints other than their own PIR. When a policer enters the orphan state, it is flagged as operationally degraded due to the fact that it is not operating as intended and a trap is generated. Whenever a policer-control-policy is added to the SAP or the existing policy is modified, the SAP's policer's parenting configurations must be reevaluated. If an orphan policer becomes parented, the degraded flag is cleared and a resulting trap is generated.
For subscribers, the policer control hierarchy is created through the policer-control-policy applied to the sub-profile used by the subscriber. A unique policer control hierarchy is created for each subscriber associated with the sub-profile. The QoS policy containing the policer with the parenting command comes into play through the subscriber sla-profile that references the QoS policy. The combining of the sub-profile and the sla-profile at the subscriber level provides the system with the proper information to create the policer control hierarchy instance for the subscriber. This functionality is available only for the 7450 ESS and 7750 SR.
Executing the parent command will fail if:
-
The policer’s stat-mode in the QoS policy is set to no-stats
-
A stat-mode no-stats override exists on an instance of the policer on a SAP or subscriber or multiservice site context
A policer with a parent command applied cannot be configured with stat-mode no-stats in either the QoS policy or as an override on an instance of the policer.
When a policer is successfully parented to an arbiter, the parent commands level and weight parameters are used to determine at what priority level and at which weight in the priority level that the child policer competes with other children (policers or other arbiters) for bandwidth.
The no form of this command is used to remove the parent association from all instances of the policer.
Parameters
- {root | arbiter-name}
-
When the parent command is executed, either the keyword root or an arbiter-name must be specified.
- root
-
The root keyword specifies that the policer is intended to become a child to the root arbiter where an instance of the policer is created. If the root arbiter does not exist, the policer will be placed in the orphan state.
- arbiter-name
-
The arbiter-name parameter specifies that the policer is intended to become a child to one of the tiered arbiters with the given arbiter-name where an instance of the policer is created. If the specified arbiter-name does not exist, the policer will be placed in the orphan state.
- weight weight-within-level
-
The weight weight-within-level keyword and parameter are optional when executing the parent command. When weight is not specified, a default level of 1 is used in the parent arbiters priority level. When weight is specified, the weight-within-level parameter must be specified as an integer value from 1 through 100.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
parent
Syntax
parent scheduler-name [weight weight] [level level] [ cir-weight cir-weight] [cir-level cir-level]
no parent
Context
[Tree] (config>qos>qgrps>egr>qgrp>queue parent)
[Tree] (config>qos>qgrps>ing>qgrp>queue parent)
Full Context
configure qos queue-group-templates egress queue-group queue parent
configure qos queue-group-templates ingress queue-group queue parent
Description
This command defines an optional parent scheduler that further governs the available bandwidth given the queue aside from the queue’s PIR setting. When multiple schedulers, policers (at egress only), and/or queues share a child status with the parent scheduler, the weight or level parameters define how this queue contends with the other children for the parent’s bandwidth.
Checks are not performed to see if a scheduler-name exists when the parent command is defined on the queue. Scheduler names are configured in the config>qos>scheduler-policy>tier level context. Multiple schedulers can exist with the scheduler-name and the association pertains to a scheduler that should exist on the egress SAP as the policy is applied and the queue created. When the queue is created on the egress SAP, the existence of the scheduler-name is dependent on a scheduler policy containing the scheduler-name being directly or indirectly applied (through a multiservice customer site) to the egress SAP. If the scheduler-name does not exist, the queue is placed in the orphaned operational state. The queue will accept packets but will not be bandwidth limited by a virtual scheduler or the scheduler hierarchy applied to the SAP. The SAP that the queue belongs to must also depict an orphan queue status. The orphaned state of the queue is automatically cleared when the scheduler-name becomes available on the egress SAP.
The parent scheduler can be made unavailable due to the removal of a scheduler policy or scheduler. When an existing parent scheduler is removed or inoperative, the queue enters the orphaned state and automatically returns to normal operation when the parent scheduler is available again.
When a parent scheduler is defined without specifying weight or strict parameters, the default bandwidth access method is weight with a value of 1.
The no form of this command removes a child association with a parent scheduler. If a parent association does not currently exist, the command has no effect and returns without an error. When a parent association has been removed, the former child queue attempts to operate based on its configured rate parameter. Removing the parent association on the queue within the policy takes effect immediately on all queues using the SAP egress QoS policy.
Parameters
- scheduler-name
-
The defined scheduler-name conforms to the same input criteria as the schedulers defined within a scheduler policy. Scheduler names are configured in the config>qos>scheduler-policy>tier level context. There are no checks performed at the time of definition to ensure that the scheduler-name exists within an existing scheduler policy. For the queue to use the defined scheduler-name, the scheduler exists on each egress SAP the queue is eventually created on. For the duration where scheduler-name does not exist on the egress SAP, the queue operates in an orphaned state.
- weight weight
-
weight defines the relative weight of this queue in comparison to other child schedulers and queues while vying for bandwidth on the parent scheduler-name. Any queues or schedulers defined as weighted receive no parental bandwidth until all policers, queues, and schedulers with a higher (numerically larger) priority on the parent have reached their maximum bandwidth or are idle.
All weight values from all weighted active queues, policers, and schedulers with a common parent scheduler are added together. Then, each individual active weight is divided by the total, deriving the percentage of remaining bandwidth provided to the queue, policer, or scheduler. A weight is considered to be active when the pertaining queue or scheduler has not reached its maximum rate and still has packets to transmit. All child policers, queues, and schedulers with a weight of 0 are considered to have the lowest priority level and are not serviced until all non-zero weighted queues, policers, and schedulers at that level are operating at the maximum bandwidth or are idle.
- level level
-
The optional level parameter defines the level of hierarchy when compared to other schedulers and queues when vying for bandwidth on the parent scheduler-name. Queues or schedulers will not receive parental bandwidth until all queues and schedulers with a higher (numerically larger) priority on the parent have reached their maximum bandwidth or are idle.
Children of the parent scheduler with a lower strict priority will not receive bandwidth until all children with a higher strict priority have either reached their maximum bandwidth or are idle. Children with the same strict level are serviced relative to their weights.
- cir-weight cir-weight
-
Specifies the weight the queue or scheduler will use at the within-CIR port priority level (defined by the cir-level parameter). The weight is specified as an integer value from 0 to 100 with 100 being the highest weight. When the cir-weight parameter is set to a value of 0 (the default value), the queue or scheduler does not receive bandwidth during the port schedulers within-CIR pass and the cir-level parameter is ignored. If the cir-weight parameter is 1 or greater, the cir-level parameter comes into play.
- cir-level cir-level
-
Specifies the port priority the queue or scheduler will use to receive bandwidth for its within-CIR offered-load. If the cir-weight parameter is set to a value of 0 (the default value), the queue or scheduler does not receive bandwidth during the port schedulers within-CIR pass and the cir-level parameter is ignored. If the cir-weight parameter is 1 or greater, the cir-level parameter comes into play.
Platforms
All
parent
Syntax
parent scheduler-name [weight weight] [level level] [ cir-weight cir-weight] [cir-level cir-level]
no parent
Context
[Tree] (config>qos>scheduler-policy>tier>scheduler parent)
Full Context
configure qos scheduler-policy tier scheduler parent
Description
This command defines an optional parent scheduler that is higher up the policy hierarchy. Only schedulers in tier levels 2 and 3 can have a parental association. When multiple schedulers, policers (at egress only), and/or queues share a child status with the scheduler on the parent, the weight or strict parameters define how this scheduler contends with the other children for the parent’s bandwidth. The parent scheduler can be removed or changed at any time and is immediately reflected on the schedulers created by association of this scheduler policy.
When a parent scheduler is defined without specifying weight or strict parameters, the default bandwidth access method is weight with a value of 1.
The no form of this command removes a child association with a parent scheduler. If a parent association does not currently exist, the command has no effect and returns without an error. When a parent association has been removed, the former child scheduler attempts to operate based on its configured rate parameter. Removing the parent association on the scheduler within the policy will take effect immediately on all schedulers with scheduler-name that have been created using the scheduler-policy-name.
Parameters
- scheduler-name
-
Specifies a scheduler name. The scheduler-name must already exist within the context of the scheduler policy in a tier that is higher (numerically lower).
- weight weight
-
Specifies the relative weight of this scheduler in comparison to other child schedulers and queues at the same strict level defined by the level parameter. Within the level, all weight values from active children at that level are summed and the ratio of each active child’s weight to the total is used to distribute the available bandwidth at that level. A weight is considered to be active when the queue or scheduler the weight pertains to has not reached its maximum rate and still has packets to transmit.
A zero (0) weight value signifies that the child scheduler will receive bandwidth only after bandwidth is distributed to all other non-zero weighted children in the strict level.
- level level
-
Specifies the strict priority level of this scheduler in comparison to other child schedulers and queues vying for bandwidth on the parent scheduler-name during the above-CIR distribution phase of bandwidth allocation. During the above-CIR distribution phase, any queues or schedulers defined at a lower strict level receive no parental bandwidth until all queues and schedulers defined with a higher (numerically larger) strict level on the parent have reached their maximum bandwidth or have satisfied their offered load requirements.
When the similar cir-level parameter default (undefined) are retained for the child scheduler, bandwidth is only allocated to the scheduler during the above-CIR distribution phase.
Children of the parent scheduler with a lower strict priority level will not receive bandwidth until all children with a higher strict priority level have either reached their maximum bandwidth or are idle. Children with the same strict level are serviced in relation to their relative weights.
- cir-weight cir-weight
-
Specifies the relative weight of this scheduler in comparison to other child schedulers and queues at the same cir-level defined by the cir-level parameter. Within the strict cir-level, all cir-weight values from active children at that level are summed and the ratio of each active child’s cir-weight to the total is used to distribute the available bandwidth at that level. A cir-weight is considered to be active when the queue or scheduler that the cir-weight pertains to has not reached the CIR and still has packets to transmit.
A zero (0) cir-weight value signifies that the child scheduler will receive bandwidth only after bandwidth is distributed to all other non-zero weighted children in the strict cir-level.
- cir-level cir-level
-
Specifies the strict priority CIR level of this scheduler in comparison to other child schedulers and queues vying for bandwidth on the parent scheduler-name during the within-CIR distribution phase of bandwidth allocation. During the within-CIR distribution phase, any queues or schedulers defined at a lower strict CIR level receive no parental bandwidth until all queues and schedulers defined with a higher (numerically larger) strict CIR level on the parent have reached their CIR bandwidth or have satisfied their offered load requirements.
If the scheduler’s cir-level parameter retains the default (undefined) state, bandwidth is only allocated to the scheduler during the above-CIR distribution phase.
Children with the same strict cir-level are serviced according to their cir-weight.
Platforms
All
parent
Syntax
parent [weight weight] [cir-weight cir-weight]
no parent
Context
[Tree] (config>service>cust>multi-service-site>ingress>sched-override>scheduler parent)
[Tree] (config>service>cust>multi-service-site>egress>sched-override>scheduler parent)
Full Context
configure service customer multi-service-site ingress scheduler-override scheduler parent
configure service customer multi-service-site egress scheduler-override scheduler parent
Description
This command overrides the scheduler’s parent weight and CIR weight information. The weights apply to the associated level or cir-level configured in the applied scheduler policy. The scheduler name must exist in the scheduler policy applied to the ingress or egress of the SAP or multi-service site.
The override weights are ignored if the scheduler does not have a parent command configured in the scheduler policy. This allows the parent of the scheduler to be removed from the scheduler policy without having to remove all of the SAP/MSS overrides. If the parent scheduler does not exist causing the configured scheduler to be fostered on an egress port scheduler, the override weights will be ignored and the default values used; this avoids having non-default weightings for fostered schedulers.
The no form of the command returns the scheduler’s parent weight and CIR weight to the value configured in the applied scheduler policy.
Default
no parent
Parameters
- weight
-
Specifies the relative weight of this scheduler in comparison to other child schedulers and queues at the same strict level defined by the level parameter in the applied scheduler policy. Within the level, all weight values from active children at that level are summed and the ratio of each active child’s weight to the total is used to distribute the available bandwidth at that level. A weight is considered to be active when the policer, queue or scheduler the weight pertains to has not reached its maximum rate and still has packets to transmit. A 0 (zero) weight value signifies that the child scheduler will receive bandwidth only after bandwidth is distributed to all other non-zero weighted children in the strict level.
- cir-weight
-
Specifies the relative weight of this scheduler in comparison to other child schedulers and queues at the same cir-level defined by the cir-level parameter in the applied scheduler policy. Within the strict cir-level, all cir-weight values from active children at that level are summed and the ratio of each active child’s cir-weight to the total is used to distribute the available bandwidth at that level. A cir-weight is considered to be active when the policer, queue or scheduler that the cir-weight pertains to has not reached the CIR and still has packets to transmit. A 0 (zero) cir-weight value signifies that the child scheduler will receive bandwidth only after bandwidth is distributed to all other non-zero weighted children in the strict cir-level.
Platforms
All
parent-location
parent-location
Syntax
parent-location {default | sla}
no parent-location
Context
[Tree] (config>qos>sap-egress parent-location)
Full Context
configure qos sap-egress parent-location
Description
This command determines the expected location of the parent schedulers for queues configured with a parent command within the sap-egress policy. All parent schedulers must be configured within a scheduler-policy applied at the location corresponding to the parent-location parameter.
If a parent scheduler name does not exist at the specified location, the queue will not be parented and will be orphaned.
The no form of this command reverts to the default.
Default
parent-location default
Parameters
- default
-
When the sap-egress policy is applied to an sla-profile for a subscriber, the parent schedulers of the queues need to be configured in the scheduler-policy applied to the subscriber’s sub-profile.
When the sap-egress policy is applied to a SAP, the parent schedulers of the queues need to be configured in the scheduler-policy applied to the SAP or the multiservice site.
- sla
-
When the sap-egress policy is applied to an sla-profile for a subscriber, the parent schedulers of the queues need to be configured in the scheduler-policy applied to the same sla-profile.
If this parameter is configured within a sap-egress policy that is applied to any object except of the egress of an sla-profile, the configured parent schedulers will not be found and so the queues will not be parented and will be orphaned. This parameter is not supported when policers-hqos-manageable is configured in the SAP egress QoS policy.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
parent-location
Syntax
parent-location {none | sub | vport}
no parent-location
Context
[Tree] (config>qos>scheduler-policy>tier parent-location)
Full Context
configure qos scheduler-policy tier parent-location
Description
This command determines the expected location of the parent schedulers for the tier 1 schedulers configured with a parent command within the scheduler-policy. The parent schedulers must be configured within a scheduler-policy applied at the location corresponding to the parent-location parameter.
If a parent scheduler name does not exist at the specified location, the schedulers will not be parented and will be orphaned.
The configuration of parent-location and frame-based-accounting in a scheduler policy is mutually exclusive in order to ensure consistency between the different scheduling levels.
The no form of this command reverts to the default.
Default
parent-location none
Parameters
- none
-
This parameter indicates that the tier 1 schedulers do not have a parent scheduler and the configuration of the parent under a tier 1 scheduler is blocked. Conversely, this parameter is blocked when any tier 1 scheduler has a parent configured.
- sub
-
When the scheduler-policy is applied to an sla-profile for a subscriber, the parent schedulers of the tier 1 schedulers need to be configured in the scheduler-policy applied to the subscriber’s sub-profile.
If this parameter is configured within a scheduler-policy that is applied to any object except for the egress of an sla-profile, the configured parent schedulers will not be found and so the tier 1 schedulers will not be parented and will be orphaned.
- vport
-
When the scheduler-policy is applied to an sla-profile, a sub-profile for a subscriber, or to the egress of a pseudowire SAP, the parent schedulers of the tier 1 schedulers need to be configured in the scheduler-policy applied to the Vport to which the subscriber will be assigned.
If this parameter is configured within a scheduler-policy that is applied to any object except for the egress of an sla-profile or sub-profile, or to the egress of a PW SAP, the configured parent schedulers will not be found and so the tier 1 schedulers will not be parented and will be orphaned.
Platforms
All
parent-mid-pool
parent-mid-pool
Syntax
parent-mid-pool mid-pool-id
no parent-mid-pool
Context
[Tree] (config>qos>hs-port-pool-policy>alt-port-class-pools>class-pool parent-mid-pool)
[Tree] (config>qos>hs-port-pool-policy>std-port-class-pools>class-pool parent-mid-pool)
Full Context
configure qos hs-port-pool-policy alt-port-class-pools class-pool parent-mid-pool
configure qos hs-port-pool-policy std-port-class-pools class-pool parent-mid-pool
Description
This command creates the buffer allocation mapping between the associated class pool and the specified mid-pool. Use care when selecting a mid-pool in an active state (properly mapped to a root-pool with a non-zero allocation percentage). If a port-class pool is parented by an inactive mid-pool, the queues using the port-class pool are forced into an operational MBS setting of 0, causing all packet to be discarded. A port-class pool can be made inactive (no available buffers) by executing parent-mid-pool none in the port-class pool context.
The no form of the command reverts to the class-pool parenting value. For the standard port-class pools, this default is 1. For alternate port-class pools the default is none.
Default
alt-port-class-pools: none
std-port-class-pools: 1
Parameters
- mid-pool-id
-
Specifies the mid-pool identifier in the HS pool policy. Either a valid mid-pool ID or none must be specified when executing the parent-mid-pool command. The mid-pool-id parameter defines the parent mid-pool to which the port-class is associated. The none keyword deactivates the port-class pool, causing the pool to have a zero size. A queue can still map to an inactive port-class pool although all packets are discarded by the queue.
Platforms
7750 SR-7/12/12e
parent-root-pool
parent-root-pool
Syntax
parent-root-pool root-pool-id
no parent-root-pool
Context
[Tree] (config>qos>hs-pool-policy>mid-tier>mid-pool parent-root-pool)
Full Context
configure qos hs-pool-policy mid-tier mid-pool parent-root-pool
Description
This command creates a buffer allocation mapping between the associated mid-pool mid-pool-id and the specified parent-root-pool root-pool-id. The specified root pool ID must have a non-zero allocation-weight or the command fails. After a mid-pool is successfully associated with a root-pool, the parent root-pool’s allocation-weight value cannot be set to zero.
When the root-pool-id is set to none, no buffers are assigned to the mid-tier pool.
The no form of the command reverts to the default.
Default
parent-root-pool 1
Parameters
- root-pool-id
-
Specifies the parent root pool to which the mid-pool is associated. This parameter is required when executing the parent-root-pool command.
Platforms
7750 SR-7/12/12e
participant-id
participant-id
Syntax
participant-id participant-id
no participant-id
Context
[Tree] (config>app-assure>group>http-error-redirect participant-id)
Full Context
configure application-assurance group http-error-redirect participant-id
Description
This command specifies a 32-character string assigned to the operator by Barefruit. It is used by barefruit landing servers (applies to template # 1 only).
Default
no participant-id
Parameters
- participant-id
-
Specifies the 32-character string supplied by Barefruit.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
participate
participate
Syntax
[no] participate
Context
[Tree] (config>router>isis>flex-algos>flex-algo participate)
Full Context
configure router isis flexible-algorithms flex-algo participate
Description
This command enables IS-IS participation in a specific flexible algorithm.
The router advertises its capability to participate in a specific flexible algorithm within the IS-IS router-capability TLV. Router participation in a flexible algorithm assumes that segment routing and, consequently the advertise-router-capability area is enabled. However, a router only advertises flexible algorithm participation when it can support the corresponding winning flexible algorithm definition. The flexible algorithm participation is not enabled by default.
The no form of this command disables participation for a particular flexible algorithm.
Default
no participate
Platforms
All
participate
Syntax
[no] participate
Context
[Tree] (config>router>ospf>flex-algos>flex-algo participate)
Full Context
configure router ospf flexible-algorithms flex-algo participate
Description
This command enables OSPFv2 participation in a specific flexible algorithm.
The router advertises its capability to participate in a specific flexible algorithm within the OSPFv2 SR algorithm TLV of the router information opaque LSA. Router participation in a flexible algorithm assumes that segment routing and, consequently, the advertise-router-capability area is enabled. However, a router only advertises flexible algorithm participation when it can support the corresponding winning flexible algorithm definition. The flexible algorithm participation is not enabled by default.
The no form of this command disables participation for a specific flexible algorithm.
Default
no participate
Platforms
All
partner-down-delay
partner-down-delay
Syntax
partner-down-delay [hrs hours] [min minutes] [sec seconds]
no partner-down-delay
Context
[Tree] (config>service>vprn>dhcp>server>failover partner-down-delay)
[Tree] (config>router>dhcp6>server>failover partner-down-delay)
[Tree] (config>service>vprn>dhcp>server>pool>failover partner-down-delay)
[Tree] (config>router>dhcp6>server>pool>failover partner-down-delay)
[Tree] (config>router>dhcp>server>failover partner-down-delay)
[Tree] (config>service>vprn>dhcp6>server>failover partner-down-delay)
[Tree] (config>service>vprn>dhcp6>server>pool>failover partner-down-delay)
[Tree] (config>router>dhcp>server>pool>failover partner-down-delay)
Full Context
configure service vprn dhcp local-dhcp-server failover partner-down-delay
configure router dhcp6 local-dhcp-server failover partner-down-delay
configure service vprn dhcp local-dhcp-server pool failover partner-down-delay
configure router dhcp6 local-dhcp-server pool failover partner-down-delay
configure router dhcp local-dhcp-server failover partner-down-delay
configure service vprn dhcp6 local-dhcp-server failover partner-down-delay
configure service vprn dhcp6 local-dhcp-server pool failover partner-down-delay
configure router dhcp local-dhcp-server pool failover partner-down-delay
Description
This command configures the partner down delay time. Since the DHCP lease synchronization failure can be caused by the failure of the intercommunication link (and not necessary the entire node), there is a possibility the redundant DHCP servers become isolated in the network. In other words, they can serve DHCP clients but they cannot synchronize the lease. This can lead to duplicate assignment of IP addresses, since the servers have configured overlapping IP address ranges but they are not aware of each other’s leases.
The purpose of the partner down delay is to prevent the IP lease duplication during the intercommunication link failure by not allowing new IP addresses to be assigned from the remote IP address range. This timer is intended to provide the operator with enough time to remedy the failed situation and to avoid duplication of IP addresses or prefixes during the failure.
During the partner-down-delay time, the prefix designated as remote is eligible only for renewals of the existing DHCP leases that have been synchronized by the peering node. Only after the sum of the partner-down-delay and the maximum-client-lead-time will the prefix designated as remote be eligible for delegation of the new DHCP leases. When this occurs, we say that the remote IP address range has been taken over.
It is possible to expedite the takeover of a remote IP address range so that the new IP leases can start being delegated from that range shortly after the intercommunication failure is detected. This can be achieved by configuring the partner-down-delay timer to 0 seconds, along with enabling the ignore-mclt-on-takeover CLI flag. Caution must be taken before enabling this functionality. It is safe to bypass safety timers (partner-down-delay + MCLT) only in cases where the operator is certain that the intercommunication between the nodes has failed due to the entire node failure and not due to the intercommunication (MCS) link failure. Failed intercommunication due to the nodal failure would ensure that only one node is present in the network for IP address delegation (as opposed to two isolated nodes with overlapping IP address ranges where address duplication can occur). For this reason, the operator must ensure that there are redundant paths between the nodes to ensure uninterrupted synchronization of DHCP leases.
In access-driven mode of operation, partner-down-delay has no effect.
The no form of this command reverts to the default.
Default
partner-down-delay hrs 23 min 59 sec 59
Parameters
- partner-down-delay
-
Specifies the partner down delay time.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
passive
passive
Syntax
[no] passive
Context
[Tree] (config>subscr-mgmt>bgp-prng-plcy passive)
Full Context
configure subscriber-mgmt bgp-peering-policy passive
Description
This command enables the passive mode for the BGP neighbors.
The no form of this command disables the passive mode.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
passive
Syntax
[no] passive
Context
[Tree] (config>service>vprn>bgp>group passive)
[Tree] (config>service>vprn>bgp>group>neighbor passive)
Full Context
configure service vprn bgp group passive
configure service vprn bgp group neighbor passive
Description
This command enables passive mode for the BGP group or neighbor.
When in passive mode, BGP will not attempt to actively connect to the configured BGP peers but responds only when it receives a connect open request from the peer.
The no form of this command used at the group level disables passive mode where BGP actively attempts to connect to its peers.
The no form of this command used at the neighbor level reverts to the value defined at the group level.
Default
no passive — BGP will actively try to connect to all the configured peers.
Platforms
All
passive
Syntax
[no] passive
Context
[Tree] (config>service>vprn>isis>if passive)
[Tree] (config>service>vprn>isis>if>level passive)
Full Context
configure service vprn isis interface passive
configure service vprn isis interface level passive
Description
This command adds the passive attribute which causes the interface to be advertised as an IS-IS interface without running the IS-IS protocol. Normally, only interface addresses that are configured for IS-IS are advertised as IS-IS interfaces at the level that they are configured.
When the passive mode is enabled, the interface or the interface at the level ignores ingress IS-IS protocol PDUs and does not transmit IS-IS protocol PDUs.
The no form of this command removes the passive attribute.
Default
no passive
Platforms
All
passive
Syntax
[no] passive
Context
[Tree] (config>service>vprn>ospf>area>if passive)
[Tree] (config>service>vprn>ospf3>area>if passive)
Full Context
configure service vprn ospf area interface passive
configure service vprn ospf3 area interface passive
Description
This command adds the passive property to the OSPF interface where passive interfaces are advertised as OSPF interfaces but do not run the OSPF protocol.
By default, only interface addresses that are configured for OSPF are advertised as OSPF interfaces. The passive parameter allows an interface to be advertised as an OSPF interface without running the OSPF protocol.
While in passive mode, the interface ignores ingress OSPF protocol packets and does not transmit any OSPF protocol packets.
The no form of this command removes the passive property from the OSPF interface.
Default
no passive
Platforms
All
passive
Syntax
[no] passive
Context
[Tree] (config>router>bgp>group passive)
[Tree] (config>router>bgp>group>neighbor passive)
Full Context
configure router bgp group passive
configure router bgp group neighbor passive
Description
Enables/disables passive mode for the BGP group or neighbor.
When in passive mode, BGP will not attempt to actively connect to the configured BGP peers but responds only when it receives a connect open request from the peer.
The no form of this command used at the group level disables passive mode where BGP actively attempts to connect to its peers.
The no form of this command used at the neighbor level reverts to the value defined at the group level.
Default
no passive
Platforms
All
passive
Syntax
[no] passive
Context
[Tree] (config>router>isis>if passive)
[Tree] (config>router>isis>if>level passive)
Full Context
configure router isis interface passive
configure router isis interface level passive
Description
This command adds the passive attribute which causes the interface to be advertised as an IS-IS interface without running the IS-IS protocol. Normally, only interface addresses that are configured for IS-IS are advertised as IS-IS interfaces at the level that they are configured.
When the passive mode is enabled, the interface or the interface at the level ignores ingress IS-IS protocol PDUs and does not transmit IS-IS protocol PDUs.
The no form of this command removes the passive attribute.
Default
no passive
Platforms
All
passive
Syntax
[no] passive
Context
[Tree] (config>router>ospf>area>interface passive)
[Tree] (config>router>ospf3>area>interface passive)
Full Context
configure router ospf area interface passive
configure router ospf3 area interface passive
Description
This command adds the passive property to the OSPF interface where passive interfaces are advertised as OSPF interfaces but do not run the OSPF protocol.
By default, only interface addresses that are configured for OSPF will be advertised as OSPF interfaces. The passive parameter allows an interface to be advertised as an OSPF interface without running the OSPF protocol.
While in passive mode, the interface will ignore ingress OSPF protocol packets and not transmit any OSPF protocol packets.
The no form of this command removes the passive property from the OSPF interface.
Default
no passive
Platforms
All
passive-dns
passive-dns
Syntax
passive-dns
Context
[Tree] (config>app-assure>group>ip-id-asst passive-dns)
Full Context
configure application-assurance group ip-identification-assist passive-dns
Description
Commands in this context configure passive DNS monitoring for the IP identification assist feature.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
passive-mode
passive-mode
Syntax
[no] passive-mode
Context
[Tree] (config>redundancy>multi-chassis>peer>mc-ep passive-mode)
Full Context
configure redundancy multi-chassis peer mc-endpoint passive-mode
Description
This command configures the passive mode behavior for the MC-EP protocol. When in passive mode the MC-EP pair will be dormant until two of the pseudowires in a MC-EP will be signaled as active by the remote PEs, being assumed that the remote pair is configured with regular MC-EP. As soon as more than one pseudowire is active, dormant MC-EP pair will activate. It will use the regular exchange to select the best pseudowire between the active ones and it will block the Rx and Tx directions of the other pseudowires.
The no form of this command will disable the passive mode behavior.
Default
no passive-mode
Platforms
All
passkey
passkey
Syntax
passkey passkey
Context
[Tree] (config>system>bluetooth passkey)
Full Context
configure system bluetooth passkey
Description
This command configures the Bluetooth passkey that is used during pairing. This passkey must match in both devices that are attempting the pairing operation.
Default
passkey 123456
Parameters
- passkey
-
Specifies the six-digit Bluetooth passkey.
Platforms
7750 SR-1, 7750 SR-s, 7950 XRS-20e
password
password
Syntax
password
Context
[Tree] (password)
Full Context
password
Description
This operational command changes the local user password.
This command is automatically invoked when a user logs in after the administrator uses the new-password-at-login command to force a new password, or the password has expired ( aging). At this time, the user is prompted to enter the old password, new password, and then the new password again to verify the input.
If the user fails to create a new password, CLI access is denied.
A user cannot configure a nonconforming password using the global password command. In this case, the CLI displays an error message and the password change fails. To configure a password value that does not conform to the minimum length or other password complexity rules, use the config>system>security>user>password command (for example, executed by an administrator).
Platforms
All
password
Syntax
password {ignore | chap password | pap password} [hash | hash2 | custom]
no password
Context
[Tree] (config>subscr-mgmt>loc-user-db>ppp>host password)
Full Context
configure subscriber-mgmt local-user-db ppp host password
Description
This command specifies a password type or configures password string for pap or chap. The pap and chap passwords are stored in a hashed format in the config files. The hash|hash2 optional keywords are used for config execution.
This command will only be interpreted if the local user database is connected directly to the PPPoE node under the VPRN/IES group interface. It is not used if the local user database is accessed by a local DHCP server.
The no form of this command reverts to the default.
Parameters
- ignore
-
Specifies that the password be ignored, in which case authentication is always succeed, independent of the password used by the PPPoE client. The client must still perform authentication.
- chap password
-
Specifies that the password, up to 64 characters, for Challenge-Handshake Authentication Protocol) (CHAP) is used. Only a password received with the CHAP protocol is accepted.
- pap password
-
Specifies that the Password Authentication Protocol (PAP) is used, up to 64 characters. Only a password received with the PAP protocol is accepted, even though the CHAP protocol is proposed to the client first because it is unknown at the time of the offer which password type is allowed to the client.
- hash | hash2
-
Specifies hashing scheme.
- custom
-
Specifies the custom encryption to management interface.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
password
Syntax
password password [{hash | hash2 | custom}]
no password
Context
[Tree] (config>router>l2tp password)
[Tree] (config>service>vprn>l2tp password)
[Tree] (config>service>vprn>l2tp>group password)
[Tree] (config>router>l2tp>group password)
[Tree] (config>router>l2tp>group>l2tpv3 password)
[Tree] (config>service>vprn>l2tp>group>tunnel password)
[Tree] (config>service>vprn>l2tp>group>l2tpv3 password)
[Tree] (config>router>l2tp>l2tpv3 password)
[Tree] (config>router>l2tp>group>tunnel password)
[Tree] (config>service>vprn>l2tp>l2tpv3 password)
Full Context
configure router l2tp password
configure service vprn l2tp password
configure service vprn l2tp group password
configure router l2tp group password
configure router l2tp group l2tpv3 password
configure service vprn l2tp group tunnel password
configure service vprn l2tp group l2tpv3 password
configure router l2tp l2tpv3 password
configure router l2tp group tunnel password
configure service vprn l2tp l2tpv3 password
Description
This command configures the password between L2TP LAC and LNS
The no form of this command removes the password.
Default
no password
Parameters
- password
-
Configures the password used for challenge/response calculation and AVP hiding. The maximum length is up to 20 characters if unhashed, 32 characters if hashed, 54 characters if the hash2 keyword is specified.
- hash
-
Specifies the key is entered in an encrypted form. If the hash or hash2 parameter is not used, the key is assumed to be in an unencrypted, clear text form. For security, all keys are stored in encrypted form in the configuration file with the hash or hash2 parameter specified.
- hash2
-
Specifies the key is entered in a more complex encrypted form that involves more variables than the key value alone, meaning that the hash2 encrypted variable cannot be copied and pasted. If the hash or hash2 parameter is not used, the key is assumed to be in an unencrypted, clear text form. For security, all keys are stored in encrypted form in the configuration file with the hash or hash2 parameter specified.
- custom
-
Specifies the custom encryption to management interface.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
password
Syntax
password password [hash | hash2 | custom]
no password
Context
[Tree] (config>service>dynsvc>plcy>auth password)
Full Context
configure service dynamic-services dynamic-services-policy authentication password
Description
This command configures the password to be used for RADIUS authentication of data-triggered dynamic services.
The no form of this command removes the password from the configuration.
Parameters
- password
-
Specifies the password that is used in RADIUS authentication of a data-triggered dynamic service. The maximum length is 20 characters if unhashed, 32 characters if hashed, and 54 characters if the hash2 keyword is specified.
- hash
-
Specifies the key is entered in an encrypted form. If the hash or hash2 parameter is not used, the key is assumed to be in an unencrypted, clear text form. For security, all keys are stored in encrypted form in the configuration file with the hash or hash2 parameter specified
- hash2
-
Specifies the key is entered in a more complex encrypted form that involves more variables than the key value alone, meaning that the hash2 encrypted variable cannot be copied and pasted. If the hash or hash2 parameter is not used, the key is assumed to be in an unencrypted, clear text form. For security, all keys are stored in encrypted form in the configuration file with the hash or hash2 parameter specified.
- custom
-
Specifies the custom encryption to management interface.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
password
Syntax
password password [hash | hash2| custom]
no password
Context
[Tree] (config>subscr-mgmt>auth-policy password)
Full Context
configure subscriber-mgmt authentication-policy password
Description
This command sets a password that is sent with user-name in every RADIUS authentication request sent to the RADIUS server upon receipt of DHCP discover or request messages. If no password is configured, no password AVP is sent.
The no form of this command reverts to the default value.
Parameters
- password
-
Specifies a text string containing the password. Allowed values are any string up to 64 characters long composed of printable, 7-bit ASCII characters. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.
- hash
-
Specifies that the key is entered in an encrypted form. If the hash or hash2 parameter is not used, the key is assumed to be in an unencrypted, clear text form. For security, all keys are stored in encrypted form in the configuration file with the hash or hash2 parameter specified.
- hash2
-
Specifies that the key is entered in a more complex encrypted form that involves more variables than the key value alone, meaning that the hash2 encrypted variable cannot be copied and pasted. If the hash or hash2 parameter is not used, the key is assumed to be in an unencrypted, clear text form. For security, all keys are stored in encrypted form in the configuration file with the hash or hash2 parameter specified.
- custom
-
Specifies the custom encryption to management interface.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
password
Syntax
password password [hash | hash2 | custom]
no password
Context
[Tree] (config>subscr-mgmt>diam-appl-plcy>nasreq password)
Full Context
configure subscriber-mgmt diameter-application-policy nasreq password
Description
This command sets a password that is sent with user-name in every RADIUS authentication request sent to the RADIUS server upon receipt of DHCP discover or request messages. If no password is provided, an empty password is sent.
The no form of this command reverts to the default value.
Parameters
- password
-
Specifies a text string containing the password. Allowed values are any string up to 64 characters. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.
- hash
-
Specifies that the key is entered in an encrypted form. If the hash or hash2 parameter is not used, the key is assumed to be in an unencrypted, clear text form. For security, all keys are stored in encrypted form in the configuration file with the hash or hash2 parameter specified.
- hash2
-
Specifies that the key is entered in a more complex encrypted form that involves more variables than the key value alone, meaning that the hash2 encrypted variable cannot be copied and pasted. If the hash or hash2 parameter is not used, the key is assumed to be in an unencrypted, clear text form. For security, all keys are stored in encrypted form in the configuration file with the hash or hash2 parameter specified.
- custom
-
Specifies the custom encryption to management interface.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
password
Syntax
password password [hash | hash2 | custom]
no password
Context
[Tree] (config>aaa>route-downloader password)
Full Context
configure aaa route-downloader password
Description
This command specifies the password that is used in the RADIUS access requests.
The no form of this command resets the password to the default which is an empty string.
Parameters
- password
-
Specifies a password string up to 32 characters.
- hash
-
Specifies the key is entered in an encrypted form. If the hash or hash2 parameter is not used, the key is assumed to be in an unencrypted, clear text form. For security, all keys are stored in encrypted form in the configuration file with the hash or hash2 parameter specified.
- hash2
-
Specifies the key is entered in a more complex encrypted form that involves more variables than the key value alone, meaning that the hash2 encrypted variable cannot be copied and pasted. If the hash or hash2 parameter is not used, the key is assumed to be in an unencrypted, clear text form. For security, all keys are stored in encrypted form in the configuration file with the hash or hash2 parameter specified.
- custom
-
Specifies the custom encryption to management interface.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
password
Syntax
password password [hash | hash2| custom]
no password
Context
[Tree] (config>subscr-mgmt>vrgw>brg>brg-profile>radius-authentication password)
[Tree] (config>aaa>radius-srv-plcy>servers>health-check>test-account password)
Full Context
configure subscriber-mgmt vrgw brg brg-profile radius-authentication password
configure aaa radius-server-policy servers health-check test-account password
Description
This command specifies the password that the test account will use to send access requests to probe the RADIUS servers.
Parameters
- password
-
Specifies the probing password up to 64 characters.
- hash
-
Specifies the key is entered in an encrypted form. If the hash or hash2 parameter is not used, the key is assumed to be in an unencrypted, clear text form. For security, all keys are stored in encrypted form in the configuration file with the hash or hash2 parameter specified.
- hash2
-
Specifies the key is entered in a more complex encrypted form that involves more variables than the key value alone, meaning that the hash2 encrypted variable cannot be copied and pasted. If the hash or hash2 parameter is not used, the key is assumed to be in an unencrypted, clear text form. For security, all keys are stored in encrypted form in the configuration file with the hash or hash2 parameter specified.
- custom
-
Specifies the custom encryption to management interface.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
password
Syntax
password
Context
[Tree] (config>system>security password)
Full Context
configure system security password
Description
Commands in this context configure password-related parameters.
Platforms
All
password
Syntax
password password [hash | hash2 | custom]
no password
Context
[Tree] (config>ipsec>rad-auth-plcy password)
Full Context
configure ipsec radius-authentication-policy password
Description
This command specifies the password that is used in the RADIUS access requests.
The no form of this command resets the password to its default of ALU and will be stored using hash/hash2 encryption.
Default
no password
Parameters
- password
-
Specifies a password string up to 64characters.
- hash
-
Specifies the key is entered in an encrypted form. If the hash or hash2 parameter is not used, the key is assumed to be in an unencrypted, clear text form. For security, all keys are stored in encrypted form in the configuration file with the hash or hash2 parameter specified.
- hash2
-
Specifies the key is entered in a more complex encrypted form that involves more variables than the key value alone, meaning that the hash2 encrypted variable cannot be copied and pasted. If the hash or hash2 parameter is not used, the key is assumed to be in an unencrypted, clear text form. For security, all keys are stored in encrypted form in the configuration file with the hash or hash2 parameter specified.
- custom
-
Specifies the custom encryption to management interface.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
password
Syntax
password password [hash | hash2 | custom]
no password
Context
[Tree] (config>aaa>isa-radius-plcy password)
Full Context
configure aaa isa-radius-policy password
Description
This command specifies the password that is used in the RADIUS access requests. It shall be specified as a string of up to 32 characters in length.
The no form of the command resets the password to its default of ALU and will be stored using hash/hash2 encryption.
Default
no password
Parameters
- password
-
Specifies a password string up to 32 characters.
- hash
-
Specifies the key is entered in an encrypted form. If the hash or hash2 parameter is not used, the key is assumed to be in an unencrypted, clear text form. For security, all keys are stored in encrypted form in the configuration file with the hash or hash2 parameter specified
- hash2
-
Specifies the key is entered in a more complex encrypted form that involves more variables than the key value alone, meaning that the hash2 encrypted variable cannot be copied and pasted. If the hash or hash2 parameter is not used, the key is assumed to be in an unencrypted, clear text form. For security, all keys are stored in encrypted form in the configuration file with the hash or hash2 parameter specified.
- custom
-
Specifies the custom encryption to management interface.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
password
Syntax
password hex-string
no password
Context
[Tree] (config>li>x-interfaces>lics>lic>authentication password)
Full Context
configure li x-interfaces lics lic authentication password
Description
This command configures the password for the X1 and X2 interfaces.
The no form of this command reverts to the default.
Parameters
- hex-string
-
Specifies the password. Must contain exactly 32 hex nibbles.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
password
Syntax
password [password]
Context
[Tree] (config>system>security>user password)
Full Context
configure system security user password
Description
This command configures the user password for console and FTP access.
The password is stored in an encrypted format in the configuration file when specified. Passwords should be encased in double quotes (" ") at the time of the password creation. The double quote character (") is not accepted inside a password. It is interpreted as the start or stop delimiter of a string.
The password can be entered as plain text or a hashed value. SR OS can distinguish between hashed passwords and plain text passwords and take the appropriate action to store the password correctly.
config>system>security>user# password testuser1
The password is hashed by default.
For example:
config>system>security# user testuser1
config>system>security>user$ password xyzabcd1
config>system>security>user# exit
config>system>security# info
-------------------------------------
...
user "testuser1"
password "$2y$10$pFoehOg/tCbBMPDJ/
kqpu.8af0AoVGY2xsR7WFqyn5fVTnwRzGmOK"
exit
...
-------------------------------------
config>system>security#
The password command allows you also to enter the password as a hashed value.
For example:
config>system>security# user testuser1
config>system>security>user$ password "$2y$10$pFoehOg/tCbBMPDJ/
kqpu.8af0AoVGY2xsR7WFqyn5fVTnwRzGmOK"
config>system>security>user# exit
config>system>security# info
-------------------------------------
...
user "testuser1"
password "$2y$10$pFoehOg/tCbBMPDJ/kqpu.8af0AoVGY2xsR7WFqyn5fVTnwRzGmOK"
exit
...
-------------------------------------
config>system>security#
Parameters
- password
-
This is the password for the user that must be entered by this user during the login procedure. The minimum length of the password is determined by the minimum-length command. The maximum length can be up to 20 chars if unhashed, 32 characters if hashed. The complexity requirements for the password is determined by the complexity-rules command and must be followed; otherwise, the password will not be accepted.
All password special characters (#, $, spaces, and so on) must be enclosed within double quotes.
For example: config>system>security>user# password "south#bay?”
The question mark character (?) cannot be directly inserted as input during a telnet connection because the character is bound to the help command during a normal Telnet/console connection.
To insert a # or ? characters, they must be entered inside a notepad or clipboard program and then cut and pasted into the Telnet session in the password field that is encased in the double quotes as delimiters for the password.
If a password is entered without any parameters, a password length of zero is implied: (carriage return).
Platforms
All
password
Syntax
password password [hash | hash2 | custom]
no password
Context
[Tree] (bof password)
Full Context
bof password
Description
This command configures the password to access the BOF interactive menu at startup.
If a password is configured, the BOF interactive menu is accessible only when the correct password is entered. If the correct password is not entered in 30 s, the node reboots.
The no form of this command removes the configured password.
Default
no password
Parameters
- password
-
Specifies the password.
If the hash, hash2, or custom parameter is not configured, the password is entered in plaintext and the password length must be between 8 and 32 characters. A plaintext password cannot contain embedded nulls or end with " hash”, " hash2”, or " custom”.
If the hash, hash2, or custom parameter is configured, the password is hashed and the password length must be between 1 and 64 characters.
- hash
-
Keyword to specify that the password is entered in an encrypted form.
- hash2
-
Keyword to specify that the password is entered in a more complex encrypted form. The hash2 encryption scheme is node-specific and the password cannot be transferred between nodes.
- custom
-
Keyword to specify that the password uses custom encryption.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
password-history
password-history
Syntax
password-history {user user-name | all}
Context
[Tree] (admin>clear password-history)
Full Context
admin clear password-history
Description
This command is used to clear old passwords used by a specific user, or for all users.
Parameters
- user-name
-
Clears the password history information about the specified user, up to 32 characters.
- all
-
Clears the password history information for all users.
Platforms
All
pat-repetition
pat-repetition
Syntax
pat-repetition [tnc tnc-milli-seconds qos qos-milli-seconds poa poa-milli-seconds]
no pat-repetition
Context
[Tree] (config>mcast-mgmt>mcast-info-plcy>bundle>channel>video>analyzer>alarms pat-repetition)
[Tree] (config>mcast-mgmt>mcast-info-plcy>bundle>video>analyzer>alarms pat-repetition)
[Tree] (config>mcast-mgmt>mcast-info-plcy>bundle>channel>source-override>video>analyzer>alarms pat-repetition)
Full Context
configure mcast-management multicast-info-policy bundle channel video analyzer alarms pat-repetition
configure mcast-management multicast-info-policy bundle video analyzer alarms pat-repetition
configure mcast-management multicast-info-policy bundle channel source-override video analyzer alarms pat-repetition
Description
This command configures the analyzer to check for the program association table (PAT). It is expected that the PAT arrives periodically within a certain interval range. It is possible to configure the type of alarm that is raised when the PAT fails to arrive within the specified interval. As the delay increases between two consecutive PATs, the type of alarm raised becomes more critical, from TNC to POA.
Default
no pat-repetition
Parameters
- tnc-milli-seconds
-
Specifies the time, in milliseconds, for which a TNC alarm is raised if the interval between two consecutive PATs is greater than or equal to this configured value.
- qos-milli-seconds
-
Specifies the time, in milliseconds, for which a QoS alarm is raised if the interval between two consecutive PATs is greater than or equal to this configured value.
- poa-milli-seconds
-
Specifies the time, in milliseconds, for which a POA alarm is raised if the interval between two consecutive PATs is greater than or equal to this configured value.
Platforms
7450 ESS, 7750 SR, 7750 SR-s
pat-syntax
pat-syntax
Syntax
[no] pat-syntax
Context
[Tree] (config>mcast-mgmt>mcast-info-plcy>bundle>video>analyzer>alarms pat-syntax)
[Tree] (config>mcast-mgmt>mcast-info-plcy>bundle>channel>source-override>video>analyzer>alarms pat-syntax)
[Tree] (config>mcast-mgmt>mcast-info-plcy>bundle>channel>video>analyzer>alarms pat-syntax)
Full Context
configure mcast-management multicast-info-policy bundle video analyzer alarms pat-syntax
configure mcast-management multicast-info-policy bundle channel source-override video analyzer alarms pat-syntax
configure mcast-management multicast-info-policy bundle channel video analyzer alarms pat-syntax
Description
This command configures the analyzer to check for PAT syntax errors.
Default
no pat-syntax
Platforms
7450 ESS, 7750 SR, 7750 SR-s
path
path
Syntax
path xc-a lag-id xc-b lag-id
path pxc pxc-id
no path
Context
[Tree] (config>fwd-path-ext>fpe path)
Full Context
configure fwd-path-ext fpe path
Description
This command references a PXC (pair of PXC sub-ports) and consequently create an association between the PXC and the application which is referenced under the same FPE object. Each application will utilize the PXC in the form of an internal cross-connect. The exact use and internal provisioning of this cross-connect depends on the application itself.
The no form of this command removes the reference and association from the configuration.
Default
no path
Parameters
- xc-a lag-id
-
Specifies the LAG identifier associated with one side of the cross-connect. The operator has the freedom to associate xc-a with LAG ID containing either sub-ports.a or sub-ports.b. In other words, the system does not perform automatic check that will ensure a match between xc-a and the LAG ID containing sub-ports.a.
- xc-b lag-id
-
Specifies the LAG identifier associated with one side of the cross-connect. The operator has the freedom to associate xc-a with LAG ID containing either sub-ports.a or sub-ports.b.
- pxc-id
-
Specifies the PXC identifier, the PXC construct that contains a physical port in a loopback mode that provides the cross-connect capability. The system creates two paired sub-ports on top of this physical port and each of these two sub-ports forwards traffic in one direction over the loopback. One sub-port is associated with the transit side of the loopback, while the other sub-port is associated with the termination side (see PXC Configuration Guides for further explanation).
Platforms
All
path
Syntax
path path-id pxc pxc-id
path path-id xc-a lag-id xc-b lag-id
no path path-id
Context
[Tree] (config>fwd-path-ext>fpe>multi-path-list path)
Full Context
configure fwd-path-ext fpe multi-path-list path
Description
This command configures a multipath FPE forwarding path. A single path in a multipath FPE can contain a single PXC port or LAG of PXC ports.
The PXC references a physical port in loopback mode that provides the cross-connect capability. The system creates two paired subports on top of the physical port, each of which forwards traffic in one direction over the loopback. One subport is associated with the transit side of the loopback, while the other is associated with the termination side.
The no form of the command removes the path.
Parameters
- path-id
-
Specifies a path ID for the forwarding path.
- pxc-id
-
Specifies a dedicated PXC ID for the forwarding path.
- xc-a lag-id
-
Specifies the LAG ID associated with one side (transit or termination) of the cross-connect. The operator can associate xc-a with the LAG containing either subports.a or subports.b. The system does not enforce a match between xc-a and the LAG ID containing subports.a.
- xc-b lag-id
-
Specifies the LAG ID associated with the other side of the cross-connect (not designated for xc-a). The operator can associate xc-b with the LAG containing either subports.a or subports.b. The system does not enforce a match between xc-b and the LAG ID containing subports.b.
Platforms
All
path
Syntax
[no] path [sonet-sdh-index]
Context
[Tree] (config>port>sonet-sdh path)
Full Context
configure port sonet-sdh path
Description
This command defines the SONET/SDH path.
The no form of this command removes the specified SONET/SDH path.
This command is supported on TDM satellite.
Default
full channel (or clear channel)
Parameters
- sonet-sdh-index
-
Specifies the components making up the specified SONET/SDH path. Depending on the type of SONET/SDH port the sonet-sdh-index must specify more path indexes to specify the payload location of the path. The sonet-sdh-index differs for SONET and SDH ports.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
path
Syntax
[no] path path-index
Context
[Tree] (config>eth-tunnel path)
Full Context
configure eth-tunnel path
Description
This command configures one of the two paths supported under the Ethernet tunnel.
The no form of this command removes the path from under the Ethernet tunnel. If this is the last path, the associated SAP need to be unconfigured before the path can be deleted.
Default
no path
Parameters
- path-index
-
Specifies the identifier for the path.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
path
Syntax
path name
no path
Context
[Tree] (config>service>epipe>spoke-sdp-fec path)
Full Context
configure service epipe spoke-sdp-fec path
Description
This command specifies the explicit path, containing a list of S-PE hops, that should be used for this spoke SDP. The path-name should correspond to the name of an explicit path configured in the config>service>pw-routing context.
If no path is configured, then each next-hop of the MS-PW used by the spoke SDP will be chosen locally at each T-PE and S-PE.
Default
no path
Parameters
- name
-
The name of the explicit path to be used, as configured under the config>service>pw-routing context.
Platforms
All
path
Syntax
path path-index tag qtag[. qtag]
no path path-index
Context
[Tree] (config>service>epipe>sap>eth-tunnel path)
[Tree] (config>service>ipipe>sap>eth-tunnel path)
Full Context
configure service epipe sap eth-tunnel path
configure service ipipe sap eth-tunnel path
Description
This command configures Ethernet tunnel SAP path parameters.
The no form of this command removes the values from the configuration.
Parameters
- path-index
-
Specifies the path index value.
- qtag[.qtag]
-
Specifies the qtag value.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
path
Syntax
path path-index tag qtag[. qtag]
no path path-index
Context
[Tree] (config>service>vpls>sap>eth-tunnel path)
Full Context
configure service vpls sap eth-tunnel path
Description
This command configures Ethernet tunnel SAP path parameters.
The no form of this command removes the values from the configuration.
Parameters
- path-index
-
Specifies the path index value.
- tag qtag[.qtag]
-
Specifies the qtag value.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
path
Syntax
[no] path path-name
Context
[Tree] (config>router>mpls path)
Full Context
configure router mpls path
Description
This command creates the path to be used for an LSP. A path can be used by multiple LSPs. A path can specify some or all hops from ingress to egress and they can be either strict or loose. A path can also be empty (no path-name specified) in which case the LSP is set up based on IGP (best effort) calculated shortest path to the egress router. Paths are created in a shutdown state. A path must be shutdown before making any changes (adding or deleting hops) to the path. When a path is shutdown, any LSP using the path becomes operationally down.
To create a strict path from the ingress to the egress router, the ingress and the egress routers must be included in the path statement.
The no form of this command deletes the path and all its associated configuration information. All the LSPs that are currently using this path will be affected. Additionally all the services that are actively using these LSPs will be affected. A path must be shutdown and unbound from all LSPs using the path before it can be deleted. The no path path-name command will not result in any action except a warning message on the console indicating that the path may be in use.
Parameters
- path-name
-
Specifies a unique case-sensitive alphanumeric name label for the LSP path up to 32 characters in length.
Platforms
All
path
Syntax
path [detail]
no path
Context
[Tree] (debug>router>rsvp>event path)
Full Context
debug router rsvp event path
Description
This command debugs path-related events.
The no form of the command disables the debugging.
Parameters
- detail
-
Displays detailed information about path-related events.
Platforms
All
path
Syntax
path [detail]
no path
Context
[Tree] (debug>router>rsvp>packet path)
Full Context
debug router rsvp packet path
Description
This command enables debugging for RSVP path packets.
The no form of the command disables the debugging.
Parameters
- detail
-
Displays detailed information about path-related events.
Platforms
All
path
Syntax
path name [create]
no path name
Context
[Tree] (config>service>pw-routing path)
Full Context
configure service pw-routing path
Description
This command configures an explicit path between this T-PE and a remote T-PE. For each path, one or more intermediate S-PE hops must be configured. A path can be used by multiple multi-segment pseudowires. Paths are used by a 7450 ESS, 7750 SR, or 7950 XRS T-PE to populate the list of Explicit Route TLVs included in the signaling of a dynamic MS-PW.
A path may specify all or only some of the hops along the route to reach a T-PE.
The no form of the command removes a specified explicit path from the configuration.
Parameters
- path-name
-
Specifies a locally-unique case-sensitive alphanumeric name label for the MS-PW path of up to 32 characters in length.
Platforms
All
path
Syntax
path {a | b} [{port-id | lag-id} raps-tag qtag1[. qtag2]]
no path {a | b}
Context
[Tree] (config>eth-ring path)
Full Context
configure eth-ring path
Description
This command assigns the ring (major or sub-ring) path to a port and defines the Ring APS tag. Rings typically have two paths: a and b.
The no form of this command removes the path a or b.
Default
no path
Parameters
- port-id
-
Specifies the port ID.
- lag-id
-
Specifies the LAG ID.
- raps-tag
-
Specifies the member encapsulation.
- qtag1
-
Specifies the top or outer VLAN ID.
- qtag2
-
Specifies the bottom or inner VLAN ID.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
path
Syntax
path path-name [create]
no path name
Context
[Tree] (config>system>telemetry>sensor-groups>sensor-group path)
Full Context
configure system telemetry sensor-groups sensor-group path
Description
This command configures a sensor path for the specified sensor-group. Multiple sensor paths can be defined for a single sensor-group. The path is defined in the form of an XML Path (XPath) syntax that refers to single or multiple objects within the YANG model.
The no form of the command removes the specified explicit path from the configuration.
Parameters
- path-name
-
Specifies a sensor path, up to 512 characters.
- create
-
Keyword used to create the sensor path.
Platforms
All
path-b
path-b
Syntax
[no] path-b
Context
[Tree] (config>redundancy>mc>peer>mcr>ring path-b)
Full Context
configure redundancy multi-chassis peer mc-ring ring path-b
Description
This command specifies the set of upper-VLAN IDs associated with the SAPs that belong to path B with respect to load-sharing. All other SAPs belong to path A.
Default
If not specified, the default is an empty set.
Platforms
All
path-computation-method
path-computation-method
Syntax
path-computation-method path-computation-method
no path-computation-method
Context
[Tree] (config>router>mpls>lsp-template path-computation-method)
[Tree] (config>router>mpls>lsp path-computation-method)
Full Context
configure router mpls lsp-template path-computation-method
configure router mpls lsp path-computation-method
Description
This command configures the path computation method of a RSVP-TE or SR-TE LSP.
The user can select among the hop-to-label translation, the local CSPF or the PCE for a configured SR-TE LSP. For SR-TE LSP templates, the PCE option is supported with the SR-TE LSP template type on-demand-p2p-srte and not other template types.
The user can select among the IGP-based path, the local CSPF, or the PCE for a configured RSVP-TE LSP. The PCE option is not supported with the RSVP-TE LSP template.
By default, the IGP-based path is used for an RSVP-TE LSP and the hop-to-label path computation method is used for an SR-TE LSP.
The no form of this command returns to the default path computation method for the type of LSP.
Default
no path-computation-method
Parameters
- path-computation-method
-
Specifies the path computation method for the LSP.
Platforms
All
path-cost
path-cost
Syntax
path-cost sap-path-cost
no path-cost [sap-path-cost]
Context
[Tree] (config>service>template>vpls-sap-template>stp path-cost)
[Tree] (config>service>vpls>sap>stp path-cost)
[Tree] (config>service>vpls>spoke-sdp>stp path-cost)
Full Context
configure service template vpls-sap-template stp path-cost
configure service vpls sap stp path-cost
configure service vpls spoke-sdp stp path-cost
Description
This command configures the Spanning Tree Protocol (STP) path cost for the SAP or spoke-SDP.
The path cost is used by STP to calculate the path cost to the root bridge. The path cost in BPDUs received on the root port is incremented with the configured path cost for that SAP or spoke-SDP. When BPDUs are sent out of other egress SAPs or spoke-SDPs, the newly calculated root path cost is used. These are the values used for CIST when running MSTP.
STP suggests that the path cost is defined as a function of the link bandwidth. Since SAPs and spoke-SDPs are controlled by complex queuing dynamics, in the 7450 ESS, 7750 SR, and 7950 XRS the STP path cost is a purely static configuration.
The no form of this command returns the path cost to the default value.
Parameters
- path-cost
-
The path cost for the SAP or spoke-SDP
Platforms
All
path-cost
Syntax
path-cost sap-path-cost
no path-cost
Context
[Tree] (config>service>pw-template>stp path-cost)
Full Context
configure service pw-template stp path-cost
Description
This command configures the Spanning Tree Protocol (STP) path cost for the SAP or spoke SDP.
The path cost is used by STP to calculate the path cost to the root bridge. The path cost in BPDUs received on the root port is incremented with the configured path cost for that SAP or spoke SDP. When BPDUs are sent out other egress SAPs or spoke SDPs, the newly calculated root path cost is used. These are the values used for CIST when running MSTP.
STP suggests that the path cost is defined as a function of the link bandwidth. Since SAPs and spoke SDPs are controlled by complex queuing dynamics, the STP path cost is a purely static configuration.
The no form of this command returns the path cost to the default value.
Default
path-cost 10
Parameters
- path-cost
-
Specifies the path cost for the SAP or spoke SDP.
Platforms
All
path-destination
path-destination
Syntax
path-destination ip-address interface if-name
path-destination ip-address [next-hop ip-address]
no path-destination
Context
[Tree] (config>saa>test>type-multi-line>lsp-trace>sr-policy path-destination)
[Tree] (config>saa>test>type-multi-line>lsp-ping>sr-policy path-destination)
Full Context
configure saa test type-multi-line lsp-trace sr-policy path-destination
configure saa test type-multi-line lsp-ping sr-policy path-destination
Description
This command configures the IP address of the path destination from the range 127/8. When the LDP FEC prefix is IPv6, the user must enter a 127/8 IPv4 mapped IPv6 address, that is, in the range ::ffff:127/104.
The no form of this command removes the configuration.
Parameters
- ip-address
-
Specifies the IP address.
- if-name
-
Specifies the name of an IP interface, up 32 characters, to send the MPLS echo request to. The name must already exist in the config>router>interface context.
Platforms
All
path-discovery
path-discovery
Syntax
path-discovery
Context
[Tree] (config>test-oam>ldp-treetrace path-discovery)
Full Context
configure test-oam ldp-treetrace path-discovery
Description
This command creates the context to configure the LDP ECMP OAM path discovery.
The ingress LER builds the ECMP tree for a given FEC (egress LER) by sending LSP Trace messages and including the LDP IPv4 Prefix FEC TLV as well as the downstream mapping TLV. It inserts an IP address range drawn from the 127/8 space. When received by the downstream LSR, it uses this range to determine which ECMP path is exercised by any IP address or a sub-range of addresses within that range based on its internal hash routine. When the MPLS Echo reply is received by the ingress LER, it records this information and proceeds with the next echo request message targeted for a node downstream of the first LSR node along one of the ECMP paths. The sub-range of IP addresses indicated in the initial reply is used since the objective is to have the LSR downstream of the ingress LER pass this message to its downstream node along the first ECMP path.
The user configures the frequency of running the tree discovery using the command config>test-oam>ldp-treetrace>path-discovery>interval.
The ingress LER gets the list of FECs from the LDP FEC database. New FECs are added to the discovery list at the next tree discovery and not when they are learned and added into the FEC database. The maximum number of FECs to be discovered with the tree building feature is limited to 500. The user can configure FECs to include or exclude using a policy profile by applying the command config>test-oam>ldp-treetrace>path-discovery>policy-statement.
Platforms
All
path-excl
path-excl
Syntax
[no] path-excl
Context
[Tree] (config>redundancy>mc>peer>mcr>ring path-excl)
Full Context
configure redundancy multi-chassis peer mc-ring ring path-excl
Description
This command specifies the set of upper-VLAN IDs associated with the SAPs that are to be excluded from control by the multi-chassis ring.
Default
If not specified, the default is an empty set.
Platforms
All
path-id
path-id
Syntax
path-id {lsp-num lsp-num | working-path | protect-path [src-global-id src-global-id] src-node-id src-node-id src-tunnel-num src-tunnel-num [dest-global-id dest-global-id] dest-node-id dest-node-id [dest-tunnel-num dest-tunnel-num]}
no path-id
Context
[Tree] (config>router>mpls>mpls-tp>transit-path path-id)
Full Context
configure router mpls mpls-tp transit-path path-id
Description
This command configures path ID for an MPLS-TP transit path at an LSR. The path ID is equivalent to the MPLS-TP LSP ID and is used to generate the maintenance entity group intermediate point (MIP) identifier for the LSP at the LSR. A path-id must be configured for on-demand OAM to verify an LSP at the LSR.
The path-id must contain at least the following parameters: lsp-num, src-node-id, src-global-id, src-tunnel-num, dest-node-id.
The path-id must be unique on a node. It is recommended that his is also configured to be a globally unique value.
The no form of this command removes the path ID from the configuration.
Default
no path-id
Parameters
- lsp-num
-
Specifies the LSP number.
- src-global-id
-
Specifies the source global ID.
- src-node-id
-
Specifies the source node ID.
- src-tunnel-num
-
Specifies the source tunnel number.
- dest-global-id
-
Specifies the destination global ID. If the destination global ID is not entered, then it is set to the same value as the source global ID.
- dest-node-id
-
Specifies the destination node ID.
- dest-tunnel-num
-
Specifies the destination tunnel number. If the destination tunnel number is not entered, then it is set to the same value as the source tunnel number.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
path-instances
path-instances
Syntax
path-instances
Context
[Tree] (config>router>p2mp-sr-tree>p2mp-policy>candidate-path path-instances)
Full Context
configure router p2mp-sr-tree p2mp-policy candidate-path path-instances
Description
Commands in this context configure the instance entries of the candidate path.
Multiple path instances can exist in a candidate path for the P2MP SR tree. Each path instance is a P2MP LSP and has an instance ID. Path instances are used for global optimization of the active candidate path.
Platforms
All
path-mtu
path-mtu
Syntax
path-mtu [bytes]
no path-mtu bytes
Context
[Tree] (config>service>pw-template path-mtu)
[Tree] (config>service>sdp path-mtu)
Full Context
configure service pw-template path-mtu
configure service sdp path-mtu
Description
This command configures the Maximum Transmission Unit (MTU) in bytes that the SDP can transmit to the far-end device router without packet dropping or IP fragmentation overriding the SDP-type default MTU.
The SDP-type default path-mtu can be overridden on a per SDP basis. Dynamic maintenance protocols on the SDP, like RSVP, may override this setting.
If the physical MTU on an egress interface indicates the next hop on an SDP path cannot support the current path-mtu, the system modifies the operational path-mtu on that SDP to a value that can be transmitted without fragmentation.
The no form of this command removes any path-mtu configured on the SDP, and the SDP uses the system default for the SDP type.
Default
the default path-mtu defined on the system for the type of SDP
Parameters
- bytes
-
Specifies the bytes.
Platforms
All
path-mtu-discovery
path-mtu-discovery
Syntax
[no] path-mtu-discovery
Context
[Tree] (config>router>ldp>tcp-session-params>peer-transport path-mtu-discovery)
Full Context
configure router ldp tcp-session-parameters peer-transport path-mtu-discovery
Description
This command enables Path MTU discovery for the associated TCP connections. When enabled, the MTU for the associated TCP session is initially set to the egress interface MTU. The DF bit is also set so that if a router along the path of the TCP connection cannot handle a packet of a particular size without fragmenting, it sends back an ICMP message to set the path MTU for the given session to a lower value that can be forwarded without fragmenting.
If one or more transport addresses used in the Hello adjacencies to the same peer LSR are different from the LSR-ID value, the user must add each of the transport addresses to the path MTU discovery configuration as a separate peer. This means when the TCP connection is bootstrapped by a given Hello adjacency, the path MTU discovery can operate over that specific TCP connection by using its specific transport address.
Default
no path-mtu-discovery
Platforms
All
path-mtu-discovery
Syntax
[no] path-mtu-discovery
Context
[Tree] (config>router>bgp>group path-mtu-discovery)
[Tree] (config>router>bgp path-mtu-discovery)
[Tree] (config>router>bgp>group>neighbor path-mtu-discovery)
Full Context
configure router bgp group path-mtu-discovery
configure router bgp path-mtu-discovery
configure router bgp group neighbor path-mtu-discovery
Description
This command enables Path MTU Discovery (PMTUD) for the associated TCP connections.
When enabled, PMTUD is activated toward an IPv4 BGP neighbor. The Don’t Fragment (DF) bit is set in the IP header of all IPv4 packets sent to the peer. If any device along the path toward the peer cannot forward the packet because the IP MTU of the interface is smaller than the IP packet size, the device drops the packet and sends an ICMP or ICMPv6 error message encoding the interface MTU. When the router receives the ICMP or ICMPv6 message, it lowers the TCP maximum segment size limit from the previous value to accomodate the IP MTU constraint.
When PMTUD is disabled and there is no tcp-mss configuration to associate with a BGP neighbor (in either the BGP configuration or the first-hop IP interface configuration), the router advertises a TCP MSS option of only 1024 bytes, limiting received TCP segments to that size.
The no form of this command disables PMTUD.
Default
no path-mtu-discovery
Platforms
All
path-preference
path-preference
Syntax
path-preference value
no path-preference
Context
[Tree] (config>router>mpls>lsp>secondary path-preference)
Full Context
configure router mpls lsp secondary path-preference
Description
This command enables the use of path preference among configured standby secondary paths per LSP. If all standby secondary paths have a default path-preference value then a non-standby secondary path will remain the active path while a standby secondary is available. A standby secondary path configured with the highest priority (for example, the lowest path-preference value) is made the active path when the primary is not in use. If multiple standby secondary paths have the same, lowest, path-preference value then the system will select the path with the highest up-time. Path preference can only be configured on the standby secondary paths.
The no form of this command resets the path-preference to the default value.
Default
path-preference 255
Parameters
- value
-
Specifies an alternate path for the LSP if the primary path is not available.
Platforms
All
path-probing
path-probing
Syntax
path-probing
Context
[Tree] (config>test-oam>ldp-treetrace path-probing)
Full Context
configure test-oam ldp-treetrace path-probing
Description
This command creates the context to configure the LDP tree trace path probing phase.
The periodic path exercising runs in the background to test the LDP ECMP paths discovered by the path discovery capability. The probe used is an LSP Ping message with an IP address drawn from the sub-range of 127/8 addresses indicated by the output of the tree discovery for this FEC.
The user configures the frequency of running the path probes using the config>test-oam>ldp-treetrace>path-probing>interval command. If an I/F is down on the ingress LER performing the LDP tree trace, then LSP Ping probes that normally go out this interface are not sent but the ingress LER node does not raise alarms.
The LSP Ping routine updates the content of the MPLS echo request message, specifically the IP address, as soon as the LDP ECMP path discovery phase has output the results of a new computation for the path in question.
Platforms
All
path-profile
path-profile
Syntax
path-profile profile-id [path-group group-id]
no path-profile profile-id
Context
[Tree] (config router mpls lsp path-profile)
[Tree] (config router mpls lsp-template path-profile)
Full Context
configure router mpls lsp path-profile
configure router mpls lsp-template path-profile
Description
This command configures the PCE path profile and path group ID.
The PCE supports the computation of disjoint paths for two different LSPs originating and/or terminating on the same or different PE routers. To indicate this constraint to the PCE, the user must configure the PCE path profile ID and path group ID to which the PCE computed or PCE controlled LSP belongs to. These parameters are passed transparently by the PCC to the PCE and are thus opaque data to the router.
The association of the optional path-group ID is to allow the PCE to determine the profile ID that must be used with this path-group ID. One path-group ID is allowed per profile ID. The user can, however, enter the same path-group ID with multiple profile IDs by executing this command multiple times. A maximum of five path-profile [path-group] entries can be associated with the same LSP.
The no form of this command removes the path profile association with the LSP.
Parameters
- profile-id
-
Specifies the profile ID.
- path-group group-id
-
Specifies the path group ID.
Platforms
All
path-restoration-state
path-restoration-state
Syntax
path-restoration-state {standby | auto}
no path-restoration-state
Context
[Tree] (config>subscr-mgmt>up-resiliency>fsg-template path-restoration-state)
Full Context
configure subscriber-mgmt up-resiliency fate-sharing-group-template path-restoration-state
Description
This command configures how the BNG-UP manages active FSGs if the BNG-UP becomes headless (PFCP path is in restoration/headless). The BNG-UP can always move all active FSGs to standby, or it can decide whether to move them to standby based on a series of heuristic tests. If any test indicates that the BNG-UP cannot forward traffic for the FSG, or another BNG-UP becomes active, the BNG-UP moves the FSG to standby.
Default
path-restoration-state auto
Parameters
- standby
-
Keyword that indicates any FSG becomes standby when the BNG-UP becomes headless.
- auto
-
Keyword that indicates the BNG-UP determines whether to change the state of the FSGs to standby based on a series of heuristic tests.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
path-restoration-time
path-restoration-time
Syntax
path-restoration-time minutes
no path-restoration-time
Context
[Tree] (config>subscr-mgmt>pfcp-association path-restoration-time)
Full Context
configure subscriber-mgmt pfcp-association path-restoration-time
Description
This command configures the time sessions are kept after a PFCP path failure is detected. When the timer expires, or if it is not configured, all sessions associated with the path are removed. If the path recovers without a restart before the timer expires, the timer is canceled, and no sessions are removed.
The no form of this command removes the path restoration configuration.
Default
no path-restoration-time
Parameters
- minutes
-
Specifies the time, in minutes, that sessions are kept after a PFCP path failure. This timer should be configured to a value that is at least twice the sum of the heartbeat interval plus the total heartbeat timeout (heartbeat retries x heartbeat timeout = N1 x T1).
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
path-threshold
path-threshold
Syntax
path-threshold num-paths
no path-threshold
Context
[Tree] (config>eth-tunnel>lag-emulation path-threshold)
Full Context
configure eth-tunnel lag-emulation path-threshold
Description
This command configures the behavior for the eth-tunnel if the number of operational members is equal to or below a threshold level
Default
no path-threshold
Parameters
- num-paths
-
Specifies the threshold for the Ethernet Tunnel group.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
path-type
path-type
Syntax
path-type {ibgp | ebgp}
no path-type
Context
[Tree] (config>router>policy-options>policy-statement>entry>from path-type)
Full Context
configure router policy-options policy-statement entry from path-type
Description
This command matches BGP routes based on their path type (EBGP or IBGP). A route learned from an EBGP peer has path-type ebgp. A route learned from an IBGP or confed-EBGP peer has path-type ibgp.
A non-BGP route does not match a policy entry if it contains the path-type command.
Default
no path-type
Parameters
- ibgp
-
Matches routes from internal BGP peers.
- ebgp
-
Matches routes from external BGP peers.
Platforms
All
patherr
patherr
Syntax
patherr [detail]
no patherr
Context
[Tree] (debug>router>rsvp>packet patherr)
Full Context
debug router rsvp packet patherr
Description
This command debugs path error packets.
The no form of the command disables the debugging.
Parameters
- detail
-
Displays detailed information about path error packets.
Platforms
All
pathtear
pathtear
Syntax
pathtear [detail]
no pathtear
Context
[Tree] (debug>router>rsvp>packet pathtear)
Full Context
debug router rsvp packet pathtear
Description
This command debugs path tear packets.
The no form of the command disables the debugging.
Parameters
- detail
-
Displays detailed information about path tear packets.
Platforms
All
pattern
pattern
Syntax
pattern pad-value
no pattern
Context
[Tree] (config>oam-pm>session>ip pattern)
Full Context
configure oam-pm session ip pattern
Description
This command configures the pattern value to be repeated in the padding portion of the TWAMP Light packet.
The no form of this command uses an incrementing byte pattern beginning with 00 and ending with FF, wrapping back to 00.
Default
pattern 0
Parameters
- pad-value
-
Specifies the specific pattern to use.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
pattern
Syntax
pattern pad-value
no pattern
Context
[Tree] (config>oam-pm>session>mpls pattern)
Full Context
configure oam-pm session mpls pattern
Description
This command configures the pattern value to be repeated in the padding portion of pad-tlv length field of the dm PDU.
The no form of this command uses an incrementing byte pattern beginning with 00 and ending with FF, wrapping back to 00.
Parameters
- pad-value
-
Specifies a two octet pattern to be repeated to fill the padding field of each echo request packet launched for each test belonging to the specified session. For example, if 255 is specified, the padding field is filled with the octet values 00, FF, 00, FF, ... (hexadecimal).
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
payload
payload
Syntax
payload {sts3 | tug3 | ds3 | e3 | vt2 | vt15 | ds1 | e1}
Context
[Tree] (config>port>sonet-sdh>path payload)
Full Context
configure port sonet-sdh path payload
Description
This command specifies if the associated SONET/SDH path is an asynchronous circuit or a virtual tributary group (VT). This command is only applicable to channelized MDAs.
This command is supported on TDM satellite, however the sts3, ds3, and e3 parameters are not supported.
Parameters
- sts3
-
Configures STS3/STM1 payload as clear channel.
- tu3
-
Configures STS3/STM1 payload as Tributary Unit Group 3 (TUG3).
- ds3
-
Configures the port or channel as DS-3 STS1/VC3 payload as DS-3.
- e3
-
Configures the port or channel as E-3 STS1/VC3 payload as E-3.
- vt2
-
Configures the path STS1 payload as vt2 as a virtual tributary group. Only allowed on STS-1 nodes (SONET VT container).
- vt15
-
Configures the path as a virtual tributary group. Only allowed on STS-1 nodes (SONET VT container).
- ds1
-
Configures the port or channel as DS1.vt15 or vt2 payload as DS-1.
- e1
-
Configures VT2 payload as E-1.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
pbb
pbb
pbb
Syntax
pbb
Context
[Tree] (debug>oam>build-packet>packet>field-override>header pbb)
[Tree] (config>test-oam>build-packet>header pbb)
Full Context
debug oam build-packet packet field-override header pbb
configure test-oam build-packet header pbb
Description
This command configures a test Provider Backbone Bridge (PBB) packet header to be launched by the OAM find-egress tool.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
pbb-etype
pbb-etype
Syntax
pbb-etype [ethertype-value]
no pbb-etype
Context
[Tree] (config>port>ethernet pbb-etype)
Full Context
configure port ethernet pbb-etype
Description
This command configures the Ethertype used for PBB encapsulation.
Default
no pbb-etype
Parameters
- ethertype-value
-
Specifies the Ethertype value in the form of 0x600 to 0xfff.
Platforms
All
pbb-etype
Syntax
pbb-etype type
no pbb-etype [type]
Context
[Tree] (config>service>sdp pbb-etype)
Full Context
configure service sdp pbb-etype
Description
This command configures the Ethertype used for PBB.
Default
no pbb-etype
Parameters
- type
-
Specifies the Ethertype.
Platforms
All
pbr-down-action-override
pbr-down-action-override
Syntax
pbr-down-action-override filter-action
no pbr-down-action-override
Context
[Tree] (config>filter>ipv6-filter>entry pbr-down-action-override)
[Tree] (config>filter>mac-filter>entry pbr-down-action-override)
[Tree] (config>filter>ip-filter>entry pbr-down-action-override)
Full Context
configure filter ipv6-filter entry pbr-down-action-override
configure filter mac-filter entry pbr-down-action-override
configure filter ip-filter entry pbr-down-action-override
Description
This command allows overriding the default action that is applied for entries with PBR/PBF action defined, when the PBR/PBF target is down.
The no form of the command preserves default behavior when PBR/PBF target is down.
Default
no pbr-down-action-override
Parameters
- filter-action
-
Specifies the packets matching the entry.
drop — Specifies that packets matching the entry will be dropped if PBR/PBF target is down.
forward — Specifies that packets matching the entry will be forwarded if PBR/PBF target is down.
filter-default-action — Specifies that packets matching the entry will be processed as per default-action configuration for this filter if PBR/PBF target is down.
Platforms
All
pcap
pcap
Syntax
pcap session-name [create]
no pcap session-name
Context
[Tree] (config>mirror>mirror-dest pcap)
Full Context
configure mirror mirror-dest pcap
Description
This command specifies a PCAP instance used for packet capture.
The no form of this command removes the PCAP instance and stops the packet capture and file transfer session.
Parameters
- session-name
-
Specifies the session name, up to 32 characters.
Platforms
All
pcap
Syntax
pcap session-name
Context
[Tree] (debug pcap)
Full Context
debug pcap
Description
This command specifies the session for the packet capture process.
Parameters
- session-name
-
Specifies the session name, up to 32 characters.
Platforms
All
pcc
pcc
Syntax
[no] pcc
Context
[Tree] (debug>router>mpls>event pcc)
Full Context
debug router mpls event pcc
Description
This command debugs pcc events.
The no form of the command disables the debugging.
Platforms
All
pcc
Syntax
pcc
Context
[Tree] (config>router>pcep pcc)
Full Context
configure router pcep pcc
Description
Commands in this context configure PCC parameters.
Platforms
All
pcc
Syntax
[no] pcc
Context
[Tree] (debug>router>pcep pcc)
Full Context
debug router pcep pcc
Description
This command enables debugging for the PCEP Path Computation Client (PCC).
The no form of this command disables PCEP PCC debugging.
Platforms
All
pce
pce
Syntax
pce
Context
[Tree] (config>router>pcep pce)
Full Context
configure router pcep pce
Description
Commands in this context configure PCE parameters.
Platforms
VSR-NRC
pce
Syntax
[no] pce
Context
[Tree] (debug>router>pcep pce)
Full Context
debug router pcep pce
Description
This command enables debugging for the PCEP Path Computation Element (PCE).
The no form of this command disables PCEP PCE debugging.
Platforms
VSR-NRC
pce-associations
pce-associations
Syntax
pce-associations
Context
[Tree] (config>router>pcep>pcc pce-associations)
Full Context
configure router pcep pcc pce-associations
Description
Commands in this context configure PCE association groups.
Platforms
All
pce-associations
Syntax
pce-associations
Context
[Tree] (config>router>mpls>lsp pce-associations)
[Tree] (config>router>mpls>lsp-template pce-associations)
Full Context
configure router mpls lsp pce-associations
configure router mpls lsp-template pce-associations
Description
Commands in this context configure LSP binding with one or more PCEP association groups.
Platforms
All
pce-control
pce-control
Syntax
[no] pce-control
Context
[Tree] (config>router>mpls>lsp-template pce-control)
[Tree] (config>router>mpls>lsp pce-control)
Full Context
configure router mpls lsp-template pce-control
configure router mpls lsp pce-control
Description
This command enables a PCE controlled LSP mode of operation. The pce-control option means the router delegates full control of the LSP to the PCE (PCE controlled). Enabling it means the PCE is acting in stateful-active mode for this LSP and the PCE will be able to reroute the path following a failure or re-optimize the path and update the router without a request from the router.
The user can delegate CSPF and non-CSPF LSPs, or LSPs that have the path-computation-method pce option enabled or disabled. The LSP maintains its latest active path computed by PCE or the router at the time it is delegated. The PCE only makes an update to the path at the next network event or reoptimization.
When configured to no, the PCE controlled mode of operation for the LSP has not effect.
Default
no pce-control
Platforms
All
pce-initiated-lsp
pce-initiated-lsp
Syntax
[no] pce-initiated-lsp
Context
[Tree] (config>router>mpls pce-initiated-lsp)
Full Context
configure router mpls pce-initiated-lsp
Description
This command creates a context to configure support for PCE-initiated LSPs.
The no form of this command removes PCE-initiated LSP support. All PCE-initiated LSPs are deleted.
Platforms
All
pce-report
pce-report
Syntax
pce-report rsvp-te {enable | disable}
pce-report sr-te {enable | disable}
Context
[Tree] (config>router>mpls pce-report)
Full Context
configure router mpls pce-report
Description
This command separately configures the reporting modes to a PCE for RSVP-TE or SR-TE LSPs. The PCC LSP database is synchronized with the PCE LSP database using the PCEP PCRpt (PCE Report) message for PCC-controlled, PCE-computed, and PCE-controlled LSPs.
The global MPLS level pce-report command can be used to enable or disable PCE reporting for all SR-TE LSPs or RSVP-TE LSPs during PCE LSP database synchronization. This configuration is inherited by all LSPs of the specified type. The PCC reports both CSPF and non-CSPF LSPs. The default value is disabled for both types of LSP. This default value is meant to control the introduction of the PCE into an existing network and to let the operator decide if all LSPs of a particular type need to be reported.
The LSP-level pce-report command overrides the global configuration for the reporting of LSPs to the PCE. The default value is to inherit the global MPLS level value. The enable or disable value allows for the override of the inherited value. The inherit value explicitly resets the LSP to inherit the global configuration for that LSP type.
If PCE reporting is disabled for the LSP, either due to inheritance or due to LSP-level configuration, then enabling the pce-control option for the LSP has no effect.
Default
pce-report rsvp-te disable
pce-report sr-te disable
Parameters
- rsvp-te
-
Specifies the PCE reporting mode for all TE LSPs of RSVP-TE type.
- sr-te
-
Specifies the PCE reporting mode for all TE LSPs of SR-TE type.
Platforms
All
pce-report
Syntax
pce-report {enable | disable | inherit}
Context
[Tree] (config>router>mpls>lsp pce-report)
[Tree] (config>router>mpls>lsp-template pce-report)
Full Context
configure router mpls lsp pce-report
configure router mpls lsp-template pce-report
Description
This command separately configures the reporting modes to a PCE for RSVP-TE or SR-TE LSPs.
The PCC LSP database is synchronized with the PCE LSP database using the PCEP PCRpt (PCE Report) message for PCC-controlled, PCE-computed and PCE-controlled LSPs.
The global MPLS-level pce-report command can be used to enable or disable PCE reporting for all SR-TE LSPs or RSVP-TE LSPs during PCE LSP database synchronization. This configuration is inherited by all LSPs of the specified type. The PCC reports both CSPF and non-CSPF LSPs. The default value is disabled for both types of LSP. This default value is meant to control the introduction of the PCE into an existing network and to let the operator decide if all LSPs of a particular type need to be reported.
The LSP-level pce-report command overrides the global configuration for the reporting of LSP to the PCE. The default value is to inherit the global MPLS level value. The enable or disable value allows for the override of the inherited value. The inherit value explicitly resets the LSP to inherit the global configuration for that LSP type.
If PCE reporting is disabled for the LSP, either due to inheritance or due to LSP-level configuration, then enabling the pce-control option for the LSP has no effect.
Default
pce-report inherit
Parameters
- enable
-
Enables PCE reporting.
- disable
-
Disables PCE reporting.
- inherit
-
Inherits the global configuration for PCE reporting.
Platforms
All
pcep
pcep
Syntax
[no] pcep
Context
[Tree] (config>router pcep)
Full Context
configure router pcep
Description
This command enables Path Computation Element communications Protocol (PCEP), and enters the context to configure PCEP parameters.
The no form of the command disables PCEP.
Platforms
All
pcep
Syntax
[no] pcep
Context
[Tree] (debug>router pcep)
Full Context
debug router pcep
Description
This command enables debugging for the Path Computation Element Protocol (PCEP).
The no form of this command disables PCEP debugging.
Platforms
All
pcm
pcm
Syntax
[no] pcm pcm-slot [chassis chassis-id]
Context
[Tree] (config>system>pwr-mgmt pcm)
Full Context
configure system power-management pcm
Description
This command sets the PCM slot number.
Parameters
- pcm-slot
-
Identifies the PCM slot.
- chassis-id
-
Specifies chassis ID for the router chassis.
Platforms
7950 XRS-20e
pcm-type
pcm-type
Syntax
[no] pcm-type {dual | quad}
Context
[Tree] (cfg>sys>pwr-mgmt>pcm pcm-type)
Full Context
configure system power-management pcm pcm-type
Description
This command sets the PCM type.
Parameters
- dual
-
Specifies the dual PCM type.
- quad
-
Specifies the quad PCM type.
Platforms
7950 XRS-20e
pcp
pcp
Syntax
pcp
Context
[Tree] (debug>router pcp)
Full Context
debug router pcp
Description
This command enables debugging for the PCP servers.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
pcp-server
pcp-server
Syntax
pcp-server
Context
[Tree] (config>router pcp-server)
Full Context
configure router pcp-server
Description
Commands in this context configure a Port Control Policy (PCP) server.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
pcp-server
Syntax
pcp-server name
Context
[Tree] (debug>router>pcp pcp-server)
Full Context
debug router pcp pcp-server
Description
This command enables debugging for the PCP servers.
Parameters
- name
-
Debugs the PCP server associated with the specified name, up to 32 characters.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
pcp-server-policy
pcp-server-policy
Syntax
pcp-server-policy name [create]
no pcp-server-policy name
Context
[Tree] (config>service>nat pcp-server-policy)
Full Context
configure service nat pcp-server-policy
Description
This command configures a PCP server policy name.
The no form of the command removes the name from the configuration.
Parameters
- name
-
Specifies a PCP server policy name up to 32 characters.
- create
-
Keyword used to create the PCP server policy.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
pcp-server-policy
Syntax
pcp-server-policy name
no pcp-server-policy
Context
[Tree] (config>router>pcp-server>server pcp-server-policy)
Full Context
configure router pcp-server server pcp-server-policy
Description
This command configures the PCP server policy.
The no form of this command reverts to the default value.
Default
no pcp-server-policy
Parameters
- name
-
Specifies the PCP server policy name, up to 32 characters.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
pcr-repetition
pcr-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>source-override>video>analyzer>alarms pcr-repetition)
[Tree] (config>mcast-mgmt>mcast-info-plcy>bundle>video>analyzer>alarms pcr-repetition)
[Tree] (config>mcast-mgmt>mcast-info-plcy>bundle>channel>video>analyzer>alarms pcr-repetition)
Full Context
configure mcast-management multicast-info-policy bundle channel source-override video analyzer alarms pcr-repetition
configure mcast-management multicast-info-policy bundle video analyzer alarms pcr-repetition
configure mcast-management multicast-info-policy bundle channel video analyzer alarms pcr-repetition
Description
This command configures the analyzer to check for the program clock reference (PCR). It is expected that the PCR arrives periodically within a certain interval range. It is possible to configure the type of alarm that is raised when the PCR fails to arrive within the specified interval. As the delay increases between two consecutive PCRs, the type of alarm raised becomes more critical, from TNC to POA.
Default
no pcr-repetition
Parameters
- tnc-milli-seconds
-
Specifies the time, in milliseconds, for which a TNC alarm is raised if the interval between two consecutive PCRs is greater than or equal to this configured value.
- qos-milli-seconds
-
Specifies the time, in milliseconds, for which a QoS alarm is raised if the interval between two consecutive PCRs is greater than or equal to this configured value.
- poa-milli-seconds
-
Specifies the time, in milliseconds, for which a POA alarm is raised if the interval between two consecutive PCRs is greater than or equal to this configured value.
Platforms
7450 ESS, 7750 SR, 7750 SR-s
pd-managed-route
pd-managed-route
Syntax
pd-managed-route [next-hop {ipv4 | ipv6}]
no pd-managed-route
Context
[Tree] (config>service>ies>sub-if>grp-if>ipv6>dhcp6 pd-managed-route)
[Tree] (config>service>vprn>sub-if>grp-if>ipv6>dhcp6 pd-managed-route)
[Tree] (config>service>ies>sub-if>ipv6>dhcp6 pd-managed-route)
[Tree] (config>service>vprn>sub-if>ipv6>dhcp6 pd-managed-route)
Full Context
configure service ies subscriber-interface group-interface ipv6 dhcp6 pd-managed-route
configure service vprn subscriber-interface group-interface ipv6 dhcp6 pd-managed-route
configure service ies subscriber-interface ipv6 dhcp6 pd-managed-route
configure service vprn subscriber-interface ipv6 dhcp6 pd-managed-route
Description
This command enables DHCP IA-PD (delegated prefix) to be modeled as managed (framed) route instead of as a subscriber-host. Antispoof filtering for the subscriber host associated with the IA-PD route must be set to nh-mac. The subscriber specific parameters (such as sla-profile or sub-profile) are ignored during the authentication phase because IA-PD is not modeled as a subscriber host. Other subscriber host-specific functions (for example, host overrides via CoA or host accounting) are not possible with a PD as the managed route.
By default, or when configured with the next-hop ipv6 parameter, the next-hop for PD managed route is an IPv6 WAN sub-host (DHCP IA-NA or SLAAC) with the same mac address as the one in the DHCP lease state for the managed IA-PD. The DHCP IA-NA next-hop host will always override the SLAAC next-hop host if both are available. If the IPv6 next-hop is not present when the framed IA-PD is instantiated, the IA-PD is set up but the PD managed route will not be installed in the IPv6 route table and the DHCPv6 lease state for the IA-PD will have the managed route status (DHCP6 MRt Status) set to "noNextHop”.
When configured with the next-hop ipv4 parameter the next-hop for PD managed route is a DHCPv4 sub-host that belongs to the same IPoE session or PPPoE session. For IPoE, ipoe-session must be enabled on the group-interface. If ipoe-session is disabled, an IPv4 next-hop will not be found. If the IPv4 next-hop is not found or not present at the time when the framed IA-PD is instantiated, the IA-PD is set up but the PD managed route is not installed in the IPv6 route table. In this case, the DHCPv6 lease state for the IA-PD will have the managed route status (DHCP6 MRt Status) set to noNextHop.
IPv6 filters, QoS IPv6 criteria, and IPv6 multicast are not supported for DHCPv6 IA-PD as managed route pointing to an IPv4 subscriber host as next-hop.
The DHCP IA-PD modeled as a route is displayed differently than regular subscriber hosts in show commands related to subscriber host state. The PD managed route is always shown directly below the host it is using as the next hop. The forwarding status of the PD managed route is also shown, where (N) indicate that the PD managed route is not forwarding. In addition, DHCP IA-PD route is displayed as a managed route for the corresponding IPv6 subscriber host (DHCP IA-NA or SLAAC) or DHCPv4 subscriber host.
DHCP IA-PD information for managed IA-PD route is still maintained in the DHCPv6 lease state.
The no form of this command reverts to the default.
Parameters
- next-hop
-
Specifies the next-hop type for the DHCP IA-PD managed route
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
pdn-connection-id
pdn-connection-id
Syntax
[no] pdn-connection-id
Context
[Tree] (config>subscr-mgmt>diam-appl-plcy>gx>include-avp pdn-connection-id)
Full Context
configure subscriber-mgmt diameter-application-policy gx include-avp pdn-connection-id
Description
This command enables the inclusion of the PDN-Connection-Id AVP, which contains the APN as signaled in the incoming GTP setup message.
The no form of this command disables the inclusion of the AVP.
Platforms
7750 SR, 7750 SR-e, 7750 SR-s, VSR
pdn-type
pdn-type
Syntax
pdn-type {ipv4 | ipv6 | ipv4v6}
no pdn-type
Context
[Tree] (config>router>gtp>uplink pdn-type)
[Tree] (config>service>vprn>gtp>uplink pdn-type)
Full Context
configure router gtp uplink pdn-type
configure service vprn gtp uplink pdn-type
Description
This command configures the PDP type to be signaled in GTP, determining which addresses are requested from the P-GW/GGSN and which hosts are set up afterwards. This can be overridden by RADIUS. If the ipv4v6 keyword is used, the P-GW/GGSN can fall back to either IPv4 or IPv6.
The no form of this command reverts to the default configuration.
Default
pdn-type ipv4
Parameters
- ipv4
-
Specifies the GTP connection requests an IPv4 address.
- ipv6
-
Specifies the GTP connection requests an IPv6 address.
- ipv4v6
-
Specifies the GTP connection requests both an IPv4 and an IPv6 address.
Platforms
7750 SR, 7750 SR-e, 7750 SR-s, VSR
pdp-context-type
pdp-context-type
Syntax
[no] pdp-context-type
Context
[Tree] (config>subscr-mgmt>diam-appl-plcy>gy>avp pdp-context-type)
Full Context
configure subscriber-mgmt diameter-application-policy gy include-avp pdp-context-type
Description
This command includes the [3GPP-1247] PDP-Context-Type AVP in Diameter DCCA CCR-Initial messages.
The no form of this command removes the PDP-Context-Type AVP from the Diameter DCCA CCR-Initial messages.
Default
pdp-context-type
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
pe-id-mac-flush-interop
pe-id-mac-flush-interop
Syntax
[no] pe-id-mac-flush-interop
Context
[Tree] (config>router>ldp>session-params>peer pe-id-mac-flush-interop)
Full Context
configure router ldp session-parameters peer pe-id-mac-flush-interop
Description
This command enables the addition of the PE-ID TLV in the LDP MAC withdrawal (mac-flush) message, under certain conditions, and modifies the mac-flush behavior for interoperability with other vendors that do not support the flush-all-from-me vendor-specific TLV. This flag can be enabled on a per LDP peer basis and allows the flush-all-from-me interoperability with other vendors. When the pe-id-mac-flush-interop flag is enabled for a given peer, the current mac-flush behavior is modified in terms of mac-flush generation, mac-flush propagation and behavior upon receiving a mac-flush.
The mac-flush generation will be changed depending on the type of event and according to the following rules:
-
Any all-from-me mac-flush event will trigger a mac-flush all-but-mine message (RFC 4762 compliant format) with the addition of a PE-ID TLV. The PE-ID TLV contains the IP address of the sending PE.
-
Any all-but-mine mac-flush event will trigger a mac-flush all-but-mine message WITHOUT the addition of the PE-ID TLV, as long as the source spoke SDP is not part of an end-point.
-
Any all-but-mine mac-flush event will trigger a mac-flush all-but-mine message WITH the addition of the PE-ID TLV, if the source spoke SDP is part of an end-point and the spoke-sdp goes from down/standby state to active state. In this case, the PE-ID TLV will contain the IP address of the PE to which the previous active spoke-sdp was connected to.
Any other case will follow the existing mac-flush procedures.
When the pe-id-mac-flush-interop flag is enabled for a given LDP peer, the mac-flush ingress processing is modified according to the following rules:
-
Any received all-from-me mac-flush will follow the existing mac-flush all-from-me rules regardless of the existence of the PE-ID.
-
Any received all-but-mine mac-flush will take into account the received PE-ID, that is all the mac addresses associated to the PE-ID will be flushed. If the PE-ID is not included, the mac addresses associated to the sending PE will be flushed.
-
Any other case will follow the existing mac-flush procedures.
When a mac-flush message has to be propagated (for an ingress sdp-binding to an egress sdp-binding) and the pe-id-mac-flush-interop flag is enabled for the ingress and egress TLDP peers, the following behavior is observed:
-
If the ingress and egress bindings are spoke SDP, the PE will propagate the mac-flush message with its own PE-ID.
-
If the ingress binding is an spoke SDP and the egress binding a mesh SDP, the PE will propagate the mac-flush message without modifying the PE-ID included in the PE-ID TLV.
-
If the ingress binding is a mesh SDP and the egress binding an spoke SDP, the PE will propagate the mac-flush message with its own PE-ID.
-
When ingress and egress bindings are mesh-sdp, the mac-flush message is never propagated. This is the behavior regardless of the pe-id-mac-flush-interop flag configuration.
The PE-ID TLV is never added when generating a mac-flush message on a B-VPLS if the send-bvpls-flush command is enabled in the I-VPLS. In the same way, no PE-ID is added when propagating mac-flush from a B-VPLS to a I-VPLS when the propagate-mac-flush-from-bvpls command is enabled. Mac-flush messages for peers within the same I-VPLS or within the same B-VPLS domain follow the procedures described above.
Default
no pe-id-mac-flush-interop
Platforms
All
peak-rate
peak-rate
Syntax
peak-rate rate
no peak-rate
Context
[Tree] (config>router>policy-acct-template>policer peak-rate)
Full Context
configure router policy-acct-template policer peak-rate
Description
This command sets the peak rate (the fill or drain rate of the bucket).
Each policer has a peak information rate and a maximum burst size. The default peak-rate (when no value is configured or the configured value is max) is the line rate of the ingress port.
The no form of this command reverts to the default value.
Default
peak-rate max
Parameters
- rate
-
Specifies the peak rate in Kb/s
Platforms
7450 ESS, 7750 SR, 7750 SR-s, 7950 XRS
peer
peer
Syntax
peer ip-address tag sync-tag
no peer
Context
[Tree] (config>service>vprn>dhcp>server>pool peer)
[Tree] (config>router>dhcp6>server>pool>failover peer)
[Tree] (config>service>vprn>dhcp>server peer)
[Tree] (config>router>dhcp>server>failover peer)
[Tree] (config>service>vprn>dhcp6>server peer)
[Tree] (config>router>dhcp>server>pool>failover peer)
[Tree] (config>router>dhcp6>server>failover peer)
[Tree] (config>service>vprn>dhcp6>server>pool peer)
Full Context
configure service vprn dhcp server pool peer
configure router dhcp6 server pool failover peer
configure service vprn dhcp server peer
configure router dhcp local-dhcp-server failover peer
configure service vprn dhcp6 server peer
configure router dhcp server pool failover peer
configure router dhcp6 local-dhcp-server failover peer
configure service vprn dhcp6 server pool peer
Description
This command creates a sync tag. DHCP leases can be synchronized per DHCP server or DHCP pool. The pair of synchronizing servers or pools is identified by a tag. The synchronization information is carried over the Multi-Chassis Synchronization (MCS) link between the two peers. MCS link is a logical link (IP, or MPLS).
MCS runs over TCP, port 45067 and it is using either data traffic or keepalives to detect failure on the communication link between the two nodes. In the absence of any MCS data traffic for more than 0.5sec, MCS will send its own keepalive to the peer. If a reply is not received within three sec, MCS will declare its operation state as DOWN and the DB Sync state as out-of-sync. MCS will consequently notify its clients (DHCP Server being one of them) of this. It can take up to three seconds before the DHCP client realizes that the inter-chassis communication link has failed.
The inter-chassis communication link failure does not necessarily assume the same failed fate for the access links. The two redundant nodes can become isolated from each other in the network. This occurs when only the intercommunication (MCS) link fails. It is important that this MCS link be highly redundant.
The no form of this command reverts to the default.
Parameters
- ip-address
-
Specifies the IPv4 or IPv6 address of the peer.
- tag sync-tag
-
Specifies a tag, up to 32 characters, that identifies the synchronizing DHCP servers or pools.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
peer
Syntax
[no] peer router router-instance address ip-address [udp-port port]
Context
[Tree] (debug>gtp peer)
Full Context
debug gtp peer
Description
This command restricts debugging to only data related to the specified GTP peer. This command can be repeated multiple times, where only data for any of the specified peers is debugged.
The no form of this command removes the restriction for the specified peer. When the last peer filter is removed, all data is debugged again, but may be restricted by other filters.
Parameters
- router-instance
-
Specifies the ID of the VRF where the peer is connected.
- ip-address
-
Specifies the IP address of the peer.
- port
-
Specifies the GTP-C port used by the peer.
Platforms
7750 SR, 7750 SR-e, 7750 SR-s, VSR
peer
Syntax
peer ip-address
no peer
Context
[Tree] (config>service>vprn>l2tp>group>tunnel peer)
[Tree] (config>router>l2tp>group>tunnel peer)
Full Context
configure service vprn l2tp group tunnel peer
configure router l2tp group tunnel peer
Description
This command configures the peer address.
The no form of this command removes the IP address from the tunnel configuration.
Default
no peer
Parameters
- ip-address
-
Sets the LNS IP address for the tunnel.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
peer
Syntax
peer ip-address [udp-port port] [ip]
Context
[Tree] (debug>router>l2tp peer)
Full Context
debug router l2tp peer
Description
This command enables and configures debugging for an L2TP peer.
Parameters
- ip-address
-
Specifies the IP address of the L2TP peer.
- port
-
Specifies the UDP port for the L2TP peer. This parameter is only supported with L2TPv2 peers.
- ip
-
Displays debugging information for peers using IP transport.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
peer
Syntax
peer index index [destination-host-string ][create]
no peer index index
Context
[Tree] (config>aaa>diam>node peer)
Full Context
configure aaa diameter node peer
Description
This command creates context for diameter peer configuration within a Diameter client node in SR OS. Up to five Diameter peers can be configured within a given Diameter client node.
This command is not applicable to legacy Diameter base.
The no form of this command removes the peer index information from the configuration.
Parameters
- index
-
Specifies the index of a peer. Index is used to break a tie if a Diameter route for a given host or realm destination points to multiple diameter peers with the same preference. In such scenario, the peer with the lowest index will be selected as next-hop in traffic forwarding.
- destination-host-string
-
Identifies the peer by its name, up to 80 characters (of type DiameterIdentity). This peer name must match the one in Origin-Host AVP received in Capability Exchange Answer message. In case of a mismatch, the TCP connection will be terminated.
- create
-
Keyword used to create the peer index. 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
peer
Syntax
peer ip-address [create]
no peer ip-address
Context
[Tree] (config>redundancy>multi-chassis peer)
Full Context
configure redundancy multi-chassis peer
Description
This command configures the IP address of the peer in a redundant multi-chassis setup, and enters the context for further, application-specific configuration options.
Parameters
- ip-address
-
Specifies a peer IP address. Multicast addresses are not allowed.
Platforms
All
peer
Syntax
[no] peer destination-host
Context
[Tree] (debug>diameter>node peer)
Full Context
debug diameter node peer
Description
This command debugs Diameter node peers. At this level, the forwarding/routing phase is completed and the peer is known. All messages flowing between this node and the peer are reported. Although the messages displayed can contain session-ids, this debugging level is session unaware (the session states are not maintained at this level).
Parameters
- destination-host
-
Specifies the host name, up to 80 characters.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
peer
Syntax
peer ip-address ip-address
no peer
Context
[Tree] (config>subscr-mgmt>pfcp-association peer)
Full Context
configure subscriber-mgmt pfcp-association peer
Description
This command configures PFCP peer IP address.
The no form of this command removes the PFCP IP address.
Default
no peer
Parameters
- ip-address
-
Specifies the PFCP peer IP address.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
peer
Syntax
peer ip-address [create]
no peer ip-address
Context
[Tree] (config>service>vprn>ptp peer)
Full Context
configure service vprn ptp peer
Description
This command configures a remote PTP peer and provides the context to configure parameters for this peer.
Up to 20 remote PTP peers may be configured.
If the clock-type is ordinary slave or boundary, and PTP is not shutdown, the last peer cannot be deleted. This prevents the case where the user has PTP enabled without any peer configured and enabled.
Peers are created within the routing instance associated with the context of this command. All configured PTP peers must use the same routing instance.
The no form of this command deletes the specified peer.
Parameters
- ip-address
-
Specifies the IP address of the remote peer.
- create
-
Keyword used to create the peer.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
peer
Syntax
peer ip-address [create]
no peer ip-address
Context
[Tree] (config>system>ptp peer)
Full Context
configure system ptp peer
Description
This command configures a remote PTP peer. It provides the context to configure parameters for the remote PTP peer.
Up to 20 remote PTP peers may be configured.
If the clock-type is ordinary slave or boundary, and PTP is not shutdown, the last peer cannot be deleted. This prevents the user from having PTP enabled without any peer configured and enabled.
Peers are created within the routing instance associated with the context of this command. All configured PTP peers must use the same routing instance.
The no form of the command deletes the specified peer. The specific address being deleted must be included.
Parameters
- ip-address
-
Specifies the IP address of the remote peer.
- create
-
Creates the remote PTP peer.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
peer
Syntax
[no] peer peer-address
Context
[Tree] (config>service>vprn>msdp peer)
[Tree] (config>service>vprn>msdp>group peer)
Full Context
configure service vprn msdp peer
configure service vprn msdp group peer
Description
This command configures peer parameters. Multicast Source Discovery Protocol (MSDP) must have at least one peer configured. A peer is defined by configuring a local-address that can be used by this node to set up a peering session and the address of a remote MSDP router, It is the address of this remote peer that is configured in this command and it identifies the remote MSDP router address.
After peer relationships are established, the MSDP peers exchange messages to advertise active multicast sources. It may be required to have multiple peering sessions in which case multiple peer statements should be included in the configurations.
By default, the options applied to a peer are inherited from the global or group-level. To override these inherited options, include peer-specific options within the peer statement.
If the peer address provided is already a configured peer, then this command only provides the context to configure the parameters pertaining to this peer.
If the peer address provided is not already a configured peer, then the peer instance must be created and the context to configure the parameters pertaining to this peer should be provided. In this case, the $ prompt to indicate that a new entity (peer) is being created should be used.
The peer address provided will be validated and, if valid, will be used as the remote address for an MSDP peering session.
When the no form of this command is entered, the existing peering address will be removed from the configuration and the existing session will be terminated. Whenever a session is terminated, all source active information pertaining to and learned from that peer will be removed. Whenever a new peering session is created or a peering session is lost, an event message should be generated.
At least one peer must be configured for MSDP to function.
Parameters
- peer-address
-
The address configured in this statement must identify the remote MSDP router that the peering session must be established with.
Platforms
All
peer
Syntax
peer ipv4-address
no peer
Context
[Tree] (config>service>vprn>nat>inside>redundancy peer)
[Tree] (config>router>nat>inside>redundancy peer)
Full Context
configure service vprn nat inside redundancy peer
configure router nat inside redundancy peer
Description
This command is used in LSN44 multi-chassis redundancy in conjunction with filters. The configured peer address is an IPv4 address that is configured under an interface on the peering LSN44 node (active or standby). This IPv4 interface address is advertised via routing on the inside in order to attract traffic from the standby to the active LSN44 node.
If configured, the steering-route is advertised only from the active LSN44 node. Consequently, upstream traffic for LSN44 is attracted to the active LSN44 node. The nat action in the ipv4-filter on the active LSN44 node forwards traffic to the local MS-ISA where LSN44 function is performed. However, in that case that upstream traffic somehow arrives on the standby LSN44 node, the nat action in the IPv4-filter forwards traffic to the peer address (active LSN44 node).
The no form of the command removes the peer ipv4-address from the configuration.
Parameters
- ipv4-address
-
Specifies the IP address of the NAT redundancy peer.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
peer
Syntax
[no] peer ip-address
Context
[Tree] (config>router>ldp>session-parameters peer)
Full Context
configure router ldp session-parameters peer
Description
This command configures parameters for an LDP peer.
Parameters
- ip-address
-
Specifies the IPv4 or IPv6 address of the LDP peer in dotted decimal notation.
Platforms
All
peer
Syntax
[no] peer ip-address
Context
[Tree] (config>router>ldp>targeted-session peer)
Full Context
configure router ldp targeted-session peer
Description
This command configures parameters for an LDP peer.
The no form of this command removes the LDP peer parameters.
Parameters
- ip-address
-
Specifies a peer IP address.
Platforms
All
peer
Syntax
[no] peer ip-address
Context
[Tree] (debug>router>ldp peer)
Full Context
debug router ldp peer
Description
Use this command for debugging an LDP peer.
Parameters
- ip-address
-
The IP address of the LDP peer.
Platforms
All
peer
Syntax
peer ip-address [preference preference]
no peer ip-address
Context
[Tree] (config>router>pcep>pcc peer)
Full Context
configure router pcep pcc peer
Description
This command configures the IP address of a peer PCEP speaker. The address is used as the destination address in the PCEP session messages to a PCEP peer.
The preference parameter allows the PCC to select the preferred PCE when both have their PCEP sessions successfully established. A maximum of two PCEP peers is supported.
The PCE peer that is not in overload is always selected by the PCC as the active PCE. However, if neither of the PCEs are signaling the overload state, the PCE with the higher numerical preference value is selected, and in case of a tie, the PCE with the lower IP address is selected.
The system does not support two or more simultaneously active PCEs.
The no form of the command removes the specified peer PCEP speaker.
Parameters
- ip-address
-
The IP address of the PCEP peer to be used as the destination address in the PCEP session.
- preference
-
The preference value of the peer.
Platforms
All
peer
Syntax
peer ip-address
no peer
Context
[Tree] (config>app-assure>aarp peer)
Full Context
configure application-assurance aarp peer
Description
This command defines the IP address of the peer router which must be a routable system IP address.
If no peer is configured and the AARP is no shutdown, it is configured as a single node AARP instance.
The no form of this command removes the IP address from the AARP instance.
Default
no peer
Parameters
- ip-address
-
Specifies the IP address in the a.b.c.d format.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
peer
Syntax
[no] peer ip-address
Context
[Tree] (config>router>msdp>group peer)
[Tree] (config>router>msdp peer)
Full Context
configure router msdp group peer
configure router msdp peer
Description
This command configures an MSDP peer. For MSDP to function, at least one peer with a local address must be configured.
After peer relationships are established, the MSDP peers exchange messages to advertise active multicast sources. Multiple peers can be individually configured if multiple peering sessions are required.
By default, the options applied to a peer are inherited from the global or group level. To override these inherited options, configure the peer-specific options within the peer context.
The specified peer address is validated and, if valid, used as the remote address for an MSDP peering session.
When a session is terminated, all source active information pertaining to and learned from that peer is removed. When a new peering session is created or a peering session is lost, an event message is generated.
The no form of this command removes the peer address from the configuration and terminates the existing session.
Parameters
- ip-address
-
Specifies the peer IP address of the remote MSDP router for the peering session.
Platforms
All
peer
Syntax
peer lic-name
no peer
Context
[Tree] (config>li>x-interfaces>x1 peer)
Full Context
configure li x-interfaces x1 peer
Description
This command configures the LIC name for X1 interface communication, which is configured under config> li>x-interfaces>lics>lic.
The no form of this command reverts to the default.
Parameters
- lic-name
-
Specifies the LIC name, up to 32 characters.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
peer
Syntax
peer lic-name
no peer
Context
[Tree] (config>li>x-interfaces>x2 peer)
Full Context
configure li x-interfaces x2 peer
Description
This command configures the LIC name for X2 interface communication, which is configured under config> li>x-interfaces>lics>lic.
The no form of this command reverts to the default.
Parameters
- lic-name
-
Specifies the LIC name, up to 32 characters.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
peer
Syntax
[no] peer lic-name
Context
[Tree] (config>li>x-interfaces>x3>peers peer)
Full Context
configure li x-interfaces x3 peers peer
Description
This command configures the LIC name for X3 interface communication, which is configured under config> li>x-interfaces>lics>lic.
The no form of this command removes the LIC name.
Parameters
- lic-name
-
Specifies the name for the LIC peer, up to 32 characters.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
peer
Syntax
[no] peer {ip-address | ipv6-address}
Context
[Tree] (config>router>bfd>seamless-bfd peer)
Full Context
configure router bfd seamless-bfd peer
Description
This command specifies the context for the local mapping, used by an S-BFD initiator, between a discriminator for a far-end S-BFD reflector and its discriminator value.
The no form of this command removes the mapping for the peer.
Parameters
- ip-address
-
Specifies the IPv4 address of the peer.
- ipv6-address
-
Specifies the IPv6 address of the peer.
Platforms
All
peer
Syntax
peer [router router-instance | service-name service-name] {ip-address | ipv6-address} [key-id key-id | authentication-keychain keychain-name] [version version] [ prefer]
no peer [router router-instance | service-name service-name] {ip-address | ipv6-address}
Context
[Tree] (config>system>time>ntp peer)
Full Context
configure system time ntp peer
Description
This command configures symmetric active mode for an NTP peer. It is recommended to configure authentication and to only configure known time servers as peers. Peers may exist within a VPRN service.
For symmetric peering to operate correctly with a peer accessible through a VPRN, local NTP server functionality must be enabled within the VPRN using the configure service vprn ntp command.
The no form of the command removes the configured peer.
Parameters
- router-instance
-
Specifies the routing context that contains the interface.
- service name
-
Specifies the service name for the VPRN, up to 64 characters. CPM routing instances are not supported.
- ip-address
-
Configures the IPv4 address of the peer that requires a peering relationship to be set up.
- ipv6-address
-
Configures the IPv6 address of the peer that requires a peering relationship to be set up.
- key-id
-
Specifies the key ID. Successful authentication requires that both peers must have the same authentication key-id, type, and key value.
Specify the key-id that identifies the configured authentication key and authentication type used by this node to transmit NTP packets to an NTP peer. If an NTP packet is received by these nodes, the authentication key-id, type, and key value must be valid, otherwise the packet is rejected and an event or trap is generated.
- keychain-name
-
Identifies the keychain name, up to 32 characters.
- version
-
Specifies the NTP version number that is generated by this node. This parameter does not need to be configured when in client mode, in which case all versions are accepted.
- prefer
-
When configuring more than one peer, one remote system can be configured as the preferred peer. When a second peer is configured as preferred, the new entry overrides the old entry.
Platforms
All
peer
Syntax
peer ip-address [create]
no peer ip-address
Context
[Tree] (config>service>vprn>ipsec>mc-shunt-profile peer)
[Tree] (config>router>ipsec>mc-shunt-profile peer)
Full Context
configure service vprn ipsec multi-chassis-shunting-profile peer
configure router ipsec multi-chassis-shunting-profile peer
Description
Commands in this context configure a multi-chassis IPsec peer IP address for the multi-chassis-shunting-profile.
The no form of this command removes the peer IP address from the configuration.
Default
no command
Parameters
- ip-address
-
Specifies a peer IP address.
- create
-
Keyword used to create the command instance.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
peer
Syntax
peer ip-address [create]
no peer ip-address
Context
[Tree] (config>anysec>tnl-enc>enc-grp peer)
Full Context
configure anysec tunnel-encryption encryption-group peer
Description
This command configures the IPv4 or IPv6 address of the peer's node SID that are part of this encryption group.
This configuration identifies the peer's segment routing node SID and programs the egress label stack for matching on the FP5 for encrypting the LSP.
The no form of this command removes the peer node SID from the ANYsec configuration. Therefore, the LSP is not encrypted and all the traffic is transmitted in clear text.
Parameters
- ip-address
-
Specifies a peer IP address.
- create
-
Keyword used to create the peer.
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
peer
Syntax
peer ip-address [detail]
Context
[Tree] (debug>anysec peer)
Full Context
debug anysec peer
Description
This command debugs ANYsec peers.
Parameters
- ip-address
-
Specifies a peer IP address.
- detail
-
Keyword used to specify detailed information.
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
peer-address-change-policy
peer-address-change-policy
Syntax
peer-address-change-policy {accept | ignore | reject}
Context
[Tree] (config>router>l2tp peer-address-change-policy)
[Tree] (config>service>vprn>l2tp peer-address-change-policy)
Full Context
configure router l2tp peer-address-change-policy
configure service vprn l2tp peer-address-change-policy
Description
This command specifies what to do in case the system receives a L2TP response from another address than the one the request was sent to.
Default
peer-address-change-policy reject
Parameters
- accept
-
Specifies that this system accepts any source IP address change of received L2TP control messages related to a locally originated tunnel in the state waitReply and rejects any peer address change for other tunnels; in case the new peer IP address is accepted, it is learned and used as destination address in subsequent L2TP messages.
- ignore
-
Specifies that this system ignores any source IP address change of received L2TP control messages, does not learn any new peer IP address, and does not change the destination address in subsequent L2TP messages.
- reject
-
Specifies that this system rejects any source IP address change of received L2TP control messages and drops those messages.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
peer-as
peer-as
Syntax
peer-as as-number
no peer-as
Context
[Tree] (config>subscr-mgmt>bgp-prng-plcy peer-as)
Full Context
configure subscriber-mgmt bgp-peering-policy peer-as
Description
This command configures the autonomous system number for the remote peer. The peer AS number must be configured for each configured peer.
The no form of this command removes the as-number from the configuration.
Parameters
- as-number
-
Specifies the AS number for the remote peer.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
peer-as
Syntax
peer-as as-number
Context
[Tree] (config>service>vprn>bgp>group peer-as)
[Tree] (config>service>vprn>bgp>group>neighbor peer-as)
Full Context
configure service vprn bgp group peer-as
configure service vprn bgp group neighbor peer-as
Description
This command configures the autonomous system number for the remote peer. The peer AS number must be configured for each configured peer.
For EBGP peers, the peer AS number configured must be different from the autonomous system number configured for this router under the global level since the peer will be in a different autonomous system than this router
For IBGP peers, the peer AS number must be the same as the autonomous system number of this router configured under the global level.
This is a required command for each configured peer. This may be configured under the group level for all neighbors in a particular group.
Default
No AS numbers are defined.
Parameters
- as-number
-
The autonomous system number, expressed as a decimal integer.
Platforms
All
peer-as
Syntax
peer-as as-number
Context
[Tree] (config>router>bgp>group peer-as)
[Tree] (config>router>bgp>group>neighbor peer-as)
Full Context
configure router bgp group peer-as
configure router bgp group neighbor peer-as
Description
This command configures the autonomous system number for the remote peer. The peer AS number must be configured for each configured peer.
For EBGP peers, the peer AS number configured must be different from the autonomous system number configured for this router under the global level since the peer will be in a different autonomous system than this router.
For IBGP peers, the peer AS number must be the same as the autonomous system number of this router configured under the global level.
This is required command for each configured peer. This may be configured under the group level for all neighbors in a particular group.
Parameters
- as-number
-
Specifies the autonomous system number expressed as a decimal integer.
Platforms
All
peer-endpoint
peer-endpoint
Syntax
peer-endpoint sap sap-id encap-type {dot1q | null | qinq}
peer-endpoint spoke-sdp sdp-id:vc-id
no peer-endpoint
Context
[Tree] (config>app-assure>aarp peer-endpoint)
Full Context
configure application-assurance aarp peer-endpoint
Description
This command defines the peer endpoint ID of the SAP or spoke-SDP parent-aa-sub of the AARP peer.
The no form of this command removes the peer endpoint from the AARP instance.
Default
no peer-endpoint
Parameters
- sap-id
-
Specifies the physical port identifier portion of the SAP definition.
- sdp-id:vc-id
-
Specifies the spoke SDP ID and VC ID.
- dot1q | null | qinq
-
Specifies the encapsulation type.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
peer-group
peer-group
Syntax
peer-group tunnel-group-id
no peer-group
Context
[Tree] (config>redundancy>multi-chassis>peer>mc-ipsec>tunnel-group peer-group)
Full Context
configure redundancy multi-chassis peer mc-ipsec tunnel-group peer-group
Description
This command specifies the corresponding tunnel-group ID on peer node. The peer tunnel-group ID does not necessary equals to local tunnel-group ID.
The no form of this command removes the tunnel-group ID from the configuration.
Parameters
- tunnel-group-id
-
Specifies the tunnel-group identifier.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
peer-ip-prefix
peer-ip-prefix
Syntax
peer-ip-prefix ip-prefix/ip-prefix-length
peer-ip-prefix ipv4-any
peer-ip-prefix ipv6-any
no peer-ip-prefix
Context
[Tree] (config>ipsec>client-db>client>client-id peer-ip-prefix)
Full Context
configure ipsec client-db client client-identification peer-ip-prefix
Description
This command specifies match criteria that uses the peer’s tunnel IP address as the input. Only one peer-ip-prefix criteria can be configured for a given client entry.
The no form of this command reverts to the default.
Default
no peer-ip-prefix
Parameters
- ip-prefix/ip-prefix-length
-
Specifies an IPv4 or IPv6 prefix. It is considered a match if the peer’s tunnel IP address is within the specified prefix.
- ipv4-any
-
Matches any IPv4 address.
- ipv6-any
-
Matches any IPv6 address.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
peer-ip-prefix
Syntax
[no] peer-ip-prefix
Context
[Tree] (config>ipsec>client-db>match-list peer-ip-prefix)
Full Context
configure ipsec client-db match-list peer-ip-prefix
Description
This command enables the use of the peer’s tunnel IP address as the match input.
The no form of this command disables the peer IP prefix matching process.
Default
no peer-ip-prefix
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
peer-limit
peer-limit
Syntax
peer-limit limit
no peer-limit
Context
[Tree] (config>service>vprn>ptp peer-limit)
Full Context
configure service vprn ptp peer-limit
Description
This command specifies an upper limit to the number of discovered peers permitted within the routing instance. This command can ensure that a routing instance does not consume all the possible discovered peers and blocking discovered peers in other routing instances.
If it is desired to reserve a fixed number of discovered peers per router instance, then all router instances supporting PTP should have values specified with this command and the sum of all the peer-limit values must not exceed the maximum number of discovered peers supported by the system.
If the user attempts to specify a peer-limit, and there are already more discovered peers in the routing instance than the new limit being specified, the configuration is not accepted.
The no form of this command removes the limit from the configuration.
Default
no limit
Parameters
- limit
-
Specifies the maximum number of discovered peers allowed in the routing instance.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
peer-limit
Syntax
peer-limit limit
no peer-limit
Context
[Tree] (config>system>ptp peer-limit)
Full Context
configure system ptp peer-limit
Description
This command specifies an upper limit to the number of discovered peers permitted within the routing instance. This can be used to ensure that a routing instance does not consume all the possible discovered peers and blocking discovered peers in other routing instances.
If it is desired to reserve a fixed number of discovered peers per router instance, then all router instances supporting PTP should have values specified with this command and the sum of all the peer-limit values must not exceed the maximum number of discovered peers supported by the system.
If the user attempts to specify a peer-limit, and there are already more discovered peers in the routing instance than the new limit being specified, the configuration will not be accepted.
Default
no peer-limit
Parameters
- limit
-
Specifies the maximum number of discovered peers allowed in the routing instance.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
peer-name
peer-name
Syntax
peer-name name
no peer-name
Context
[Tree] (config>redundancy>multi-chassis>peer peer-name)
Full Context
configure redundancy multi-chassis peer peer-name
Description
This command specifies a peer name.
Default
no peer-name
Parameters
- name
-
Specifies the string up to 32 characters. Any printable, seven-bit ASCII characters can be used within the string. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.
Platforms
All
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>router>gtp>s11 peer-profile-map)
[Tree] (config>service>vprn>gtp>uplink peer-profile-map)
[Tree] (config>service>vprn>gtp>s11 peer-profile-map)
Full Context
configure router gtp uplink peer-profile-map
configure router gtp s11 peer-profile-map
configure service vprn gtp uplink peer-profile-map
configure service vprn gtp s11 peer-profile-map
Description
This command configures a mapping of addresses and subnets to GTP peer profiles.
Platforms
7750 SR, 7750 SR-e, 7750 SR-s, VSR
peer-rdi-rx
peer-rdi-rx
Syntax
peer-rdi-rx
Context
[Tree] (config>port>ethernet>efm-oam peer-rdi-rx)
Full Context
configure port ethernet efm-oam peer-rdi-rx
Description
This container allows an action to be configured for the various event conditions that can be received from a peer under the context of the EFM OAM protocol.
Platforms
All
peer-template
peer-template
Syntax
[no] peer-template template-name
Context
[Tree] (config>router>ldp>targeted-session peer-template)
Full Context
configure router ldp targeted-session peer-template
Description
This command creates a targeted session peer parameter template that can be referenced in the automatic creation of targeted Hello adjacency and LDP session to a discovered peer.
The no form of this command deletes the peer template. A peer template cannot be deleted if it is bound to a peer prefix list.
Parameters
- template-name
-
Specifies the template name to identify targeted peer template. It must be 32 characters maximum.
Platforms
All
peer-template-map
peer-template-map
Syntax
peer-template-map template-name policy peer-prefix-policy1 [peer-prefix-policy2..up to 5]
no peer-template-map peer-template template-name
Context
[Tree] (config>router>ldp>targeted-session peer-template-map)
Full Context
configure router ldp targeted-session peer-template-map
Description
This command enables the automatic creation of a targeted Hello adjacency and LDP session to a discovered peer. The user configures a targeted session peer parameter template and binds it to a peer prefix policy.
Each application of a targeted session template to a given prefix in the prefix list will result in the establishment of a targeted Hello adjacency to an LDP peer using the template parameters as long as the prefix corresponds to a router-id for a node in the TE database. As a result of this, the user must enable the traffic-engineering option in ISIS or OSPF. The targeted Hello adjacency will either trigger a new LDP session or will be associated with an existing LDP session to that peer.
Up to 5 peer prefix policies can be associated with a single peer template at all times. Also, the user can associate multiple templates with the same or different peer prefix policies. Thus multiple templates can match with a given peer prefix. In all cases, the targeted session parameters applied to a given peer prefix are taken from the first created template by the user. This provides a more deterministic behavior regardless of the order in which the templates are associated with the prefix policies.
Each time the user executes the above command, with the same or different prefix policy associations, or the user changes a prefix policy associated with a targeted peer template, the system re-evaluates the prefix policy. The outcome of the re-evaluation will tell LDP if an existing targeted Hello adjacency needs to be torn down or if an existing targeted Hello adjacency needs to have its parameters updated on the fly.
If a /32 prefix is added to (removed from) or if a prefix range is expanded (shrunk) in a prefix list associated with a targeted peer template, the same prefix policy re-evaluation described above is performed.
The template comes up in the no shutdown state and as such it takes effect immediately. Once a template is in use, the user can change any of the parameters on the fly without shutting down the template. In this case, all targeted Hello adjacencies are updated.
The SR OS supports multiple ways of establishing a targeted Hello adjacency to a peer LSR:
-
User configuration of the peer with the targeted session parameters inherited from the config>router>ldp>targeted-session in the top level context or explicitly configured for this peer in the config>router>ldp>targ-session>peer context and which overrides the top level parameters shared by all targeted peers. Let us refer to the top level configuration context as the global context. Some parameters only exist in the global context; their value will always be inherited by all targeted peers regardless of which event triggered it.
-
User configuration of an SDP of any type to a peer with the signaling tldp option enabled (default configuration). In this case the targeted session parameter values are taken from the global context.
-
User configuration of a (FEC 129) PW template binding in a BGP-VPLS service. In this case the targeted session parameter values are taken from the global context.
-
User configuration of a (FEC 129 type II) PW template binding in a VLL service (dynamic multi-segment PW). In this case the target session parameter values are taken from the global context
-
User configuration of a mapping of a targeted session peer parameter template to a prefix policy when the peer address exists in the TE database (this feature). In this case, the targeted session parameter values are taken from the template.
Since the above triggering events can occur simultaneously or in any arbitrary order, the LDP code implements a priority handling mechanism in order to decide which event overrides the active targeted session parameters. The overriding trigger will become the owner of the targeted adjacency to a given peer. The following is the priority order:
-
Priority 1: manual configuration of session parameters
-
Priority 2: mapping of targeted session template to prefix policy.
-
Priority 3: auto-tx parameters
-
Priority 4: auto-rx parameters
-
Priority 5: manual configuration of SDP, PW template binding in BGP-AD VPLS and in FEC 129 VLL.
Any parameter value change to an active targeted Hello adjacency caused by any of the above triggering events is performed on the fly by having LDP immediately send a Hello message with the new parameters to the peer without waiting for the next scheduled time for the Hello message. This allows the peer to adjust its local state machine immediately and maintains both the Hello adjacency and the LDP session in UP state. The only exceptions are the following:
-
The triggering event caused a change to the local-lsr-id parameter value. In this case, the Hello adjacency is brought down which will also cause the LDP session to be brought down if this is the last Hello adjacency associated with the session. A new Hello adjacency and LDP session will then get established to the peer using the new value of the local LSR ID.
-
The triggering event caused the targeted peer shutdown option to be enabled. In this case, the Hello adjacency is brought down which will also cause the LDP session to be brought down if this is the last Hello adjacency associated with the session.
Finally, the value of any LDP parameter which is specific to the LDP/TCP session to a peer is inherited from the config>router>ldp>session-params>peer context. This includes MD5 authentication, LDP prefix per-peer policies, label distribution mode (DU or DOD), and so on.
The no form of this command deletes the binding of the template to the peer prefix list and brings down all Hello adjacencies to the discovered LDP peers.
Platforms
All
peer-to-peer
peer-to-peer
Syntax
[no] peer-to-peer
Context
[Tree] (debug>diameter>node>peer peer-to-peer)
Full Context
debug diameter node peer peer-to-peer
Description
This command reports only peer level message that are required for bringing up, maintaining and tearing down the peering connection (CER/A, DWR/A, and so on).
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
peer-tracking-policy
peer-tracking-policy
Syntax
peer-tracking-policy policy-name
no peer-tracking-policy
Context
[Tree] (config>service>vprn>bgp peer-tracking-policy)
Full Context
configure service vprn bgp peer-tracking-policy
Description
This command specifies the name of a policy statement to use with the BGP peer-tracking function on the BGP sessions where this is enabled. The policy controls which IP routes in RTM are eligible to indicate reachability of IPv4 and IPv6 BGP neighbor addresses. If the longest matching route in RTM for a BGP neighbor address is an IP route that is rejected by the policy, or it is a BGP route accepted by the policy, or if there is no matching route, the neighbor is considered unreachable and BGP tears down the peering session and holds it in the idle state until a valid route is once again available and accepted by the policy.
The default peer-tracking policy (when the no peer-tracking-policy command is configured) is to use the longest matching active route in RTM that is not an LDP shortcut route or an aggregate route.
When peer-tracking is configured, the peer-tracking policy should only permit one of direct-interface or direct routes to be advertised to a BGP peer. Advertising both routes will cause the best route to oscillate.
Default
no peer-tracking-policy
Parameters
- policy-name
-
Specifies the route policy name. Allowed values are any string up to 64 characters composed of printable, 7-bit ASCII characters. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed between double quotes. Route policies are configured in the config>router>policy-options context.
Platforms
All
peer-tracking-policy
Syntax
peer-tracking-policy policy-name
no peer-tracking-policy
Context
[Tree] (config>router>bgp peer-tracking-policy)
Full Context
configure router bgp peer-tracking-policy
Description
This command specifies the name of a policy statement to use with the BGP peer-tracking function on the BGP sessions where this is enabled. The policy controls which IP routes in RTM are eligible to indicate reachability of IPv4 and IPv6 BGP neighbor addresses. If the longest matching route in RTM for a BGP neighbor address is an IP route that is rejected by the policy, or it is a BGP route accepted by the policy, or if there is no matching route, the neighbor is considered unreachable and BGP tears down the peering session and holds it in the idle state until a valid route is once again available and accepted by the policy.
The default peer-tracking policy (when the no peer-tracking-policy command is configured) is to use the longest matching active route in RTM that is not an LDP shortcut route or an aggregate route.
When peer-tracking is configured, the peer-tracking policy should only permit one of direct-interface or direct routes to be advertised to a BGP peer. Advertising both routes will cause the best route to oscillate.
Default
no peer-tracking-policy
Parameters
- policy-name
-
Specifies the route policy name. Allowed values are any string up to 64 characters long composed of printable, 7-bit ASCII characters. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes. Route policies are configured in the config>router>policy-options context.
Platforms
All
peer-transport
peer-transport
Syntax
peer-transport ip-address
no peer transport
Context
[Tree] (config>router>ldp>tcp-session-parameters peer-transport)
Full Context
configure router ldp tcp-session-parameters peer-transport
Description
This command configures the peer transport address, that is, the destination address of the TCP connection, and not the address corresponding to the LDP LSR-ID of the peer.
Parameters
- ip-address
-
Specifies the IPv4 or IPv6 address of the TCP connection to the LDP peer in dotted decimal notation.
Platforms
All
peer-tunnel-attributes
peer-tunnel-attributes
Syntax
peer-tunnel-attributes
Context
[Tree] (config>anysec>tnl-enc>enc-grp peer-tunnel-attributes)
Full Context
configure anysec tunnel-encryption encryption-group peer-tunnel-attributes
Description
Commands in this context configure the peer tunnel attributes.
Tunnel attributes are used to match and identify the outgoing tunnels for encryptoin with ANYsec. A single tunnel attribute is used for multiple peers. Since an LSP is unidirectional, the outgoing tunnel can have different attributes from the incoming tunnel (for example, security termination policy).
Default
peer-tunnel-attributes
Platforms
7750 SR-1-24D, 7750 SR-1-46S, 7750 SR-1-48D, 7750 SR-1-92S, 7750 SR-1x-48D, 7750 SR-1x-92S, 7750 SR-1se
peer6
peer6
Syntax
peer6 ipv6-address
no peer6
Context
[Tree] (config>service>vprn>nat>inside>redundancy peer6)
[Tree] (config>router>nat>inside>redundancy peer6)
Full Context
configure service vprn nat inside redundancy peer6
configure router nat inside redundancy peer6
Description
This command is used in NAT64 multi-chassis redundancy in conjunction with filters. The configured peer6 address is an IPv6 address configured under an interface on the peering NAT64 node (active or standby). This IPv6 interface address is advertised via routing on the inside in order to attract traffic from the standby to the active NAT64 node.
Under normal circumstances, the NAT64 prefix is advertised only from the active NAT64 node. Consequently, upstream traffic for NAT64 is attracted to the active NAT64 node. The nat action in the ipv6-filter on the active NAT64 node forwards traffic to the local MS-ISA where NAT64 function is performed. However, if that upstream traffic arrives on the standby NAT64 node, the nat action in the IPv6-filter forwards traffic to the peer6 address (active NAT64 node).
The no form of the command removes the peer6 ip-address from the configuration.
Parameters
- ipv6-address
-
Specifies the IPv6 address of the NAT redundancy peer.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
peers
peers
Syntax
peers
Context
[Tree] (config>li>x-interfaces>x3 peers)
Full Context
configure li x-interfaces x3 peers
Description
This command enables the configuration of X3 peer LICs.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
pending-requests-limit
pending-requests-limit
Syntax
pending-request-limit limit
no pending-request-limit
Context
[Tree] (config>service>vprn>radius-server>server pending-requests-limit)
[Tree] (config>router>radius-server>server pending-requests-limit)
Full Context
configure service vprn radius-server server pending-requests-limit
configure router radius-server server pending-requests-limit
Description
This command specifies the per-server maximum number of outstanding requests sent to the RADIUS server. If the maximum number is exceeded, the next RADIUS server in the pool is selected.
The no form of this command removes the limit value from the configuration.
Default
pending-requests-limit 4096
Parameters
- limit
-
Specifies the maximum number of outstanding requests sent to the RADIUS server.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
peq
peq
Syntax
[no] peq peq-slot [chassis chassis-id]
Context
[Tree] (config>system>pwr-mgmt peq)
Full Context
configure system power-management peq
Description
This command sets the APEQ slot number.
Parameters
- peq-slot
-
Identifies the APEQ slot.
- chassis-id
-
Specifies chassis ID for the router chassis.
Platforms
7750 SR-12e, 7950 XRS
peq-type
peq-type
Syntax
peq-type peq-type
no peq-type
Context
[Tree] (cfg>sys>pwr-mgmt>peq peq-type)
Full Context
configure system power-management peq peq-type
Description
This command sets the type of APEQ for the designated APEQ slot.
The no form of this command moves the APEQ to an unprovisioned state.
Default
no peq-type
Parameters
- peq-type
-
Identifies the APEQ type.
Platforms
7750 SR-12e, 7950 XRS
per-fp-egr-queuing
per-fp-egr-queuing
Syntax
[no] per-fp-egr-queuing
Context
[Tree] (config>lag>access per-fp-egr-queuing)
Full Context
configure lag access per-fp-egr-queuing
Description
This command specifies whether a more efficient method of queue allocation for LAG SAPs should be utilized.
The no form of this command disables the method of queue allocation for LAG SAPs.
Platforms
All
per-fp-ing-queuing
per-fp-ing-queuing
Syntax
[no] per-fp-ing-queuing
Context
[Tree] (config>lag>access per-fp-ing-queuing)
Full Context
configure lag access per-fp-ing-queuing
Description
This command provides the ability to reduce the number of hardware queues assigned on each LAG SAP ingress. When the feature is enabled, the queue allocation for SAPs on a LAG will be optimized and only one set of queues per ingress forwarding path (FP) is allocated instead of one per port.
The no form of this command disables the method of queue allocation for LAG SAPs.
Platforms
All
per-fp-ing-queuing
Syntax
[no] per-fp-ing-queuing
Context
[Tree] (config>eth-tunnel>lag-emulation>access per-fp-ing-queuing)
Full Context
configure eth-tunnel lag-emulation access per-fp-ing-queuing
Description
This command provides the ability to reduce the number of hardware queues assigned on each LAG SAP ingress. When the feature is enabled, the queue allocation for SAPs on a LAG will be optimized and only one set of queues per ingress forwarding path (FP) is allocated instead of one per port.
The no form of this command reverts the default.
Default
no per-fp-ing-queuing
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
per-fp-sap-instance
per-fp-sap-instance
Syntax
[no] per-fp-sap-instance
Context
[Tree] (config>lag>access per-fp-sap-instance)
Full Context
configure lag access per-fp-sap-instance
Description
This command enables optimized SAP instance allocation on a LAG. When enabled, SAP instance is allocated per each FP the LAG links exits on instead of per each LAG port.
The no form of this command disables optimized SAP instance allocation.
Default
no per-fp-sap-instance
Platforms
All
per-host-authentication
per-host-authentication
Syntax
[no] per-host-authentication
Context
[Tree] (config>port>ethernet>dot1x per-host-authentication)
Full Context
configure port ethernet dot1x per-host-authentication
Description
This command enables dot1x authenticating per host source mac or VLAN. The port does not allow traffic from any hosts or any MAC. When a host is authenticated via RADIUS policy, its source mac is then allowed through the port, while the port is closed for any other mac. Any traffic from the allowed host is forwarded on the port, including untagged and tagged traffic.
Default
no per-host-authentication
Platforms
All
per-host-replication
per-host-replication
Syntax
per-host-replication [uni-mac | mcast-mac]
no per-host-replication
Context
[Tree] (config>subscr-mgmt>igmp-policy per-host-replication)
Full Context
configure subscriber-mgmt igmp-policy per-host-replication
Description
This command enables per-host-replication in IPoE model. For PPPoX, per-host-replication is the only mode of operation. In the per-host-replication mode, multicast traffic is replicated per each host within the subscriber irrespective of the fact that some hosts may be subscribed to the same multicast stream. As a result, in case that multiple hosts within the subscriber are registered for the same multicast group, the multicast streams of that group is generated. The destination MAC address of multicast streams is changed to unicast so that each host receives its own copy of the stream. Multicast traffic in the per-host-replication mode can be classified via the existing QoS CLI structure. As such the multicast traffic will flow through the subscriber queues. HQoS Adjustment is not needed in this case.
The alternative behavior for multicast replication in IPoE environment is per-SAP- replication. In this model, only a single copy of the multicast stream is sent per SAP, irrespective of the number of hosts that are subscribed to the same multicast group. This behavior applies to 1:1 connectivity model as well as on 1:N connectivity model (SAP centric behavior as opposed to subscriber centric behavior).
In the per-SAP-replication model the destination MAC address is multicast (as opposed to unicast in the per-host-replication model). Multicast traffic is flowing via the SAP queue which is outside of the subscriber context. The consequence is that multicast traffic is not accounted in the subscriber HQoS. In addition, HQoS Adaptation is not supported in the per SAP replication model.
Default
no per-host-replication — By default there is no per host replication and replication is done per SAP. This mode utilizes the SAP queues. With per-host-replication it will allow the use of the subscriber queues. Per-host-replication uses unicast MAC and multicast IP to deliver multicast content to end hosts. This is useful for multi host per SAP cases. To interoperate with end devices that do not support unicast MAC, there is an option to use per-host-replication with a multicast MAC. The traffic is the same as replication per SAP but the difference of using the subscriber queues.
Parameters
- uni-mac
-
Specifies that multicast traffic is sent with a unicast MAC and multicast IP.
- mcast-mac
-
Specifies that multicast traffic is sent with a multicast MAC and IP.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
per-host-replication
Syntax
[no] per-host-replication [uni-mac | mcast-mac]
Context
[Tree] (config>subscr-mgmt>mld-policy per-host-replication)
Full Context
configure subscriber-mgmt mld-policy per-host-replication
Description
This command enables per-host-replication. In the per-host-replication mode, multicast traffic is replicated per each host within the subscriber irrespective of the fact that some hosts may be subscribed to the same multicast stream. As a result, in case that multiple hosts within the subscriber are registered for the same multicast group, the multicast streams of that group are generated. The destination MAC address of multicast streams is changed to unicast so that each host receives its own copy of the stream. Multicast traffic in the per-host-replication mode can be classified via the existing QoS CLI structure. As such the multicast traffic flows through the subscriber queues. HQoS Adjustment is not needed in this case.
The alternative behavior for multicast replication in IPoE environment is per-SAP- replication. In this model, only a single copy of the multicast stream is sent per SAP, irrespective of the number of hosts that are subscribed to the same multicast group. This behavior applies to 1:1 connectivity model as well as on 1:N connectivity model (SAP centric behavior as opposed to subscriber centric behavior).
In the per-SAP-replication model the destination MAC address is multicast (as opposed to unicast in the per-host-replication model). Multicast traffic is flowing via the SAP queue which is outside of the subscriber context. The consequence is that multicast traffic is not accounted in the subscriber HQoS. In addition, HQoS Adaptation is not supported in the per SAP replication model.
The no form of this command reverts to the default.
Parameters
- uni-mac
-
Specifies that multicast traffic s sent with a unicast MAC and multicast IP.
- mcast-mac
-
Specifies the multicast traffic is sent with a multicast MAC and IP.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
per-lag-hashing
per-lag-hashing
Syntax
[no] per-lag-hashing
Context
[Tree] (config>mirror>mirror-dest per-lag-hashing)
Full Context
configure mirror mirror-dest per-lag-hashing
Description
This command enables per-LAG hashing on the mirror destination.
When this command is enabled, the mirror destination SAP or SDP of type LAG uses all of the link members for flow hashing. Hashing to link members is based on IP flows.
The no form of this command disables per-LAG hashing. All mirrored packets sent to a SAP or SDP of type LAG, are sent to only one of the LAG link members. If the link member to which the mirrored packets are being sent fails, another link member takes over and provides mirrored packet forwarding. Although no hashing is performed, resiliency is still provided by this next link member.
Default
no per-lag-hashing
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
per-link-hash
per-link-hash
Syntax
per-link-hash
per-link-hash weighted [auto-rebalance] [subscriber-hash-mode mode]
no per-link-hash
Context
[Tree] (config>lag per-link-hash)
Full Context
configure lag per-link-hash
Description
This command configures per-link-hashing on a LAG. When enabled, SAPs/subscribers/interfaces are hashed on LAG egress to a single LAG link.
The no form of this command disables per-link-hashing on a LAG.
Default
no per-link-hash
Parameters
- weighted
-
SAPs, subscribers, and interfaces are distributed amongst LAG links based on their preconfigured class and weight. As new links are added to a LAG, existing SAPs, subscribers, and interfaces are not impacted.
- auto-rebalance
-
SAPs, subscribers, and interfaces are distributed amongst LAG links based on their preconfigured class and weight. As new links are added to a LAG, existing SAPs, subscribers, and interfaces are rebalanced automatically.
- mode
-
Subscriber traffic can be load balanced over LAG member links in a weighted way. Traffic hashing can be performed based on SAPs or Vports.
SAP-based hashing supports weights configured at the subscriber level in a subscriber profile. SAP hashing mode supports only SAP and subscriber (1:1) deployment models.
Vport based load balancing supports SAP and subscriber (1:1) and SAP and service (N:1) deployment models.
Platforms
All
per-mcast-plane-capacity
per-mcast-plane-capacity
Syntax
[no] per-mcast-plane-capacity
Context
[Tree] (config>mcast-mgmt>chassis-level per-mcast-plane-capacity)
Full Context
configure mcast-management chassis-level per-mcast-plane-capacity
Description
Commands in this context configure multicast plane bandwidth parameters. This CLI node contains the configuration of the overall multicast (primary plus secondary) and specific secondary rate limits for each switch fabric multicast plane.
Platforms
7450 ESS, 7750 SR-1x-48D, 7750 SR-1x-92S, 7750 SR-7/12/12e, 7750 SR-s, 7950 XRS, VSR
per-peer-queuing
per-peer-queuing
Syntax
[no] per-peer-queuing
Context
[Tree] (config>system>security per-peer-queuing)
Full Context
configure system security per-peer-queuing
Description
This command enables CPM hardware queuing per peer. This means that when a peering session is established, the router will automatically allocate a separate CPM hardware queue for that peer.
The no form of this command disables CPM hardware queuing per peer.
Default
per-peer-queuing
Platforms
All
per-service-hashing
per-service-hashing
Syntax
[no] per-service-hashing
Context
[Tree] (config>service>epipe>load-balancing per-service-hashing)
Full Context
configure service epipe load-balancing per-service-hashing
Description
This command enables on a per service basis, consistent per-service hashing for Ethernet services over LAG, over Ethernet tunnel (eth-tunnel) using load sharing protection-type or over CCAG. Specifically, it enables the new hashing procedures for Epipe, VPLS, regular or PBB services.
The following algorithm describes the hash-key used for hashing when the new option is enabled:
-
If the packet is PBB encapsulated (contains an I-TAG ethertype) at the ingress side, use the ISID value from the I-TAG
-
If the packet is not PBB encapsulated at the ingress side
-
For regular (non-PBB) VPLS and Epipe services, use the related service ID
-
If the packet is originated from an ingress IVPLS or PBB Epipe SAP
-
If there is an ISID configured use the related ISID value
-
If there is no ISID yet configured use the related service ID
-
For BVPLS transit traffic use the related flood list id
-
Transit traffic is the traffic going between BVPLS endpoints
-
An example of non-PBB transit traffic in BVPLS is the OAM traffic
-
The preceding rules apply regardless of traffic type
-
Unicast, BUM flooded without MMRP or with MMRP, IGMP snooped
-
The no form of this command implies the use of existing hashing options.
Default
no per-service-hashing
Platforms
All
per-service-hashing
Syntax
[no] per-service-hashing
Context
[Tree] (config>service>vpls>load-balancing per-service-hashing)
[Tree] (config>service>template>vpls-template>load-balancing per-service-hashing)
Full Context
configure service vpls load-balancing per-service-hashing
configure service template vpls-template load-balancing per-service-hashing
Description
This command enables on a per service basis, consistent per-service hashing for Ethernet services over LAG, over Ethernet tunnel (eth-tunnel) using load sharing protection-type or over CCAG. Specifically, it enables the new hashing procedures for Epipe, VPLS, regular or PBB services.
The following algorithm describes the hash-key used for hashing when the new option is enabled:
-
If the packet is PBB encapsulated (contains an I-TAG ethertype) at the ingress side, use the ISID value from the I-TAG
-
If the packet is not PBB encapsulated at the ingress side
-
For regular (non-PBB) VPLS and Epipe services, use the related service ID
-
If the packet is originated from an ingress IVPLS or PBB Epipe SAP
-
-
If there is an ISID configured use the related ISID value
-
If there is no ISID yet configured use the related service ID
-
For BVPLS transit traffic use the related flood list id
-
-
Transit traffic is the traffic going between BVPLS endpoints
-
An example of non-PBB transit traffic in BVPLS is the OAM traffic
-
The above rules apply regardless of traffic type
-
Unicast, BUM flooded without MMRP or with MMRP, IGMP snooped
-
The no form of this command implies the use of existing hashing options.
Default
no per-service-hashing
Platforms
All
per-source-rate
per-source-rate
Syntax
per-source-rate packet-rate-limit
no per-source-rate
Context
[Tree] (config>sys>security>cpu-protection>policy per-source-rate)
Full Context
configure system security cpu-protection policy per-source-rate
Description
This command configures a per-source packet arrival rate limit. Use this command to apply a packet arrival rate limit on a per source basis. A source is defined as a unique combination of SAP and MAC source address (mac-monitoring) or SAP and source IP address (ip-src-monitoring). The CPU will receive no more than the configured packet rate from each source (only certain protocols are rate limited for ip-src-monitoring as configured under include-protocols in the cpu-protection policy). The measurement is cleared each second.
This parameter is only applicable if the policy is assigned to an interface (some examples include saps, subscriber-interfaces, and spoke-sdps), and the mac-monitor or ip-src-monitor keyword is specified in the cpu-protection configuration of that interface.
The ip-src-monitoring is useful in subscriber management architectures that have routers between the subscriber and the BNG (router). In layer-3 aggregation scenarios, all packets from all subscribers behind the same aggregation router will arrive with the same source MAC address and as such the mac-monitoring functionality cannot differentiate traffic from different subscribers.
Default
per-source-rate max
Parameters
- packet-rate-limit
-
Specifies a per-source packet (per SAP/MAC source address or per SAP/IP source address) arrival rate limit in packets per second.
Platforms
7450 ESS, 7750 SR-7/12/12e, 7750 SR-7s, 7750 SR-14s, 7950 XRS
per-spi-replication
per-spi-replication
Syntax
[no] per-spi-replication
Context
[Tree] (config>subscr-mgmt>igmp-policy per-spi-replication)
Full Context
configure subscriber-mgmt igmp-policy per-spi-replication
Description
This command enables per-SLA Profile Instance (SPI) replication. In this mode, a multicast stream is transmitted for the subscriber host SLA profile for each registered multicast group (channel). As a result, multiple copies of the same multicast stream are transmitted over the same SAP. The replication of the multicast packets depends on the number of SLA profile instances configured for the subscriber. For example, if the subscriber hosts use three SLA profiles, the (S,G) is replicated three times, but if the subscriber hosts use the same SLA profile, the (S,G) is only replicated once.
The no form of this command disables per-SPI replication.
Default
no per-spi-replication
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
per-user
per-user
Syntax
per-user user-directory dir-url file-name file-name
no per-user
Context
[Tree] (config>system>login-control>login-scripts per-user)
Full Context
configure system login-control login-scripts per-user
Description
This command allows users to define their own login scripts that can be executed each time they first login to a CLI session. The command executes the script " file-url / username / file-name" when the user username logs into a CLI session (authenticated by any means including local user database, TACACS+, or RADIUS).
For example:
per-user user-directory "cf1:/local/users" file-name "login-script.txt"
would search for the following script when user "admin” logs in and authenticates via RADIUS:
cf1:/local/users/admin/login-script.txt
The per user login script is executed after any global script executes and before any login-exec script configured against a local user is executed. This allows users, for example, who are authenticated via TACACS+ or RADIUS to define their own login scripts.
This CLI script executes in the context of the user who opens the CLI session. Any commands in the script that the user is not authorized to execute will fail.
The no form of this command disables the execution of any per user login-scripts.
Default
no per-user
Parameters
- dir-url
-
Specifies the path or directory name.
- file-name
-
Specifies the name of the file (located in the dir-url directory) including the extension.
Platforms
All
percent-rate
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent]
Context
[Tree] (config>port>ethernet>network>egr>qgrp>qover>q percent-rate)
[Tree] (config>port>eth>access>egr>qgrp>qover>q percent-rate)
Full Context
configure port ethernet network egress queue-group queue-overrides queue percent-rate
configure port ethernet access egress queue-group queue-overrides queue percent-rate
Description
This command specifies percent rates (CIR and PIR).
This command is ignored for egress HSQ queue group queues which are attached to an HS WRR group within an associated HS attachment policy. In this case, the configuration of the percent-rate is performed under the hs-wrr-group within the egress queue group template.
Parameters
- pir-percent
-
Specifies the PIR as a percentage.
- cir-percent
-
Specifies the CIR as a percentage.
Platforms
All
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent]
no percent-rate
Context
[Tree] (config>service>cpipe>sap>egress>policer-over>plcr percent-rate)
[Tree] (config>service>epipe>sap>egress>policer-over>plcr percent-rate)
[Tree] (config>service>ipipe>sap>ingress>policer-over>plcr percent-rate)
[Tree] (config>service>ipipe>sap>egress>policer-over>plcr percent-rate)
[Tree] (config>service>cpipe>sap>ingress>policer-over>plcr percent-rate)
Full Context
configure service cpipe sap egress policer-override policer percent-rate
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
configure service cpipe sap ingress policer-override policer percent-rate
Description
This command configures the percent rates (CIR and PIR) override.
Parameters
- pir-percent
-
Specifies the policer’s PIR as a percentage of the policers’s parent arbiter rate.
- cir-percent
-
Specifies the policer’s CIR as a percentage of the policers’s parent arbiter rate.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS
- configure service cpipe sap egress policer-override policer percent-rate
- configure service cpipe sap ingress policer-override policer percent-rate
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
- configure service ipipe sap egress policer-override policer percent-rate
- configure service epipe sap egress policer-override policer percent-rate
- configure service ipipe sap ingress policer-override policer percent-rate
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent]
no percent-rate
Context
[Tree] (config>service>ipipe>sap>ingress>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>epipe>sap>egress>queue-override>queue percent-rate)
[Tree] (config>service>ipipe>sap>egress>queue-override>queue percent-rate)
Full Context
configure service ipipe sap ingress 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 epipe sap egress queue-override queue percent-rate
configure service ipipe sap egress queue-override queue percent-rate
Description
The percent-rate command within the SAP ingress and egress QoS policy enables supports for a queue’s PIR and CIR rate to be configured as a percentage of the egress port’s line rate or of its parent scheduler’s rate.
When the rates are expressed as a port-limit, the actual rates used per instance of the queue will vary based on the port speed. For example, when the same QoS policy is used on a 1-Gb and a 10-Gb Ethernet port, the queue’s rates will be 10 times greater on the 10 Gb port due to the difference in port speeds. This enables the same QOS policy to be used on SAPs on different ports without needing to use SAP based queue overrides to modify a queue’s rate to get the same relative performance from the queue.
If the port’s speed changes after the queue is created, the queue’s PIR and CIR rates will be recalculated based on the defined percentage value.
When the rates are expressed as a local-limit, the actual rates used per instance of the queue are relative to the queue’s parent scheduler rate. This enables the same QOS policy to be used on SAPs with different parent scheduler rates without needing to use SAP based queue overrides to modify a queue’s rate to get the same relative performance from the queue.
If the parent scheduler rate changes after the queue is created, the queue’s PIR and CIR rates will be recalculated based on the defined percentage value.
Queue rate overrides can only be specified in the form as configured in the QoS policy (a SAP override can only be specified as a percent-rate if the associated QoS policy was also defined as percent-rate). Likewise, a SAP override can only be specified as a rate (kb/s) if the associated QoS policy was also defined as a rate. Queue-overrides are relative to the limit type specified in the QOS policy.
When no percent-rate is defined within a SAP ingress or egress queue-override, the queue reverts to the defined shaping and CIR rates within the SAP ingress and egress QOS policy associated with the queue.
Parameters
- percent-of-line-rate
-
The percent-of-line-rate parameter is used to express the queue’s shaping rate as a percentage of line rate. The line rate associated with the queue’s port may dynamically change due to configuration or auto-negotiation. The line rate may also be affected by an egress port scheduler defined max-rate.
- pir-percent
-
Specifies the queue’s PIR as a percentage dependent on the use of the port-limit or local-limit.
- cir-percent
-
Specifies the queue’s CIR as a percentage dependent on the use of the port-limit or local-limit.
Platforms
All
- configure service ipipe sap ingress queue-override queue percent-rate
- configure service epipe sap egress queue-override queue percent-rate
- configure service ipipe sap egress queue-override queue percent-rate
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
- configure service cpipe sap egress queue-override queue percent-rate
- configure service cpipe sap ingress queue-override queue percent-rate
percent-rate
Syntax
percent-rate percent
no percent-rate
Context
[Tree] (config>service>epipe>sap>egress>queue-override>hs-wrr-group percent-rate)
[Tree] (config>service>ipipe>sap>egress>queue-override>hs-wrr-group percent-rate)
Full Context
configure service epipe sap egress queue-override hs-wrr-group percent-rate
configure service ipipe sap egress queue-override hs-wrr-group percent-rate
Description
This command overrides the scheduling rate applied to the HS WRR group as a percentage of the port rate, including both the port's egress rate and port's HS scheduler policy maximum rate, if configured. The override rate type must match the corresponding rate type within the applied QoS policy.
The no form of this command removes the percent rate override value from the configuration.
Parameters
- percent
-
Specifies the percent rate of the HS WRR group.
Platforms
7750 SR-7/12/12e
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent]
no percent-rate
Context
[Tree] (config>service>vpls>sap>egress>policer-override>plcr percent-rate)
[Tree] (config>service>vpls>sap>ingress>policer-override>plcr percent-rate)
Full Context
configure service vpls sap egress policer-override policer percent-rate
configure service vpls 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' parent arbiter rate.
- cir-percent
-
Specifies the policer's CIR as a percentage of the policers' parent arbiter rate.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
percent-rate
Syntax
percent-rate percent
no percent-rate
Context
[Tree] (config>service>vpls>sap>egress>queue-override>hs-wrr-group percent-rate)
Full Context
configure service vpls sap egress queue-override hs-wrr-group percent-rate
Description
This command overrides the scheduling rate applied to the HS WRR group as a percentage of the port rate, including both the port's egress rate and port's HS scheduler policy max-rate, if configured. The override rate type must match the corresponding rate type within the applied QoS policy.
The no form of this command removes the percent rate override value from the configuration.
Parameters
- percent
-
Specifies the percent rate of the HS WRR group.
Platforms
7750 SR-7/12/12e
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent]
Context
[Tree] (config>service>vpls>sap>egress>queue-override>queue percent-rate)
[Tree] (config>service>vpls>sap>ingress>queue-override>queue percent-rate)
Full Context
configure service vpls sap egress queue-override queue percent-rate
configure service vpls sap ingress queue-override queue percent-rate
Description
The percent-rate command supports a queue’s shaping rate and CIR rate as a percentage of the egress port’s line rate. When the rates are expressed as a percentage within the template, the actual rate used per instance of the queue group queue-id will vary based on the port speed. For example, when the same template is used to create a queue group on a 1-Gb and a 10-Gb Ethernet port, the queue’s rates will be 10 times greater on the 10-Gb port due to the difference in port speeds. This enables the same template to be used on multiple ports without needing to use port based queue overrides to modify a queue’s rate to get the same relative performance from the queue.
If the port’s speed changes after the queue is created, the queue’s shaping and CIR rates will be recalculated based on the defined percentage value.
The rate and percent-rate commands override one another. If the current rate for a queue is defined using the percent-rate command and the rate command is executed, the percent-rate values are deleted. In a similar fashion, the percent-rate command causes any rate command values to be deleted. A queue’s rate may dynamically be changed back and forth from a percentage to an explicit rate at any time.
An egress port queue group queue rate override may be expressed as either a percentage or an explicit rate independent on how the queue's template rate is expressed.
This command is ignored for egress HSQ queue group queues which are attached to an HS WRR group within an associated HS attachment policy. In this case the configuration of the percent-rate is performed under the hs-wrr-group within the SAP egress QoS policy.
The no form of this command returns the queue to its default shaping rate and cir rate. When no percent-rate is defined within a port egress queue group queue override, the queue reverts to the defined shaping and CIR rates within the egress queue group template associated with the queue.
Parameters
- pir-percent
-
Specifies the queue’s shaping rate as a percentage of line rate. The line rate associated with the queue’s port may dynamically change due to configuration or auto-negotiation. The line rate may also be affected by an egress port scheduler defined max-rate.
- cir-percent
-
Specifies the queue’s committed scheduling rate as a percentage of line rate. The line rate associated with the queue’s port may dynamically change due to configuration or auto-negotiation. The line rate may also be affected by an egress port scheduler defined max-rate.
Platforms
All
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent]
no percent-rate
Context
[Tree] (config>service>ies>if>sap>ingress>policer-override>plcr percent-rate)
[Tree] (config>service>ies>if>sap>egress>policer-override>plcr percent-rate)
Full Context
configure service ies interface sap ingress policer-override policer percent-rate
configure service ies interface sap egress policer-override policer percent-rate
Description
This command configures the percent rates (CIR and PIR) override and can only be used when the rate for the associated policer in the applied SAP ingress QoS policy is also configured with the percent-rate command.
The no form of this command removes the percent-rate override so that the percent-rate configured for the policer in the applied SAP egress QoS policy is used.
Parameters
- pir-percent
-
Specifies the policer's PIR as a percentage of the policers's parent arbiter rate.
- cir-percent
-
Specifies the policer's CIR as a percentage of the policers's parent arbiter rate.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
percent-rate
Syntax
percent-rate percent
no percent-rate
Context
[Tree] (config>service>ies>if>sap>egress>queue-override>hs-wrr-group percent-rate)
Full Context
configure service ies interface sap egress queue-override hs-wrr-group percent-rate
Description
This command overrides the scheduling rate applied to the HS WRR group as a percentage of the port rate, including both the port's egress rate and port's HS scheduler policy max-rate, if configured. The override rate type must match the corresponding rate type within the applied QoS policy.
The no form of this command removes the percent rate override value from the configuration.
Parameters
- percent
-
Specifies the percent rate of the HS WRR group.
Platforms
7750 SR-7/12/12e
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent]
no percent-rate
Context
[Tree] (config>service>ies>if>sap>egress>queue-override>queue percent-rate)
[Tree] (config>service>ies>if>sap>ingress>queue-override>queue percent-rate)
Full Context
configure service ies interface sap egress queue-override queue percent-rate
configure service ies interface sap ingress queue-override queue percent-rate
Description
The percent-rate command supports a queue’s shaping rate and CIR rate as a percentage of the egress port’s line rate. When the rates are expressed as a percentage within the template, the actual rate used per instance of the queue group queue-id will vary based on the port speed. For example, when the same template is used to create a queue group on a 1-Gigabit and a 10-Gigabit Ethernet port, the queue’s rates will be 10 times greater on the 10 Gigabit port due to the difference in port speeds. This enables the same template to be used on multiple ports without needing to use port based queue overrides to modify a queue’s rate to get the same relative performance from the queue.
If the port’s speed changes after the queue is created, the queue’s shaping and CIR rates will be recalculated based on the defined percentage value.
The rate and percent-rate commands override one another. If the current rate for a queue is defined using the percent-rate command and the rate command is executed, the percent-rate values are deleted. In a similar fashion, the percent-rate command causes any rate command values to be deleted. A queue’s rate may dynamically be changed back and forth from a percentage to an explicit rate at anytime.
An egress port queue group queue rate override may be expressed as either a percentage or an explicit rate independent on how the queue's template rate is expressed.
This command is ignored for egress HSQ queue group queues which are attached to an HS WRR group within an associated HS attachment policy. In this case, the configuration of the percent-rate is performed under the hs-wrr-group within the SAP egress QoS policy.
The no form of this command returns the queue to its default shaping rate and cir rate. When no percent-rate is defined within a port egress queue group queue override, the queue reverts to the defined shaping and CIR rates within the egress queue group template associated with the queue.
Parameters
- pir-percent
-
Specifies the queue’s shaping rate as a percentage of line rate. The line rate associated with the queue’s port may dynamically change due to configuration or auto-negotiation. The line rate may also be affected by an egress port scheduler defined max-rate.
- cir-percent
-
Specifies the queue’s committed scheduling rate as a percentage of line rate. The line rate associated with the queue’s port may dynamically change due to configuration or auto-negotiation. The line rate may also be affected by an egress port scheduler defined max-rate.
Platforms
All
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent]
no percent-rate
Context
[Tree] (config>service>vprn>if>sap>ingress>policer-override>plcr percent-rate)
[Tree] (config>service>vprn>if>sap>egress>policer-override>plcr percent-rate)
Full Context
configure service vprn interface sap ingress policer-override policer percent-rate
configure service vprn interface sap egress policer-override policer percent-rate
Description
This command configures the percent rates (CIR and PIR) override and can only be used when the rate for the associated policer in the applied SAP ingress QoS policy is also configured with the percent-rate command.
The no form of this command removes the percent-rate override so that the percent-rate configured for the policer in the applied SAP egress QoS policy is used.
Parameters
- pir-percent
-
Specifies the policer's PIR as a percentage of the policers's parent arbiter rate.
- cir-percent
-
Specifies the policer's CIR as a percentage of the policers's parent arbiter rate.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
percent-rate
Syntax
percent-rate percent
no percent-rate
Context
[Tree] (config>service>vprn>if>sap>egress>queue-override>hs-wrr-group percent-rate)
Full Context
configure service vprn interface sap egress queue-override hs-wrr-group percent-rate
Description
This command overrides the scheduling rate applied to the HS WRR group as a percentage of the port rate, including both the port's egress rate and port's HS scheduler policy max-rate, if configured. The override rate type must match the corresponding rate type within the applied QoS policy.
The no form of this command removes the percent rate override value from the configuration.
Parameters
- percent
-
Specifies the percent rate of the HS WRR group.
Platforms
7750 SR-7/12/12e
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent]
no percent-rate
Context
[Tree] (config>service>vprn>if>sap>egress>queue-override>queue percent-rate)
Full Context
configure service vprn interface sap egress queue-override queue percent-rate
Description
The percent-rate command supports a queue’s shaping rate and CIR rate as a percentage of the egress port’s line rate. When the rates are expressed as a percentage within the template, the actual rate used per instance of the queue group queue-id will vary based on the port speed. For example, when the same template is used to create a queue group on a 1-Gigabit and a 10-Gigabit Ethernet port, the queue’s rates will be 10 times greater on the 10 Gigabit port due to the difference in port speeds. This enables the same template to be used on multiple ports without needing to use port based queue overrides to modify a queue’s rate to get the same relative performance from the queue.
If the port’s speed changes after the queue is created, the queue’s shaping and CIR rates will be recalculated based on the defined percentage value.
The rate and percent-rate commands override one another. If the current rate for a queue is defined using the percent-rate command and the rate command is executed, the percent-rate values are deleted. In a similar fashion, the percent-rate command causes any rate command values to be deleted. A queue’s rate may dynamically be changed back and forth from a percentage to an explicit rate at anytime.
An egress port queue group queue rate override may be expressed as either a percentage or an explicit rate independent on how the queue's template rate is expressed.
This command is ignored for egress HSQ queue group queues which are attached to an HS WRR group within an associated HS attachment policy. In this case, the configuration of the percent-rate is performed under the hs-wrr-group within the SAP egress QoS policy.
The no form of this command returns the queue to its default shaping rate and cir rate. When no percent-rate is defined within a port egress queue group queue override, the queue reverts to the defined shaping and CIR rates within the egress queue group template associated with the queue.
Parameters
- pir-percent
-
Specifies the queue’s shaping rate as a percentage of line rate. The line rate associated with the queue’s port may dynamically change due to configuration or auto-negotiation. The line rate may also be affected by an egress port scheduler defined max-rate.
- cir-percent
-
Specifies the queue’s committed scheduling rate as a percentage of line rate. The line rate associated with the queue’s port may dynamically change due to configuration or auto-negotiation. The line rate may also be affected by an egress port scheduler defined max-rate.
Platforms
All
percent-rate
Syntax
percent-rate percentage [local-limit | reference-port-limit]
no percent-rate
Context
[Tree] (config>qos>plcr-ctrl-plcy>tier>arbiter percent-rate)
Full Context
configure qos policer-control-policy tier arbiter percent-rate
Description
This command configures the percent rate of this contexts policer policy.
The no form of this command removes the configuration.
Parameters
- percentage
-
Specifies the percentage.
- local-limit
-
Keyword used to specify the local limit.
- reference-port-limit
-
Keyword used to specify the reference port limit.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent] [local-limit | reference-port-limit]
no percent-rate
Context
[Tree] (config>qos>sap-ingress>policer percent-rate)
[Tree] (config>qos>sap-egress>policer percent-rate)
Full Context
configure qos sap-ingress policer percent-rate
configure qos sap-egress policer percent-rate
Description
The percent-rate command within the SAP ingress and egress QoS policies enables supports for a policer’s PIR and CIR rate to be configured as a percentage of the immediate parent root policer/arbiter rate or the FP capacity.
This enables the same QoS policy to be used on SAPs on different FPs without needing to use SAP-based policer overrides to modify a policer’s rate to get the same relative performance from the policer.
If the parent arbiter rate changes after the policer is created, the policer’s PIR and CIR rates will be recalculated based on the defined percentage value.
The rate and percent-rate commands override one another. If the current rate for a policer is defined using the percent-rate command and the rate command is executed, the percent-rate values are deleted. In a similar fashion, the percent-rate command causes any rate command values to be deleted. A policer’s rate may dynamically be changed back and forth from a percentage to an explicit rate at any time.
The no form of this command returns the queue to its default shaping rate and CIR rate.
Parameters
- pir-percent
-
Specifies the policer’s PIR as a percentage of the immediate parent root policer/arbiter rate or the FP capacity.
- cir-percent
-
The cir keyword is optional and, when defined, the required cir-percent CIR parameter expresses the policer’s CIR as a percentage of the immediate parent root policer/arbiter rate or the FP capacity.
- local-limit
-
Keyword used to specify the local limit.
- reference-port-limit
-
Keyword used to specify the reference port limit.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent] [fir fir-percent] [{ port-limit | local-limit | reference-port-limit}]
percent-rate pir-percent police [{port-limit | local-limit | reference-port-limit}]
no percent-rate
Context
[Tree] (config>qos>sap-ingress>queue percent-rate)
Full Context
configure qos sap-ingress queue percent-rate
Description
This command configures a queue's PIR and CIR as a percentage of the ingress port line rate or as a percentage of its parent scheduler rate. When the rates are expressed as a port-limit, the actual rates used per instance of the queue will vary based on the port speed. For example, when the same QoS policy is used on a 1 Gb and a 10 Gb Ethernet port, the queue's rates will be 10 times greater on the 10 Gb port due to the difference in port speeds. This enables the same QoS policy to be used on SAPs on different ports without needing to use SAP-based queue overrides to modify a queue's rate to get the same relative performance from the queue.
If the port’s speed changes after the queue is created, the queue’s PIR, CIR, and FIR rates will be recalculated based on the defined percentage value.
When the rates are expressed as a local-limit, the actual rates used per instance of the queue are relative to the queue's parent scheduler rate. This enables the same QoS policy to be used on SAPs with different parent scheduler rates without needing to use SAP-based queue overrides to modify a queue's rate to get the same relative performance from the queue. If the parent scheduler rate changes after the queue is created, the queue's PIR, CIR, and FIR will be recalculated based on the defined percentage value.
The rate and percent-rate commands override one another. If the current rate for a queue is defined using the percent-rate command and the rate command is executed, the percent-rate values are deleted. Similarly, the percent-rate command causes any rate command values to be deleted. A queue's rate may dynamically be changed back and forth from a percentage to an explicit rate at any time.
Queue rate overrides can only be specified in the form configured in the QoS policy (for example, a SAP override can only be specified as a percent-rate if the associated QoS policy was also defined as percent-rate). Likewise, a SAP override can only be specified as a rate (kb/s) if the associated QoS policy was also defined as a rate. Queue-overrides are relative to the limit type specified in the QoS policy.
When no percent-rate is defined within a SAP ingress queue-override, the queue uses the defined shaping rate, CIR, and FIR within the SAP ingress QoS policy associated with the queue.
The no form of this command returns the queue to its default shaping rate, CIR, and FIR.
Parameters
- pir-percent
-
Specifies the queue’s PIR as a percentage dependent on the use of the port-limit or local-limit.
- cir-percent
-
Specifies the queue's CIR as a percentage dependent on the use of the port-limit or local-limit.
- fir-percent
-
Specifies the queue's FIR as a percentage dependent on the use of the port-limit or local-limit. FIR is only supported on FP4 hardware and is ignored when the related policy is applied to FP2- or FP3-based hardware.
- police
-
Keyword used to specify that traffic feeding into the physical queue instance above the specified PIR rate is dropped. When the police keyword is defined, only the PIR rate may be overridden. The police keyword is only applicable to SAP ingress.
- port-limit
-
Keyword used to specify that the configured PIR, CIR, and FIR percentages are relative to the rate of the port (including the ingress-rate setting) to which the queue is attached. The port-limit is the default.
- local-limit
-
Keyword used to specify that the configured PIR, CIR, and FIR percentages are relative to the queue’s parent scheduler rate. If there is no parent scheduler rate, or its rate is max, the port-limit is used.
- reference-port-limit
-
Keyword used to specify that the configured PIR, CIR, and FIR percentages are relative to the rate of the reference port (including the ingress-rate setting) to which the queue is attached.
Platforms
All
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent] [{port-limit | local-limit | reference-port-limit}]
no percent-rate
Context
[Tree] (config>qos>sap-egress>queue percent-rate)
Full Context
configure qos sap-egress queue percent-rate
Description
This command configures a queue's PIR and CIR as a percentage of the egress port line rate or as a percentage of its parent scheduler rate or agg-rate rate. When the rates are expressed as a port-limit, the actual rates used per instance of the queue will vary based on the port speed. For example, when the same QoS policy is used on a 1 Gb and a 10 Gb Ethernet port, the queue’s rates will be 10 times greater on the 10 Gb port due to the difference in port speeds. This enables the same QoS policy to be used on SAPs on different ports without needing to use SAP-based queue overrides to modify a queue’s rate to get the same relative performance from the queue.
If the port’s speed changes after the queue is created, the queue’s PIR and CIR will be recalculated based on the defined percentage value.
When the rates are expressed as a local-limit, the actual rates used per instance of the queue are relative to the queue’s parent scheduler rate or agg-rate rate. This enables the same QoS policy to be used on SAPs with different parent scheduler rates without needing to use SAP-based queue overrides to modify a queue’s rate to get the same relative performance from the queue. If the parent scheduler rate changes after the queue is created, the queue’s PIR and CIR will be recalculated based on the defined percentage value.
The rate and percent-rate commands override one another. If the current rate for a queue is defined using the percent-rate command and the rate command is executed, the percent-rate values are deleted. Similarly, the percent-rate command causes any rate command values to be deleted. A queue’s rate may dynamically be changed back and forth from a percentage to an explicit rate at any time.
Queue rate overrides can only be specified in the form as configured in the QoS policy (a SAP override can only be specified as a percent-rate if the associated QoS policy was also defined as percent-rate). Likewise, a SAP override can only be specified as a rate (kb/s) if the associated QoS policy was also defined as a rate. Queue-overrides are relative to the limit type specified in the QoS policy.
When configured on an egress HSQ queue group queue, the cir keyword is ignored.
This command is ignored for egress HSQ queue group queues which are attached to an HS WRR group within an associated HS attachment policy. In this case, the configuration of the percent-rate is performed under the hs-wrr-group within the SAP egress QoS policy.
When no percent-rate is defined within a SAP egress queue-override, the queue uses the defined shaping rate and CIR within the SAP egress QoS policy associated with the queue.
The no form of this command returns the queue to its default shaping rate and CIR.
Parameters
- pir-percent
-
Specifies the queue’s PIR as a percentage dependent on the use of the port-limit or local-limit.
- cir-percent
-
Specifies the queue’s CIR as a percentage dependent on the use of the port-limit or local-limit.
- port-limit
-
Keyword used to specify that the configure PIR and CIR percentages are relative to the rate of the port (including the egress-rate setting) to which this queue connects. The port-limit is the default.
- local-limit
-
Keyword used to specify that the configure PIR and CIR percentages are relative to the rate of the queue’s parent scheduler rate or agg-rate rate at egress. If there is no parent scheduler rate or agg-rate rate, or those rates are max, the port-limit is used.
- reference-port-limit
-
Keyword used to specify that the configure PIR and CIR percentages are relative to the rate of the reference port (including the egress-rate setting) to which this queue connects.
Platforms
All
percent-rate
Syntax
percent-rate percent
no percent-rate
Context
[Tree] (config>qos>sap-egress>hs-wrr-group percent-rate)
Full Context
configure qos sap-egress hs-wrr-group percent-rate
Description
This command specifies the scheduling rate applied to the HS WRR group as a percentage of the port rate, including both the port's egress rate and port's HS scheduler policy max-rate, if configured. The percent-rate and rate commands are mutually exclusive.
The no form of the command reverts to the rate max.
Parameters
- percent
-
Specifies the percent rate of the HS WRR group.
Platforms
7750 SR-7/12/12e
percent-rate
Syntax
percent-rate percent
no percent-rate
Context
[Tree] (config>qos>qgrps>egr>qgrp>hs-wrr-group percent-rate)
Full Context
configure qos queue-group-templates egress queue-group hs-wrr-group percent-rate
Description
This command specifies the scheduling rate applied to the HS WRR group as a percentage of the port rate, including both the port's egress-rate and port's HS scheduler policy max-rate, if configured. The percent-rate and rate commands are mutually exclusive.
The no form of the command reverts to the rate max.
Parameters
- percent
-
Specifies the percent rate of the HS WRR group.
Platforms
7750 SR-7/12/12e
percent-rate
Syntax
percent-rate pir-percent [cir cir-percentage] [local-limit | reference-port-limit]
no percent-rate
Context
[Tree] (config>qos>qgrps>egr>qgrp>policer percent-rate)
Full Context
configure qos queue-group-templates egress queue-group policer percent-rate
Description
This command configures the percent rate for this contexts policer.
The no form of this command removes the configuration.
Parameters
- pir-percent
-
Specifies the policer’s PIR as a percentage of the immediate parent root policer/arbiter rate or the FP capacity.
- cir-percent
-
The cir keyword is optional and, when defined, the required cir-percent CIR parameter expresses the policer’s CIR as a percentage of the immediate parent root policer/arbiter rate or the FP capacity.
- local-limit
-
Keyword used to specify the local limit.
- reference-port-limit
-
Keyword used to specify the reference port limit.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
percent-rate
Syntax
percent-rate pir-percent [cir cir-percentage]
no percent-rate
Context
[Tree] (config>qos>qgrps>ing>qgrp>policer percent-rate)
Full Context
configure qos queue-group-templates ingress queue-group policer percent-rate
Description
This command configures the percent rate for this contexts policer.
The no form of this command removes the configuration.
Parameters
- pir-percent
-
Specifies the policer’s PIR as a percentage of the immediate parent root policer/arbiter rate or the FP capacity.
- cir-percent
-
The cir keyword is optional and, when defined, the required cir-percent CIR parameter expresses the policer’s CIR as a percentage of the immediate parent root policer/arbiter rate or the FP capacity.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent] [fir fir-percent] [{ port-limit | local-limit | reference-port-limit}]
percent-rate pir-percent police [{port-limit | local-limit | reference-port-limit}]
no percent-rate
Context
[Tree] (config>qos>queue-group-templates>ingress>queue-group>queue percent-rate)
Full Context
configure qos queue-group-templates ingress queue-group queue percent-rate
Description
This command configures a queue's PIR and CIR as a percentage of the ingress port line rate or as a percentage of its parent scheduler rate. When the rates are expressed as a port-limit, the actual rates used per instance of the queue will vary based on the port speed. For example, when the same QoS policy is used on a 1 Gb and a 10 Gb Ethernet port, the queue's rates will be 10 times greater on the 10 Gb port due to the difference in port speeds. This enables the same QoS policy to be used on SAPs on different ports without needing to use SAP-based queue overrides to modify a queue's rate to get the same relative performance from the queue.
If the port’s speed changes after the queue is created, the queue’s PIR, CIR, and FIR rates will be recalculated based on the defined percentage value.
When the rates are expressed as a local-limit, the actual rates used per instance of the queue are relative to the queue's parent scheduler rate. This enables the same QoS policy to be used on SAPs with different parent scheduler rates without needing to use SAP-based queue overrides to modify a queue's rate to get the same relative performance from the queue. If the parent scheduler rate changes after the queue is created, the queue's PIR, CIR, and FIR will be recalculated based on the defined percentage value.
The rate and percent-rate commands override one another. If the current rate for a queue is defined using the percent-rate command and the rate command is executed, the percent-rate values are deleted. Similarly, the percent-rate command causes any rate command values to be deleted. A queue's rate may dynamically be changed back and forth from a percentage to an explicit rate at any time.
Queue rate overrides can only be specified in the form configured in the QoS policy (for example, a SAP override can only be specified as a percent-rate if the associated QoS policy was also defined as percent-rate). Likewise, a SAP override can only be specified as a rate (kb/s) if the associated QoS policy was also defined as a rate. Queue-overrides are relative to the limit type specified in the QoS policy.
When no percent-rate is defined within a SAP ingress queue-override, the queue uses the defined shaping rate, CIR, and FIR within the SAP ingress QoS policy associated with the queue.
The no form of this command returns the queue to its default shaping rate, CIR, and FIR.
Parameters
- pir-percent
-
Specifies the queue’s PIR as a percentage dependent on the use of the port-limit or local-limit.
- cir-percent
-
Specifies the queue's CIR as a percentage dependent on the use of the port-limit or local-limit.
- fir-percent
-
Specifies the queue's FIR as a percentage dependent on the use of the port-limit or local-limit. FIR is only supported on FP4 hardware and is ignored when the related policy is applied to FP2- or FP3-based hardware.
- police
-
Keyword used to specify that traffic feeding into the physical queue instance above the specified PIR rate will be dropped. When the police keyword is defined, only the PIR rate may be overridden. The police keyword is only applicable to SAP ingress.
- port-limit
-
Keyword used to specify that the configured PIR, CIR, and FIR percentages are relative to the rate of the port (including the ingress-rate setting) to which the queue is attached. The port-limit is the default.
- local-limit
-
Keyword used to specify that the configured PIR, CIR, and FIR percentages are relative to the queue’s parent scheduler rate. If there is no parent scheduler rate, or its rate is max, the port-limit is used.
- reference-port-limit
-
Keyword used to specify that the configured PIR, CIR, and FIR percentages are relative to the rate of the reference port (including the ingress-rate setting) to which the queue is attached.
Platforms
All
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent] [{port-limit | local-limit | reference-port-limit}]
no percent-rate
Context
[Tree] (config>qos>qgrps>egr>queue-group>queue percent-rate)
Full Context
configure qos queue-group-templates egress queue-group queue percent-rate
Description
The percent-rate command within the egress queue group template enables support for a queue’s PIR and CIR rate to be configured as a percentage of the egress port’s line rate. When the rates are expressed as a percentage within the template, the actual rate used per instance of the queue group queue-id will vary based on the port speed. For example, when the same template is used to create a queue group on a 1-Gb and a 10-Gb Ethernet port, the queue’s rates will be 10 times greater on the 10 Gb port due to the difference in port speeds. This enables the same template to be used on multiple ports without needing to use port-based queue overrides to modify a queue’s rate to get the same relative performance from the queue.
If the port’s speed changes after the queue is created, the queue’s shaping and CIR rates will be recalculated based on the defined percentage value.
When configured on an egress HSQ queue group queue, the cir keyword is ignored.
This command is ignored for egress HSQ queue group queues which are attached to an HS WRR group within an associated HS attachment policy. In this case the configuration of the rate is performed under the hs-wrr-group within the egress queue group template.
The rate and percent-rate commands override one another. If the current rate for a queue is defined using the percent-rate command and the rate command is executed, the percent-rate values are deleted. Similarly, the percent-rate command causes any rate command values to be deleted. A queue’s rate may dynamically be changed back and forth from a percentage to an explicit rate at any time.
The no form of this command returns the queue to its default shaping rate and CIR rate.
Parameters
- pir-percent
-
Expresses the queue’s shaping rate as a percentage of line rate. The line rate associated with the queue’s port may dynamically change due to configuration or auto-negotiation and the egress rate setting.
- cir-percent
-
The cir keyword is optional and when defined, the required pir-percent parameter expresses the queue’s committed scheduling rate as a percentage of line rate. The line rate associated with the queue’s port may change dynamically due to configuration or auto-negotiation and the egress rate setting.
- port-limit
-
Keyword used to specify that the configure PIR and CIR percentages are relative to the rate of the port (including the egress-rate setting) to which this queue connects. The port-limit is the default.
- local-limit
-
Keyword used to specify that the configure PIR and CIR percentages are relative to the rate of the queue’s parent scheduler rate or agg-rate rate at egress. If there is no parent scheduler rate or agg-rate rate, or those rates are max, the port-limit is used.
- reference-port-limit
-
Keyword used to specify that the configure PIR and CIR percentages are relative to the rate of the reference port (including the egress-rate setting) to which this queue connects.
Platforms
All
percent-rate
Syntax
percent-rate pir-percent [cir cir-percentage] [local-limit | reference-port-limit]
no percent-rate
Context
[Tree] (config>qos>scheduler-policy>tier>scheduler percent-rate)
Full Context
configure qos scheduler-policy tier scheduler percent-rate
Description
This command configures the percentage rate for the scheduler policy.
The no form of this command removes the configuration.
Parameters
- pir-percent
-
Specifies the policer’s PIR as a percentage of the immediate parent root policer/arbiter rate or the FP capacity.
- cir-percent
-
The cir keyword is optional and, when defined, the required cir-percent CIR parameter expresses the policer’s CIR as a percentage of the immediate parent root policer/arbiter rate or the FP capacity.
- local-limit
-
Keyword used to specify the local limit.
- reference-port-limit
-
Keyword used to specify the reference port limit.
Platforms
All
percent-rate
Syntax
percent-rate pir-percent [cir cir-percent]
no percent-rate
Context
[Tree] (config>qos>port-scheduler-policy>group percent-rate)
Full Context
configure qos port-scheduler-policy group percent-rate
Description
The percent-rate command within the port scheduler policy group enables support for a policer’s PIR and CIR rate to be configured as a percentage of the immediate parent root policer/arbiter rate or the FP capacity.
If the parent arbiter rate changes after the policer is created, the policer’s PIR and CIR rates will be recalculated based on the defined percentage value.
The rate and percent-rate commands override one another. If the current rate for a policer is defined using the percent-rate command and the rate command is executed, the percent-rate values are deleted. In a similar fashion, the percent-rate command causes any rate command values to be deleted. A policer’s rate may dynamically be changed back and forth from a percentage to an explicit rate at any time.
The no form of this command returns the queue to its default shaping rate and cir rate.
Parameters
- pir-percent
-
Specifies the policer’s PIR as a percentage of the immediate parent root policer/arbiter rate or the FP capacity.
- cir cir-percent
-
The cir keyword is optional and, when defined, the required cir-percent CIR parameter expresses the policer’s CIR as a percentage of the immediate parent root policer/arbiter rate or the FP capacity.
Platforms
All
percent-reduction-from-mbs
percent-reduction-from-mbs
Syntax
percent-reduction-from-mbs percent
no percent-reduction-from-mbs
Context
[Tree] (config>mcast-mgmt>bw-plcy>t2>prim-path>queue>drop-tail>low percent-reduction-from-mbs)
[Tree] (config>mcast-mgmt>bw-plcy>t2>sec-path>queue>drop-tail>low percent-reduction-from-mbs)
Full Context
configure mcast-management bandwidth-policy t2-paths primary-path queue-parameters drop-tail low percent-reduction-from-mbs
configure mcast-management bandwidth-policy t2-paths secondary-path queue-parameters drop-tail low percent-reduction-from-mbs
Description
This command overrides the default percentage value used to determine the low drop-tail value for the queue. By default, 10 percent of the queue depth is reserved for high congestion priority traffic. When specified, the percent-reduction-from-mbs percentage value is applied to the queues’ MBS threshold. The resulting value is subtracted from the MBS to derive the low drop-tail threshold maintained by the queue. The low drop-tail threshold defines the point at which all low-congestion priority packets destined for the queue are discarded based on queue depth. Low- and high-congestion priority is derived from the multicast records preference value compared to the record’s bundle priority threshold.
The no form of this command restores the default value.
Default
percent-reduction-from-mbs 10
Parameters
- percent
-
Specifies the percent of queue depth reserved for high-congestion priority traffic.
Platforms
7450 ESS, 7750 SR-1x-48D, 7750 SR-1x-92S, 7750 SR-7/12/12e, 7750 SR-s, 7950 XRS, VSR
percent-reduction-from-mbs
Syntax
percent-reduction-from-mbs percent
no percent-reduction-from-mbs
Context
[Tree] (config>service>ies>if>sap>ingress>queue-override>queue>drop-tail>low percent-reduction-from-mbs)
[Tree] (config>service>ies>if>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)
[Tree] (config>service>vpls>sap>egress>queue-override>queue>drop-tail>low percent-reduction-from-mbs)
Full Context
configure service ies interface sap ingress queue-override queue drop-tail low percent-reduction-from-mbs
configure service ies interface 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
configure service vpls 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 this percentage is configured to be 30% for the low drop tail, then the low drop tail is at 420 kbytes and out-of-profile packets are not accepted into the queue if its depth is greater than this value, and discarded.
Parameters
- percent
-
Specifies the percentage reduction from the MBS for a queue drop tail.
Platforms
All
percent-reduction-from-mbs
Syntax
percent-reduction-from-mbs percent
no percent-reduction-from-mbs
Context
[Tree] (config>port>ethernet>access>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)
[Tree] (config>port>ethernet>access>ing>qgrp>qover>q>drop-tail>low percent-reduction-from-mbs)
Full Context
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
configure port ethernet access ingress queue-group queue-overrides queue drop-tail low percent-reduction-from-mbs
Description
This command overrides the low queue drop tail as a percentage reduction from the MBS of the queue. For example, if a queue has an MBS of 600 kbytes and this percentage is configured to be 30% for the low drop tail, then the low drop tail will be at 420 kbytes and out-of-profile packets will not be accepted into the queue if its depth is greater than this value, and so will be discarded.
Parameters
- percent
-
Specifies the percentage reduction from the MBS for a queue drop tail.
Platforms
All
percent-reduction-from-mbs
Syntax
percent-reduction-from-mbs percent
no percent-reduction-from-mbs
Context
[Tree] (config>service>cpipe>sap>egress>queue-override>queue>drop-tail>low percent-reduction-from-mbs)
[Tree] (config>service>ipipe>sap>egress>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)
[Tree] (config>service>cpipe>sap>ingress>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)
Full Context
configure service cpipe sap egress queue-override queue drop-tail low percent-reduction-from-mbs
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 cpipe 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
Description
This command overrides the low queue drop tail as a percentage reduction from the MBS of the queue. For example, if a queue has an MBS of 600 kbytes and the percentage reduction is configured to be 30% for the low drop tail, then the low drop tail will be at 420 kbytes. Any out-of-profile packets will not be accepted into the queue if its depth is greater than this value, and so will be discarded.
Parameters
- percent
-
Specifies the percentage reduction from the MBS for a queue drop tail.
Platforms
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
All
- configure service epipe sap egress queue-override queue drop-tail low percent-reduction-from-mbs
- 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 ipipe 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>egress>queue-override>queue>drop-tail>low percent-reduction-from-mbs)
[Tree] (config>service>vprn>if>sap>ingress>queue-override>queue>drop-tail>low percent-reduction-from-mbs)
Full Context
configure service vprn interface sap egress queue-override queue drop-tail low percent-reduction-from-mbs
configure service vprn interface 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 and out-of-profile packets will not be accepted into the queue if its depth is greater than this value, and so will be discarded.
Parameters
- percent
-
Specifies the percentage reduction from the MBS for a queue drop tail.
Platforms
All
percent-reduction-from-mbs
Syntax
percent-reduction-from-mbs percent
no percent-reduction-from-mbs
Context
[Tree] (config>qos>sap-ingress>queue>drop-tail>low percent-reduction-from-mbs)
Full Context
configure qos sap-ingress queue drop-tail low percent-reduction-from-mbs
Description
This command configures the ingress SAP low drop tail as a percentage reduction from the MBS of the queue. For example, if a queue has an MBS of 600 kbytes and this percentage is configured to be 30% for the low drop tail, then the low drop tail will be at 420 kbytes and out-of-profile packets will not be accepted into the queue if its depth is greater than this value and will be discarded.
Default
percent-reduction-from-mbs 10
Parameters
- percent
-
Specifies the percentage reduction from the MBS for a queue drop tail.
Platforms
All
percent-reduction-from-mbs
Syntax
percent-reduction-from-mbs percent
no percent-reduction-from-mbs
Context
[Tree] (config>qos>sap-egress>queue>drop-tail>high percent-reduction-from-mbs)
[Tree] (config>qos>sap-egress>queue>drop-tail>exceed 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>highplus 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 exceed percent-reduction-from-mbs
configure qos sap-egress queue drop-tail low percent-reduction-from-mbs
configure qos sap-egress queue drop-tail highplus percent-reduction-from-mbs
Description
This command configures the egress SAP queue drop tails as a percentage reduction from the MBS of the queue. For example, if a queue has an MBS of 600 kbytes and this percentage is configured to be 30% for the low drop tail, then the low drop tail will be at 420 kbytes and out-of-profile packets will not be accepted into the queue if its depth is greater than this value and will be discarded.
The drop tails apply to packets with the following profile state:
-
Exceed drop tail: exceed-profile
-
High drop tail: in-profile
-
Highplus drop tail: inplus-profile
-
Low drop tail: out-of-profile
Default
Exceed drop tail: 20%
Low drop tail: 10%
High drop tail: 0%
Highplus drop tail: 0%
Parameters
- percent
-
Specifies the percentage reduction from the MBS for a queue drop tail.
Platforms
All
percent-reduction-from-mbs
Syntax
percent-reduction-from-mbs percent
no percent-reduction-from-mbs
Context
[Tree] (config>qos>network-queue>queue>drop-tail>low percent-reduction-from-mbs)
Full Context
configure qos network-queue queue drop-tail low percent-reduction-from-mbs
Description
This command configures the ingress and egress network queue low drop tail as a percentage reduction from the MBS of the queue. For example, if a queue has an MBS of 600 kbytes and percent-reduction-from-mbs is configured to be 30% for the low drop tail, then the low drop tail will be at 420 kbytes and out-of-profile packets will not be accepted into the queue if its depth is greater than this value and will be discarded.
The exceed drop tail is not configurable for network queues, however, it is set to a value of 10% in addition to low drop tail and capped by the MBS.
Default
percent-reduction-from-mbs 10
Parameters
- percent
-
Specifies the percentage reduction from the MBS for a queue drop tail.
Platforms
All
percent-reduction-from-mbs
Syntax
percent-reduction-from-mbs percent
no percent-reduction-from-mbs
Context
[Tree] (config>qos>qgrps>ing>qgrp>queue>drop-tail>low percent-reduction-from-mbs)
Full Context
configure qos queue-group-templates ingress queue-group queue drop-tail low percent-reduction-from-mbs
Description
This command configures the ingress queue group queue low drop tail as a percentage reduction from the MBS of the queue. For example, if a queue has an MBS of 600 kbytes and the percentage reduction is configured to be 30% for the low drop tail, the low drop tail will be at 420 kbytes. Out-of-profile packets will not be accepted into the queue and will be discarded if the queue depth is greater than this value.
Default
10%
Parameters
- percent
-
Specifies the percentage reduction from the MBS for a queue drop tail.
Platforms
All
percent-reduction-from-mbs
Syntax
percent-reduction-from-mbs percent
no percent-reduction-from-mbs
Context
[Tree] (config>qos>qgrps>egr>qgrp>queue>drop-tail>high 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>low 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 high 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 low percent-reduction-from-mbs
configure qos queue-group-templates egress queue-group queue drop-tail highplus percent-reduction-from-mbs
Description
This command configures the egress queue group queue drop tails as a percentage reduction from the MBS of the queue. For example, if a queue has an MBS of 600 kbytes and the percentage reduction is configured to be 30% for the low drop tail, the low drop tail will be at 420 kbytes. Out-of-profile packets will not be accepted into the queue and will be discarded if the queue depth is greater than this value.
The drop tails apply to packets with the following profile states:
-
exceed drop tail: exceed-profile
-
high drop tail: in-profile
-
highplus drop tail: inplus-profile
-
low drop tail: out-of-profile
Default
exceed drop tail: 20%
low drop tail: 10%
high drop tail: 0%
highplus drop tail: 0%
Parameters
- percent
-
Specifies the percentage reduction from the MBS for a queue drop tail.
Platforms
All
percent-reduction-from-mbs
Syntax
percent-reduction-from-mbs percent
no percent-reduction-from-mbs
Context
[Tree] (config>qos>shared-queue>queue>drop-tail>low percent-reduction-from-mbs)
Full Context
configure qos shared-queue queue drop-tail low percent-reduction-from-mbs
Description
This command configures the ingress shared queue low drop tail as a percentage reduction from the MBS of the queue. For example, if a queue has an MBS of 600 kbytes and percent-reduction-from-mbs is configured to be 30% for the low drop tail, then the low drop tail will be at 420 kbytes and out-of-profile packets will not be accepted into the queue if its depth is greater than this value and will be discarded.
Default
percent-reduction-from-mbs 10
Parameters
- percent
-
Specifies the percentage reduction from the MBS for a queue drop tail.
Platforms
All
performance
performance
Syntax
performance
Context
[Tree] (config>isa>aa-grp>statistics performance)
Full Context
configure isa application-assurance-group statistics performance
Description
This command configures the ISA group to enable the aa-performance statistic record. This record contains information on the traffic load and resource consumption for each ISA in the group, to allow tracking of ISA load for long term capacity planning and short term anomalies. The user can configure the accounting policy to be used, and enables the record using the [no] collect-stats command.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
performance
Syntax
[no] performance
Context
[Tree] (config>test-oam>sath>svc-test>svc-stream>test-types performance)
Full Context
configure test-oam service-activation-testhead service-test service-stream test-types performance
Description
This command configures the performance test of the service stream.
The no form of this command removes the configured performance test.
Default
no performance
Platforms
7450 ESS, 7750 SR, 7750 SR-s, 7950 XRS
performance
Syntax
performance
Context
[Tree] (config>test-oam>service-activation-testhead>service-test>test-duration performance)
Full Context
configure test-oam service-activation-testhead service-test test-duration performance
Description
Commands in this context configure the duration for the performance test type.
Platforms
7450 ESS, 7750 SR, 7750 SR-s, 7950 XRS
period
period
Syntax
period milli-seconds
no period
Context
[Tree] (config>router>rsvp>msg-pacing period)
Full Context
configure router rsvp msg-pacing period
Description
This command specifies the time interval (in ms), when the router can send the specified number of RSVP messages which is specified in the max-burst command.
Default
period 100
Parameters
- milli-seconds
-
Specifies the time interval in increments of 10 ms.
Platforms
All
periodic
periodic
Syntax
periodic
Context
[Tree] (config>subscr-mgmt>shcv-policy periodic)
Full Context
configure subscriber-mgmt shcv-policy periodic
Description
Commands in this context configure periodic SHCV properties for the subscriber management group-interface. This tool periodically scans all known DHCP hosts only and perform unicast ARP/NS requests. The subscriber host connectivity verification maintains state (connected versus not-connected) for all hosts.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
periodic-sm
periodic-sm
Syntax
[no] periodic-sm
Context
[Tree] (debug>service>id>mrp periodic-sm)
Full Context
debug service id mrp periodic-sm
Description
This command enables debugging of the periodic state machine.
The no form of this command disables debugging of the periodic state machine.
Platforms
All
periodic-time
periodic-time
Syntax
periodic-time value
no periodic-time
Context
[Tree] (config>service>vpls>sap>mrp periodic-time)
[Tree] (config>service>vpls>spoke-sdp>mrp periodic-time)
[Tree] (config>service>vpls>mesh-sdp>mrp periodic-time)
Full Context
configure service vpls sap mrp periodic-time
configure service vpls spoke-sdp mrp periodic-time
configure service vpls mesh-sdp mrp periodic-time
Description
This command controls the frequency the Periodic Transmission state machine generates periodic events if the Periodic Transmission Timer is enabled. The timer is required on a per-Port basis. The Periodic Transmission Timer is set to one second when it is started.
Default
periodic-time 10
Parameters
- value
-
The frequency with which the Periodic Transmission state machine generates periodic events, in tenths of a second.
Platforms
All
periodic-timer
periodic-timer
Syntax
[no] periodic-timer
Context
[Tree] (config>service>vpls>mesh-sdp>mrp periodic-timer)
[Tree] (config>service>vpls>spoke-sdp>mrp periodic-timer)
[Tree] (config>service>vpls>sap>mrp periodic-timer)
Full Context
configure service vpls mesh-sdp mrp periodic-timer
configure service vpls spoke-sdp mrp periodic-timer
configure service vpls sap mrp periodic-timer
Description
This command enables or disables the Periodic Transmission Timer.
Default
no periodic-timer
Platforms
All
periodic-update
periodic-update
Syntax
periodic-update interval hours [rate-limit rate]
no periodic-update
Context
[Tree] (config>aaa>isa-radius-plcy periodic-update)
Full Context
configure aaa isa-radius-policy periodic-update
Description
This command enables periodic RADIUS logging of currently allocated port blocks for a NAT subscriber (NAT binding).
Default
no periodic-update (no Interim Update messages are sent)
Parameters
- interval hours
-
Specifies the interval at which RADIUS logging is refreshed. The log generation might delayed past the configured interval value if the message pacing (rate-limit) is enabled or when the number of un-acknowledged (pending) messages in SR OS has reached its upper limit. An increased number of pending Interim Update messages in SR OS is due to lack of adequate responsiveness of the RADIUS server.
- rate-limit rate
-
Specifies the pacing of the Interim Update messages related to refreshment of the currently allocated port blocks. By default, when this command is disabled, the messages are sent at a high rate determined by the processing capability of the SR OS. Such a high message rate can exceed the processing power of the logging server which can result in the loss of logging information. To overcome this, the Interim Update messages can be generated in a staggered manner at a configured interval that is accommodating toward the processing capabilities of the logging server.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
periodic-update-interval
periodic-update-interval
Syntax
periodic-update-interval [days days] [ hrs hours] [min minutes] [sec seconds]
Context
[Tree] (config>system>security>pki>ca-prof>auto-crl-update periodic-update-interval)
Full Context
configure system security pki ca-profile auto-crl-update periodic-update-interval
Description
This command specifies the interval for periodic updates. The minimal interval is 1 hour. The maximum interval is 366 days.
Default
periodic-update-interval days 1
Parameters
- days days
-
Specifies the number of days for periodic updates.
- hours
-
Specifies the number of hours for periodic updates.
- minutes
-
Specifies the number of minutes for periodic updates.
- seconds
-
Specifies the number of seconds for periodic updates.
Platforms
All
permit-empty-passwords
permit-empty-passwords
Syntax
[no] configure system security ssh permit-empty-passwords
Context
[Tree] (config>system>security>ssh permit-empty-passwords)
Full Context
configure system security ssh permit-empty-passwords
Description
This command configures the permission of users with empty password strings to log in.
The no form of this command prevents users with empty password strings from logging in.
Default
permit-empty-passwords
Platforms
All
persist
persist
Syntax
persist {on | off}
Context
[Tree] (bof persist)
Full Context
bof persist
Description
This command specifies whether the system will preserve system indexes when a save command is executed in classic or mixed configuration mode. During a subsequent boot, the index file is read along with the configuration file. As a result, a number of system indexes are preserved between reboots, including the interface index, LSP IDs, path IDs, and so on. This reduces resynchronizations of the Network Management System (NMS) with the affected network element.
This command is ignored in model-driven configuration mode. In model-driven mode, system indices are always saved and they are embedded in the configuration file.
In the event that persist is on and the reboot with the appropriate index file fails in classic or mixed configuration mode, SNMP is operationally shut down to prevent the management system from accessing and possibly synchronizing with a partially booted or incomplete network element. To enable SNMP access, enter the config>system>snmp>no shutdown command.
If persist is enabled and the admin save url command is executed with an FTP path used as the url parameter, two FTP sessions simultaneously open to the FTP server. The FTP server must be configured to allow multiple sessions from the same login, otherwise, the configuration and index files will not be saved correctly.
-
In classic or mixed configuration mode, persistency files (.ndx) are saved on the same disk as the configuration files and the image files.
-
When an operator sets the location for the persistency file in classic or mixed configuration mode, the system will check to ensure that the disk has enough free space. If there is not enough free space, the persistency will not become active and a trap will be generated. Then, it is up to the operator to free adequate disk space. In the meantime, the system will perform a space availability check every 30 seconds. As soon as the space is available the persistency will become active on the next (30 second) check.
Default
persist off
Parameters
- on
-
Enables the system index saves between reboots.
- off
-
Disables the system index saves between reboots.
Platforms
All
persistence
persistence
Syntax
persistence seconds
no persistence
Context
[Tree] (config>python>py-pol>cache>minimum-lifetimes persistence)
Full Context
configure python python-policy cache minimum-lifetimes persistence
Description
This command configures the minimum lifetime for a cache entry to be made persistent.
The no form of this command reverts to the default.
Parameters
- persistence
-
The minimum lifetime, in seconds.
Platforms
All
persistence
Syntax
[no] persistence
Context
[Tree] (config>python>py-pol>cache persistence)
Full Context
configure python python-policy cache persistence
Description
This command enables persistency support for the cached entries of the python-policy.
The no form of this command reverts to the default.
Platforms
All
persistence
Syntax
persistence
Context
[Tree] (config>system persistence)
Full Context
configure system persistence
Description
Commands in this context configure persistence parameters on the system.
The persistence feature enables state information learned through applications such as subscriber management, DHCP server, or application assurance to be retained across reboots.
Platforms
All
persistence
Syntax
persistence [persistence-client]
no persistence
Context
[Tree] (debug>system persistence)
Full Context
debug system persistence
Description
This command displays persistence debug information.
Parameters
- persistence-client
-
Displays persistence debug information.
Platforms
All
persistency-database
persistency-database
Syntax
[no] persistency-database
Context
[Tree] (config>service>vprn>gsmp>group persistency-database)
[Tree] (config>service>vpls>gsmp>group persistency-database)
Full Context
configure service vprn gsmp group persistency-database
configure service vpls gsmp group persistency-database
Description
This command enables the system to store DSL line information in memory. If the GSMP connection terminates, the DSL line information will remain in memory and accessible for RADIUS authentication and accounting.
The no form of this command reverts to the default.
Platforms
All
persistency-database
Syntax
[no] persistency-database
Context
[Tree] (config>service>vpls>gsmp persistency-database)
Full Context
configure service vpls gsmp persistency-database
Description
This command enables the system to store DSL line information in memory. If the GSMP connection terminates, the DSL line information will remain in memory and accessible for Radius authentication and accounting.
Default
no persistency-database
Platforms
All
persistency-database
Syntax
[no] persistency-database
Context
[Tree] (config>service>vprn>gsmp persistency-database)
Full Context
configure service vprn gsmp persistency-database
Description
This command enables the system to store DSL line information in memory. If the GSMP connection terminates, the DSL line information remains in memory and accessible for RADIUS authentication and accounting.
The no form of this command reverts to the default.
Default
no persistency-database
Platforms
All
persistent-subscriptions
persistent-subscriptions
Syntax
persistent-subscriptions
Context
[Tree] (config>system>telemetry persistent-subscriptions)
Full Context
configure system telemetry persistent-subscriptions
Description
Commands in this context configure persistent subscriptions.
Platforms
All
pfcp
pfcp
Syntax
pfcp
Context
[Tree] (config>service>vpls>sap pfcp)
Full Context
configure service vpls sap pfcp
Description
Commands in this context configure an active PFCP association for the VPLS capture SAP.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
pfcp
Syntax
pfcp
Context
[Tree] (debug>subscr-mgmt pfcp)
Full Context
debug subscriber-mgmt pfcp
Description
Commands in this context use debug commands associated with the PFCP protocol.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
pfcp-association
pfcp-association
Syntax
pfcp-association name [create]
no pfcp-association name
Context
[Tree] (config>subscr-mgmt pfcp-association)
Full Context
configure subscriber-mgmt pfcp-association
Description
This command creates a PFCP association towards a BNG CUPS CPF.
The no form of this command removes the association.
Parameters
- name
-
Specifies the name of the PFCP association, up to 32 characters.
- create
-
Keyword used to create the PFCP association.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
pfcp-li-shared-key
pfcp-li-shared-key
Syntax
pfcp-li-shared-key secretpfcp-li-shared-key secret hash2
no pfcp-li-shared-key
Context
[Tree] (config>li>sci pfcp-li-shared-key)
Full Context
configure li sci pfcp-li-shared-key
Description
This command configures the shared secret key that SR OS uses in its role as a user plane (UP) to the MAG-c. The SR OS UP uses the shared secret key to encrypt and decrypt the LI PFCP IEs it exchanges with the MAG-c. The SR OS UP and the MAG-c must use matching secret keys. The system only accepts a secret key configured as a printable string.
The no form of this command removes the configuration.
Parameters
- secret
-
Specifies the name of the shared secret key, up to 128 characters. The system only accepts a secret key configured as a printable string.
- hash2
-
Keyword used to apply hash2 to the shared key.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
pfcp-mappings
pfcp-mappings
Syntax
pfcp-mappings
Context
[Tree] (config>subscr-mgmt>sla-prof pfcp-mappings)
Full Context
configure subscriber-mgmt sla-profile pfcp-mappings
Description
Commands in this context configure the mapping of PFCP QoS IEs (such as QER GBR/MBR IEs), to local QoS overrides (such as queue and policer rates).
Platforms
7750 SR, 7750 SR-e, 7750 SR-s, VSR
pfs
pfs
Syntax
pfs [dh-group {1 | 2 | 5 | 14 | 15 | 19 | 20 | 21}]
no pfs
Context
[Tree] (config>ipsec>ike-policy pfs)
Full Context
configure ipsec ike-policy pfs
Description
This command enables perfect forward secrecy on the IPsec tunnel using this policy. PFS provides for a new Diffie-Hellman key exchange each time the SA key is renegotiated. After that SA expires, the key is forgotten and another key is generated (if the SA remains up). This means that an attacker who cracks part of the exchange can only read the part that used the key before the key changed. There is no advantage in cracking the other parts if they attacker has already cracked one.
The no form of this command disables PFS. If this it turned off during an active SA, when the SA expires and it is time to re-key the session, the original Diffie-Hellman primes will be used to generate the new keys.
Default
no pfs
Parameters
- dh-group {1 | 2 | 5 | 14 | 15 | 19 | 20 | 21}
-
Specifies which Diffie-Hellman group to use for calculating session keys. More bits provide a higher level of security, but require more processing. Three groups are supported with IKE-v1:
Group 1: 768 bits
Group 2: 1024 bits
Group 5: 1536 bits
Group 14: 2048 bits
Group 15: 3072 bits
Group 19: P-256 ECC Curve, 256 bits
Group 20: P-384 ECC Curve, 384 bits
Group 21: P-512 ECC Curve, 512 bits
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
pfs-dh-group
pfs-dh-group
Syntax
pfs-dh-group {1 | 2 | 5 | 14 | 15 | 19 | 20 | 21}
pfs-dh-group inherit
no pfs-dh-group
Context
[Tree] (config>ipsec>ipsec-transform pfs-dh-group)
Full Context
configure ipsec ipsec-transform pfs-dh-group
Description
This command specifies the Diffie-Hellman group to be used for Perfect Forward Secrecy (PFS) computation during CHILD_SA rekeying.
The no form of this command reverts to the default.
Default
pfs-dh-group inherit
Parameters
- {1 | 2 | 5 | 14 | 15 | 19 | 20 | 21}
-
Specifies the Diffie-Hellman group to achieve PFS.
- inherit
-
Specifies that the value of the DH group used by the system is inherited from the IPsec gateway or IPsec tunnel.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
pgw
pgw
Syntax
pgw
Context
[Tree] (config>subscr-mgmt>gtp>peer-profile pgw)
Full Context
configure subscriber-mgmt gtp peer-profile pgw
Description
Commands in this context configure communication with a Packet Data Network Gateway.
Platforms
7750 SR, 7750 SR-e, 7750 SR-s, VSR
phone
phone
Syntax
[no] phone phone-number
Context
[Tree] (config>service>cust phone)
Full Context
configure service customer phone
Description
This command adds telephone number information for a customer ID. The no form of this command removes the phone number value from the customer ID.
Parameters
- string
-
Specifies the customer phone number entered as an ASCII string up to 80 characters. If the string contains special characters (#, $, spaces, and so on), 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>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>channel>video>analyzer>alarms pid-pmt-unref)
Full Context
configure mcast-management multicast-info-policy bundle 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 channel video analyzer alarms pid-pmt-unref
Description
This command configures the analyzer to check for unreferenced PIDs that have not been referred in the PMT.
Default
no pid-pmt-unref
Platforms
7450 ESS, 7750 SR, 7750 SR-s
pim
pim
Syntax
pim {asm | ssm} grp-ip-address
no pim
Context
[Tree] (config>service>vprn>mvpn>pt>inclusive pim)
Full Context
configure service vprn mvpn provider-tunnel inclusive pim
Description
This command specifies the PIM mode to use, ASM or SSM, for PIM-based inclusive provider tunnels and the multicast group address to use. Also enables the context for specifying parameters for PIM peering on the inclusive provider tunnel.
Auto-discovery must be enabled in order for SSM to operate.
The no form of this command removes the pim context including the statements under the context.
Default
no pim
Parameters
- asm
-
Specifies to use PIM ASM for inclusive provider tunnels.
- ssm
-
Specifies to u PIM SSM for inclusive provider tunnels.
- group-address
-
Specifies the multicast group address to use.
Platforms
All
pim
Syntax
[no] pim
Context
[Tree] (config>service>vprn pim)
Full Context
configure service vprn pim
Description
This command configures a Protocol Independent Multicast (PIM) instance in the VPRN service. When an PIM instance is created, the protocol is enabled. PIM is used for multicast routing within the network. Devices in the network can receive the multicast feed requested and non-participating routers can be pruned. The router supports PIM sparse mode (PIM-SM).
The no form of this command deletes the PIM protocol instance removing all associated configuration parameters.
Platforms
All
pim
Syntax
[no] pim
Context
[Tree] (config>router pim)
Full Context
configure router pim
Description
This command enables a Protocol Independent Multicast (PIM) instance.
PIM is used for multicast routing within the network. Devices in the network can receive the multicast feed requested and non-participating routers can be pruned. The router OS supports PIM sparse mode (PIM-SM).
The no form of this command disables the PIM instance.
Default
no pim
Platforms
All
pim
Syntax
pim [grp-address]
no pim
Context
[Tree] (debug>router>msdp pim)
Full Context
debug router msdp pim
Description
This command enables debugging for MSDP PIM.
The no form of this command disables MSDP PIM debugging.
Parameters
- grp-address
-
Debugs the IP multicast group address for which this entry contains information.
Platforms
All
pim-asm
pim-asm
Syntax
pim-asm {grp-ip-address/mask | grp-ip-address netmask}
no pim-asm
Context
[Tree] (config>service>vprn>mvpn>pt>selective pim-asm)
Full Context
configure service vprn mvpn provider-tunnel selective pim-asm
Description
This command specifies the range of PIM-ASM groups to use on the sender PE to setup ASM multicast tree for draft Rosen based Data MDT.
Parameters
- grp-ip-address
-
Specifies the multicast group address.
- mask
-
Specifies the mask of the multicast-ip-address.
- netmask
-
The subnet mask in dotted decimal notation.
Platforms
All
pim-policy
pim-policy
Syntax
pim-policy pim-policy-name [create]
no pim-policy pim-policy-name
Context
[Tree] (config>subscr-mgmt pim-policy)
Full Context
configure subscriber-mgmt pim-policy
Description
This command creates a PIM policy or enters the context to configure a PIM policy.
The no form of this command deletes the specified PIM policy.
Parameters
- pim-policy-name
-
Specifies the PIM policy name, up to 32 characters, composed of printable, 7-bit ASCII characters. If the string contains special characters (#, $, spaces, and so on), 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 (#, $, spaces, and so on), the entire string must be enclosed within double quotes.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
pim-snooping
pim-snooping
Syntax
pim-snooping [saps] [spoke-sdps]
no pim-snooping
Context
[Tree] (config>redundancy>multi-chassis>peer>sync pim-snooping)
Full Context
configure redundancy multi-chassis peer sync pim-snooping
Description
This command specifies whether PIM snooping for IPv4 information should be synchronized with a multi-chassis peer. Entering pim-snooping without any parameters results in the synchronization being applied only to SAPs.
Specifying the spoke-sdps parameter results in the synchronization being applied to manually configured spoke SDPs. Specifying both the saps and spoke-sdps parameters results in the synchronization being applied to both SAPs and manually configured spoke SDPs.
The synchronization of PIM snooping is only supported for manually configured spoke SDPs but is not supported for spoke SDPs configured within an endpoint. See PIM Snooping for IPv4 Synchronization for service support.
Default
no pim-snooping
Parameters
- saps
-
Specifies that SAPs are to be synchronized with the multi-chassis peer according to the synchronization tags configured on the port. This is the default when no parameters are specified.
- spoke-sdps
-
Specifies that spoke SDPs are to be synchronized with the multi-chassis peer according to the synchronization tags configured on spoke SDPs.
Platforms
All
pim-snooping
Syntax
pim-snooping
Context
[Tree] (config>service>vpls>spoke-sdp pim-snooping)
[Tree] (config>service>vpls pim-snooping)
[Tree] (config>service>vpls>sap pim-snooping)
Full Context
configure service vpls spoke-sdp pim-snooping
configure service vpls pim-snooping
configure service vpls sap pim-snooping
Description
This command enables PIM snooping for the VPLS service. When enabled, it is enabled for all SAPs except default SAPs. A default SAP is a SAP that has a wild card VLAN ID, such as sap 1/1/1:*.
The no form of this command removes the PIM snooping configuration.
Platforms
All
pim-snooping
Syntax
[no] pim-snooping
Context
[Tree] (debug>service>id pim-snooping)
Full Context
debug service id pim-snooping
Description
This command enables PIM-snooping debugging.
Platforms
All
pim-ssm
pim-ssm
Syntax
pim-ssm {grp-ip-address/mask | grp-ip-address netmask}
no pim-ssm
Context
[Tree] (config>service>vprn>mvpn>pt>selective pim-ssm)
Full Context
configure service vprn mvpn provider-tunnel selective pim-ssm
Description
This command specifies the PIM SSM groups to use for the selective provider tunnel.
Parameters
- group-address/mask
-
Specifies a multicast group address and netmask length.
Platforms
All
pim-ssm-scaling
pim-ssm-scaling
Syntax
[no] pim-ssm-scaling
Context
[Tree] (config>router>pim pim-ssm-scaling)
Full Context
configure router pim pim-ssm-scaling
Description
This command enables an increase of PIM SSM (S,G) scaling to a maximum of 256kper system. The per-complex (FP) multicast scaling limit is still in place, but multiple complexes can be used to achieve the 256k per-system (S,G) scaling.
The no form of this command disables the increase in PIM SSM scaling.
Default
no pim-ssm-scaling
Platforms
All
ping
ping
Syntax
ping ip-address | dns-name [bypass-routing | {interface interface-name} | {next-hop ip-address}] [{router router-or-service} | {router-instance router-instance} | {service-name service-name}] [source ip-address] [count requests] [detail | rapid] [do-not-fragment] [fc fc-name] [interval centisecs | secs] [pattern pattern] [size bytes] [timeout timeout] [tos type-of-service] [ttl time-to-live]
ping ipv4-address subscriber-id sub-ident-string [{router router-or-service} | {router-instance router-instance} | {service-name service-name}] [source ip-address] [count requests] [detail | rapid] [do-not-fragment] [fc fc-name] [interval centisecs | secs] [pattern pattern] [size bytes] [timeout timeout] [tos type-of-service] [ttl time-to-live]
ping srv6-policy color color endpoint ipv6-address [segment-list segment-list] [candidate-path protocol-owner static | bgp [preference preference] [distinguisher distinguisher]] [count requests] [detail | rapid] [do-not-fragment] [fc fc-name] [interval centisecs | secs] [pattern pattern] [size bytes] [timeout timeout] [tos type-of-service] [ttl time-to-live]
Context
[Tree] (ping)
Full Context
ping
Description
This command sends a ping to a destination to verify IP reachability.
Use the ping {ip-address | dns-name} [{bypass-routing | {interface interface-name} | {next-hop ip-address}}] command syntax to send a generic ping. This is the basic TCP/IP utility to verify IP reachability.
Use the ping ipv4-address subscriber-id sub-ident-string command syntax to send a ping to verify L2-Aware remote host reachability.
The L2-Aware form of this command can be initiated from the gateway IPv4 address in the inside routing context or from any IPv4 address in the outside routing context. If the gateway IPv4 address is used as the source address, it must be explicitly specified in conjunction with the L2-Aware syntax.
Any source address can be used for the ping to test the relevant NAT policy. If the source address refers to a policy that is not configured on the router, the message "MINOR: OAM #2160 router ID is not an outside router for this subscriber” is displayed. The source address does not need to belong to the system.
If the outside routing context is not specified, by default, the Base router is selected. If the specified or default Base router instance is not the outside routing context for the subscriber, the L2-Aware form of this command fails to execute, and the message "MINOR: OAM #2160 router ID is not an outside router for this subscriber” is displayed.
The NAT application shares query IDs between L2-Aware pings and ICMP or GRE traffic that has undergone NAT and is destined for a DMZ host. If there is query ID space exhaustion, ICMP or GRE flows destined for DMZ hosts are deleted, so their query IDs can be reused for the requested L2-Aware pings.
Use the ping srv6-policy color color endpoint ipv6-address command syntax to launch a ping for an SRv6 policy matching a specific color and endpoint. The ping probe may optionally be targeted at a specific segment list of the SRv6 policy. When the segment list is not specified, the ping probe is sent on the lowest available segment list.
Parameters
- bypass-routing
-
Specifies whether to send the ping request to a host on a directly attached network, bypassing the routing table.
- bytes
-
Specifies the request packet size in bytes, expressed as a decimal integer.
- candidate-path
-
Specifies a candidate path of the SRv6 policy to ping. The candidate path does not need to be the currently active candidate path.
- centiseconds
-
Sets the interval in centiseconds.
- detail
-
Displays detailed information.
- distinguisher
- Specifies the distinguisher of the SRv6 policy candidate path to send the ping probe on. This parameter must be configured if protocol-owner is configured to bgp.
- do-not-fragment
-
Sets the DF (Do Not Fragment) bit in the ICMP ping packet (does not apply to ICMPv6).
- dns-name
-
Specifies the DNS name of the far-end device on which to send the svc-ping request message, expressed as a character string.
- fc-name
-
Specifies the forwarding class of the MPLS echo request packets.
- interface-name
-
Specifies the name of an IP interface. The name must already exist in the configure router interface context.
- ip-address
-
Specifies the far-end IP address, in dotted decimal notation, on which to send the svc-ping request message.
- next-hop ip-address
-
Displays only static routes with the specified next hop IP address.
- pattern
-
Specifies that the date portion in a ping packet that is filled with the pattern value specified. If not specified, position information is filled instead.
- preference
- Specifies the preference of the SRv6 policy candidate path to send the ping probe on.
- protocol-owner
- Specifies the protocol owner of the SRv6 policy candidate path to ping.
- rapid
-
Specifies that packets be generated as fast as possible instead of the default 1 per second. Changes the units for the interval command from seconds to centiseconds.
- requests
-
Specifies the number of times to perform an OAM ping probe operation. Each OAM echo message request must either time out or receive a reply before the next message request is sent.
- router-instance
-
Specifies the preferred method for entering a service name. Stored as the service name. This is the only service-linking function allowed for both mixed-mode and model-driven configuration modes.
- router-or-service
-
Specifies the routing instance or service, by number. The router-instance parameter is preferred for specifying the router or service.
- seconds
-
Overrides the default timeout value and is the amount of time that the router waits for a message reply after sending the message request. Upon the expiration of the message time out, the requesting router assumes that the message response is not received. A request timeout message is displayed by the CLI for each message request sent that expires. Any response received after the request times out is silently discarded.
- secs
-
Sets the interval in seconds.
- service-name
-
Specifies the alias function that allows the service-name to be used, converted, and stored as a service ID.
- sub-ident-string
-
Specifies the L2-Aware NAT subscriber to which ICMP-ping is sent, up to 32 characters. The subscriber-id keyword serves as a differentiator between the subscribers with the same IP address in the same routing context (which is allowed in L2-Aware NAT). The subscriber-id keyword is mandatory for L2-Aware IPv4 ping, but optional in generic ping framework.
- source ip-address
-
Specifies the IP address to be used.
- timeout
-
Specifies the time out, in seconds.
- type-of-service
-
Specifies the service type.
- time-to-live
-
Specifies the TTL value for the MPLS label, expressed as a decimal integer.
- srv6-policy
- Keyword to specify that the ping probe is applied to an SRv6 policy.
- color-id
- Specifies the SRv6 policy color ID.
- endpoint ipv6-address
- Specifies an endpoint as the target of the ping.
- segment-list
- Specifies the segment list to trace.
Platforms
All
ping-reply
ping-reply
Syntax
[no] ping-reply
Context
[Tree] (config>service>ies>if>ipv6>vrrp ping-reply)
Full Context
configure service ies interface ipv6 vrrp ping-reply
Description
This command enables the non-owner master to reply to ICMP echo requests directed at the virtual router instances IP addresses. The ping request can be received on any routed interface.
Ping must not have been disabled at the management security level (either on the parental Ip interface or based on the ping source host address). when ping-reply is not enabled, icmp Echo Requests to non-owner master virtual IP addresses are silently discarded.
Non-owner backup virtual routers never respond to ICMP echo requests regardless of the setting of ping-reply configuration.
The ping-reply command is only available in non-owner vrrp virtual-router-id nodal context. If the ping-reply command is not executed, ICMP echo requests to the virtual router instance IP addresses will be silently discarded.
The no form of this command restores the default operation of discarding all ICMP echo request messages destined to the non-owner virtual router instance IP addresses.
Default
no ping-reply
Platforms
All
ping-reply
Syntax
[no] ping-reply
Context
[Tree] (config>service>ies>if>vrrp ping-reply)
Full Context
configure service ies interface vrrp ping-reply
Description
This command enables the non-owner master to reply to ICMP Echo Requests directed at the virtual router instances IP addresses. The ping request can be received on any routed interface.
Ping must not have been disabled at the management security level (either on the parental IP interface or based on the Ping source host address). When ping-reply is not enabled, ICMP Echo Requests to non-owner master virtual IP addresses are silently discarded.
Non-owner backup virtual routers never respond to ICMP Echo Requests regardless of the setting of ping-reply configuration.
The ping-reply command is only available in non-owner vrrp virtual-router-id nodal context. If the ping-reply command is not executed, ICMP Echo Requests to the virtual router instance IP addresses will be silently discarded.
The no form of this command restores the default operation of discarding all ICMP Echo Request messages destined to the non-owner virtual router instance IP addresses.
Default
no ping-reply
Platforms
All
ping-reply
Syntax
[no] ping-reply
Context
[Tree] (config>service>vprn>if>ipv6>vrrp ping-reply)
[Tree] (config>service>vprn>if>vrrp ping-reply)
Full Context
configure service vprn interface ipv6 vrrp ping-reply
configure service vprn interface vrrp ping-reply
Description
This command enables the non-owner master to reply to ICMP Echo Requests directed at the virtual router instances IP addresses. The ping request can be received on any routed interface.
Ping must not have been disabled at the management security level (either on the parental IP interface or based on the Ping source host address). When ping-reply is not enabled, ICMP Echo Requests to non-owner master virtual IP addresses are silently discarded.
Non-owner backup virtual routers never respond to ICMP Echo Requests regardless of the setting of ping-reply configuration.
The ping-reply command is only available in non-owner vrrp virtual-router-id nodal context. If the ping-reply command is not executed, ICMP Echo Requests to the virtual router instance IP addresses will be silently discarded.
The no form of this command restores the default operation of discarding all ICMP Echo Request messages destined to the non-owner virtual router instance IP addresses.
Default
no ping-reply
Platforms
All
ping-reply
Syntax
[no] ping-reply
Context
[Tree] (config>router>if>ipv6>vrrp ping-reply)
[Tree] (config>router>if>vrrp ping-reply)
Full Context
configure router interface ipv6 vrrp ping-reply
configure router interface vrrp ping-reply
Description
This command enables the non-owner master to reply to ICMP echo requests directed at the virtual router instances IP addresses.
Non-owner virtual router instances are limited by the VRRP specifications to responding to ARP requests destined to the virtual router IP addresses and routing IP packets not addressed to the virtual router IP addresses. Many network administrators find this limitation frustrating when troubleshooting VRRP connectivity issues.
SR OS allows this access limitation to be selectively lifted for certain applications. Ping, Telnet and SSH can be individually enabled or disabled on a per-virtual-router-instance basis.
The ping-reply command enables the non-owner master to reply to ICMP echo requests directed at the virtual router instances IP addresses. The Ping request can be received on any routed interface. Ping must not have been disabled at the management security level (either on the parental IP interface or based on the Ping source host address).
When ping-reply is not enabled, ICMP echo requests to non-owner master virtual IP addresses are silently discarded.
Non-owner backup virtual routers never respond to ICMP echo requests regardless of the ping-reply setting.
The ping-reply command is only available in non-owner vrrp nodal context.
By default, ICMP echo requests to the virtual router instance IP addresses are silently discarded.
The no form of the command configures discarding all ICMP echo request messages destined to the non-owner virtual router instance IP addresses.
Default
no ping-reply — ICMP echo requests to the virtual router instance IP addresses are discarded.
Platforms
All
ping-template
ping-template
Syntax
ping-template template-name [create]
no ping-template template-name
Context
[Tree] (config>test-oam>icmp ping-template)
Full Context
configure test-oam icmp ping-template
Description
This command creates a ping-template that can be assigned to a VPRN or IES service IP interface.
The no form of this command removes the template name from the configuration.
Parameters
- template-name
-
Specifies the name of the ping template, up to 64 characters.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
ping-template
Syntax
ping-template template-name
no ping-template
Context
[Tree] (config>service>ies>if ping-template)
[Tree] (config>service>vprn>if ping-template)
Full Context
configure service ies interface ping-template
configure service vprn interface ping-template
Description
This command maps a ping-template name to the service IP interface. The ping-template template-name is configured in the config>test-oam>icmp context and assigned to the service IP interface using this command.
The config>service>ies|vprn>if>ping-template must be shut down to remove or change the destination-address value.
The no form of this command removes the template name from the configuration.
Parameters
- template-name
-
Specifies the name of the ping template to be assigned to the IP interface, up to 64 characters.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, 7950 XRS
ping-test
ping-test
Syntax
[no] ping-test
Context
[Tree] (config>filter>redirect-policy>dest ping-test)
Full Context
configure filter redirect-policy destination ping-test
Description
This command configures parameters to perform connectivity ping tests to validate the ability for the destination to receive redirected traffic.
Default
no ping-test
Platforms
All
pip
pip
Syntax
pip
Context
[Tree] (config>mcast-mgmt>mcast-info-plcy>video-policy>video-if pip)
Full Context
configure mcast-management multicast-info-policy video-policy video-interface pip
Description
Commands in this context configure within a video interface policy the properties relating to requests received by the video interface for Picture-in-Picture (PIP) channel requests.
Platforms
7450 ESS, 7750 SR, 7750 SR-s
pir
pir
Syntax
pir pir-rate
pir max
no pir
Context
[Tree] (config>subscr-mgmt>cat-map>category>exh-lvl pir)
Full Context
configure subscriber-mgmt category-map category exhausted-credit-service-level pir
Description
This command configures the PIR which is enforced for all queues pertaining to this category.
The no form of this command reverts to the default.
Parameters
- pir-rate
-
Specifies the amount of bandwidth in kilobits per second.
- max
-
Specifies to use the maximum amount of bandwidth.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
pir
Syntax
pir congested-pir
no pir
Context
[Tree] (config>app-assure>group>policer>congestion-override pir)
Full Context
configure application-assurance group policer congestion-override pir
Description
This command provides a mechanism to configure the PIR for the congestion override policer. It is recommended that the PIR is configured larger than twice the maximum MTU for the traffic handled by the policer to allow for some burstiness of the traffic.
The no form of this command resets the PIR value to its default.
Default
pir max
Parameters
- congested-pir
-
Specifies an integer value defining size, in kbytes, for the PIR of the policer.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
pir
Syntax
pir pir-rate
no pir
Context
[Tree] (config>app-assure>group>pol>cng-ovrd-stg2 pir)
Full Context
configure application-assurance group policer congestion-override-stage2 pir
Description
This command provides a mechanism to configure the PIR for the congestion override policer. It is recommended that the PIR is configured larger than twice the maximum MTU for the traffic handled by the policer to allow for some burstiness of the traffic.
The no form of this command resets the PIR value to its default.
Default
pir max
Parameters
- congested-pir
-
Specifies an integer value defining size, in kbytes, for the PIR of the policer.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
pir-threshold
pir-threshold
Syntax
pir-threshold kbps
no pir-threshold
Context
[Tree] (config>test-oam>sath>accept-crit-tmpl pir-threshold)
Full Context
configure test-oam service-activation-testhead acceptance-criteria-template pir-threshold
Description
This command configures a PIR value that is compared to the measured results for the cir- pir, policing, and performance test types. If the measured value is greater than or equal to the configured value, the test passes; otherwise, it fails. For more information, see the m-factor command.
The no form of this command disables the comparison of the parameter with the measured value; the threshold value is ignored while declaring the test result.
Default
no pir-threshold
Parameters
- kbps
-
Specifies the value, in kb/s, for comparison with the measured value.
Platforms
7450 ESS, 7750 SR, 7750 SR-s, 7950 XRS
pki
pki
Syntax
pki
Context
[Tree] (config>system>security pki)
Full Context
configure system security pki
Description
Commands in this context configure PKI related parameters.
Platforms
All
pkt-too-big
pkt-too-big
Syntax
[no] pkt-too-big
Context
[Tree] (config>ipsec>tnl-temp>icmp6-gen pkt-too-big)
[Tree] (config>service>vprn>if>ipsec>ipsec-tunnel>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)
[Tree] (config>router>if>ipsec-tunnel>icmp-gen pkt-too-big)
Full Context
configure ipsec tunnel-template icmp6-generation pkt-too-big
configure service vprn interface ipsec ipsec-tunnel 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
configure router interface ipsec-tunnel icmp-gen 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
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
VSR
- configure service ies interface ipsec ipsec-tunnel icmp6-generation pkt-too-big
- configure service vprn interface ipsec 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>video>analyzer>alarms pmt-repetition)
[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)
Full Context
configure mcast-management multicast-info-policy bundle video analyzer alarms pmt-repetition
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
Description
This command configures the analyzer to check for the program map table (PMT). It is expected that the PMT arrives periodically within a certain interval range. It is possible to configure the type of alarm that is raised when the PMT fails to arrive within the specified interval. As the delay increases between two consecutive PMTs, the type of alarm raised becomes more critical, from TNC to POA.
Default
no pmt-repetition
Parameters
- tnc-milli-seconds
-
Specifies the time, in milliseconds, for which a TNC alarm is raised if the interval between two consecutive PMTs is greater than or equal to this configured value.
- qos-milli-seconds
-
Specifies the time, in milliseconds, for which a QoS alarm is raised if the interval between two consecutive PMTs is greater than or equal to this configured value.
- poa-milli-seconds
-
Specifies the time, in milliseconds, for which a POA alarm is raised if the interval between two consecutive PMTs is greater than or equal to this configured value.
Platforms
7450 ESS, 7750 SR, 7750 SR-s
pmt-syntax
pmt-syntax
Syntax
[no] pat-syntax
Context
[Tree] (config>mcast-mgmt>mcast-info-plcy>bundle>channel>video>analyzer>alarms pmt-syntax)
[Tree] (config>mcast-mgmt>mcast-info-plcy>bundle>video>analyzer>alarms pmt-syntax)
[Tree] (config>mcast-mgmt>mcast-info-plcy>bundle>channel>source-override>video>analyzer>alarms pmt-syntax)
Full Context
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
configure mcast-management multicast-info-policy bundle channel source-override 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>vprn>if>sap>ipsec-tunnel pmtu-discovery-aging)
[Tree] (config>ipsec>tnl-temp pmtu-discovery-aging)
[Tree] (config>service>ies>if>ipsec>ipsec-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>ies>if>sap>ip-tunnel pmtu-discovery-aging)
[Tree] (config>router>if>ipsec>ipsec-tunnel pmtu-discovery-aging)
Full Context
configure service vprn interface sap ipsec-tunnel pmtu-discovery-aging
configure ipsec tunnel-template pmtu-discovery-aging
configure service ies interface ipsec ipsec-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 ies interface sap ip-tunnel pmtu-discovery-aging
configure router interface ipsec ipsec-tunnel pmtu-discovery-aging
Description
This command configures the time used to age out the learned temporary MTU which is from the public network. The temporary MTU is used for MTU propagation.
The no form of of this command reverts to the default value.
Default
pmtu-discovery-aging 900
Parameters
- seconds
-
specifies the time, in seconds, used to age out the learned MTU
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
- configure service vprn interface sap ipsec-tunnel pmtu-discovery-aging
- configure service ies interface sap ip-tunnel pmtu-discovery-aging
- configure ipsec tunnel-template pmtu-discovery-aging
- configure service vprn interface sap ip-tunnel pmtu-discovery-aging
VSR
- configure service ies interface ipsec ipsec-tunnel pmtu-discovery-aging
- configure service vprn interface ipsec ipsec-tunnel pmtu-discovery-aging
- configure router interface ipsec ipsec-tunnel pmtu-discovery-aging
poi-tlv-enable
poi-tlv-enable
Syntax
[no] poi-tlv-enable
Context
[Tree] (config>service>vprn>isis poi-tlv-enable)
Full Context
configure service vprn isis poi-tlv-enable
Description
Enable use of Purge Originator Identification (POI) TLV for this IS-IS instance. The POI is added to purges and contains the system ID of the router that generated the purge, which simplifies troubleshooting and determining what caused the purge.
The no form of this command removes the POI functionality from the configuration.
Default
no poi-tlv-enable
Platforms
All
poi-tlv-enable
Syntax
[no] poi-tlv-enable
Context
[Tree] (config>router>isis poi-tlv-enable)
Full Context
configure router isis poi-tlv-enable
Description
Enable use of Purge Originator Identification (POI) TLV for this IS-IS instance. The POI is added to purges and contains the system ID of the router that generated the purge, which simplifies troubleshooting and determining what caused the purge.
The no form of this command removes the POI functionality from the configuration.
Default
no poi-tlv-enable
Platforms
All
policer
policer
Syntax
policer policer-id {ingress-only | egress-only | ingress-egress}
no policer policer-id
Context
[Tree] (config>subscr-mgmt>cat-map>category policer)
Full Context
configure subscriber-mgmt category-map category policer
Description
This command configures a policer in this category.
The no form of this command reverts to the default.
Parameters
- policer-id
-
Specifies an existing policer identifier.
- ingress-only
-
Specifies that ingress policers are defined in this category.
- egress-only
-
Specifies that egress policers are defined in this category.
- ingress-egress
-
Specifies that ingress and egress policers are defined in this category.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
policer
Syntax
[no] policer policer-id
Context
[Tree] (config>subscr-mgmt>sla-prof>egress>qos policer)
[Tree] (config>subscr-mgmt>sla-prof>ingress>qos policer)
Full Context
configure subscriber-mgmt sla-profile egress qos policer
configure subscriber-mgmt sla-profile ingress qos policer
Description
This command is used in the sap-ingress and sap-egress QoS policies to create, modify or delete a policer. Policers are created and used in a similar manner to queues. The policer ID space is separate from the queue ID space, allowing both a queue and a policer to share the same ID. The sap-ingress policy may have up to 32 policers (numbered 1 through 32) may be defined while the sap-egress QoS policy supports a maximum of 8 (numbered 1 through 8). While a policer may be defined within a QoS policy, it is not actually created on SAPs or subscribers associated with the policy until a forwarding class is mapped to the policer’s ID.
All policers must be created within the QoS policies. A default policer is not created when a sap-ingress or sap-egress QoS policy is created.
Once a policer is created, the policer's metering rate and profiling rates may be defined as well as the policer's maximum and committed burst sizes (MBS and CBS respectively). Unlike queues which have dedicated counters, policers allow various stat-mode settings that define the counters that is associated with the policer. Another supported feature—packet-byte-offset—provides a policer with the ability to modify the size of each packet based on a defined number of bytes.
Once a policer is created, it cannot be deleted from the QoS policy unless any forwarding classes that are mapped to the policer are first moved to other policers or queues.
The system will allow a policer to be created on a SAP QoS policy regardless of the ability to support policers on objects where the policy is currently applied. The system only scans the current objects for policer support and sufficient resources to create the policer when a forwarding class is first mapped to the policer ID. If the policer cannot be created due to one or more instances of the policy not supporting policing or having insufficient resources to create the policer, the forwarding class mapping will fail.
The no form of this command is used to delete a policer from a sap-ingress or sap-egress QoS policy. The specified policer cannot currently have any forwarding class mappings for the removal of the policer to succeed. It is not necessary to actually delete the policer ID for the policer instances to be removed from SAPs or subscribers associated with the QoS policy once all forwarding classes have been moved away from the policer. It is automatically deleted from each policing instance although it still appears in the QoS policy.
Parameters
- policer-id
-
Specifies the policer ID. The policer-id must be specified when executing the policer command. If the specified ID already exists, the system enters that policer's context to allow the policer’s parameters to be modified. If the ID does not exist and is within the allowed range for the QoS policy type, a context for the policer ID is created (depending on the system's current create keyword requirements which may require the create keyword to actually add the new policer ID to the QoS policy) and the system will enter that new policer’s context for possible parameter modification.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
policer
Syntax
policer policer-name
no policer
Context
[Tree] (config>service>vprn>sub-if>grp-if>wlan-gw>ranges>range>vrgw>lanext>network policer)
[Tree] (config>service>ies>sub-if>grp-if>wlan-gw>ranges>range>vrgw>lanext>network policer)
Full Context
configure service vprn subscriber-interface group-interface wlan-gw vlan-tag-ranges range vrgw lanext network policer
configure service ies 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>access>qgrp>policer-over policer)
[Tree] (config>card>fp>ingress>network>qgrp>policer-over policer)
Full Context
configure card fp ingress access queue-group policer-override policer
configure card fp ingress network queue-group policer-override policer
Description
This command creates, modifies or deletes a policer. Policers are created and used in a similar manner to queues. The policer ID space is separate from the queue ID space, allowing both a queue and a policer to share the same ID. The sap-ingress policy may have up to 32 policers (numbered 1 through 32) may be defined while the sap-egress QoS policy supports a maximum of 8 (numbered 1 through 8). While a policer may be defined within a QoS policy, it is not actually created on SAPs or subscribers associated with the policy until a forwarding class is mapped to the policer’s ID.
All policers must be created within the QoS policies. A default policer is not created when a sap-ingress or sap-egress QoS policy is created.
Once a policer is created, the policer's metering rate and profiling rates may be defined as well as the policer's maximum and committed burst sizes (MBS and CBS respectively). Unlike queues which have dedicated counters, policers allow various stat-mode settings that define the counters that will be associated with the policer. Another supported feature—packet-byte-offset—provides a policer with the ability to modify the size of each packet based on a defined number of bytes.
Once a policer is created, it cannot be deleted from the QoS policy unless any forwarding classes that are mapped to the policer are first moved to other policers or queues.
The system will allow a policer to be created on a SAP QoS policy regardless of the ability to support policers on objects where the policy is currently applied. The system only scans the current objects for policer support and sufficient resources to create the policer when a forwarding class is first mapped to the policer ID. If the policer cannot be created due to one or more instances of the policy not supporting policing or having insufficient resources to create the policer, the forwarding class mapping fails.
The no form of this command deletes a policer from a sap-ingress or sap-egress QoS policy. The specified policer cannot currently have any forwarding class mappings for the removal of the policer to succeed. It is not necessary to actually delete the policer ID for the policer instances to be removed from SAPs or subscribers associated with the QoS policy once all forwarding classes have been moved away from the policer. It is automatically deleted from each policing instance although it still appears in the QoS policy.
Parameters
- policer-id
-
Specifies that the policer-id must be specified when executing the policer command. If the specified ID already exists, the system enters that policer's context to allow the policer’s parameters to be modified. If the ID does not exist and is within the allowed range for the QoS policy type, a context for the policer ID will be created (depending on the system's current create keyword requirements which may require the create keyword to actually add the new policer ID to the QoS policy) and the system will enter that new policer’s context for possible parameter modification.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer
Syntax
policer policer-id [create]
no policer policer-id
Context
[Tree] (config>service>cpipe>sap>ingress>policer-over policer)
[Tree] (config>service>epipe>sap>egress>policer-over policer)
[Tree] (config>service>ipipe>sap>ingress>policer-over policer)
[Tree] (config>service>ipipe>sap>egress>policer-over policer)
[Tree] (config>service>cpipe>sap>egress>policer-over policer)
Full Context
configure service cpipe sap ingress policer-override policer
configure service epipe sap egress policer-override policer
configure service ipipe sap ingress policer-override policer
configure service ipipe sap egress policer-override policer
configure service cpipe 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
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
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
- configure service ipipe sap ingress policer-override policer
- configure service epipe sap egress policer-override policer
- configure service ipipe sap egress 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>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
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer
Syntax
policer policer-id [create]
no policer policer-id
Context
[Tree] (config>service>vprn>if>sap>egress>policer-override policer)
[Tree] (config>service>vprn>if>sap>ingress>policer-override policer)
Full Context
configure service vprn interface sap egress policer-override policer
configure service vprn interface sap ingress policer-override policer
Description
This command, within the SAP ingress or egress contexts, is used to create a CLI node for specific overrides to a specific policer created on the SAP through a sap-ingress or sap-egress QoS policy.
The no form of this command is used to remove any existing overrides for the specified policer-id.
Parameters
- policer-id
-
This parameter is required when executing the policer command within the policer-override context. The specified policer-id must exist within the sap-ingress or sap-egress QoS policy applied to the SAP. If the policer is not currently used by any forwarding class or forwarding type mappings, the policer will not actually exist on the SAP. This does not preclude creating an override context for the policer-id.
- create
-
The create keyword is required when a policer override node is being created and the system is configured to expect explicit confirmation that a new object is being created. When the system is not configured to expect explicit configuration, the create keyword is not required.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer
Syntax
policer policer-name type type granularity granularity [create]
policer policer-name
no policer policer-name
Context
[Tree] (config>app-assure>group policer)
Full Context
configure application-assurance group policer
Description
This command creates application assurance policer profile of a specified type. Policers can be bandwidth or flow limiting and can have a system scope (limits traffic entering AA ISA for all or a subset of AA subscribers), subscriber scope or granularity (limits apply to each AA subscriber traffic).
The policer type and granularity can only be configured during creation. They cannot be modified. The policer profile must be removed from all AQPs in order to be removed. Changes to policer profile parameters take effect immediately for policers instantiated as result of AQP actions using this profile.
The no form of this command deletes the specified policer from the configuration.
Parameters
- policer-name
-
Specifies a string of up to 32 characters that identifies the policer.
- type
-
Specifies the policer type.
- granularity
-
Specifies the granularity type.
- create
-
Keyword used to create the policer name and parameters.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
policer
Syntax
policer policer-name direction direction [create]
no policer policer-name direction direction
Context
[Tree] (config>app-assure>group>statistics>tca policer)
Full Context
configure application-assurance group statistics threshold-crossing-alert policer
Description
This command configures a TCA for the counter capturing drops or admit events due to the specified flow policer. A policer TCA can be created for traffic generated from the subscriber side of AA ( from-sub) or for traffic generated from the network toward the AA subscriber (to-sub). The create keyword is mandatory when creating a policer TCA.
Parameters
- policer-name
-
Specifies the name of the flow policer, up to 32 characters
- direction
-
Specifies the traffic direction.
- create
-
Keyword used to create the TCA.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
policer
Syntax
policer policer-id [fp-redirect-group]
no policer
Context
[Tree] (config>qos>sap-ingress>fc policer)
Full Context
configure qos sap-ingress fc policer
Description
Within a sap-ingress QoS policy forwarding class context, the policer command is used to map packets that match the forwarding class and are considered unicast in nature to the specified policer-id. The specified policer-id must already exist within the sap-ingress QoS policy. While the system is determining the forwarding class of a packet, it is also looking up its forwarding destination. If ingress forwarding logic has resolved a unicast destination (the packet does not need to be sent to multiple destinations), it is considered to be a unicast packet and will be mapped to either an ingress queue (using the queue queue-id or queue queue-id group ingress-queue-group commands) or an ingress policer ( policer policer-id). The queue and policer commands within the forwarding class context are mutually exclusive. By default, the unicast forwarding type is mapped to the SAP ingress default queue (queue 1). If the policer policer-id command is executed, any previous policer mapping or queue mapping for the unicast forwarding type within the forwarding class is overridden if the policer mapping is successful.
A policer defined within the sap-ingress policy is not actually created on an ingress SAP or a subscriber using an sla-profile where the policy is applied until at least one forwarding type (unicast, broadcast, unknown, or multicast) from one of the forwarding classes is mapped to the policer. If insufficient policer resources exist to create the policer for a SAP or subscriber or multiservice site or ingress policing is not supported on the port associated with the SAP or subscriber or multiservice site, the initial forwarding class forwarding type mapping will fail.
When the unicast forwarding type within a forwarding class is mapped to a policer, the unicast packets classified to the subclasses within the forwarding class are also mapped to the policer.
The no form of this command is used to restore the mapping of the unicast forwarding type within the forwarding class to the default queue. If all forwarding class forwarding types had been removed from the default queue, the queue will not exist on the SAPs or subscriber or multiservice sites associated with the QoS policy and the no policer command will cause the system to attempt to create the default queue on each object. If the system cannot create the default queue in each instance, the no policer command will fail and the unicast forwarding type within the forwarding class will continue its mapping to the existing policer-id. If the no policer command results in a policer without any current mappings, the policer will be removed from the SAPs and subscribers associated with the QoS policy. All statistics associated with the policer on each SAP and subscriber will be lost.
Parameters
- policer-id
-
When the forwarding class policer command is executed, a valid policer-id must be specified. The parameter policer-id references a policer-id that has already been created within the sap-ingress QoS policy.
- fp-redirect-group
-
Redirects a forwarding class to a forwarding plane queue-group as specified in a SAP QoS policy.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer
Syntax
policer policer-id [create]
no policer policer-id
Context
[Tree] (config>qos>sap-ingress policer)
Full Context
configure qos sap-ingress policer
Description
This command is used in the sap-ingress and sap-egress QoS policies to create, modify, or delete a policer. Policers are created and used in a similar manner to queues. The policer ID space is separate from the queue ID space, allowing both a queue and a policer to share the same ID. The sap-ingress policy may be defined to have up to 63 policers (numbered 1 through 63) while the sap-egress QoS policy supports a maximum of 8 (numbered 1 through 8). While a policer may be defined within a QoS policy, it is not actually created on SAPs or subscribers or multiservice sites associated with the policy until a forwarding class is mapped to the policer’s ID.
All policers must be created within the QoS policies. A default policer is not created when a sap-ingress or sap-egress QoS policy is created.
When a policer is created, the policer's metering rate and profiling rates may be defined as well as the policer's maximum and committed burst sizes (MBS and CBS, respectively). Unlike queues that have dedicated counters, policers allow various stat-mode settings that define the counters that will be associated with the policer. Another supported feature—packet-byte-offset—provides a policer with the ability to modify the size of each packet, based on a defined number of bytes.
When a policer is created, it cannot be deleted from the QoS policy unless any forwarding classes that are mapped to the policer are first moved to other policers or queues.
The system will allow a policer to be created on a SAP QoS policy regardless of the ability to support policers on objects where the policy is currently applied. The system only scans the current objects for policer support and sufficient resources to create the policer when a forwarding class is first mapped to the policer ID. If the policer cannot be created due to one or more instances of the policy not supporting policing or having insufficient resources to create the policer, the forwarding class mapping will fail.
The no form of this command is used to delete a policer from a sap-ingress or sap-egress QoS policy. The specified policer cannot currently have any forwarding class mappings for the removal of the policer to succeed. It is not necessary to actually delete the policer ID for the policer instances to be removed from SAPs or subscriber or multiservice sites associated with the QoS policy when all forwarding classes have been moved away from the policer. It is automatically deleted from each policing instance although it still appears in the QoS policy.
Parameters
- policer-id
-
The policer-id must be specified when executing the policer command. If the specified ID already exists, the system enters that policer's context to allow the policer’s parameters to be modified. If the ID does not exist and is within the allowed range for the QoS policy type, a context for the policer ID will be created (depending on the system's current create keyword requirements, which may require the create keyword to actually add the new policer ID to the QoS policy) and the system will enter that new policer’s context for possible parameter modification.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer
Syntax
policer policer-id [{[port-redirect-group-queue] [queue queue-id] | group group-name [instance instance-id] [queue queue-id]}]
no policer
Context
[Tree] (config>qos>sap-egress>fc policer)
Full Context
configure qos sap-egress fc policer
Description
Within a sap-egress QoS policy forwarding class context, the policer command is used to map packets that match the forwarding class to the specified policer-id. The specified policer-id must already exist within the sap-egress QoS policy. The forwarding class of the packet is first discovered at ingress, based on the ingress classification rules. When the packet arrives at egress, the sap-egress QoS policy may match a forwarding class reclassification rule that overrides the ingress derived forwarding class. The forwarding class context within the sap-egress QoS policy is then used to map the packet to an egress queue (using the queue queue-id, or port-redirect-group queue queue-id, or group queue-group-name instance instance-id queue queue-id commands) or an egress policer (policer policer-id). The queue and policer commands within the forwarding class context are mutually exclusive. By default, the forwarding class is mapped to the SAP egress default queue (queue 1). If the policer policer- id command is executed, any previous policer mapping or queue mapping for the forwarding class is overridden if the policer mapping is successful.
A policer defined within the sap-egress policy is not actually created on an egress SAP, or a subscriber using an SLA profile where the policy is applied, until at least one forwarding class is mapped to the policer. If insufficient policer resources exist to create the policer for a SAP or subscriber, or egress policing is not supported on the port associated with the SAP or subscriber, the initial forwarding class mapping will fail.
Packets that are mapped to an egress policer that are not discarded by the policer must be placed into a default queue on the packet’s destination port. The system uses egress port queue groups for this purpose. An egress queue group named policer-output-queues is automatically created on each port that supports egress policers. By default, the system uses the forwarding class mappings within this queue group to decide which queue within the group will receive each packet output from the policer. This default policer output queuing behavior may be overridden for non-subscriber packets by redirection to a queue group. The name and instance of the queue group to redirect to is either specified in the QoS policy, or the fact that a forwarding class must be redirected is identified in the QoS policy and the specific queue group instance is only identified at the time the QoS policy is applied:
-
If the policer policer-id command is successfully executed, the default egress queuing is performed for the forwarding class using the policer-output-queues queue group and the queue-id within the group based on the forwarding class map from the group template.
-
If the policer policer-id queue queue-id command is successfully executed, the specified SAP queue-id within the egress QoS policy is used instead of the default policer output queues.
-
If the policer policer-id port-redirect-group-queue keyword is successfully executed, the system will map the forwarding class to the queue within the egress queue group instance specified at the time the QoS policy is applied to the SAP, using the forwarding class map from the queue group template.
-
If the policer policer-id port-redirect-group queue queue-id command is successfully executed, the system will map the forwarding class to the configured queue-id within the egress queue group instance that is specified at the time the QoS policy is applied to the SAP (ignoring using the forwarding class map from the queue group template).
-
If the policer policer-id group queue-group-name instance instance-id command is successfully executed, the system will map the forwarding class to the queue within the specified egress queue group instance using the forwarding class map from the group template.
-
If the policer policer-id group queue-group-name instance instance-id queue queue-id command is successfully executed, the system will map the forwarding class to the specified queue-id within the specified egress queue group instance (ignoring the forwarding class map in the group template).
If the specified group group-name is not defined as an egress queue-group-template, the policer command will fail. Also, if the specified group does not exist on the port for the SAPs or subscribers associated with the sap-egress QoS policy, the policer command will fail. While a group queue-group-name is specified in a sap-egress QoS policy, the groups corresponding egress template cannot be deleted. While a port egress queue group is associated with a policer instance, the port queue group cannot be deleted.
If the specified queue queue-id is not defined in the egress queue-group-template queue-group- name, the policer command will fail. While a queue-id within an egress queue group template is referenced by a sap-egress QoS policy forwarding class policer command, the queue cannot be deleted from the queue group template.
If an egress policed packet is discarded by the egress port queue group queue, the source policer discard stats are incremented. This means that the discard counters for the policer represent both the policer discard events and the destination queue drop tail events associated with the policer.
The no form of this command is used to restore the mapping of the forwarding class to the default queue. If all forwarding classes have been removed from the default queue, the queue will not exist on the SAPs or subscribers associated with the QoS policy and the no policer command will cause the system to attempt to create the default queue on each object. If the system cannot create the default queue in each instance, the no policer command will fail and the forwarding class will continue its mapping to the existing policer-id. If the no policer command results in a policer without any current mappings, the policer will be removed from the SAPs and subscribers associated with the QoS policy. All statistics associated with the policer on each SAP and subscribers will be lost.
Default
no policer
Parameters
- policer-id
-
When the forwarding class policer command is executed, a valid policer-id must be specified. The parameter policer-id references a policer-id that has already been created within the sap-egress QoS policy.
- port-redirect-group-queue
-
Used to override the forwarding class default egress queue destination to an egress port queue group. The specific egress queue group instance to use is specified at the time the QoS policy is applied to the SAP. Therefore, this parameter is only valid if SAP-based redirection is required.
- queue queue-id
-
This parameter overrides the forwarding class default egress queue destination to a specified queue-id. If port-redirect-group is not configured, this will be a local SAP queue of that queue-id. A queue of ID queue-id must exist within the egress QoS policy. If port-redirect-group-queue is configured, the queue queue-id in the egress port queue group instance is used.
- group group-name
-
The group queue-group-name is optional and is used to override the forwarding class's default egress queue destination. If the queue group-queue-id parameter is not specified, the forwarding class map within the specified group's template is used to derive which queue within the group will receive the forwarding class's packets. An egress queue group template must exist for the specified queue-group-name or the policer command will fail. The specified queue-group-name must also exist as an egress queue group on the ports where SAPs and subscribers associated with the sap-egress policy are applied or the policer command will fail.
- queue queue-id
-
The queue group-queue-id is optional when the group queue-group-name parameter is specified and is used to override the forwarding class mapping within the group's egress queue group template. The specified group-queue-id must exist within the group's egress queue group template or the policer command will fail.
- instance instance-id
-
This parameter is used to specify the specific instance of a queue group with template queue-group-name to which this queue should be redirected. This parameter is only valid for queue groups on egress ports where policy-based redirection is required.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer
Syntax
policer policer-id [create]
no policer
Context
[Tree] (config>qos>sap-egress policer)
Full Context
configure qos sap-egress policer
Description
A policer defined within the sap-egress policy is not actually created on an egress SAP, or a subscriber using an SLA profile where the policy is applied, until at least one forwarding class is mapped to the policer. If insufficient policer resources exist to create the policer for a SAP or subscriber, or egress policing is not supported on the port associated with the SAP or subscriber, the initial forwarding class mapping will fail.
Packets that are mapped to an egress policer that are not discarded by the policer must be placed into a default queue on the packet’s destination port. The system uses egress port queue groups for this purpose. An egress queue group named policer-output-queues is automatically created on each port that supports egress policers. By default, the system uses the forwarding class mappings within this queue group to decide which queue within the group will receive each packet output from the policer. This default policer output queuing behavior may be overridden for non-subscriber packets by redirection to a queue group. The name and instance of the queue group to redirect to is either specified in the QoS policy, or the fact that a forwarding class must be redirected is identified in the QoS policy and the specific queue group instance is only identified at the time the QoS policy is applied:
-
If the policer policer-id command is successfully executed, the default egress queuing is performed for the forwarding class using the policer-output-queues queue group and the queue-id within the group based on the forwarding class map from the group template.
-
If the policer policer-id queue queue-id command is successfully executed, the specified SAP queue-id within the egress QoS policy is used instead of the default policer output queues.
-
If the policer policer-id port-redirect-group-queue keyword is successfully executed, the system will map the forwarding class to the queue within the egress queue group instance specified at the time the QoS policy is applied to the SAP, using the forwarding class map from the queue group template.
-
If the policer policer-id port-redirect-group queue queue-id command is successfully executed, the system will map the forwarding class to the configured queue-id within the egress queue group instance that is specified at the time the QoS policy is applied to the SAP (ignoring using the forwarding class map from the queue group template).
-
If the policer policer-id group queue-group-name instance instance-id command is successfully executed, the system will map the forwarding class to the queue within the specified egress queue group instance using the forwarding class map from the group template.
-
If the policer policer-id group queue-group-name instance instance-id queue queue-id command is successfully executed, the system will map the forwarding class to the specified queue-id within the specified egress queue group instance (ignoring the forwarding class map in the group template).
If the specified group group-name is not defined as an egress queue-group-template, the policer command will fail. Also, if the specified group does not exist on the port for the SAPs or subscribers associated with the sap-egress QoS policy, the policer command will fail. While a group queue-group-name is specified in a sap-egress QoS policy, the groups corresponding egress template cannot be deleted. While a port egress queue group is associated with a policer instance, the port queue group cannot be deleted.
If the specified queue queue-id is not defined in the egress queue-group-template queue-group- name, the policer command will fail. While a queue-id within an egress queue group template is referenced by a sap-egress QoS policy forwarding class policer command, the queue cannot be deleted from the queue group template.
If an egress policed packet is discarded by the egress port queue group queue, the source policer discard stats are incremented. This means that the discard counters for the policer represent both the policer discard events and the destination queue drop tail events associated with the policer.
The no form of this command is used to restore the mapping of the forwarding class to the default queue. If all forwarding classes have been removed from the default queue, the queue will not exist on the SAPs or subscribers associated with the QoS policy and the no policer command will cause the system to attempt to create the default queue on each object. If the system cannot create the default queue in each instance, the no policer command will fail and the forwarding class will continue its mapping to the existing policer-id. If the no policer command results in a policer without any current mappings, the policer will be removed from the SAPs and subscribers associated with the QoS policy. All statistics associated with the policer on each SAP and subscribers will be lost.
Default
no policer
Parameters
- policer-id
-
When the forwarding class policer command is executed, a valid policer-id must be specified. The parameter policer-id references a policer-id that has already been created within the sap-egress QoS policy.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer
Syntax
policer policer-id [create]
no policer policer-id
Context
[Tree] (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.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer
Syntax
[no] policer policer-id
Context
[Tree] (config>log>acct-policy>cr policer)
Full Context
configure log accounting-policy custom-record policer
Description
This command creates a policer context for which counters should be included in the custom-record.
The no form of this command deletes the policer and its counters from the custom-record.
Parameters
- policer-id
-
Specifies the policer for which counters should be included in or deleted from the custom-record.
Platforms
All
policer
Syntax
[no] policer policer-id
Context
[Tree] (config>router>policy-acct-template policer)
Full Context
configure router policy-acct-template policer
Description
Commands in this context configure policer index information. Each policy accounting template supports up to 63 policers.
Policing by action of a policy accounting template is only supported by FP4 cards and systems.
The no form of this command deletes the policer ID from the configuration.
Parameters
- policer-id
-
Specifies the policer index.
Platforms
7450 ESS, 7750 SR, 7750 SR-s, 7950 XRS
policer-control-override
policer-control-override
Syntax
policer-control-override [create]
no policer-control-override
Context
[Tree] (config>card>fp>ingress>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
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>ingress policer-control-override)
[Tree] (config>service>epipe>sap>egress policer-control-override)
[Tree] (config>service>ipipe>sap>egress policer-control-override)
[Tree] (config>service>cpipe>sap>egress policer-control-override)
[Tree] (config>service>ipipe>sap>ingress policer-control-override)
[Tree] (config>service>epipe>sap>ingress policer-control-override)
Full Context
configure service cpipe sap ingress policer-control-override
configure service epipe sap egress policer-control-override
configure service ipipe sap egress policer-control-override
configure service cpipe sap egress policer-control-override
configure service ipipe sap ingress policer-control-override
configure service epipe 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 ingress policer-control-override
- configure service ipipe sap ingress policer-control-override
- configure service epipe sap egress 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>ingress policer-control-override)
[Tree] (config>service>vpls>sap>egress policer-control-override)
Full Context
configure service vpls sap ingress policer-control-override
configure service vpls 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
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>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
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>ingress policer-control-override)
[Tree] (config>service>vprn>if>sap>egress policer-control-override)
Full Context
configure service vprn interface sap ingress policer-control-override
configure service vprn 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
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>egress 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>ingress policer-control-policy)
Full Context
configure service ies subscriber-interface group-interface sap egress policer-control-policy
configure service vprn subscriber-interface group-interface sap egress policer-control-policy
configure service ies subscriber-interface group-interface sap ingress 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>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
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>ipipe>sap>egress policer-control-policy)
[Tree] (config>service>ipipe>sap>ingress policer-control-policy)
[Tree] (config>service>epipe>sap>egress policer-control-policy)
[Tree] (config>service>epipe>sap>ingress policer-control-policy)
[Tree] (config>service>cpipe>sap>egress policer-control-policy)
[Tree] (config>service>cpipe>sap>ingress policer-control-policy)
Full Context
configure service ipipe sap egress policer-control-policy
configure service ipipe sap ingress policer-control-policy
configure service epipe sap egress policer-control-policy
configure service epipe sap ingress policer-control-policy
configure service cpipe sap egress policer-control-policy
configure service cpipe 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 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, VSR
- configure service ipipe sap ingress policer-control-policy
- configure service epipe sap ingress policer-control-policy
- configure service ipipe sap egress policer-control-policy
- configure service epipe sap egress policer-control-policy
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
policer-control-policy
Syntax
policer-control-policy policy-name
no policer-control-policy
Context
[Tree] (config>service>vpls>sap>ingress policer-control-policy)
[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>egress policer-control-policy)
Full Context
configure service vpls sap ingress policer-control-policy
configure service template vpls-sap-template egress policer-control-policy
configure service template vpls-sap-template 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
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>ingress policer-control-policy)
[Tree] (config>service>ies>if>sap>egress policer-control-policy)
Full Context
configure service ies interface sap ingress policer-control-policy
configure service ies 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
no policer-control-policy
Context
[Tree] (config>service>vprn>if>sap>egress policer-control-policy)
[Tree] (config>service>vprn>if>sap>ingress policer-control-policy)
Full Context
configure service vprn interface sap egress policer-control-policy
configure service vprn 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 [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>cpipe>sap>ingress policer-override)
[Tree] (config>service>cpipe>sap>egress policer-override)
[Tree] (config>service>ipipe>sap>ingress policer-override)
[Tree] (config>service>epipe>sap>egress policer-override)
[Tree] (config>service>ipipe>sap>egress policer-override)
[Tree] (config>service>epipe>sap>ingress policer-override)
Full Context
configure service cpipe sap ingress policer-override
configure service cpipe sap egress policer-override
configure service ipipe sap ingress policer-override
configure service epipe sap egress policer-override
configure service ipipe sap egress policer-override
configure service epipe 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
- configure service cpipe sap ingress policer-override
- configure service cpipe sap egress policer-override
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
- configure service epipe sap ingress policer-override
- configure service ipipe sap egress policer-override
- configure service ipipe sap ingress policer-override
- configure service epipe sap egress 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>egress policer-override)
[Tree] (config>service>ies>if>sap>ingress policer-override)
Full Context
configure service ies interface sap egress policer-override
configure service ies interface 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-override
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer-override
Syntax
[no] policer-override
Context
[Tree] (config>service>vprn>if>sap>ingress policer-override)
[Tree] (config>service>vprn>if>sap>egress policer-override)
Full Context
configure service vprn interface sap ingress policer-override
configure service vprn interface sap egress policer-override
Description
This command, within the SAP ingress or egress contexts, is used to create a CLI node for specific overrides to one or more policers created on the SAP through the sap-ingress or sap-egress QoS policies.
The no form of this command is used to remove any existing policer overrides.
Default
no policer-override
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, 7950 XRS, VSR
policer-stats
policer-stats
Syntax
[no] policer-stats
Context
[Tree] (config>app-assure>group>statistics>aa-admit-deny policer-stats)
Full Context
configure application-assurance group statistics aa-admit-deny policer-stats
Description
This command configures whether to include or exclude system and subscriber-level flow count and flow-setup rate policer admit-deny statistics in accounting records.
Default
no policer-stats
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
policer-stats-resources
policer-stats-resources
Syntax
[no] policer-stats-resources
Context
[Tree] (config>app-assure>group>statistics>aa-admit-deny policer-stats-resources)
Full Context
configure application-assurance group statistics aa-admit-deny policer-stats-resources
Description
This command allows the operator to allocate or deallocate AA partition resources for policer admit-deny statistics.
Default
no policer-stats-resources
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
policers
policers
Syntax
policers policy-limit
no policers
Context
[Tree] (config>card>fp>ingress>policy-accounting policers)
Full Context
configure card fp ingress policy-accounting policers
Description
This command configures the number of policer resources for an policy accounting. Policy accounting can be used to collect statistics about the amount of traffic matching particular routes and, on FP4 cards and systems only, it can also be used to police traffic associated with certain routes as destinations of the traffic.
Using only statistics (policing is not performed) requires the reservation of policer statistics index resources on each FP receiving the traffic to be counted. Every policy-accounting interface on a card or FP uses one of these resources for every source and destination class index listed in the template referenced by the interface. The total reservation at the FP level is set using the configure card slot-number fp fp-number policy-accounting command.
Using FP4 policing requires the above resource, and in addition, policer index resources. Every policy-accounting interface on a card or FP uses one of these resources for every destination class associated with a policer in the template referenced by the interface. The total reservation of this second resource at the FP level is set using the configure card slot-number fp fp-number ingress policy-accounting policers command.
The total number of the above resources, per FP, must be less than or equal to 128000. In addition, the second resource pool size must be less than or equal to the size of the first resource pool.
It is possible to increase or decrease the size of either resource sub pool at any time. A decrease can cause some interfaces (randomly selected) to immediately lose their resources and stop counting or policing some traffic that was previously being counted or policed.
If the policy accounting is enabled on a spoke SDP or R-VPLS interface all FPs in the system should have a reservation for each of the above resources, otherwise the show router interface policy-accounting command output reports that statistics are possibly incomplete.
Default
no policers
Parameters
- policy-limit
-
Specifies the number of policer resources for policy accounting.
Platforms
7450 ESS, 7750 SR, 7750 SR-s, 7950 XRS
policers
Syntax
policers [all-dynamic | all-static]
Context
[Tree] (config>subscr-mgmt>sla-prof>aggregate-qos-stats>egress policers)
Full Context
configure subscriber-mgmt sla-profile aggregate-qos-stats egress policers
Description
This command configures which types of policers are used to calculate the total egress aggregate statistics. This can include all static policers that are configured in a QoS SAP-egress policy, or all dynamic policers that are created on demand, according to the session needs.
Default
policers all-static
Parameters
- all-dynamic
- Keyword that specifies to select all dynamic policers for aggregate QoS egress statistics calculation.
- all-static
- Keyword that specifies to select all static policers for aggregate QoS egress statistics calculation.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
policers-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>ppp>host>msap-defaults policy)
[Tree] (config>subscr-mgmt>loc-user-db>ipoe>host>msap-defaults policy)
Full Context
configure subscriber-mgmt local-user-db ppp host msap-defaults policy
configure subscriber-mgmt local-user-db ipoe 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 (#, $, spaces, and so on), the entire string must be enclosed within double quotes.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
policy
Syntax
policy name1 [name2] [ name3] [name4] [name5]
no policy
Context
[Tree] (config>subscr-mgmt>sub-prof>rad-acct policy)
Full Context
configure subscriber-mgmt sub-profile radius-accounting policy
Description
This command specifies the RADIUS accounting policy for the subscriber that is using this subscriber profile. This command allows the configuration of up to five RADIUS accounting policies. The RADIUS accounting policies function according to their respective configuration, including the individual accounting mode, their own included attributes, and the update interval.
Parameters
- name1
-
Specifies the name of the RADIUS accounting policy, up to 32 characters, to be used for the subscriber profile.
- name2
-
Specifies the name of the second RADIUS accounting policy, up to 32 characters, to be used for the subscriber profile.
- name3
-
Specifies the name of the third RADIUS accounting policy, up to 32 characters, to be used for the subscriber profile.
- name4
-
Specifies the name of the fourth RADIUS accounting policy, up to 32 characters, to be used for the subscriber profile.
- name5
-
Specifies the name of the fifth RADIUS accounting policy, up to 32 characters, to be used for the subscriber profile.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
policy
Syntax
policy vrrp-policy-id
no policy[vrrp-policy-id]
Context
[Tree] (config>service>vprn>sub-if>grp-if>srrp policy)
[Tree] (config>service>ies>sub-if>grp-if>srrp policy)
Full Context
configure service vprn subscriber-interface group-interface srrp policy
configure service ies subscriber-interface group-interface srrp policy
Description
This command associates one or more VRRP policies with the SRRP instance. A VRRP policy is a collection of connectivity and verification tests used to manipulate the in-use priorities of VRRP and SRRP instances. A VRRP policy can test the link state of ports, ping IP hosts, discover the existence of routes in the routing table or the ability to reach Layer 2 hosts. When one or more of these tests fail, the VRRP policy has the option of decrementing or setting an explicit value for the in-use priority of an SRRP instance.
More than one VRRP policy may be associated with an SRRP instance. When more than one VRRP policy is associated with an SRRP instance the delta decrement of the in-use priority is cumulative unless one or more test fail that have explicit priority values. When one or more explicit tests fail, the lowest priority value event takes effect for the SRRP instance. When the highest delta-in-use-limit is used to manage the lowest delta derived in-use priority for the SRRP instance.
VRRP policy associations may be added and removed at any time. A maximum of two VRRP policies can be associated with a single SRRP instance.
The no form of this command removes the association with the vrrp-policy-id from the SRRP instance.
Parameters
- vrrp-policy-id
-
Specifies one or more VRRP policies with the SRRP instance.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
policy
Syntax
[no] policy policy-name
Context
[Tree] (debug>diam>application policy)
Full Context
debug diameter application policy
Description
This command debugs Diameter applications for a particular application policy.
Parameters
- policy-name
-
Specifies the policy name, up to 32 characters.
Platforms
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
policy
Syntax
policy msap-policy-name
no policy
Context
[Tree] (config>service>vpls>sap>msap-defaults policy)
Full Context
configure service vpls sap msap-defaults policy
Description
This command sets default msap-policy for all subscribers created based on trigger packets received on the specified capture-sap in case the corresponding VSA is not included in the RADIUS authentication response. This command is applicable to capture SAP only.
Default
no policy
Platforms
All
policy
Syntax
policy policy-name
no policy
Context
[Tree] (config>service>vpls>mesh-sdp>igmp-snooping>mcac policy)
[Tree] (config>service>vpls>spoke-sdp>igmp-snooping>mcac policy)
[Tree] (config>service>vpls>sap>igmp-snooping>mcac policy)
[Tree] (config>service>vpls>spoke-sdp>mld-snooping>mcac policy)
[Tree] (config>service>pw-template>igmp-snooping>mcac policy)
[Tree] (config>service>vpls>sap>mld-snooping>mcac policy)
[Tree] (config>service>vpls>mesh-sdp>mld-snooping>mcac policy)
Full Context
configure service vpls mesh-sdp igmp-snooping mcac policy
configure service vpls spoke-sdp igmp-snooping mcac policy
configure service vpls sap igmp-snooping mcac policy
configure service vpls spoke-sdp mld-snooping mcac policy
configure service pw-template igmp-snooping mcac policy
configure service vpls sap mld-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 (#, $, spaces, and so on), the entire string must be enclosed within double quotes.
Platforms
All
policy
Syntax
policy vrrp-policy-id
no policy
Context
[Tree] (config>service>ies>if>ipv6>vrrp policy)
Full Context
configure service ies interface ipv6 vrrp policy
Description
This command creates VRRP control policies. The VRRP policy ID must be created by the policy command prior to association with the virtual router instance.
The policy command provides the ability to associate a VRRP priority control policy to a virtual router instance. The policy may be associated with more than one virtual router instance. The priority events within the policy either override or diminish the base-priority dynamically affecting the in-use priority. As priority events clear in the policy, the in-use priority may eventually be restored to the base-priority value.
The policy command is only available in the non-owner vrrp virtual-router-id nodal context. The priority of owner virtual router instances is permanently set to 255 and cannot be changed by VRRP priority control policies. For non-owner virtual router instances, if the policy command is not executed, the base-priority will be used as the in-use priority.
The no form of this command removes any existing VRRP priority control policy association from the virtual router instance. All such associations must be removed prior to the policy being deleted from the system.
Parameters
- vrrp-policy-id
-
The vrrp-policy-id parameter associated the corresponding VRRP priority control policy-id with the virtual router instance. The vrrp-policy-id must already exist in the system for the policy command to be successful.
Platforms
All
policy
Syntax
policy vrrp-policy-id
no policy
Context
[Tree] (config>service>ies>if>vrrp policy)
Full Context
configure service ies interface vrrp policy
Description
This command creates VRRP control policies. The VRRP policy ID must be created by the policy command prior to association with the virtual router instance.
The policy command provides the ability to associate a VRRP priority control policy to a virtual router instance. The policy may be associated with more than one virtual router instance. The priority events within the policy either override or diminish the base-priority dynamically affecting the in-use priority. As priority events clear in the policy, the in-use priority may eventually be restored to the base-priority value.
The policy command is only available in the non-owner vrrp virtual-router-id nodal context. The priority of owner virtual router instances is permanently set to 255 and cannot be changed by VRRP priority control policies. For non-owner virtual router instances, if the policy command is not executed, the base-priority will be used as the in-use priority.
The no form of this command removes any existing VRRP priority control policy association from the virtual router instance. All such associations must be removed prior to the policy being deleted from the system.
Parameters
- vrrp-policy-id
-
The vrrp-policy-id parameter associated the corresponding VRRP priority control policy-id with the virtual router instance. The vrrp-policy-id must already exist in the system for the policy command to be successful.
Platforms
All
policy
Syntax
policy policy-name
no policy
Context
[Tree] (config>service>vprn>bgp>next-hop-res policy)
Full Context
configure service vprn bgp next-hop-resolution policy
Description
This command specifies the name of a policy statement to use with the BGP next-hop resolution process. The policy controls which IP routes in RTM are eligible to resolve the BGP next-hop addresses of IPv4 and IPv6 routes. The policy has no effect on the resolution of BGP next-hops to MPLS tunnels. If a BGP next-hop of an IPv4 or IPv6 route R is resolved in RTM and the longest matching route for the next-hop address is an IP route N that is rejected by the policy then route R is unresolved; if the route N is accepted by the policy then it becomes the resolving route for R.
The default next-hop resolution policy (when the no policy command is configured) is to use the longest matching active route in RTM that is not a BGP route (unless use-bgp-routes is configured), an aggregate route or a subscriber management route.
Default
no policy
Parameters
- policy-name
-
Specifies the route policy name. Allowed values are any string up to 32 characters composed of printable, 7-bit ASCII characters. If the string contains special characters (#, $, spaces, and so on), 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>grp-if>mcac policy)
[Tree] (config>service>vprn>mld>grp-if>mcac policy)
[Tree] (config>service>vprn>igmp>if>mcac policy)
[Tree] (config>service>vprn>pim>if>mcac policy)
Full Context
configure service vprn igmp group-interface mcac policy
configure service vprn mld group-interface mcac policy
configure service vprn igmp interface mcac policy
configure service vprn pim 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 (#, $, spaces, and so on), the entire string must be enclosed between double quotes.
Platforms
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
All
- configure service vprn pim interface mcac policy
- configure service vprn igmp interface mcac policy
policy
Syntax
policy vrrp-policy-id
no policy
Context
[Tree] (config>service>vprn>if>vrrp policy)
[Tree] (config>service>vprn>if>ipv6>vrrp policy)
Full Context
configure service vprn interface vrrp policy
configure service vprn interface ipv6 vrrp policy
Description
This command associates a VRRP priority control policy with the virtual router instance (non-owner context only).
Parameters
- vrrp-policy-id
-
Specifies a VRRP priority control policy.
Platforms
All
policy
Syntax
policy
Context
[Tree] (config>app-assure>group policy)
Full Context
configure application-assurance group policy
Description
Commands in this context configure parameters for application assurance policy. To edit any policy content begin command must be executed first to enter editing mode. The editing mode is left when the abort or commit commands are issued.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
policy
Syntax
policy aa-sub {sap sap-id | spoke-sdp sdp-id:vc-id | transit transit-aasub-name} [create]
no policy aa-sub {sap sap-id | spoke-sdp sdp-id:vc-id | transit transit-aasub-name}
Context
[Tree] (config>app-assure>group>policy-override policy)
Full Context
configure application-assurance group policy-override policy
Description
This command specifies a given SAP or SDP to be used for a static policy override.
The no form of this command removes the policy override.
Parameters
- sap-id
-
Specifies the physical port identifier portion of the SAP definition.
- sdp-id:vc-id
-
Specifies the spoke SDP ID and VC ID.
- transit-aasub-name
-
Specifies an existing transit subscriber name, up to 32 characters.
- create
-
Keyword used to create the policy override.
Platforms
7450 ESS, 7750 SR, 7750 SR-e, 7750 SR-s, VSR
policy
Syntax
policy policy-name
no policy
Context
[Tree] (config>router>mcac policy)
[Tree] (config>router>mld>interface policy)
[Tree] (config>router>igmp>interface>mcac policy)
[Tree] (config>router>igmp>grp-if>mcac policy)
[Tree] (config>router>mld>group-interface policy)
[Tree] (config>router>pim>interface policy)
Full Context
configure router mcac policy
configure router mld interface policy
configure router igmp interface mcac policy
configure router igmp group-interface mcac policy
configure router mld group-interface policy
configure router pim 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 igmp interface mcac policy
- configure router mcac policy
- configure router pim interface policy
7450 ESS, 7750 SR, 7750 SR-a, 7750 SR-e, 7750 SR-s, VSR
- configure router igmp group-interface mcac policy
- configure router mld group-interface policy
policy
Syntax
policy vrrp-policy-id
no policy
Context
[Tree] (config>router>if>ipv6>vrrp policy)
[Tree] (config>router>if>vrrp policy)
Full Context
configure router interface ipv6 vrrp policy
configure router interface vrrp policy
Description
This command adds a VRRP priority control policy association with the virtual router instance.
To further augment the virtual router instance base priority, VRRP priority control policies can be used to override or adjust the base priority value depending on events or conditions within the chassis.
The policy can be associated with more than one virtual router instance. The priority events within the policy either override or diminish the base priority set with the priority command dynamically affecting the in-use priority. As priority events clear in the policy, the in-use priority can eventually be restored to the base priority value.
The policy command is only available in the non-owner vrrp nodal context. The priority of owner virtual router instances is permanently set to 255 and cannot be changed by VRRP priority control policies. For non-owner virtual router instances, if the policy command is not executed, the base priority is used as the in-use priority.
The no form of the command removes existing VRRP priority control policy associations from the virtual router instance. All associations must be removed prior to deleting the policy from the system.
Default
no policy — No VRRP priority control policy is associated with the virtual router instance.
Parameters
- vrrp-policy-id
-
The policy ID of the VRRP priority control expressed as a decimal integer. The vrrp-policy-id must already exist for the command to function.
Platforms
All
policy
Syntax
policy policy-id context context-value
policy policy-id context name name
no policy policy-id
Context
[Tree] (config>vrrp policy)
Full Context
configure vrrp policy
Description
This command creates the context to configure a VRRP priority control policy which is used to control the VRRP in-use priority based on priority control events. It is a parental node for the various VRRP priority control policy commands that define the policy parameters and priority event conditions.
The virtual router instance priority command defines the initial or base value to be used by non-owner virtual routers. This value can be modified by assigning a VRRP priority control policy to the virtual router instance. The VRRP priority control policy can override or diminish the base priority setting to establish the actual in-use priority of the virtual router instance.
The policy policy-id command must be created first, before it can be associated with a virtual router instance.
Because VRRP priority control policies define conditions and events that must be maintained, they can be resource intensive. The number of policies is limited to 1000.
The policy-id do not have to be consecutive integers. The range of available policy identifiers is from 1 to 9999.
The no form of the command deletes the specific policy-id from the system. The policy-id must be removed first from all virtual router instances before the no policy command can be issued. If the policy-id is associated with a virtual router instance, the command will fail.
Parameters
- policy-id
-
The VRRP priority control ID expressed as a decimal integer that uniquely identifies this policy from any other VRRP priority control policy defined on the system. Up to 1000 policies can be defined.
- context-value
-
Specifies the service ID to which this policy applies. A value of zero (0) means that this policy does not apply to a service but applies to the base router instance.
Platforms
All
policy
Syntax
policy cpu-protection-policy-id [create]
no policy cpu-protection-policy-id
Context
[Tree] (config>sys>security>cpu-protection policy)
Full Context
configure system security cpu-protection policy
Description
This command configures CPU protection policies.
The no form of this command deletes the specified policy from the configuration.
Policies 254 and 255 are reserved as the default access and network interface policies, and cannot de deleted. The parameters within these policies can be modified. An event will be logged (warning) when the default policies are modified.
Default
Policy 254 (default access interface policy):
-
per-source-rate: max (no limit)
-
overall-rate: 6000
-
out-profile–rate: 6000
-
alarm
Policy 255 (default network interface policy):
-
per-source-rate: max (no limit)
-
overall-rate: max (no limit)
-
out-profile-rate: 3000
-
alarm
Parameters
- cpu-protection-policy-id
-
Assigns a policy ID to the specific CPU protection policy.
- create
-
Keyword used to create CPU protection policy. The create keyword requirement can be enabled/disabled in the environment>create context.
Platforms
7450 ESS, 7750 SR-7/12/12e, 7750 SR-7s, 7750 SR-14s, 7950 XRS
policy
Syntax
policy policy-name [create] [type {access-network | port}]
no policy policy-name
Context
[Tree] (config>sys>security>dist-cpu-protection policy)
Full Context
configure system security dist-cpu-protection policy
Description
This command configures one of the maximum 18 Distributed CPU Protection (DCP) policies. These policies can be applied to objects such as SAPs, network interfaces or ports.
Parameters
- policy-name
-
Specifies the name of the policy, up to 32 characters.
- create
-
Keyword used to create a new policy.
- type
-
Specifies the Distributed CPU protection type for the policy.
Platforms
All
policy
Syntax
policy policy-name
no policy
Context
[Tree] (config>router>bgp>next-hop-resolution policy)
Full Context
configure router bgp next-hop-resolution policy
Description
This command specifies the policy statement name to use with the BGP next-hop resolution process. The policy determines the eligibility of IP routes in the RTM to resolve the BGP next-hop addresses of IPv4 and IPv6 routes. The policy has no effect on the resolution of BGP next hops to MPLS tunnels.
For example, if a BGP next hop of an IPv4 or IPv6 route R is resolved in RTM and the longest matching route for the next-hop address is an IP route N that is rejected by the policy then route R is unresolved. If the route N is accepted by the policy, it becomes the resolving route for R.
The no form of this command reverts to the default next-hop resolution policy, which uses the longest matching active route in RTM that is not a BGP route (unless use-bgp-routes is configured), an aggregate route or a subscriber management route.
Default
no policy
Parameters
- policy-name
-
Specifies the route policy name. Allowed values are any string up to 64 characters long composed of printable, 7-bit ASCII characters. If the string contains special characters (#, $, spaces, and so on), 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 (#, $, spaces, and so on), 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-template>pce-assoc policy)
[Tree] (config>router>mpls>lsp>pce-assoc policy)
Full Context
configure router mpls lsp-template pce-associations policy
configure router mpls lsp 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 (#, $, spaces, and so on), 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 (#, $, spaces, and so on), the entire string must be enclosed within double quotes.
Platforms
All
policy-variables
policy-variables
Syntax
policy-variables
Context
[Tree] (config>router>policy-options>policy-statement>entry>from policy-variables)
Full Context
configure router policy-options policy-statement entry from policy-variables
Description
Commands in this context configure policy-variables parameters.
The no form of this command removes all policy variables.
Platforms
All
poll
poll
Syntax
poll ca ca-profile-name
Context
[Tree] (admin>certificate>cmpv2 poll)
Full Context
admin certificate cmpv2 poll
Description
This command polls the status of the pending CMPv2 request toward the specified CA.
If the response is ready, this command will resume the CMPv2 protocol exchange with server as the original command would do. The requests could be also still be pending as a result, then this command could be used again to poll the status.
SR OS allows only one pending CMP request per CA, which means no new request is allowed when a pending request is present.
Parameters
- ca-profile-name
-
Specifies a ca-profile name up to 32 characters.
Platforms
All
poll-interval
poll-interval
Syntax
poll-interval seconds
no poll-interval
Context
[Tree] (config>service>vprn>ospf3>area>if poll-interval)
[Tree] (config>service>vprn>ospf>area>if poll-interval)
Full Context
configure service vprn ospf3 area interface poll-interval
configure service vprn ospf area interface poll-interval
Description
This command configures the poll interval, in seconds. The poll interval is the time between two Hello packets to a dead (non-adjacent) OSPF NBMA neighbor. The default value of the poll interval timer is higher than the hello interval timer to avoid wasting bandwidth on non-broadcast networks, since OSPF messages are unicast to each configured neighbor. The poll interval timer is used only on non-broadcast interface types and has no effect if configured on other interface types.
The no form of this command removes the poll-interval configuration.
Default
120
Parameters
- seconds
-
Specifies the poll interval, in seconds.
Platforms
All
poll-interval
Syntax
poll-interval seconds
no poll-interval
Context
[Tree] (config>router>ospf>area>interface poll-interval)
[Tree] (config>router>ospf3>area>interface poll-interval)
Full Context
configure router ospf area interface poll-interval
configure router ospf3 area interface poll-interval
Description
This command configures the poll interval, in seconds. The poll interval is the time between two Hello packets to a dead (non-adjacent) OSPF NBMA neighbor. The default value of the poll interval timer is higher than the hello interval timer to avoid wasting bandwidth on non-broadcast networks, since OSPF messages are unicast to each configured neighbor. The poll interval timer is used only on non-broadcast interface types and has no effect if configured on other interface types.
The no form of this command removes the poll-interval configuration.
Default
120
Parameters
- seconds
-
Specifies the poll interval, in seconds.
Platforms
All