This command enables the context to use the OAM test suite.

This command enables the GSMP ANCP OAM capability to be negotiated at startup of the GSMP connection.

The no form of this command disables the feature.

This command enables the context to configure OAM functionality for a PVCC delimiting a SAP.

The ATM-capable MDAs support F5 end-to-end OAM functionality (AIS, RDI, Loopback):

This command enables the context to configure OAM functionality for a PVCC delimiting a SAP.

This command enters the context to configure OAM functionality for a PVCC delimiting a SAP.

The ATM-capable MDAs support F5 end-to-end OAM functionality (AIS, RDI, Loopback):

This command enables OAM debugging.

This command configures system-wide ATM parameters.

This command monitors the OAM performance statistics.

This command allows the operator to start and stop on-demand OAM-PM sessions.

This is the top level context that contains the configuration parameters that defines storage parameters (including binning structures), availability/resiliency and the individual proactive, and on-demand tests used to gather the performance/statistical information.

This command enables the context to monitor Operations, Administration, and Maintenance Performance Management information.

This command creates or edits an OAM template Generally applicable proactive OAM parameters are configured using templates. The top-level template is the OAM template.

Generic MPLS-TP OAM and fault management parameters are configured in the OAM Template.

Proactive CC/CV uses BFD and parameters such as Tx/Rx timer intervals, multiplier and other session/fault management parameters specific to BFD are configured using a BFD Template, which is referenced from the OAM template.

This command applies an OAM template to an MPLS-TP working or protect path. It contains configuration parameters for proactive OAM mechanisms that can be enabled on the path; for example, BFD. Configuration of an OAM template is optional.

The no form of this command removes the OAM template from the path.

This command enables debug output of OCSP protocol for the specified CA.

This command enables debug output of the OCSP protocol for a CA profile.

The no form of this command disables the debug output.

This command enables the context to configure OCSP parameters.

This command enables the inclusion of the octet-counters attributes.

The no form of the command excludes octet-counters attributes.

This command includes the admitted octet count in the AA subscriber's custom record and only applies to the 7750 SR.

The no form of this command excludes the admitted octet count.

This command includes the denied octet count in the AA subscriber's custom record and only applies to the 7750 SR.

The no form of this command excludes the denied octet count.

This command configures the OpenFlow controller for this OpenFlow switch and creates a context for the configuration of additional OpenFlow control channel parameters. Up to two controllers can be configured per OpenFlow switch instance.

The no form of this command deletes the controller for this OpenFlow switch instance.

This command creates an OpenFlow switch instance.

The no form of the command deletes the OpenFlow switch instance from the context.

This command enables the context for configuring a discover delay to influence the offer selection of DHCPv4 clients.

This command configures the time interval during which a DHCP offer is valid.

The no form of this command reverts to the default.

This command modifies the offered rate measurement used to determine the bandwidth the queue or policer is requesting from its parent virtual scheduling context.

This command modifies the parameters that control the child requested bandwidth for all policers and queues associated with the policy.

This command specifies the number of minutes that will be added to the time when summer time takes effect. The same number of minutes will be subtracted from the time when the summer time ends.

This command is used to enable a CAC failure-triggered IGP update.

The no form of this command should reset on-cac-failure to the default value and disable the CAC failure-triggered IGP update.

This command debugs Diameter node errors. Only errors raised before the peer is determined. For example, there is no route for this message in the realm routing table, and therefore the peer cannot be determined.

This command reports only peer error conditions.

This command debugs Diameter application errors and reports only peer error conditions, for example, an unknown session-id.

This command is applicable only to the R16.0R4 or later implementation of Diameter base in the SR OS.

This command configures session failure handling. The behavior of a Diameter application (Gx, Gy, or NASREQ) that fails to receive a response (an answer message CCA) to a transmitted request message (CCR) for a session, can be controlled by the Diameter server through two AVPs carried in CCA messages that are defined in RFC 4006, Diameter Credit-Control Application:

If those AVPs are not provided by the Diameter server, the local configuration provided by this command takes effect. This command defines the following:

This command is applicable only to legacy implementation of Diameter base in the SR OS.

This command configures session failure handling. The behavior of the application’s session in case of a peer failure can be controlled by the Diameter server through two AVPs carried in CCA messages that are defined in RFC 4006, Diameter Credit-Control Application:

If those AVPs are not provided by the Diameter server, the local configuration provided by this command will take effect. This command defines the following:

This command specifies whether the prefix is assigned to an interface on the specified link.

The no form of this command reverts to the default.

This command specifies whether the prefix is to be assigned to an interface on the specified link.

The no form of this command reverts to the default.

This command specifies whether the prefix can be used for onlink determination.

This command specifies whether the prefix can be used for on link determination.

This command enables the sending of one gratuitous ARP to each SAP and is applicable to PPPoE only deployments in which there are multiple subnets under the subscriber interface. In such case, if the switchover occurs, it is sufficient to send a single Gratuitous ARP on every VLAN to update the Layer 2 forwarding path in the access aggregation network. This single gratuitous ARP will contain the IP address of the first GW address found under the subscriber interface address.

The no form of this command reverts to the default.

This command specify the one-time http redirection filter id. This filter will apply to the host when host is created, and is replaced by the sla-profile ingress filter (configured in the config>subscr-mgmt>sla-prof>ingress context) after first HTTP request from host has been redirected.

Note: The system does not check if the configured filter include http-redirection entry. If the filter does not include the http-redirection then it will not be replaced in future.

If 7750 SR receives filter insertion via CoA or access-accept when one-time redirection filter is still active then the received filter entries will only be applied to the sla-profile ingress filter. And after 1st http redirection, the original sla-profile ingress filter + received filter will replace the redirection filter.

The no form of this command reverts to the default.

This command produces one-time HTTP redirection debug output.

This command enables one-time http-redirect to specify redirect URL for traffic matching the specified destination port.

The no form of this command reverts to the default.

This command issues an ETH-CFM one-way delay test.

This command enables one way delay threshold time limit.

This command enables/disables eth-test functionality on MEP.

This command enables/disables eth-test functionality on MEP.

This command enables one way delay threshold time limit.

This command enables one way delay threshold time limit.

This command enables a one-way delay threshold time limit.

This command configures a one way delay threshold time limit.

This command specifies 16-byte opaque data HEX string to be inserted in NSH meta-data (with MD-Type set to 1). The opaque data can also be provided (overridden) by AAA server. AAA server has precedence over static configuration. The opaque-data and insert-subscriber-id commands are mutually exclusive.

The no form of this command removes the HEX string from the configuration.

This command specifies the PCP opcodes supported by the PCP servers using this PCP policy.

This command decodes and logs all sent and received open messages in the debug log.

The no form of this command disables debugging.

This command enables configuration content for OpenFlow Hybrid Switch compatibility.

The no form of the command removes the OpenFlow configuration from the context.

This command operationally brings down the WLAN-GW group if the total number of operational WLAN-GW IOMs in the WLAN-GW group fall below the configured number of active WLAN-GW IOMs. This triggers withdrawal of the route to tunnel endpoint and subscriber subnets in routing.

This command associates an operational group to the status of the Epipe. When this oper-group is used in Epipes with static VXLAN or BGP-EVPN, the oper-group behaves as follows:

The operational group must be monitored in a different service and not in the service where it is defined.

The no version of this command removes the oper-group association.

This command adds the bgp-evpn mpls instance or an Ethernet Segment (ES) as a member of the oper-group.

When configured on a bgp-evpn instance, the oper-group is up when it is either empty (meaning that the oper-group has no members) or at least an EVPN destination is created under the EVPN instance added as member. When configured, no other SAP, SDP binding, or bgp-evpn instance can be added to the same oper-group within the same or different service.

The oper-group will be down when it is applied on a bgp-evpn instance as well as:

When configured on an ES, the state of the oper-group depends on the state of the SAPs contained in the ES. The oper-group transitions to up if at least one SAP in the ES is up. The oper-group goes down when all the associated SAPs are operationally down. The ES oper-group should be monitored on the LAG associated to the ES, along with single-active multi-homing, so that the NDF state can be signaled to the CE by LAG standby signaling.

This command associates an operational group to the VXLAN static egress VTEP. If the egress VTEP IP disappears from the routing table, the oper-group status will become operationally down.

The operational group must be monitored in a different service and not in the service where it is defined.

The no version of this command removes the oper-group association.

This command configures the operational group identifier.

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

This command associates the context to which it is configured to the operational group specified in the group-name. The oper-group oper-name must be already configured under config>service context before its name is referenced in this command.

The no form of this command removes the association.

This command configures VRRP to associate with an operational group. When associated, VRRP notifies the operational group of its state changes so that other protocols can monitor it to provide a redundancy mechanism. When VRRP is the master router (MR), the operational group is up and is down for all other VRRP states.

The no form of this command removes the association.

This command configures VRRP to associate with an operational group. When associated, VRRP notifies the operational group of its state changes so that other protocols can monitor it to provide a redundancy mechanism. When VRRP is the master router (MR), the operational group is up and is down for all other VRRP states.

The no form of this command removes the association.

This command configures VRRP to associate with an operational group. When associated, VRRP notifies the operational group of its state changes so that other protocols can monitor it to provide a redundancy mechanism. When VRRP is the master router (MR), the operational group is up; the operational group is down for all other VRRP states.

The no form of the command removes the association.

This command creates a system-wide group (operational group) name which can be used to associate a number of service objects (for example, SAPs or pseudowires). The status of the group is derived from the status of its members. The status of the group can then be used to influence the status of non-member objects. For example, when a group status is marked as down, the object(s) that monitor the group change their status accordingly.

The no form of the command removes the group. All the object associations need to be removed before the no form of the command can be executed.

This command sets the threshold for the minimum number of operational links for the associated link-group. If the number of operational links drops below this threshold, the configured offsets are applied. For example, oper-members=3. The metric of the member interfaces is increased when the number of interfaces is lower than 3.

The no form of this command reverts the oper-members limit to 1.

This command sets the threshold for the minimum number of operational links for the associated link-group. If the number of operational links drops below this threshold, the configured offsets are applied. For example, oper-members=3. The metric of the member interfaces is increased when the number of interfaces is lower than 3.

The no form of this command reverts the oper-members limit to 1.

This command allows the subscriber interface to treat this group interface to be operationally enabled without any active SAPs.

This command is typically used with MSAPs where advertising the subnet prior to having a MSAP dynamically created is needed.

The no form of this command reverts to the default.

This command specifies optional data relevant to the IGMP event that can be exported. This optional data includes:

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

This command creates the optimal route reflection context.

This command enables the cpm-http-redirect optimized-mode. The optimized-mode improves the scale of HTTP redirect sessions supported system wide.

This command configures match criteria for the DHCP filter policy entry.

The no form of this command reverts to the default.

This command configures match criteria for the DHCP6 filter policy entry.

The no form of this command reverts to the default.

This command configures DHCPv4 options via LUDB that are passed in all DHCP messages to the client. The options are blindly appended to any options already present in the DHCP message. In other words, there is no intelligent merging of the options where overlapping options from different sources are further evaluated to determine whether only one option or multiple options should be returned to the client.

Multiple DHCP options can be configured at the same time although each option requires its own option statement. Those options are equivalent to RADIUS VSAs Alc-ToCLient-Dhcp4-Options.

DHCPv4 options can be provided via DHCPv4 server in the relay case. In addition, DHCPv4 options provided via LUDB or RADIUS can be supplied and consequently appended to the already existing options. If DHCPv4 options are provided simultaneously via LUDB and RADIUS, the RADIUS as a source of DHCPv4 option is blocked and the options supplied via LUDB are passed to the client. This is valid for the relay and proxy case.

Any DHCP option may be encoded in the option statement. An example of the option statement for DHCPv4 default-gateway is given below:

option 3 192.168.1.254

DHCPv4 options may be fixed length or variable length. They are appended at the end of DHCPv4 messages. All options begin with a tag octet, which uniquely identifies the option. Fixed-length options without data consist of only a tag octet. Only options 0 and 255 are fixed length. All other options are variable-length.

The no form of the removes the option from the configuration.

This command specifies the DHCPv6 options to send to the server.

The no form of this command removes the option parameters from the configuration.

This command enables the context to configure DHCPv6 relay information options.

The no form of this command disables DHCPv6 relay information options.

This command enables DHCP Option 82 (Relay Agent Information Option) parameters processing and enters the context for configuring Option 82 sub-options.

The no form of this command reverts to the default.

This command configures the PCP options supported by the PCP servers using this PCP policy.

This command configures allows options to be associated with the authentication key.

This command configures the option-present match condition.

The no form of this command reverts to the default.

This command configures matching packets that contain any IP options in the IP header as an IP filter match criterion.

The no form of the command removes the checking of IP options in the IP header as a match criterion.

This command configures matching packets that contain the option field or have an option field of zero in the IP header as an IP filter match criterion.

The no form of this command removes the checking of the option field in the IP header as a match criterion.

This command specifies the Vendor-Identifying Vendor Option to match. Option 60 is encoded as Type-Length-Value (TLV). The hex-string portion of Option 60 in the received DHCP request is used for matching. Only the first 32 bytes can be defined here. If Option 60 from the message is longer, those bytes are ignored.

The no form of this command reverts to the default.

This command enables the context to configure pool options. The options defined here can be overruled by defining the same option in the local user database.

This command enables the context to configure options that are reflected in DHCP.

This command enables the CLI context to configure persistence options parameters.

This command enables the context to configure IPv6 DNS server information in the local user database.

This command configures a match criteria for the origin attribute. Originally, the origin attribute was applicable only to BGP as a mandatory well-known BGP attribute.

The functionality of the origin attribute has expanded to subscriber-management routes (/32 IPv4 host and IPv6 PD WAN host routes). By default, each subscriber-management route will internally (local to the node) carry the origin attribute with one of three values (aaa, dynamic, and static). The value of the attribute depends on the origin of the subscriber-management route. The aaa, dynamic or static values are never carried in BGP updates as part of the BGP origin attribute and are visible within the BGP process.

The values for the origin attribute in the subscriber-management routes allows customized advertisement of the subscriber-management routes by the routing policy.

This command sets the BGP origin assigned to routes exported into BGP.

If the routes are exported into protocols other than BGP, this option is ignored.

The no form of this command disables setting the BGP origin for the route policy entry.

This command configures the Origin-Host AVP that is sent in all Diameter messages. Together with the Origin-Realm AVP, these two AVPs form a Diameter Identity.

This command is applicable only to legacy implementations of Diameter base in the SR OS.

The no form of this command removes the origin host string from the configuration.

When this command is configured, all VPRN BGP routes that have an origin validation state of “Invalid” are considered unusable by the best path selection algorithm, meaning they are not used for forwarding, not advertised to BGP peers, and not eligible for export as a VPN-IP route.

With the default value, VPRN BGP routes with an origin validation state of “Invalid” are usable if they are selected.

When origin-invalid-unusable is configured, all routes that have an origin validation state of ‘Invalid’ are considered unusable by the best path selection algorithm, meaning they are not used for forwarding and not advertised to BGP peers.

With the default of no origin-invalid-unusable, routes with an origin validation state of ‘Invalid’ are compared to other ‘usable’ routes for the same prefix according to the BGP decision process.

This command configures the Origin-Realm AVP that is sent in all Diameter messages. Together with the Origin-Host AVP, these two AVPs form a Diameter Identity.

This command is applicable only to legacy implementations of Diameter base in the SR OS.

The no form of this command reverts to the default.

This command restricts output to a specific origin-realm.

This command enables the context to display origin validation information.

This command is used to match BGP routes on the basis of origin validation state:

This command is used to mark BGP IPv4 and IPv6 routes matching the default-action or a specific entry of a route policy with one of the 3 following origin validation states:

This command specifies whether when configuring an NSSA with no summaries, the Area Border Router (ABR) injects a type-7 LSA default route into the NSSA area. The default behavior is to inject a type-3 LSA default route, but some older implementations expect a type-7 LSA default route.

When configuring an NSSA with no summaries, the ABR will inject a type 3 LSA default route into the NSSA area. Some older implementations expect a type 7 LSA default route.

The no form of this command disables origination of a default route.

This command enables the generation of a default route and its LSA type (3 or 7) into a Not So Stubby Area (NSSA) by an NSSA Area Border Router (ABR).

When configuring an NSSA with no summaries, the ABR will inject a type 3 LSA default route into the NSSA area. Some older implementations expect a type 7 LSA default route.

The no form of this command disables origination of a default route.

This command configures the QoS marking used for packets carrying telemetry notifications.

The no form of this command removes the QoS marking.

This command overrides the default orphan behavior for port schedulers created using the port scheduler policy. The default orphan behavior is to give all orphan queues and schedulers bandwidth after all other properly parented queues and schedulers. Orphans by default do not receive any within-CIR bandwidth and receive above-CIR bandwidth after priority levels 8 through 1 have been allocated. The orphan-override command accepts the same parameters as the port-parent command in the SAP egress and network queue policy contexts. The defined parameters are used as a default port-parent association for any queue or scheduler on the port that the port scheduler policy is applied.

Orphan queues and schedulers are identified as:

A queue or scheduler may be properly parented to an upper level scheduler, but that scheduler may be orphaned. In this case, the queue or scheduler receives bandwidth from its parent scheduler based on the parent schedulers ability to receive bandwidth as an orphan.

Within-CIR Priority Level Parameters

The within-CIR parameters define which port priority level the orphan queues and schedulers should be associated with when receiving bandwidth for the queue or schedulers within-CIR offered load. The within-CIR offered load is the amount of bandwidth the queue or schedulers could use that is equal to or less than its defined or summed CIR value. The summed value is only valid on schedulers and is the sum of the within-CIR offered loads of the children attached to the scheduler. The parameters that control within-CIR bandwidth allocation for orphans are the orphan-override commands cir-level and cir-weight keywords. The cir-level keyword defines the port priority level that the scheduler or queue uses to receive bandwidth for its within-CIR offered load. The cir-weight is used when multiple queues or schedulers exist at the same port priority level for within-CIR bandwidth. The weight value defines the relative ratio that is used to distribute bandwidth at the priority level when more within-CIR offered load exists than the port priority level has bandwidth.

A cir-weight equal to zero (the default value) has special meaning and informs the system that the orphan queues and schedulers do not receive bandwidth from the within-CIR distribution. Instead, all bandwidth for the orphan queues and schedulers must be allocated from the port scheduler’s above-CIR pass.

Above-CIR Priority Level Parameters

The above-CIR parameters define which port priority level the orphan queues and schedulers should be associated with when receiving bandwidth for the queue or schedulers above-CIR offered load. The above-CIR offered load is the amount of bandwidth the queue or schedulers could use that is equal to or less than its defined PIR value (based on the queue or schedulers rate command) less any bandwidth that was given to the queue or scheduler during the above-CIR scheduler pass. The parameters that control above-CIR bandwidth allocation for orphans are the orphan-override commands level and weight keywords. The level keyword defines the port priority level that the scheduler or queue uses to receive bandwidth for its above-CIR offered load. The weight is used when multiple queues or schedulers exist at the same port priority level for above-CIR bandwidth. The weight value defines the relative ratio that is used to distribute bandwidth at the priority level when more above-CIR offered load exists than the port priority level has bandwidth.

The no form of this command removes the orphan override port parent association for the orphan queues and schedulers on port schedulers created with the port scheduler policy. Any orphan queues and schedulers on a port associated with the port scheduler policy will revert to default orphan behavior.

This command enables access to the context to enable an OSPF protocol instance.

OSPF instances are shutdown when created, so that all parameters can be configured prior to the instance being enabled.

The no form of this command deletes the OSPF protocol instance removing all associated configuration parameters.

This command enables the context to configure monitor commands for the OSPF instance.

This command creates an OSPF routing instance and then enters the associated context to configure the associated protocol parameters.

Additionally, the router ID can be specified as another parameter of the OSPF command. This parameter is required for all non-base OSPF instances.

The default value for the base instance is inherited from the configuration in the config>router context. When that is not configured, the following apply:

This is a required command when configuring multiple instances and the instance being configured is not the base instance. When configuring multiple instances of OSPF, there is a risk of loops because networks are advertised by multiple domains configured with multiple interconnections to one another. To prevent this from happening, all routers in a domain should be configured with the same domain ID. Each domain (OSPF-instance) should be assigned a specific bit value in the 32-bit tag mask.

The default value for non-base instances is 0.0.0.0 and is invalid; in this case, the instance of OSPF will not start. When configuring a new router ID, the instance is not automatically restarted with the new router ID. The next time the instance is initialized, the new router ID is used.

Issue the shutdown and no shutdown commands for the instance for the new router ID to be used, or reboot the entire router.

OSPF instances are shutdown when created, so that all parameters can be configured prior to the instance being enabled.

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

Indicates the OSPF instance for debugging purposes.

This command enables OSPF dynamic hostnames.

The router receiving the new Dynamic Hostname within the OSPF Router Information (RI) LSA is instructed to process the received dynamic hostname information.

The no form of this command disables OSPF dynamic hostnames.

This command creates an OSPFv3 routing instance and then enters the associated context to configure associated protocol parameters.

OSPF instances are shutdown when created, so that all parameters can be configured before the instance is enabled.

The no form of this command deletes the OSPFv3 protocol instance, removing all associated configuration parameters.

This command enables the context to configure monitor commands for the OSPF3 instance.

This command creates an OSPFv3 routing instance and then enters the associated context to configure associated protocol parameters.

OSPFv3 instances are shutdown when created, so that all parameters can be configured prior to the instance being enabled.

The no form of this command deletes the OSPFv3 protocol instance, removing all associated configuration parameters.

Indicates the OSPF3 instance for debugging purposes.

This command sets the "other configuration" flag. This flag indicates that DHCPv6 is available for auto-configuration of other (non-address) information such as DNS-related information or information on other servers in the network. See RFC 3736, Stateless Dynamic Host Configuration Protocol (DHCP) for IPv6.

The no form of this command removes the flag.

This command sets the "Other configuration" flag. This flag indicates that DHCPv6lite is available for autoconfiguration of other (non-address) information such as DNS-related information or information about other servers in the network. See RFC 3736, Stateless Dynamic Host Configuration Protocol (DHCP) for IPv6.

This command specifies whether or not to enable OTU encapsulation. The port must be shut down before OTU is enabled. This command is valid only for ports on assemblies that support this encapsulation mode. Refer to the appropriate Installation Guide for ports assembly to determine if OTU encapsulation is supported.

Note that OTU cannot be disabled on OTU3 encapsulated OC768 or 40-Gigabit Ethernet.by the no otu command. Therefore, the default depends on the port type. The default for OTU3 encapsulated OC768 or 40-Gigabit Ethernet is otu.

The no form of this command disables OTU (clear channel 10GE-LAN/WAN or OC192).

This command specifies the data rate to use when configured for an OTU encapsulated 10GE-LAN signal. The port must be shut down before changing the 10GE LAN OTU2 data rate.

This command configures the outgoing label value to use for an MPLS-TP working or protect path. The out-link is the outgoing interface on the node that this path will use, and must be specified. If the out-link refers to a numbered IP interface, the user may optionally configure the next-hop parameter and the system will determine the interface to use to reach the configured next-hop, but will check that the user-entered value for the out-link corresponds to the link returned by the system. If they do not correspond, then the path will not come up.

This command configures the action to be performed when out of credit is reached.

The no form of this command reverts to the default.

This command specifies the action to be taken if the credit is exhausted.

This command changes the reporting reason in an intermediate interrogation when the final granted units have been consumed and a corresponding out-of-credit-action different from disconnect-host is started.

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

This command includes the out of profile packets discarded count.

For queues with stat-mode v4-v6, this command includes the IPv6 octets discarded count instead.

The no form of this command excludes the out of profile packets discarded count.

This command includes the out of profile packets discarded count.

The no form of this command excludes the out of profile packets discarded count.

This command includes the out of profile octets discarded count.

The no form of this command excludes the out of profile octets discarded count.

This command includes the out of profile octets forwarded count.

For queues with stat-mode v4-v6, this command includes the IPv6 octets forwarded count instead.

The no form of this command excludes the out of profile octets forwarded count.

This command includes the out of profile octets forwarded count.

The no form of this command excludes the out of profile octets forwarded count.

This command includes the out of profile octets forwarded count.

The no form of this command excludes the out of profile octets forwarded count.

This command includes the out of profile octets offered count.

The no form of this command excludes the out of profile octets offered count.

This command includes the out of profile octets offered count.

The no form of this command excludes the out of profile octets offered count.

This command includes the out of profile packets discarded count.

For queues with stat-mode v4-v6, this command includes the IPv6 packets discarded count instead.

The no form of this command excludes the out of profile packets discarded count.

This command includes the out of profile packets discarded count.

The no form of this command excludes the out of profile packets discarded count.

This command includes the out of profile packets discarded count.

The no form of this command excludes the out of profile packets discarded count.

This command includes the out of profile packets forwarded count.

For queues with stat-mode v4-v6, this command includes the IPv6 packets forwarded count instead.

The no form of this command excludes the out of profile packets forwarded count.

This command includes the out of profile packets forwarded count.

The no form of this command excludes the out of profile packets forwarded count.

This command includes the out of profile packets forwarded count.

The no form of this command excludes the out of profile packets forwarded count.

This command includes the out of profile packets offered count.

The no form of this command excludes the out of profile packets offered count.

This command includes the out of profile packets offered count.

The no form of this command excludes the out of profile packets offered count.

This command applies a packet arrival rate limit for the entire SAP/interface, above which packets will be market as discard eligible, in other words, out-profile/low-priority/yellow. The rate defined is a global rate limit for the interface regardless of the number of traffic flows. It is a per-SAP/interface rate.

The no form of this command sets out-profile-rate parameter back to the default value.

This command is used in a SAP ingress QoS policy to define an explicit out-of-profile remark action for a forwarding class or subclass. While the SAP ingress QoS policy may be applied to any SAP, the remarking functions are only enforced when the SAP is associated with an IP or subscriber interface (in an IES or VPRN). When the policy is applied to a Layer 2 SAP (for example, Epipe or VPLS), the remarking definitions are silently ignored.

In the case where the policy is applied to a Layer 3 SAP, the out-of-profile remarking definition will be applied to packets that have been classified to the forwarding class or subclass. It is possible for a packet to match a classification command that maps the packet to a particular forwarding class or subclass, only to have a more explicit (higher priority match) override the association. Only the highest priority match forwarding class or subclass association will drive the out-of-profile marking.

The out-remark command is only applicable to ingress IP routed packets that are considered out-of-profile. The profile of a SAP ingress packet is affected by either the explicit in-profile/out-of-profile definitions or the ingress policing function applied to the packet. Table 108 describes the effect of the out-remark command on received SAP ingress packets. Within the out-of-profile IP packet’s ToS field, either the six DSCP bits or the three precedence bits are remarked.

A packet that is explicitly remarked at ingress will not be affected by any egress remarking decision. Explicit ingress remarking has highest priority.

An explicit dscp name or precedence value must be specified for out-of-profile remarking to be applied.

The no form of this command disables ingress remarking of out-of-profile packets classified to the forwarding class or subclass.

This parameter limits the number of outbound Telnet and SSH sessions. A maximum of 15 telnet and ssh connections can be established from the router. The local serial port cannot be disabled.

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

This command opens the configuration tree for sending or accepting BGP filter lists from peers (outbound route filtering).

This command enables debugging for all BGP outbound route filtering (ORF) packets. ORF is used to inform a neighbor of targets (using target-list) that it is willing to receive.

This command configures the matching of the first tag that is carried transparently through the service. Service delimiting tags are stripped from the frame and the outer tag on ingress is the first tag after any service delimiting tags. The outer tag is the first tag before any service delimiting tags on egress. This allows matching VLAN tags for explicit filtering or QoS setting when using default or null encapsulations.

On dot1Q SAPs, the outer tag is the only tag that can be matched. On dot1Q SAPs with exact match (sap 2/1/1:50), the outer tag will be populated with the next tag that is carried transparently through the service or 0 if there is no additional VLAN tags on the frame.

On QinQ SAPs that strip a single service delimiting tag, the outer tag will contain the next tag (which is still the first tag carried transparently through the service.) On SAPs with two service delimiting tags (two tags stripped), the outer-tag will contain 0 even if there are more than two tags on the frame.

The optional vid_mask is defaulted to 4095 (exact match) but may be specified to allow pattern matching. The masking operation is ((value & vid-mask) = = (tag & vid-mask)). A value of 6 and a mask of 7 would match all VIDs with the lower 3 bits set to 6.

For QoS, the VID type cannot be specified on the default QoS policy.

The default vid-mask is set to 4095 for exact match.

This command configures the matching of the first tag that is carried transparently through the service. Service delimiting tags are stripped from the frame and outer tag on ingress is the first tag after any service delimiting tags. Outer tag is the first tag before any service delimiting tags on egress. This allows matching VLAN tags for explicit filtering or QoS setting when using default or null encapsulations.

On dot1Q SAPs outer-tag is the only tag that can be matched. On dot1Q SAPs with exact match (sap 2/1/1:50) the outer-tag will be populated with the next tag that is carried transparently through the service or 0 if there is no additional VLAN tags on the frame.

On QinQ SAPs that strip a single service delimiting tag, outer-tag will contain the next tag (which is still the first tag carried transparently through the service.) On SAPs with two service delimiting tags (two tags stripped) outer-tag will contain 0 even if there are more than 2 tags on the frame.

The optional vid-mask is defaulted to 4095 (exact match) but may be specified to allow pattern matching. The masking operation is ((value & vid-mask) = = (tag & vid-mask)). A value of 6 and a mask of 7 would match all VIDs with the lower 3 bits set to 6.

For QoS the VID type cannot be specified on the default QoS policy.

The default vid-mask is set to 4095 for exact match.

This command provides a context to configure and enable or disable the external BITS timing reference output to the central clock of the router. On redundant systems, there are two possible BITS-out interfaces, one for each CPM or CCM.

This command enters the context to configure output authorization for model-driven interfaces or telemetry data.

This command enters the “outside” context to configure the outside NAT instance.

This command enables the inclusion of the outside IP attributes.

The no form of the command excludes outside IP attributes.

This command enables the inclusion of the NAT outside service ID attributes.

The no form of the command excludes NAT outside service ID attributes.

This command configures the maximum number of subscriber hosts per SLA profile instance or per subscriber.

The no form of this command removes the maximum number of subscriber hosts limit.

This command configures the maximum number of subscriber sessions per SLA profile instance or per subscriber.

The no form of this command removes the maximum number of subscriber sessions limit.

This command applies a maximum packet arrival rate limit (applied per SAP/interface) for the entire SAP/interface, above which packets will be discarded immediately. The rate defined is a global rate limit for the interface regardless of how many traffic flows are present on the SAP/interface. It is a per-SAP/interface rate.

The no form of this command sets overall-rate parameter back to the default value.

This command specifies the percentage of the flow cache entries removed when the maximum number of entries is exceeded. The entries removed are the entries that have not been updated for the longest amount of time.

The no form of this command resets the number of entries cleared from the flow cache on overflow to the default value.

This command configures overflow-triggered auto-bandwidth adjustment. It sets the threshold at which bandwidth adjustment is initiated due to the configured number of overflow samples having been reached, regardless of how much time remains until the adjust interval ends.

A sample interval is counted as an overflow if the average data rate during the sample interval is higher than the currently reserved bandwidth by at least the thresholds configured as part of this command.

If overflow-triggered auto-bandwidth adjustment is successful the overflow count, maximum average data rate and adjust count are reset. If overflow-triggered auto-bandwidth adjustment fails then the overflow count is reset but the maximum average data rate and adjust count maintain current values.

The no form of this command disables overflow-triggered automatic bandwidth adjustment.

This command administratively sets the SPB to operate in the overload state for a specific time period, in seconds, or indefinitely. During normal operation, the router may be forced to enter an overload state due to a lack of resources. When in the overload state, the router is only used if the destination is reachable by SPB and is not used for other transit traffic.

If a time period is specified, the overload state persists for the configured length of time. If no time is specified, the overload state operation is maintained indefinitely.

The overload command can be useful in circumstances where SPB is overloaded or used prior to executing a shutdown command to divert traffic around the switch.

The no form of this command causes the router to exit the overload state.

This command administratively sets the router to operate in the overload state for a specific time period, in seconds, or indefinitely.

During normal operation, the router may be forced to enter an overload state due to a lack of resources. When in the overload state, the router is only used if the destination is reachable by the router and will not be used for other transit traffic.

If a time period is specified, the overload state persists for the configured length of time. If no time is specified, the overload state operation is maintained indefinitely.

The overload command can be useful in circumstances where the router is overloaded or used prior to executing a shutdown command to divert traffic around the router.

The no form of this command causes the router to exit the overload state.

This command administratively sets the IS-IS router to operate in the overload state for a specific time period, in seconds, or indefinitely.

During normal operation, the router may be forced to enter an overload state due to a lack of resources. When in the overload state, the router is only used if the destination is reachable by the router and will not be used for other transit traffic.

If a time period is specified, the overload state persists for the configured length of time. If no time is specified, the overload state operation is maintained indefinitely.

The overload command can be useful in circumstances where the router is overloaded or used prior to executing a shutdown command to divert traffic around the router.

The max-metric parameter can be set to advertise transit links with the maximum metric of 0xffffffe (wide metrics) or 0x3f (regular metrics), instead of setting the overload bit when placing the router in overload.

The no form of this command causes the router to exit the overload state.

This command changes the overload state of the local router so that it appears to be overloaded. When overload is enabled, the router can participate in OSPF routing, but is not used for transit traffic. Traffic destined to directly attached interfaces continue to reach the router.

To put the IGP in an overload state, enter a timeout value. The IGP will enter the overload state until the timeout timer expires or a no overload command is executed.

If the overload command is performed during the execution of an overload-on-boot command, the overload command takes precedence. This could occur as a result of a saved configuration file in which both parameters are saved. When the file is saved by the system, the overload-on-boot command is saved after the overload command.

Use the no form of this command to return to the default. When the no overload command is executed, the overload state is terminated, regardless the reason the protocol entered overload state.

This command administratively sets the IS-IS router to operate in the overload state for a specific time period, in seconds, or indefinitely.

During normal operation, the router may be forced to enter an overload state due to a lack of resources. When in the overload state, the router is only used if the destination is reachable by the router and will not be used for other transit traffic.

If a time period is specified, the overload state persists for the configured length of time. If no time is specified, the overload state operation is maintained indefinitely.

The overload command is cleared from the configuration after a reboot if overload-on-boot is configured with or without a timeout value. To keep the IS-IS router in the overload state indefinitely after rebooting, configure overload-on-boot with no timeout value or configure the overload command with no overload-on-boot command.

The overload command can be useful in circumstances where the router is overloaded or used prior to executing a shutdown command to divert traffic around the router.

The max-metric parameter can be set to advertise transit links with the maximum metric of 0xffffffe (wide metrics) or 0x3f (regular metrics), instead of setting the overload bit when placing the router in overload.

The no form of this command causes the router to exit the overload state.

This command changes the overload state of the local router so that it appears to be overloaded. When overload is enabled, the router can participate in OSPF routing, but is not used for transit traffic. Traffic destined to directly attached interfaces continues to reach the router.

To put the IGP in an overload state enter a timeout value. The IGP will enter the overload state until the timeout timer expires or a no overload command is executed.

If the overload command is encountered during the execution of an overload-on-boot command then this command takes precedence. This could occur as a result of a saved configuration file where both parameters are saved. When the file is saved by the system the overload-on-boot command is saved after the overload command. However, when overload-on-boot is configured under OSPF with no timeout value configured, the router will remain in overload state indefinitely after a reboot.

The no form of this command reverts to the default. When the no overload command is executed, the overload state is terminated regardless of the reason the protocol entered overload state.

This command configures a drop action for cases where flow records are not created (overload).

This command configures a TCA for the counter capturing drops due to the overload-drop AQP command. An overload-drop 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 an overload-drop TCA.

This command enables external routes that are exported with an IS-IS export policy to continue to be advertised when the router is in overload.

The no form of this command causes external routes to be withdrawn when the router is in overload.

This command enables external routes that are exported with an IS-IS export policy to continue to be advertised when the router is in overload.

The no form of this command causes external routes to be withdrawn when the router is in overload.

This command enables inter-level routes that are exported with an IS-IS export policy to continue to be advertised when the router is in overload.

The no form of this command causes inter-level routes to be withdrawn when the router is in overload.

This command enables inter-level routes that are exported with an IS-IS export policy to continue to be advertised when the router is in overload.

The no form of this command causes inter-level routes to be withdrawn when the router is in overload.

This command controls whether routes should be re-advertised with a maximum metric value when the system goes into overload state for any reason. When this command is enabled and the router is in overload, all external type-1 routes are advertised with the maximum metric.

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

This command controls whether external type-1 routes should be re-advertised with a maximum metric value when the system goes into overload state for any reason. When this command is enabled and the router is in overload, all external type-1 routes are advertised with the maximum metric.

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

This command controls whether external type-2 routes should be re-advertised with a maximum metric value when the system goes into overload state for any reason. When this command is enabled and the router is in overload, all external type-2 routes is advertised with the maximum metric.

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

This command controls whether external type-2 routes should be re-advertised with a maximum metric value when the system goes into overload state for any reason. When this command is enabled and the router is in overload, all external type-2 routes are advertised with the maximum metric.

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

This command controls whether the OSPF stub networks should be advertised with a maximum metric value when the system goes into overload state for any reason. When enabled, the system uses the maximum metric value. When this command is enabled and the router is in overload, all stub interfaces, including loopback and system interfaces, are advertised at the maximum metric.

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

This command controls whether the OSPF stub networks should be advertised with a maximum metric value when the system goes into overload state for any reason. When enabled, the system uses the maximum metric value. When this command is enabled and the router is in overload, all stub interfaces, including loopback and system interfaces, are advertised at the maximum metric.

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

When the router is in an overload state, SPB the B-VPLS is used only if there is no other SPB B-VPLS to reach the destination. This command configures the IGP upon bootup in the overload state until one of the following events occur:

The no form of this command does not affect the overload-on-boot function.

If no timeout is specified, SPB IS-IS goes into overload indefinitely after a reboot. After the reboot, the SPB IS-IS status displays a permanent overload state:

L1 LSDB Overload: Manual on boot (Indefinitely in overload)

This state can be cleared with the config>service>vpls>spb>no overload command.

When specifying a timeout value, SPB IS-IS goes into overload for the configured timeout after a reboot. After the reboot, SPB IS-IS status displays the remaining time the system stays in overload:

L1 LSDB Overload: Manual on boot (Overload Time Left: 17)

The overload state can be cleared before the timeout expires with config>service>vpls>spb>no overload command.

The no form of this command removes the overload-on-boot functionality from the configuration.

When the router is in an overload state, the router is used only if there is no other router to reach the destination. This command configures the IGP upon bootup in the overload state until one of the following events occur:

The no overload command does not affect the overload-on-boot function.

If no timeout is specified, IS-IS will go into overload indefinitely after a reboot. After the reboot, the IS-IS status will display a permanent overload state:

This state can be cleared with the config>router>isis>no overload command.

When specifying a timeout value, IS-IS will go into overload for the configured timeout after a reboot. After the reboot, the IS-IS status will display the remaining time the system stays in overload:

The overload state can be cleared before the timeout expires with the config>router>isis>no overload command.

The no form of this command removes the overload-on-boot functionality from the configuration.

When the router is in an overload state, it is used only if there is no other router to reach the destination. This command configures the IGP upon bootup in the overload state until one of the following events occur:

If no timeout is specified, IS-IS will go into overload indefinitely after a reboot. After the reboot, the IS-IS status will display a permanent overload state:

This state can be cleared with the config>router>isis>no overload command.

When specifying a timeout value, IS-IS will go into overload for the configured timeout after a reboot. After the reboot, the IS-IS status will display the remaining time the system stays in overload:

The overload state can be cleared before the timeout expires with the config>router>isis>no overload command.

The no form of this command removes the overload-on-boot functionality from the configuration.

Use the show router isis status command to display the administrative and operational state as well as all timers.

When the router is in an overload state, it is used only if there is no other router to reach the destination. This command configures the IGP upon bootup in the overload state until one of the following events occur:

The no overload command does not affect the overload-on-boot function.

The no form of this command removes the overload-on-boot functionality from the configuration.

When the router is in an overload state, the router is used only if there is no other router to reach the destination. This command configures the IGP upon bootup in the overload state until one of the following events occur:

The no overload command does not affect the overload-on-boot function.

If no timeout is specified, IS-IS will go into overload indefinitely after a reboot. After the reboot, the IS-IS status will display a permanent overload state:

This state can be cleared with the config>router>isis>no overload command.

When specifying a timeout value, IS-IS will go into overload for the configured timeout after a reboot. After the reboot, the IS-IS status will display the remaining time the system stays in overload:

The overload state can be cleared before the timeout expires with the config>router>isis>no overload command.

The no form of this command removes the overload-on-boot functionality from the configuration.

Use the show router isis status command to display the administrative and operational state as well as all timers.

When the router is in an overload state, the router is used only if there is no other router to reach the destination. This command configures the IGP upon bootup in the overload state until one of the following events occur:

The no overload command does not affect the overload-on-boot function.

The no form of this command removes the overload-on-boot functionality from the configuration.

The default timeout value is 60 seconds, which means after 60 seconds overload status the SR will recover (change back to non-overload status). However, when overload-on-boot is configured under OSPF with no timeout value the router will remain in overload state indefinitely after a reboot.

This command enables the context for overload subscriber detection for this application assurance group.

This command changes the precedence of static RP over dynamically learned Rendezvous Point (RP).

When enabled, the static group-to-RP mappings take precedence over the dynamically learned mappings.

This command changes the precedence of static RP over dynamically-learned Rendezvous Points (RPs).

When enabled, the static group-to-RP mappings take precedence over the dynamically learned mappings.

The no form of this command reverts to the default.

This command provides the ability to override the announced MSD node Base MPLS Imposition (BMI). The MSD-BMI value announced by a router can be used by recipients to understand the number of MPLS labels that can be imposed inclusive of all service, transport, or special labels.

When override-bmi is not configured, the router announces the node maximum supported BMI assuming the most simple services and Layer 2 encapsulation.

The no form of this command reverts to the default.

This command provides the ability to override the announced MSD node Base MPLS Imposition (BMI). The MSD-BMI value announced by a router can be used by recipients to understand the number of MPLS labels that can be imposed inclusive of all service, transport, or special labels.

When override-bmi is not configured, the router announces the node maximum supported BMI assuming the most simple services and Layer 2 encapsulation.

The no form of this command reverts to the default.

This command enables the context to configure override counter (HSMDA) parameters.

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

This command enables the context to configure override counter (HSMDA) parameters. This command only applies to the 7750 SR.

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

This command provides the ability to override the announced MSD node Entropy Readable Label Depth (ERLD). It is useful for ingress LSRs to know each intermediate LSR's capability of reading the maximum label stack depth and performing EL-based load balancing.

When override-erld is not configured, then the router announces the node maximum supported ERLD assuming the most simple Layer 2 encapsulation.

The no form of this command reverts to the default.

This command provides the ability to override the announced MSD node Entropy Readable Label Depth (ERLD). It is useful for ingress LSRs to know each intermediate LSR's capability of reading the maximum label stack depth and performing EL-based load balancing.

When override-erld is not configured, then the router announces the node maximum supported ERLD assuming the most simple Layer 2 encapsulation.

This command allows a DHCP IA_NA address to override and replace a host existing SLAAC address. When this feature is enabled, a subscriber SLAAC address is removed once the DHCP IA_NA address assignment is completed. If used with conjunction with the allow-multiple-wan-address command, the DHCP IA_NA address will also override the SLAAC address.

This command enables or disables entropy label capability (ELC) on BGP tunnels.

When this command is enabled, the system assumes that all far ends for BGP tunnels are entropy-label-capable, regardless of any received capability signaling. This ensures that the entropy label will be inserted on BGP tunnels in the absence of capability signaling support by the far end.

This is a system-wide configuration, since efficient entropy label operation requires that all LSRs in a network support entropy labels. This command should be used with care, particularly in inter-AS use cases, since entropy label capability may differ between domains.

This command configures the ability to override any received entropy label capability advertisement. When enabled, the system assumes that all nodes for an IGP domain are capable of receiving and processing the entropy label on segment routed tunnels. This command can only be configured if entropy-label is enabled via the config>router>isis>segment-routing>entropy-label or config>router>ospf>segment-routing>entropy-label command.

The no form of this command disables the override. The system assumes entropy label capability for other nodes in the IGP instance if capability advertisements are received.

This command configures the authentication method used with this IKE policy on its own side.

This command selects the owner protocol of the inclusive PMSI tunnel in the service. Only one of the protocols will support the provider tunnel.

The bgp-vpls and bgp-evpn-mpls parameters cannot be configured together in the same service. Although bgp-ad and bgp-evpn can coexist in the same service, bgp-ad cannot be configured as the owner of the provider-tunnel. In addition, the following applies to this configuration: