Model-driven management interfaces
SR OS supports two classes of management interfaces:
Classic management interfaces
SNMP
classic CLI
Model-driven management interfaces
Model-Driven CLI (MD-CLI)
NETCONF
gRPC (gNMI and gNOI)
Unless otherwise indicated, the term ‟CLI” in the SR OS user documentation refers to the classic CLI. The classic CLI has been supported in SR OS from the initial introduction of SR OS. For more information about classic CLI commands, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Classic CLI Command Reference Guide.
The MD-CLI is a model-driven CLI introduced in SR OS Release 16.0.R1. For more information about MD-CLI commands, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR MD-CLI User Guide and the 7450 ESS, 7750 SR, 7950 XRS, and VSR MD-CLI Command Reference Guide.
Model-driven management interfaces are based on a common infrastructure that uses YANG models as the core definition for configuration, state, and operational actions. All model-driven interfaces take the same common underlying YANG modules and render them for the particular management interface.
The model-driven interfaces are similar to the classic CLI interfaces with the following notable differences.
The classic and model-driven configuration formats are incompatible; the system automatically converts the classic configuration to the model-driven format when the management interface configuration mode is changed to model-driven.
Some classic CLI branches have been moved, renamed, or reorganized in the SR OS YANG modules.
Many elements use strict references in model-driven interfaces instead of the loose references used in the classic CLI and SNMP. For more information, see Loose references to IDs and Strict routing policy validation.
Many elements use string names as keys in model-driven interfaces instead of the numerical identifiers used in the classic CLI and SNMP. See String names as keys for more information.
The classic CLI shutdown command has been replaced with admin-state in model-driven interfaces.
The classic CLI commands with multiple parameters have been separated into individual leafs in model-driven interfaces.
The model-driven interfaces make extensive use of Boolean values (true and false) for configuration settings.
The default configuration handling is as follows.
In classic configuration mode, the default handling is similar to RFC 6243 ‟trim” mode. Configuration values are not reported if they are equal to the default value, even if the user explicitly configured the value.
In model-driven configuration mode, the system operates with ‟explicit” default handling. Users can set a leaf to the same value as the default and the system displays it as part of the configuration. This handling is similar to RFC 6243 ‟explicit” mode.
In mixed configuration mode, the system uses ‟explicit” default handling but it is not persistent. Explicitly configured default values are not preserved during a high-availability CPM switchover or a reboot. Nokia recommends deleting the leaf instead of setting any leaf explicitly to its default value in mixed configuration mode.
A newly created routing instance, group, or EBGP neighbor in a model-driven interface applies the secure default behavior to reject all routes. Using the ebgp-default-reject-policy command to implement this is compliant with RFC 8212. Nokia recommends configuring import and export policies that express the intended routing instead of using the insecure default behavior. For more information about RFC behavior, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Unicast Routing Protocols Guide.
Management interface configuration modes
SR OS routers can be in different management interface configuration modes, which affects the management interfaces that can be used to configure the router. The following interfaces are available for configuration on SR OS:
-
classic (default)
Configuration via the classic CLI and SNMP, no model-driven interfaces are supported.
model-driven
Configuration via model-driven interfaces: the MD-CLI, NETCONF, and gRPC/gNMI, read-only access via the classic CLI and SNMP.
mixed
Configuration via the classic CLI and model-driven interfaces: the MD-CLI, NETCONF, and gRPC/gNMI, read-only access via SNMP.
Mixed configuration mode is a transition mode for operators to migrate from classic management interfaces to operating in a full model-driven mode. It allows the use of previous classic CLI scripts or other OSS integration developed by users for configuration, although with some prerequisites (see Prerequisites for using model-driven management interfaces) and some limitations (see Management interface configuration mode).
Use the configure system management-interface configuration-mode command to enable configuration editing by model-driven interfaces.
| Configuration mode | ||||
|---|---|---|---|---|
| Classic | Mixed | Model-driven | ||
Classic Interfaces |
Classic CLI: configuration write |
✓ | ✓ |
|
Classic CLI: configuration read |
✓ | ✓ | ✓ | |
Classic CLI: non-configuration commands |
✓ | ✓ | ✓ | |
SNMP: configuration write |
✓ |
|
|
|
SNMP: non-configuration writes (such as admin reboot) |
✓ |
|
|
|
SNMP: configuration read |
✓ | ✓ | ✓ | |
SNMP: state read |
✓ | ✓ | ✓ | |
SNMP: notifications (traps) |
✓ | ✓ | ✓ | |
Model-driven Interfaces with Nokia YANG Models |
MD-CLI: configuration write and read |
✓ | ✓ | |
MD-CLI: state read |
✓ | ✓ | ✓ | |
NETCONF: configuration write and read |
|
✓ | ✓ | |
NETCONF: state read |
✓ | ✓ | ✓ | |
gNMI Set/Get: configuration write and read |
✓ | ✓ | ||
gNMI Get: state read |
✓ | ✓ | ✓ | |
gNMI Telemetry: configuration read |
|
✓ | ✓ | |
gNMI Telemetry: state read |
✓ | ✓ | ✓ | |
Saved Configuration File Format |
bof |
Classic |
Classic |
Classic |
configure |
Classic |
Classic |
MD |
|
debug |
Classic |
Classic |
MD |
|
li |
Classic |
Classic |
MD |
|
|
Features |
OpenConfig YANG models |
✓ | ||
Commit history |
✓ | |||
Configuration annotations |
✓ | |||
Configuration groups |
✓ | |||
MD-CLI rollback command |
✓ | |||
Classic CLI admin rollback revert command |
✓ | ✓ |
|
|
Explicit defaults1 |
✓ | |||
Explicit non-deletable SPC objects2 |
✓ | |||
Configuration changes accepted immediately after a CPM high-availability switchover3 |
✓ | ✓ | ||
Named route policy entries |
✓ | |||
|
gRPC MD-CLI service for the NISH client |
✓ | ✓ | ||
|
Remote management using the NISH manager |
✓ | ✓ | ||
|
MD-CLI command aliases |
✓ | |||
|
Python 3 for pyexec, EHS, CRON, and MD-CLI command aliases |
✓ | |||
|
The use of the pySROS library from any location |
✓ | |||
| Incremental saved configuration files | ✓ | |||
YANG data models
Model-driven management interfaces are based on a common infrastructure that uses YANG models as the core definition for configuration, state, and operational actions. All model-driven interfaces (NETCONF, gRPC/gNMI, and the MD-CLI) use the same common underlying YANG modules and render them for the particular management interface. These YANG models are also used for telemetry.
SR OS supports:
Nokia YANG data models
OpenConfig YANG data models
Nokia SR OS YANG data models
The Nokia SR OS YANG modules are the base for the model-driven architecture.
SR OS configuration is divided into several top level configuration regions (see Datastores and regions for details). The data models for each configuration region are separated into different YANG modules.
The primary configuration region (configure) is modeled in the nokia-conf YANG module specified in a single file located at YANG/nokia-combined/nokia-conf.yang in the SR OS image distribution.
An alternative packaging of the primary configuration region is also available as a set of submodules (for example, nokia-conf-system) that belong to a single module located at YANG/nokia-conf.yang in the SR OS image distribution. The submodules have independent revision dates and can be used to identify which parts of the configuration model have changed.
The packaging options (combined and submodule) are alternate representations of the same data model. There is no difference between using the combined or submodule packaging for all the basic configuration or state operations (including with telemetry). The same containers, list, leafs, and so on, exist in the same namespaces whether you are using the combined or submodule packaging. The main difference between the combined and submodule options is seen in the NETCONF <hello>, YANG library, and <get-schema> data where there are lists of modules and submodules.
Some YANG tools may show errors about circular dependencies in the submodules. For example, Pyang gives an error about circular dependencies but does complete the processing to build complete tree or jstree output. If circular dependencies are preventing any necessary tools from correctly processing the YANG, use the combined packaging instead of the submodules. For details about enabling various sets of YANG modules, see the yang-modules commands in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Classic CLI Command Reference Guide.
The lawful intercept (LI) configuration region is modeled in the nokia-li-conf YANG module specified in a single file called nokia-li-conf.yang.
The BOF configuration region is modeled in the nokia-bof-conf YANG module specified in a single file called nokia-bof-conf.yang.
SR OS state information is modeled in the nokia-state YANG module specified in a single file located at YANG/nokia-combined/nokia-state.yang in the SR OS image distribution.
LI state information is modeled in nokia-li-state.yang which augments the primary nokia-state module.
BOF state information is modeled in nokia-bof-state.yang.
There are also a series of nokia-types-* modules that are included by various configuration and state modules.
The SR OS YANG modules have the following attributes.
The modules can be used with NETCONF, telemetry, or with the Set/Get RPCs of the gRPC-based gNMI service.
The modules and submodules indicate the SR OS major release stream using a YANG extension (for example, sros-ext:sros-major-release "rel16";). Module and submodule revisions form a contiguous series of revisions inside a major release stream. There may be two files for the same module with the same revision date but with different contents because they are from two different major release streams. Each active major release stream has revisions ongoing in parallel.
All configuration modules, state modules, and types modules are advertised in the SR OS NETCONF server <hello>. Submodules are not advertised in the <hello>.
The common operational clear, monitor, show, and tools CLI commands do not have equivalent YANG data models.
Some admin and file operations have YANG models whereby each operation is modeled using a YANG ‟action” statement. These can be viewed in the nokia-oper-*.yang files. See YANG-modeled operations for more information.
OpenConfig YANG data models
OpenConfig presents a vendor-neutral set of YANG models. OpenConfig YANG model elements are mapped to application-specific SR OS configuration and state.
Basic configuration
OpenConfig YANG models are available in model-driven interfaces, including the MD-CLI, gNMI, and NETCONF. use the following command to enable them
configure system management-interface yang-modules openconfig-modulesAccess to the OpenConfig models is different depending on the model-driven interface.
MD-CLI
OpenConfig configuration statements are located in the configure openconfig context.
OpenConfig state information is located in the state openconfig context.
When a configuration is validated or committed, the system verifies that openconfig-modules is set to true. If openconfig-modules is set to false and there are OpenConfig configuration statements in the candidate, the action fails with an error indicating that the OpenConfig module cannot be disabled when OpenConfig configuration elements exist.
The operator must set openconfig-modules to true and perform the validate or commit action again. Assuming the configuration is complete and there are no other errors, the transaction succeeds.
The system checks openconfig-modules to determine whether OpenConfig state elements can be accessed.
gNMI and NETCONF
The system checks openconfig-modules to determine whether OpenConfig models can be advertised and whether the system can accept or send OpenConfig configuration or state elements.
If openconfig-modules is set to false, the system blocks OpenConfig edits, requests, and responses from being sent or accepted at the gNMI or NETCONF level. A <get> operation from the root without a declared namespace or branch succeeds but does not include any OpenConfig data. However, a <get> operation that explicitly requests data from the OpenConfig namespace generates an error.
AAA rules for OpenConfig are different in the MD-CLI, NETCONF and gNMI
A configure openconfig AAA profile entry applies to configure openconfig commands in the MD‑CLI, and to config and state elements in NETCONF and gNMI.
A state openconfig AAA profile entry only applies to state openconfig information in the MD-CLI. AAA entries for NETCONF and gNMI state elements are not supported.
Shared model management support
Introduction
Nokia provides a suite of vendor-specific YANG models to configure the network element. OpenConfig is an informal working group which provides vendor-neutral YANG models based on the needed usage of a technology by the community. The Nokia vendor-specific model is a more complete representation of the capabilities of the network element, which includes vendor specific features and functions not described by the OpenConfig YANG models. The two YANG configuration models, Nokia’s vendor-specific and OpenConfig’s vendor-neutral, may be used together to configure the network element. Support for OpenConfig models can be established by examining the OpenConfig model with the vendor-specific deviations and augments.
Merging configuration statements
To ensure complete traceability and the origin of the configuration (that is, which data model configured the feature), the Nokia and OpenConfig configuration statements are maintained separately in the configuration tree. This allows for the greatest flexibility when accommodating configuration differences between the Nokia and OpenConfig models. The configuration statements are merged, giving precedence to the Nokia model configuration statements when there is a collision (that is, when the same function is configured in both the OpenConfig and Nokia models).
To merge configuration for objects, the keys for an object must be equal and deterministic for both the Nokia and OpenConfig models. This provides an anchor for the object and allows the configuration to be rationalized and merged. For example, augments may have been made to OpenConfig models to allow for a deterministic key where a key function is not supported.
One example is using the following command to configure the primary address. In this case, the OpenConfig model does not allow which of the specified interfaces should be the primary. The control of the primary interface is very important.
configure openconfig interfaces interface subinterfaces subinterface ipv4 config primary-addressWhen configuration statements are completed using one configuration model, tab completion for a name or reference identifier is not available in the other model. For example, the name or identifier of a list entry must be equally and explicitly entered in both data models to share the configuration elements across the different models.
There are two different approaches taken for shared model management, on a per Nokia application basis: leaf level and list level management.
An application that supports shared model management at the leaf level allows both configuration models access to the leaf and merge operations can occur at the leaf level. If both Nokia and OpenConfig models include configuration for a leaf, the Nokia configuration takes precedence. The OpenConfig configuration statements remain in its configuration database but are not applied as part of the operational configuration.
An application that supports granularity at the list level allows individual list entries for an application to be managed by one model only. The configuration model that creates the list entry is the only model that can modify or delete the list entry. An attempt to modify the list entry using the configuration access method that does not manage the list entry returns an error message identifying the managing owner of the list entry.
Cannot access or modify element - managed by <managing owner> module
Unless configured explicitly using the Nokia configuration model, a configuration element that does not have a static default value is managed by OpenConfig.
In some situations, partial or incomplete OpenConfig configurations may be allowed. For example, where the OpenConfig structure is accepted but the triggering mapping has not been configured under OpenConfig, the information is not pushed to the application. These partial configurations remain in the OpenConfig configuration tree as they are syntactically correct, however, without an application mapping event, they remain outside of the operating configuration. When a partial configuration is stored in the OpenConfig configuration tree, it does not show as an active element under the SR OS specific application, that is, via show commands or in the /state tree.
Application support
Applications may allow for the configuration to be delivered from either the Nokia YANG model or the OpenConfig YANG models. In many cases, applications allow some level of cooperative configuration such that the configuration statements can be received from both Nokia YANG models and OpenConfig YANG models. To determine the level of cooperative configuration allowed by an application, the application-specific Nokia or the nokia-conf-combined.yang YANG models can be checked for the following extension statement.
sros-ext:shared-model-management {
sros-ext:openconfig false;
}
If the above statement is found, the cooperative shared model management configuration is not allowed for that element and all descendants of the element.
The level of shared model management support can be viewed via the MD CLI help if the OpenConfig YANG models have been enabled.
[ex:configure system management-interface yang-modules]
A:admin@node-2# openconfig-modules true
The models that prevent shared model management at a specific level of the hierarchy include the following statement in the help. For example, the commands in the configure policy-options policy-statement context display the following:
[ex:/configure policy-options policy-statement "policy-1"]
A:admin@node-2# entry ?
[entry-id] <number>
<number> - <1..4294967295>
Entry ID for a route policy entry
Validating and committing
Validation ensures the structure and completeness of the configuration against the OpenConfig model. It does not deliver the configuration to application. It is possible that a validation succeeds when the structure and requirements of the OpenConfig model are met.
The commit function performs the validation as above, with the additional step of delivering the converted OpenConfig statements to the application. A successful validation can be followed by a failure to commit the transaction. For example, the following scenarios result in a failed commit action:
the Nokia application requirements are not met
the list entry is managed by Nokia
a resource limit enforced by the application is exceeded by merging the OpenConfig configuration
Nokia applications that include conditional ‟when” statements using the Nokia YANG model must have the statements satisfied by the Nokia configuration. The OpenConfig configuration cannot verify or satisfy Nokia conditional ‟when” statements. This approach prevents ‟when” statements from changing from one state to another by updating the OpenConfig statements and affecting a non-child leaf in the Nokia configuration. For example, the following message is displayed when the OpenConfig configuration sets the port Ethernet mode to hybrid but the conditional ‟when” statement requires the Nokia configuration to satisfy the condition.
configure port 1/1/4 ethernet access - OpenConfig and Nokia condition mismatch - failed condition
Error reporting
Errors can occur in situations such as the following:
the OpenConfig model attempts to deliver an incomplete configuration as required by the Nokia application
conflicts exist where an OpenConfig model attempts to access a list entry managed by Nokia
other delivery errors from the commit operation
Failed transactions display an error message indicating the reason for the failure. A failure maintains the complete set of YANG parameters, as if the commit function had not been issued. This allows the administrator to correct the source of the error.
In the event of a delivery error, the OpenConfig path and the Nokia path are included in the error message. An example error message is shown below.
<severity>:<module> #<code>: <context in which the error occurred> <related context>
- <error message>
Using the info command
Several variations of the info command are available to collect the required operational data required to view the configuration. These include:
- info
- shows the configuration as explicitly entered from the current context
- info converted
- include converted third-party model configuration from the running datastore. When an object is management by OpenConfig, meaning the running configuration has an entry delivered by an OpenConfig configuration statement, the object is preceded by the statement "## managed: by OpenConfig”
- info converted model openconfig
- includes converted third-party model configuration from the running datastore with the ‟## managed:” indicator removed from the output
- info inheritance
- includes configuration inherited from configuration groups
For more information about the info command, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR MD-CLI User Guide.
Deviating and augmenting
Deviation files are created for the OpenConfig model when the model deviates from the application requirements of the network elements, such as implementations that are not supported, added, or replaced, granularity mismatches, and different ranges. These deviations are included in an OpenConfig YANG file which contains text descriptions when different units or ranges are in place. Deviations are not raised for OpenConfig ‟must” statements, as the ‟must” statement in OpenConfig models is not supported in SR OS. The deviation file follows the naming format nokia-sr-<OpenConfigModule>-deviations.yang, for example, nokia-sr-openconfig-network-instance-deviations.yang.
It is not always necessary to use a deviation file where a specific function is not supported. For example, in the case of enumerations, when an enumerated OpenConfig value is not supported, the validation or commit function fails with an indication that the entry is not valid.
When a mapping exists for an attribute and the configuration is out of range, an error is generated. For example, the Nokia application configuration for leaf B has a range of 1 to 100, where the OpenConfig leaf B specifies a range of 1 to 300. When the OpenConfig value is set above 100, an unsupported value error message is returned.
As an example of a granularity mismatch, Nokia application leaf C supports centiseconds and OpenConfig leaf C supports milliseconds. If the OpenConfig value in milliseconds can be converted to a valid application value, the OpenConfig value is accepted. For example, OpenConfig leaf C 100 ms is converted to application leaf C 1 centisecond. However, if the OpenConfig value cannot be converted to a valid application value, an error is generated. For example, OpenConfig leaf C 125ms cannot be mapped into centiseconds.
Augments files are also included to add configuration for OpenConfig that is required by the Nokia application to function as expected. The augments file follows the naming format nokia-sr-<OpenConfigModule>-augments.yang.
Datastores and regions
As described in RFC 8342 a datastore is a conceptual place to store and access information. A datastore maps to an instantiated YANG data tree. See RFC 8342 for more information about datastores.
SR OS supports conventional configuration datastores (for example, running and candidate) as well as some proprietary datastores (for example, li-running).
SR OS also has a proprietary concept called a region (or configuration region). The set of branches and elements in the configure branch of the CLI are all located in the primary configuration region simply called configure. The majority of SR OS configuration is in the configuration region including ports, interfaces, services and filters. Examples of other regions are:
bof (boot options file)
debug (debugging configuration)
li (lawful intercept)
show system management-interface datastore-locksNMDA support
SR OS supports the Network Management Datastore Architecture (NMDA) for the <intended> and <operational> datastores. When the nmda-support command is enabled, the following changes to the YANG model advertisements for NETCONF occur:
-
The ietf-yang-library:1.1 revision 2019-01-04 YANG module is advertised in the hello capabilities replacing the ietf-yang-library: 1.0 revision 2016-06-21 version.
-
The following additional YANG modules are advertised in the hello capabilities:
- nokia-datastores
- ietf-datastores
- ietf-netconf-nmda
- ietf-origin
-
The ietf-yang-library YANG module revision 2019-01-04 replaces the ietf-yang-library revision 2016-06-21 YANG module when using ietf-netconf-monitoring and ietf-yang-library modules-state.
-
The following additional YANG modules are advertised when using ietf-netconf-monitoring and ietf-yang-library modules-state:
- nokia-datastores
- ietf-datastores
- ietf-netconf-nmda
- ietf-origin
SPC objects
System-Provisioned Configuration (SPC) objects (configuration list elements and their descendants) are provided as a convenience to users in SR OS.
There are two basic classes of SPC objects: deletable and non-deletable.
Deletable SPC objects are placed into the configuration by SR OS but can be deleted (removed) by a user. The following characteristics apply to deletable SPC objects.
-
Deletable SPC objects can be removed or recreated via NETCONF <edit-config> requests.
-
Deletable SPC objects that have not been removed are visible in a NETCONF <get-config> response.
-
Deletable SPC objects that have been removed are not visible in model-driven interfaces.
-
In the classic CLI these are removed by specifying the keyword no, which is then visible in an info command or in a saved config (admin save); for example, no log-id 99.
- The following list summarizes the deletable SPC objects in the SR OS (listed against their MD-CLI paths).
configure log filter 1001
configure log log-id (99,100)
configure system security user-params local-user user "admin"
configure system security aaa local-profiles profile "administrative"
configure system security aaa local-profiles profile "default"
configure system security ssh server-cipher-list-v2 cipher (190..230)
configure system security ssh client-cipher-list-v2 cipher (190..230)
configure system security ssh server-mac-list-v2 mac (200..240)
configure system security ssh client-mac-list-v2 mac (200..240)Non-deletable SPC (ND-SPC) objects are not added to the configuration by SR OS, but they can be referenced by other parts of the configuration even if they are not visible as part of the configuration. The following characteristics apply to ND-SPC objects.
Some ND-SPC objects contain leafs (or other descendant elements) that can be modified (for example, cpu-protection policy 254). Some ND-SPC objects cannot be modified (for example, qos sap-ingress ‟default”).
ND-SPC objects are not displayed in model-driven interfaces as part of the configuration unless a user explicitly creates the object. This explicit creation of ND-SPC objects is only supported when operating in model-driven configuration mode; it is not supported in mixed configuration mode. When a user explicitly creates an ND-SPC object, SR OS remembers that it was explicitly created and displays it as part of the configuration. This may be useful for NETCONF clients and tools that perform offline validation of the configuration against the SR OS YANG models and to resolve leafrefs that point to ND-SPC objects.
Deleted ND-SPC objects in model-driven interfaces no longer appear as part of the configuration. All descendant elements are reset as unconfigured.
ND-SPC objects can be referenced by other parts of the configuration regardless of whether they have been modified or created.
ND-SPC objects created inside a configuration group in model-driven interfaces do not appear in the output of info intended or info inheritance.
-
ND-SPC objects are not displayed in the classic CLI as part of the configuration unless a child or descendant element is modified. Some exceptions to this behavior include the following examples.
configure service customer 1 name ‟1” configure system security cpu-protection policy 254 -
ND-SPC objects cannot be deleted in the classic CLI. A deletion attempt returns an error.
The following non-deletable SPC objects are the common ones used.
configure service customer "1" configure qos sap-egress queue 1 configure qos sap-ingress queue (1,11)- The following list summarizes the non-deletable SPC objects in the SR OS (listed
against their MD-CLI paths). Note: Support for commands in the following list depends on the type of router. See the 7450 ESS, 7750 SR, 7950 XRS, and VSR MD-CLI Command Reference Guide for support information.
bof port "management" bof router "management" bof router interface "management" configure application-assurance group partition cflowd export-type ("volume","tcp-performance","rtp-performance","comprehensive","pgw-edr") configure application-assurance group partition policy app-group "Unknown" configure application-assurance group partition policy application "Unknown" configure application-assurance group partition statistics aa-sub-study ("protocol","application") configure call-trace location (cf1,cf2) configure call-trace trace-profile "default" configure call-trace trace-profile ‟default” configure card fp ingress network pool "default" configure cflowd sample-profile 1 configure eth-cfm default-domain bridge-identifier <x> configure filter log 101 configure lag scheduler vlan-qos-policy "default" configure log log-events (adp event tmnxDiscoveryEndNotify ... wpp event tmnxWppPGHostAuthFailed) configure log log-id 101 configure multicast-management bandwidth-policy "default" configure multicast-management multicast-info-policy "default" configure multicast-management multicast-info-policy bundle "default" configure oam-pm bin-group 1 configure oam-pm bin-group bin-type (fd,fdr,ifdv) configure oam-pm bin-group bin-type bin (0..2) configure port ethernet egress port-scheduler-policy overrides level (1..8) configure port ethernet lldp dest-mac (nearest-bridge,nearest-non-tpmr,nearest-customer) configure port ethernet lldp dest-mac tx-mgmt-address (oob,system,system-ipv6,oob-ipv6) configure port scheduler vlan-qos-policy "default" configure port tdm ds1 channel-group egress port-scheduler-policy overrides level (1..8) configure port tdm ds3 channel-group egress port-scheduler-policy overrides level (1..8) configure port tdm e1 channel-group egress port-scheduler-policy overrides level (1..8) configure port tdm e3 channel-group egress port-scheduler-policy overrides level (1..8) configure qos fp-resource-policy "default" configure qos fp-resource-policy aggregate-shapers queue-sets size (2..8) configure qos hw-agg-shaper-scheduler-policy sched-class (1..6) configure qos network "default" configure qos network egress fc (be,l2,af,l1,h2,ef,h1,nc) configure qos network ingress fc (be,l2,af,l1,h2,ef,h1,nc) configure qos network-queue "default" configure qos network-queue queue (1,9) configure qos policer-control-policy root priority-mbs-thresholds priority (1..8) configure qos policer-control-policy root tier (1,2) configure qos port-scheduler-policy level (1..8) configure qos queue-group-templates egress queue-group "policer-output-queues" configure qos queue-group-templates egress queue-group queue 1 configure qos queue-group-templates egress queue-group sched-class-elevation sched-class (1..6) configure qos sap-egress "default" configure qos sap-egress queue 1 configure qos sap-egress sched-class-elevation sched-class (1..6) configure qos sap-ingress "default" configure qos sap-ingress queue (1,11) configure qos scheduler-policy tier (1..3) configure qos shared-queue "egress-pbr-ingress-queues" configure qos shared-queue "policer-output-queues" configure qos shared-queue fc be configure qos slope-policy "_tmnx_hs_default" configure qos slope-policy "default" configure router ("Base","management","vpls-management") configure router bgp convergence family (ipv4,vpn-ipv4,ipv6,vpn-ipv6,label-ipv4,label-ipv6) configure router bgp multipath family (ipv4,ipv6,label-ipv4,label-ipv6) configure router bgp next-hop-resolution labeled-routes transport-tunnel family (vpn,label-ipv4,label-ipv4) configure router bgp next-hop-resolution shortcut-tunnel family (ipv4,ipv6) configure router interface ("system","management") configure router interface network-domains network-domain "default" configure router isis 0 igp-shortcut tunnel-next-hop family (ipv4,ipv6,srv4,srv6) configure router isis interface level (1,2) configure router isis level (1,2) configure router isis link-group level (1,2) configure router isis segment-routing-v6 locator level (1,2) configure router isis segment-routing-v6 micro-segment-locator level (1,2) configure router mpls class-forwarding-policy fc (be,l2,af,l1,h2,ef,h1,nc) configure router mpls interface "system" configure router mpls lsp auto-bandwidth fc (be,l2,af,l1,h2,ef,h1,nc) configure router mpls lsp-template auto-bandwidth fc (be,l2,af,l1,h2,ef,h1,nc) configure router network-domains network-domain "default" configure router network-domains network-domain ‟default” configure router ospf igp-shortcut tunnel-next-hop family (ipv4,srv4) configure router ospf3 igp-shortcut tunnel-next-hop family (ipv4,ipv6,srv4,srv6) configure router p2mp-sr-tree p2mp-policy candidate-path path-instances (1,2) configure router rsvp interface "system" configure router sgt-qos... configure service cpipe sap egress qos policer-control-policy overrides root priority-mbs-thresholds priority (1..8) configure service cpipe sap ingress qos policer-control-policy overrides root priority-mbs-thresholds priority (1..8) configure service customer "1" configure service epipe sap egress qos policer-control-policy overrides root priority-mbs-thresholds priority (1..8) configure service epipe sap ingress qos policer-control-policy overrides root priority-mbs-thresholds priority (1..8) configure service ies interface sap egress qos policer-control-policy overrides root priority-mbs-thresholds priority (1..8) configure service ies interface sap ingress qos policer-control-policy overrides root priority-mbs-thresholds priority (1..8) configure service ies subscriber-interface group-interface wlan-gw vlan-range "unmatched" configure service ipipe sap egress qos policer-control-policy overrides root priority-mbs-thresholds priority (1..8) configure service ipipe sap ingress qos policer-control-policy overrides root priority-mbs-thresholds priority (1..8) configure service vpls interface sap egress qos policer-control-policy overrides root priority-mbs-thresholds priority (1..8) configure service vpls interface sap ingress qos policer-control-policy overrides root priority-mbs-thresholds priority (1..8) configure service vprn bgp multipath family (ipv4,ipv6,label-ipv4,label-ipv6) configure service vprn interface sap egress qos policer-control-policy overrides root priority-mbs-thresholds priority (1..8) configure service vprn interface sap ingress qos policer-control-policy overrides root priority-mbs-thresholds priority (1..8) configure service vprn isis interface level (1,2) configure service vprn isis level (1,2) configure service vprn isis link-group level (1,2) configure service vprn sgt-qos... configure service vprn subscriber-interface group-interface wlan-gw vlan-range "unmatched" configure subscriber-mgmt gtp peer-profile ("default","default_s11") configure subscriber-mgmt ipoe-session-policy "_tmnx_bonding" configure subscriber-mgmt ipoe-session-policy "default" configure subscriber-mgmt ppp-policy "default" configure system alarm-contact-input (1..4) configure system fp resource-allocation lpm scale-option (1..4) configure system fp resource-allocation pool (1,2) configure system power-management 1 configure system ptp router "Base" configure system security cpu-protection policy (254,255) configure system security dist-cpu-protection policy ("_default-access-policy","_default-network-policy","_default-port-policy") configure system security snmp access group (cli-li-readwrite,cli-readonly,cli-readwrite,cli-vprn-readwrite,snmp-mgmt,snmp-ro,snmp-rw,snmp-rwa,snmp-trap,snmp-vpls-mgmt,snmp-vprn,snmp-vprn-ro) configure system security snmp view (iso,li-view,mgmt-view,no-security,vprn-view) configure system security user-template {tacplus-default,radius-default,ldap-default} configure system usb "cf2" configure test-oam service-activation-testhead acceptance-criteria-template "default" configure test-oam service-activation-testhead frame-size-template "default" configure test-oam twamp twamp-light source-udp-port-pools port (64374..64383)
Prerequisites for using model-driven management interfaces
Loose references to IDs
A loose reference does not require the target of the reference to exist in the configuration.
For example, when the management interface configuration mode is classic, you cannot configure the following command, even if ip-filter 37 does not exist in the configuration.
configure service pw-template 23 egress filter ip 37Before switching from the classic mode to model-driven or mixed, all loose references using IDs must be replaced with references using string names or removed from the configuration for the following elements:
- all services including the following;
configure service vprn configure service vpls configure service epipe - the following mirror
element
configure mirror mirror-dest - the following service
elements
configure service pw-templates configure service customer - the following filter
elements
configure filter ip-filter configure filter ipv6-filter configure filter mac-filter - the following QoS
elements
configure qos network configure qos sap-ingress configure qos sap-egress - the following Ethernet CFM
elements
configure eth-cfm domain configure eth-cfm association
A name can also be changed in releases before Release 15.1.R1. Elements without names are automatically assigned a name (the ID converted to a string) during an upgrade to Release 15.1.R1 or later, and cannot be changed without manually deleting and recreating the element.
Loose references to IDs for the objects in the preceding list cannot be created while in mixed or model-driven configuration mode. Any classic CLI scripts must also be updated to avoid the use of any of the following commands.
In the following example, a configuration is shown for the service PW template egress filter.
configure service pw-template 23 egress filter ip 37You can change this configuration to the following.
configure service pw-template 23 egress filter-name ip ops-sec-filter-a33Because ip-filter 37 is a loose reference, it does not require a name for the configuration to be valid. However, you may want to assign a name as follows, to make the binding operational.
configure filter ip-filter 37 name ops-sec-filter-a33
The following lists the set of affected loose references. Some items take a service name as an input. SR OS converts these service names to IDs, and stores the IDs in the configuration. In these cases, the service-name becomes an alias at configuration edit time and is not stored as a reference.
The following lists the set of affected loose references. Some items take a service name as an input. SR OS converts these service names to IDs, and stores the IDs in the configuration. In these cases, the service-name becomes an alias at configuration edit time and is not stored as a reference.
IPsec related configuration:
configure service vprn interface sap ipsec-tunnel local-gateway-address
configure service vprn interface sap ip-tunnel delivery-service
configure service vprn interface sap l2tpv3-session router
configure service epipe sap l2tpv3-session router
configure service vpls sap l2tpv3-session router
configure service vprn interface sap ipsec-gw default-secure-service
configure service ies interface sap ipsec-gw default-secure-service
configure service vprn interface sap ipsec-gw dhcp server
configure service ies interface sap ipsec-gw dhcp server
configure service vprn interface sap ipsec-gw dhcp6 server
configure service ies interface sap ipsec-gw dhcp6 server
configure service vprn interface sap ipsec-gw local-address-assignment ipv4 address-
source
configure service vprn interface sap ipsec-gw local-address-assignment ipv6 address-
source
configure service ies interface sap ipsec-gw local-address-assignment ipv4 address-
source
configure service ies interface sap ipsec-gw local-address-assignment ipv6 address-
source
configure service vprn interface sap ipsec-tunnel bfd-enable
configure ipsec client-db client private-service
configure system file-transmission-profile router
eth-cfm, oam-pm, and saa:
configure eth-cfm default-domain bridge-identifier
configure eth-cfm domain association bridge-identifier
configure oam-pm session ip router
configure oam-pm session ip router service-name
configure saa test type cpe-ping service
configure saa test type icmp-ping router
configure saa test type icmp-ping service-name
configure saa test type icmp-trace router
configure saa test type icmp-trace service-name
configure saa test type mac-ping service
configure saa test type mac-trace service
configure saa test type vprn-ping
configure saa test type vprn-ping service
configure saa test type vprn-trace
configure saa test type vprn-trace service
Filters:
configure service pw-template egress filter ipv6
configure service pw-template egress filter ip
configure service pw-template egress filter mac
configure service pw-template ingress filter ipv6
configure service pw-template ingress filter ip
configure service pw-template ingress filter mac
configure service template epipe-sap-template egress filter ip
configure service template epipe-sap-template egress filter ipv6
configure service template epipe-sap-template egress filter mac
configure service template epipe-sap-template ingress filter ip
configure service template epipe-sap-template ingress filter ipv6
configure service template epipe-sap-template ingress filter mac
configure service template vpls-sap-template egress filter ip
configure service template vpls-sap-template egress filter ipv6
configure service template vpls-sap-template egress filter mac
configure service template vpls-sap-template ingress filter ip
configure service template vpls-sap-template ingress filter ipv6
configure service template vpls-sap-template ingress filter mac
configure li li-filter-block-reservation li-reserved-block ip-filter
configure li li-filter-block-reservation li-reserved-block ipv6-filter
configure li li-filter-block-reservation li-reserved-block mac-filter
PKI:
configure system security pki ca-profile cmpv2 url
configure system security pki ca-profile ocsp service
QoS:
configure service template epipe-sap-template ingress qos
configure service template epipe-sap-template egress qos
configure service template vpls-sap-template ingress qos
configure service template vpls-sap-template egress qos
configure service pw-template ingress qos
configure service pw-template egress qos
Subscriber management:
configure service ies subscriber-interface group-interface srrp bfd-enable
configure service vprn subscriber-interface group-interface srrp bfd-enable
configure subscriber-mgmt local-user-db ipoe host host-identification service-id
configure subscriber-mgmt local-user-db ipoe host interface service-id
configure subscriber-mgmt local-user-db ipoe host match-radius-proxy-cache server
configure subscriber-mgmt local-user-db ipoe host msap-defaults service
configure subscriber-mgmt local-user-db ipoe host retail-service-id
configure subscriber-mgmt local-user-db ppp host interface service-id
configure subscriber-mgmt local-user-db ppp host l2tp group service-id
configure subscriber-mgmt local-user-db ppp host msap-defaults service
configure subscriber-mgmt local-user-db ppp host retail-service-id
configure subscriber-mgmt msap-policy vpls-only-sap-parameters igmp-snooping mvr
from-vpls
configure service vpls sap msap-defaults service
Miscellaneous:
configure vrrp policy
configure service vprn interface vrrp bfd-enable
configure service vprn interface ipv6 vrrp bfd-enable
configure router l2tp group ppp default-group-interface service-id
configure router l2tp group tunnel ppp default-group-interface service-id
configure service vprn l2tp group ppp default-group-interface service-id
configure service vprn l2tp group tunnel ppp default-group-interface service-id
configure redundancy multi-chassis peer mc-ring l3-ring in-band-control-path
service-id
configure redundancy multi-chassis peer mc-ring l3-ring ring-node connectivity-
verify service-id
configure redundancy multi-chassis peer mc-ring ring in-band-control-path service-id
configure redundancy multi-chassis peer mc-ring ring ring-node connectivity-verify
service-id
configure open-flow of-switch of-controller vprn
Strict routing policy validation
Strict routing policy validation is used for model-driven interfaces. The routing policy must exist for the management interface configuration mode to be changed. Remove references to non-existent routing policies before attempting to switch modes. Strict policy validation is applied to the following routing policy references:
ARP and ND in the Base router and VPRN instances
BGP in the Base router and VPRN instances
global and local variables in main policies and sub-policies
IGMP, MLD, and PIM in the Base router and VPRN instances
IS-IS in the Base router and VPRN instances
LDP
OSPF and OSPFv3 in the Base router and VPRN instances
policy-option in from, to, action, and default-action statements
policy-option in sub-policies, prefix-list, as-path, as-path-group, damping, and community policies
RIP and RIPng in the Base router and VPRN instances
RSVP
single policy-statement or logical policy expressions
static routes in the Base router and VPRN instances
subscriber management, except for in mld-policy configuration for a local user database (LUDB) host
VPLS for BGP VSI
VPRN for GRT, MVPN, and VRF
String names as keys
Many elements use string names as keys in model-driven interfaces instead of the numerical identifiers used in the classic CLI and SNMP.
It is recommended that you assign names to the following elements before an upgrade to Release 15.1 or later:
- all services including the following;
configure service vprn configure service vpls configure service epipe - the following mirror
element
configure mirror mirror-dest - the following service
elements
configure service pw-templates configure service customer - the following filter
elements
configure filter ip-filter configure filter ipv6-filter configure filter mac-filter - the following QoS
elements
configure qos network configure qos sap-ingress configure qos sap-egress - the following Ethernet CFM
elements
configure eth-cfm domain configure eth-cfm association
Transitioning between modes
- Verify that the system configuration only contains commands that are supported in model-driven interfaces. For more information, see section ‟Unsupported Configuration in MD Interfaces” in the SR OS R22.x.Rx Software Release Notes, part number 3HE 18412 000 x TQZZA.
- Update the system configuration to meet the prerequisites described in Prerequisites for using model-driven management interfaces.
-
Perform a mode change configuration check as follows.
Use the following command to check if the configuration meets the preceding prerequisite reference requirements to change the management interface configuration mode. Incompatible configuration commands are displayed with an error reason if the prerequisite is not met.
tools perform system management-interface configuration-mode checkNote: The command does not check if the configuration contains commands that are unsupported in model-driven interfaces. For more information, see section ‟Unsupported Configuration in MD Interfaces” in the SR OS R22.x.Rx Software Release Notes, part number 3HE 18412 000 x TQZZA.The following example shows the output of the configuration-mode check command when there are incompatible configuration commands.
=============================================================================== Mode Switch Validation Check =============================================================================== Current Mode : classic Desired Mode : model-driven Configure : Errors Detected LI : No Errors ------------------------------------------------------------------------------- Configuration Validation Errors ------------------------------------------------------------------------------- 1 : MINOR: MGMT_CORE #2004 Incompatible configuration - dynsvc-password configured in system security password 2 : MINOR: MGMT_CORE #2004 Incompatible configuration - 'eth-cfm association bridge-identifier' reference to service-id exists 3 : MINOR: MGMT_CORE #2004 Incompatible configuration - ca-profile cmpv2 url service-id references exist 4 : MINOR: MGMT_CORE #224 Entry does not exist (MD-CLI: configure policy- options policy-statement "PEERING_ROUTER_OUT" entry 50 from prefix-list) ------------------------------------------------------------------------------- Action required: configuration requires updating before mode switch =============================================================================== - Save and back up your configuration. Existing configuration is converted to the MD-CLI format if the mode is changed to model-driven and the saved configuration file is in MD-CLI format.
-
Change the configuration mode to mixed or model-driven as follows.
Note:
-
Depending on the size of the system configuration, transitioning from classic mode may take several seconds to several minutes while the model-driven database is populated and synchronized to the current configuration. During the transition period, configuration changes are not allowed and service is not affected.
-
Transitioning to classic mode is immediate with no impact to services on the router.
-
-
Save the configuration manually.
-
In mixed mode, issue admin save from the classic CLI.
-
In model-driven mode, issue admin save from the MD-CLI.
-
Configuring the CLI engine
The CLI engine refers to the CLI environment used in a user session (for example, console, Telnet, or SSH) to configure and operate the router. The CLI engine is either the classic CLI engine or the MD-CLI engine. The following terms are also used:
- preferred CLI engine
- the CLI engine that is started at user login
- authorized CLI engine
- a CLI engine that a user can switch to (using the CLI engine switch command (‟//”)) or where a user can execute commands
- active CLI engine
- the CLI engine that is currently in use for a user session
The default preferred CLI engine and authorized CLI engines for a session are determined by the management interface configuration mode, which eliminates the need to explicitly configure the CLI engine. With the use of these dynamic defaults, it is possible to transition between the different configuration modes. Management interface configuration modes and CLI engines summarizes the CLI engines for the management interface configuration modes.
| Management interface configuration mode | Default preferred CLI engine | Default authorized CLI engines |
|---|---|---|
classic |
classic-cli |
classic-cli |
mixed |
classic-cli |
md-cli, classic-cli |
model-driven |
md-cli |
md-cli, classic-cli (read-only) |
The preferred and authorized CLI engines for a session can be changed to use either the classic CLI or the MD-CLI engine.
In the classic CLI, the first engine configured is the preferred CLI engine. The default is no cli-engine.
A:node-2>config>system>management-interface>cli# cli-engine ?
- cli-engine <engine-type> [<engine-type>...(upto 2 max)]
- no cli-engine
<engine-type> : classic-cli|md-cli
In the MD-CLI, the cli-engine command is a user-ordered list, and the first engine from that list is configured as the preferred CLI engine. Leaving the cli-engine command unconfigured (or deleting the cli-engine values) maintains or reverts to the dynamic default. MD-CLI cli-engine configurations summarizes the supported actions for the MD-CLI cli-engine configuration.
| cli-engine configuration | Preferred CLI engine | Authorized CLI engines | Description |
|---|---|---|---|
|
[classic-cli] |
classic-cli |
classic-cli |
User is restricted to the classic CLI engine |
|
[classic-cli md-cli] |
classic-cli |
classic-cli, md-cli |
User can switch between classic CLI and MD-CLI engines in a session |
|
[md-cli classic-cli] |
md-cli |
md-cli, classic-cli |
User can switch between MD-CLI and classic CLI engines in a session |
|
[md-cli] |
md-cli |
md-cli |
User is restricted to the MD-CLI engine |
Commit history
The commit history provides a persistent history of configuration changes committed in model-driven interfaces. A separate history of the last commits (default 50, up to 200) is maintained for each configuration region (bof, configure, debug, and li). Each commit is uniquely identified by a numerical sequential incrementing commit ID assigned by the system.
In the MD-CLI, use the following show command to view the commit history or use the state model:
show system management-interface commit-history
state system management-interface configuration-region commit-historyThe saved configuration file header also displays the commit history from the last configuration save.
An optional commit comment can be entered using the MD-CLI commit comment command or the NETCONF <commit> RPC. Newline separators (\n) can be entered in the comment string to display multiple comment lines.
The following example shows the first commit made by the system when the router boots, followed by two commits by a user with the MD-CLI.
System and user commits with MD-CLI
[ex:/configure]
A:admin@node-2# commit comment "Second commit with the MD-CLI."
[ex:/configure]
A:admin@node-2# commit comment "Third commit with the MD-CLI."
[ex:/configure]
A:admin@node-2# show system management-interface commit-history
===============================================================================
Commit History
===============================================================================
Total Commits : 3
3
Committed 2022-02-01T11:01:03.8-05:00 by admin (MD-CLI) from 10.1.145.205
Comment "Third commit with the MD-CLI."
Location "cf3:\config.cfg"
2
Committed 2022-02-01T11:00:47.7-05:00 by admin (MD-CLI) from 10.1.145.205
Comment "Second commit with the MD-CLI."
Location "cf3:\config.cfg.1"
1
Committed 2022-02-01T10:56:01.3-05:00 by system (MD-CLI) from Console
Log "System booted version B-22.2.R1."
Location "Configuration is not saved to startup."The following example shows a fourth commit made by automation using the NETCONF <commit> RPC with the <comment> augmentation.
NETCONF <commit> RPC with <comment> augmentation
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit>
<comment>Fourth commit with NETCONF.</comment>
</commit>
</rpc>
]]>]]>show system management-interface commit-history===============================================================================
Commit History
===============================================================================
Total Commits : 4
4
Committed 2022-02-01T11:13:38.7-05:00 by admin (NETCONF) from 10.1.236.68
Comment "Fourth commit with NETCONF."
Location "cf3:\config.cfg"
3
Committed 2022-02-01T11:01:03.8-05:00 by admin (MD-CLI) from 10.1.145.205
Comment "Third commit with the MD-CLI."
Location "cf3:\config.cfg.1"
2
Committed 2022-02-01T11:00:47.7-05:00 by admin (MD-CLI) from 10.1.145.205
Comment "Second commit with the MD-CLI."
Location "cf3:\config.cfg.2"
1
Committed 2022-02-01T10:56:01.3-05:00 by system (MD-CLI) from Console
Log "System booted version 22.2.R1."
Location "Configuration is not saved to startup."The following usage guidelines apply to the commit history.
-
The commit history is supported in model-driven configuration mode only.
-
The system files located in the cf3:\.commit-history directory must not be edited or deleted.
-
Editing the BOF from the boot loader does not create a commit history entry.
-
Nokia recommends setting the commit history value to at least 50, which is the default value. The commit history can be disabled by setting the value to 0.
-
Use the MD-CLI environment time-format and environment time-display options to change the time formats displayed in the output of the following commands.
show system management-interface commit-history info state system management-interface <region-name> commit-history admin show configurationThe time formats in admin show configuration are in the generated and finished lines.
-
The MD-CLI environment commands do not change any time formats in the saved configuration file header or footer. These time formats are always written in RFC 3339 format in the Coordinated Universal Time (UTC) or local time zone. Use the following command to configure the value.
configure system time prefer-local-time
Incremental saved configuration files
When incremental saved configuration files are enabled, the system saves each configuration commit to the configure configuration region in a separate incremental saved configuration file, instead of saving a complete saved configuration file each time. This mechanism makes commits over model-driven interfaces (the MD-CLI, NETCONF and gRPC/gNMI) much faster, because less configuration needs to be saved.
When the system boots or the rollback command is issued, the last complete saved configuration file is loaded first, and then any required incremental saved configuration files are loaded in the sequence they were committed to apply the previous saved configuration.
The commit history displays information about incremental and complete saved configuration files. The "Location" field displays the complete saved configuration file location, and the "Increment" field displays the incremental saved configuration file location. When the "Location" field is not displayed, the incremental saved configuration file in the "Increment" field is loaded as described above.
Use the following command to show the commit history.
show system management-interface commit-history===============================================================================
Commit History
===============================================================================
Total Commits : 2
2
Committed 2022-06-21T12:55:05.4-04:00 by admin (MD-CLI) from 192.168.0.10
Increment "cf3:\.commit-history\config-2022-06-21T16-55-05.4Z-4.is"
1
Committed 2022-06-21T12:49:31.4-04:00 by admin (MD-CLI) from 192.168.0.10
Increment "cf3:\.commit-history\config-2022-06-21T16-49-31.4Z-3.is"
Location "cf3:\config.cfg"
A background process generates a complete saved configuration file periodically to reduce the number of incremental saved configuration files that are needed by system. The commit history is updated with a "Location" field like in the following example.
===============================================================================
Commit History
===============================================================================
Total Commits : 2
2
Committed 2022-06-21T12:55:05.4-04:00 by admin (MD-CLI) from 192.168.0.10
Increment "cf3:\.commit-history\config-2022-06-21T16-55-05.4Z-4.is"
Location "cf3:\config.cfg"
1
Committed 2022-06-21T12:49:31.4-04:00 by admin (MD-CLI) from 192.168.0.10
Increment "cf3:\.commit-history\config-2022-06-21T16-49-31.4Z-3.is"
Location "cf3:\config.cfg.1"
Incremental saved configuration files are enabled with the configure system management-interface configuration-save incremental-saves command, and must be configured together with the following constraints.
- configure system management-interface configuration-mode must be model-driven
- configure system grpc gnmi auto-config-save, configure system management-interface cli md-cli auto-config-save, and configure system management-interface netconf auto-config-save must be set to true
-
- configure system management-interface commit-history must be >= 50
- configure system management-interface configuration-save configuration-backup must be >= configure system management-interface commit-history
- configure redundancy synchronize must be config or boot-env on systems that support redundancy
The following usage guidelines apply.
- The commit history and incremental saved configuration files in the cf3:\.commit-history directory must not be edited by the user
- Multiple configuration save and synchronization events occur because additional system files are saved and synchronized between the active and standby CPM
- The first commit after a system boot or ISSU is followed by a complete save if an admin save command was not executed
- The configuration must be saved by executing the admin save command before executing the admin redundancy force-switchover command
YANG-modeled operations
In addition to YANG-based configuration and state, the SR OS also supports YANG-based operations (for example, admin reboot, file remove).
The SR OS YANG-modeled operations infrastructure applies to MD-CLI and NETCONF interfaces and is supported in any management interface configuration mode (classic, mixed, or model-driven). It is not applicable to operations requested in classic CLI, SNMP, or gRPC interfaces.
YANG-based operations are allocated an operation ID. You can examine the details of an operation, including the following information:
-
execution status of the operation: in-progress, terminated, or terminated-incomplete
-
start-time of the operation
-
timeouts associated with the operation
state system management-interface operations operationContents of the global operations table when a file remove-directory command is in progress
[/]
A:admin@node-2# info state system management-interface operations
oldest-operation-id 4
newest-operation-id 4
operation 4 {
asynchronous false
status in-progress
start-time 2021-04-13T16:13:18.1+00:00
request-path "/file/remove-directory"
session-id 13
user "admin"
}Configure and use the operation ID to remove an operation. Use the following command to remove an operation:
admin system management-interface operations delete-operationAsynchronous versus synchronous operations
SR OS supports the following basic response modes for YANG-modeled operations:
synchronous
This is the default response mode. This mode is supported on MD-CLI and NETCONF.
asynchronous
This mode is supported only on NETCONF.
In synchronous mode, the response to the operation request contains the complete result data and is held until the operation is complete. No additional operations can be initiated in the same management session (MD-CLI or NETCONF) until the previous operation completes. This behavior is evident in MD-CLI, for example, where the MD-CLI prompt does not return and no input is accepted until the currently running operation is completed.
In asynchronous mode, the response to the operation request does not contain the result data and is sent without waiting for the operation to complete. The request only starts the operation and the client (requester) obtains the result later. Users can perform other commands in the management session while the asynchronous operation runs in the background.
The response to an asynchronous operation request contains an operation ID. This ID is a handle for the operation and allows users to:
query the status of the operation
stop or delete the operation
Synchronous operations require a management session (NETCONF or MD-CLI) for each concurrent operation, whereas a single management session can manage hundreds of concurrent asynchronous operations.
Only a subset of SR OS operational commands are supported in the asynchronous response mode. See the SR OS nokia-oper-*.yang files for actions with the ‟asynchronous” leaf as part of the input to identify operations that support asynchronous mode.
The following figure shows a typical flow for an asynchronous operation.
A stopped asynchronous operation (for example, stopped using the stop-operation command) stays in the global operations table until it is explicitly deleted using a delete-operation command or the retention timeout expires. Synchronous operations are automatically removed from the global operations table when they are completed or stopped.
Because of the parallel processing nature of asynchronous operations, it is possible that an operation completes before the original requester of the operation receives a reply to the request. This means a client could receive a notification about an operation ID that the client does not yet know about.
Examples of operations in the MD-CLI
All operations in the MD-CLI execute in synchronous response mode.
The following example shows an operation with no specific result data to return.
MD-CLI operation with no result data to return
[/]
A:admin@mode-2# admin clear security password-history allThe following examples show operations that return result data.
MD-CLI operation with result data
[/]
A:admin@node-2# file version cf3://image/both.tim
TiMOS-C-21.5.R1 for x86_64
Wed May 19 15:02:26 PDT 2021 by builder in /builds/c/215B/R1/panos/main/srosThe following example shows another operation that returns result data.
[/]
A:node-2# oam eth-cfm loopback aa:bb:cc:dd:ee:22 md-admin-name MyDomain
ma-admin-name MyAssociation mep-id 1 size 0 send-count 5 interval 10 timeout 5
Eth-Cfm Loopback Test Initiated: Mac-Address: aa:bb:cc:dd:ee:22, out sap: 2/2/1:20
38 bytes; lb_seq=1 passed
38 bytes; lb_seq=2 passed
38 bytes; lb_seq=3 passed
38 bytes; lb_seq=4 passed
38 bytes; lb_seq=5 passed
Sent 5 packets, received 5 packets [0 out-of-order, 0 Bad Msdu]
Packet loss 0.00%Examples of synchronous operations in NETCONF
The following example shows synchronous operation that returns no result data.
synchronous operation that returns no result data
Request:
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<action xmlns="urn:ietf:params:xml:ns:yang:1">
<admin xmlns="urn:nokia.com:sros:ns:yang:sr:oper-admin">
<clear>
<security>
<password-history>
<all/>
</password-history>
</security>
</clear>
</admin>
</action>
</rpc>
]]>]]>
Response:
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nokiaoper="urn:nokia.com:sros:ns:yang:sr:oper-admin">
<nokiaoper:operation-id>12</nokiaoper:operation-id>
<nokiaoper:start-time>2021-06-16T20:11:44.9Z</nokiaoper:start-time>
<nokiaoper:status>completed</nokiaoper:status>
<nokiaoper:end-time>2021-06-16T20:11:44.9Z</nokiaoper:end-time>
</rpc-reply>
]]>]]>
The following example shows a synchronous operation that returns result data.
synchronous operation that returns result data
Request:
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<action xmlns="urn:ietf:params:xml:ns:yang:1">
<file xmlns="urn:nokia.com:sros:ns:yang:sr:oper-file">
<version>
<url>cf3://image/both.tim</url>
</version>
</file>
</action>
</rpc>
]]>]]>
Response:
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nokiaoper="urn:nokia.com:sros:ns:yang:sr:oper-file">
<nokiaoper:operation-id>17</nokiaoper:operation-id>
<nokiaoper:start-time>2021-06-16T20:37:40.3Z</nokiaoper:start-time>
<nokiaoper:results>
<nokiaoper:version>
<nokiaoper:version-number>C-21.5.R1</nokiaoper:version-number>
<nokiaoper:version-string>TiMOS-C-21.5.R1 for x86_64 Wed May 19 15:02:26
PDT 2021 by builder in /builds/c/215B/R1/panos/main/sros</nokiaoper:
version-string>
</nokiaoper:version>
</nokiaoper:results>
<nokiaoper:status>completed</nokiaoper:status>
<nokiaoper:end-time>2021-06-16T20:37:40.4Z</nokiaoper:end-time>
</rpc-reply>
]]>]]>
Examples of asynchronous operations in NETCONF
The following example shows asynchronous operations in NETCONF.
asynchronous operations in NETCONF
Request:
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<action xmlns="urn:ietf:params:xml:ns:yang:1">
<global-operations xmlns="urn:nokia.com:sros:ns:yang:sr:oper-global">
<oam>
<eth-cfm>
<loopback>
<asynchronous>true</asynchronous>
<destination>aa:bb:cc:dd:ee:22</destination>
<md-admin-name>MyDomain</md-admin-name>
<ma-admin-name>MyAssociation</ma-admin-name>
<mep-id>1</mep-id>
<send-count>5</send-count>
<timeout>5</timeout>
<interval>10</interval>
</loopback>
</eth-cfm>
</oam>
</global-operations>
</action>
</rpc>
]]>]]>
Response:
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nokiaoper="urn:nokia.com:sros:ns:yang:sr:oper-global">
<nokiaoper:operation-id>111</nokiaoper:operation-id>
<nokiaoper:start-time>2021-06-16T14:17:18.3Z</nokiaoper:start-time>
<nokiaoper:status>in-progress</nokiaoper:status>
</rpc-reply>
]]>]]>
The following example shows the global operations table status while the operation is running.
global operations table status while an operation is running
[/]
A:admin@node-2# info state system management-interface operations
oldest-operation-id 111
newest-operation-id 111
operation 111 {
asynchronous true
status in-progress
start-time 2021-06-16T10:17:18.3-04:00
request-path "/global-operations/oam/eth-cfm/loopback"
session-id 21
user "admin"
execution-timeout {
time 2021-06-16T11:17:18.3-04:00
remaining 3599
}
}
next-execution-timeout {
operation-id 111
time 2021-06-16T11:17:18.3-04:00
remaining 3599
}
Use the following command to display log event output when the operation is completed.
show log log-id 99The following example shows the log event output.
Display log event output for completed operations
===============================================================================
Event Log 99 log-name 99
===============================================================================
Description : Default System Log
Memory Log contents [size=500 next event=5 (not wrapped)]
4 2021/06/16 10:17:22.400 EDT WARNING: MGMT_CORE #2005 Base Operation
"operation-id 111 finished with status completed. Presence of messages in the global operations
table: error-messages false, warning-messages false, info-messages false."
The following is an example of the results available in the state branch.
Results available in the state branch
[/]
A:admin@node-2# info state eth-cfm domain MyDomain association MyAssociation mep 1
loopback-results {
unicast-latest-run {
test-status completed
start-time 2021-06-16T10:17:18.0-04:00
end-time 2021-06-16T10:17:22.0-04:00
destination-mac-address aa:bb:cc:dd:ee:22
statistics {
sent-packets 5
received-in-order 5
received-out-of-order 0
received-bad-msdu 0
packet-loss 0.0
}
}
multicast-latest-run {
statistics {
sent-packets 0
received-packets 0
}
}
}
The following example shows the delete operation usage to clean up.
Delete operation usage to clean up
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<action xmlns="urn:ietf:params:xml:ns:yang:1">
<admin xmlns="urn:nokia.com:sros:ns:yang:sr:oper-admin">
<system>
<management-interface>
<operations>
<delete-operation>
<delete-id>111</delete-id>
</delete-operation>
</operations>
</management-interface>
</system>
</admin>
</action>
</rpc>
]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nokiaoper="urn:nokia.com:sros:ns:yang:sr:oper-admin">
<nokiaoper:operation-id>112</nokiaoper:operation-id>
<nokiaoper:start-time>2021-06-16T14:17:38.5Z</nokiaoper:start-time>
<nokiaoper:status>completed</nokiaoper:status>
<nokiaoper:end-time>2021-06-16T14:17:38.6Z</nokiaoper:end-time>
</rpc-reply>
]]>]]>