This guide provides information about the Model-Driven Command Line Interface (MD-CLI).
This guide is organized into functional sections and provides concepts and descriptions of the MD-CLI environment, the configuration workflow, and the syntax and command usage within the MD-CLI. It also describes how the MD-CLI interacts with the classic CLI to perform non-configuration operations.
For a list of unsupported features by platform and chassis, refer to the SR OS R16.0.Rx Software Release Notes, part number 3HE 14220 000x TQZZA.
Command outputs shown in this guide are examples only; actual outputs may differ depending on supported functionality and user configuration.
![]() | Note: This guide generically covers Release 16.0.R1 content and may contain some content that will be released in later maintenance loads. Refer to the SR OS R16.0.Rx Software Release Notes, part number 3HE 14220 000x TQZZA, for information about features supported in each load of the Release 16.0.R1 software. |
All references to the term ‘CLI’ in the SR OS user documentation are generally referring to the classic CLI. The classic CLI is the CLI that has been supported in SR OS from the initial introduction of SR OS.
The MD-CLI is a management interface that can be used to manage Nokia SR OS routers. Some of the benefits of the MD-CLI include:
For more information about NETCONF and gRPC, refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide.
Refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide for information about the management interface configuration mode.
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:
The CLI engine refers to the CLI environment that is being used in a user session (for example, console, Telnet, or SSH) to configure and operate the router.
To enable the MD-CLI engine from the classic CLI, perform the following steps:
When a new user session begins, the MD-CLI engine is available and the MD-CLI prompt is displayed.
When the configuration mode is changed to model-driven, the following applies:
A single CLI command is available in both the classic CLI and MD-CLI engines to switch between the two engines in a user session. When authorized (cli-engine list contains both classic-cli and md-cli), the CLI engine switch command (“//”, the double forward slash) can be executed from any CLI context in both engines to switch to the other CLI engine.
The context in which the CLI engine switch command is executed is saved when toggling between CLI engines and returns to the same context when toggling back.
If switching engines is not authorized (when cli-engine is only [classic-cli] or [md-cli]), the command is rejected.
When switching engines is authorized, all classic CLI engine commands can be executed from the MD-CLI engine. Entering a classic CLI engine command preceded by the “//” command executes the command in the classic CLI engine and returns immediately to the MD-CLI engine. The MD-CLI context is preserved before the switch to the classic CLI engine, and the context is restored when the session returns to the MD-CLI engine. In the following example, the classic CLI command is executed from the configure aaa context in the MD-CLI. When the session returns to the MD-CLI engine, it is returned to the same context.
It is acceptable to have a space between “//” and the CLI command. For example, //show users and // show users are equivalent commands.
User interactions, such as pagination, confirmation, or control characters (for example, CTRL-c to abort an ongoing command execution), are supported during CLI command execution. The CLI engine is switched back to the MD-CLI engine just before the CLI command prompt would normally appear.
Executing MD-CLI commands from the classic CLI engine works in the same way as described for executing classic CLI commands from the MD-CLI engine.
The following describes MD-CLI engine interactions with the classic CLI when using the “//” command:
A command history is maintained per CLI engine. CLI commands executed in the MD-CLI do not appear in the classic CLI history. CLI commands executed in the classic CLI do not appear in the MD-CLI history.
The /!classic-cli command is available in both the classic CLI and MD-CLI engines to explicitly switch to the classic CLI engine in a session, as long as classic-cli is an authorized CLI engine. If switching to the classic CLI engine is not authorized, the command is rejected. Issuing the /!classic-cli command in the classic CLI engine has no effect.
The /!classic-cli switch command can be executed from any CLI context in both engines and the context is preserved for both engines. When the command is executed, the session enters the last saved working context of the classic CLI engine.
The /!md-cli command is available in both the classic CLI and MD-CLI engines to explicitly switch to the MD-CLI engine in a session, as long as md-cli is an authorized CLI engine. If switching to the MD-CLI engine is not authorized, the command is rejected. Issuing the /!md-cli command in the MD-CLI engine has no effect.
The /!md-cli switch command can be executed from any CLI context in both engines and the context is preserved for both engines. When the command is executed, the session enters the last saved working context of the MD-CLI engine.
The /!md-cli and /!classic-cli commands can be useful when executing commands from a file, allowing the file to be executed in either CLI engine and ensuring the commands are run in the intended CLI engine.
The MD-CLI command prompt displays on two lines. The first line contains the following information:
The format of the first line is as follows:
<uncommitted changes indicator> (<configuration mode>) [context]
Examples:
The second line contains the following information:
The format of the second line is as follows:
CPM:user@name#
The following examples display the two-line prompt in different modes.
The following portion of the MD-CLI command tree displays commands related to the environment variables.
The environment configuration for the MD-CLI is available in both the classic CLI and in the MD-CLI, but the configuration applies only to MD-CLI sessions.
In the MD-CLI:
In the classic CLI:
Changes made to the environment configuration apply only to new sessions and do not affect current sessions.
The environment can be customized for all sessions in the configuration under the configure system management-interface cli md-cli environment context, or per session using the environment command. When a new MD-CLI session is started, the per-session environment configuration is copied from the global environment configuration. Changes made to the global environment configuration after the session begins apply only to new sessions and do not affect current sessions. Changes made to the environment parameters for a session apply only for that session.
The per-session environment is accessed by entering environment at the operational root or with /environment from any other mode or context. Changes made in the per-session environment are immediate.
The info command displays the difference between the per-session environment and the configured global environment parameters. Therefore, for a new MD-CLI session, the info command has no output, as the per-session environment is the same as the global environment. The info detail command displays the current values in the global environment for all parameters.
As the default setting of the environment configuration, the uncommitted changes indicator is displayed as part of the command prompt. This setting can be modified per session or it can be changed for all MD-CLI sessions by changing the environment configuration.
The uncommitted-changes-indicator command under the environment prompt context suppresses or displays the change indicator for an MD-CLI session. Environment changes are applied immediately and are lost when the session disconnects.
By default, a blank line precedes the command prompt. This setting can be modified for each MD-CLI session.
The newline command under the environment prompt context suppresses or displays a new line before the prompt.
By default, the context is displayed in the command prompt. This setting can be modified for each MD-CLI session.
The context command under the environment prompt context suppresses or displays the current context.
By default, the timestamp is not displayed before the command prompt. This setting can be modified for each MD-CLI session.
The timestamp command under the environment prompt context suppresses or displays the timestamp.
The environment time-display command configures the time zone display to UTC or local time (as configured in configure system time).
The progress indicator appears on the line immediately following the command and disappears when the MD-CLI command completes or when output is available to display. The indicator is a display of dynamically changing dots.
The delay interval can be configured with the delay command or the indicator can be disabled with the admin-state disable command under the environment progress-indicator context. For example, the user can disable the progress indicator for logged sessions.
The environment more command enables pagination when configured to true and disables pagination when configured to false. With pagination enabled, the display output can be paused and continued, based on the “Press Q to quit, Enter to print next line or any other key to print next page” message at the bottom of the screen.
The pagination setting can be overridden by using | no-more for a single command. As with pagination disabled, the output is displayed completely without any prompts to continue.
The default size for a console window is 24 lines long by 80 characters wide. The environment console command can be used to change these settings.
The INFO: CLI messages are displayed by default. The environment message-security-level command suppresses the INFO messages by changing the setting to warning.
Following are examples of INFO: CLI messages that are suppressed when the setting is changed to warning:
The environment datastore is subject to AAA command authorization. A user can be prevented from modifying the global environment settings or the per-session environment settings, or both.
In the following configuration output, entry 113 blocks user “tstuser” from modifying the global environment settings. In addition, entry 114 prevents the user from changing the per-session environment settings.
A short help description is displayed immediately when the question mark (?) is entered (without needing to press Return). The following displays help from the operational root level.
The help results may depend on the cursor position. For example, the output may differ when a “?” is entered with a space preceding it:
Table 1 describes the meaning of the indicators displayed in the online help.
Symbol | Description |
+ | Indicates a container or list |
- | Indicates a leaf, a leaf-list, a list or container with no leafs, or a global command (if in the operational root) |
^ | Indicates a mandatory element (an element that must be configured before the configuration is considered valid) |
In the following help display example, admin-state, local-address, and router-instance are leafs, mcs-peer is a container, and address and sync-tag are mandatory elements.
When online help is entered for a leaf or leaf-list, a short description of the element is displayed after the element type. The valid input values for the element are also listed, as shown in the following examples.
The description string for the VPRN service can have a length of 1 to 80 characters:
The ? help for the autonomous-system parameter lists the valid number range, followed by a short description of the parameter:
A parameter value may have a unit type associated with it, as shown in the following example of the cbs parameter:
This example shows a parameter that is a reference to another parameter. This slope-policy parameter refers to the slope policy name that is configured through the configure qos slope-policy context. The name is a string of 1 to 32 characters.
An immutable element can only be configured in the transaction in which the parent element is created. It cannot be modified while the parent element exists. Any modification to an immutable element in model-driven interfaces causes SR OS to automatically delete the parent element and recreate it with the new value for the immutable element.
Immutable elements are identified in the online help, as seen in the following examples:
Immutable elements also exist in the classic CLI. They are parameters that are on the command line with the create keyword. For example, in the following classic CLI command, all the parameters shown here on the command line are immutable. These parameters cannot be changed without deleting and recreating the service.
The following help display is an example of optional indicators:
The square brackets ([]) around port-id indicate that the port-id keyword is optional when entering the command.
The angle brackets (<>) indicate a variable name and the pipe (|) indicates a choice. In the preceding example, the correct format of the port command contains one of four options: a port, a connector, a connector port, or a PXC port.
In the preceding example, any of the following would be valid formats for the port command:
The commands in Table 2 are available at the operational root level of the MD-CLI hierarchy.
Command | Description |
admin | Enter the administrative context for system operations |
clear | Clear statistics or reset operational state |
configure | Enter the configuration context |
environment | Enter the environment configuration context |
show | Show operational information |
tools | Enter the tools context for troubleshooting and debugging |
The global commands in Table 3 are available from various levels of the MD-CLI hierarchy.
Command | Description |
back | Move back one or more levels |
edit-config | Enter a candidate configuration mode |
exec | Execute commands from a file |
exit | Return to the previous context or to the operational root |
history | Show the most recently entered commands |
logout | Exit the CLI session |
pwc | Show the present working context |
quit-config | Leave the candidate configuration mode |
top | Move to the top level of the context |
tree | Show the command tree under the present working context |
Table 4 lists configuration commands that are available in configuration mode.
Command | Description |
commit | Commit changes to the running datastore |
compare | Show changes between datastores |
delete | Delete configuration from the candidate datastore |
discard | Discard changes in the candidate datastore |
info | Show the running configuration from the present working context |
load | Load a configuration from a file |
rollback | Rollback to a previous configuration |
validate | Validate changes in the candidate datastore |
The following commands can be used to navigate the MD-CLI hierarchy (context) levels:
The tree command displays the command tree under the present working context, excluding the present working context element. Hierarchy is indicated with a pipe (|) and a “+-- “ separator precedes each element. The tree output is in alphabetical order of elements.
The flat option displays the command hierarchy under the present working context on one line, excluding the present working context element.
The detail option displays all key and field values in the output on every line.
The flat and detail options can be combined in any order.
Table 5 lists the control characters and keystrokes available to execute and edit commands.
Command | Description |
/ (Slash) | Return to the operational root (equivalent to exit all) if used without parameters Navigate into context or set the value and remain in current context if used at the beginning of a line (equivalent to exit all, and then the command) |
CTRL-z | Execute command and return to the operational root (equivalent to Enter and exit all) |
CTRL-c | Abort the pending command |
CTRL-d | Delete the current character |
CTRL-h | Delete the current character and move the cursor left |
CTRL-u | Delete text up to the cursor and preserve the character under the cursor |
CTRL-k | Delete text after the cursor. The character under the cursor is not preserved. |
CTRL-a (or Home) | Move to the beginning of the line |
CTRL-e (or End) | Move to the end of the line |
CTRL-p (or Up arrow) | Display prior command from history |
CTRL-n (or Down arrow) | Display next command from history |
CTRL-b (or Left arrow) | Move the cursor one space to the left |
CTRL-f (or Right arrow) | Move the cursor one space to the right |
CTRL-w | Delete the word up to the cursor |
ESC+b | Move back one word, or to the beginning of the current word if the cursor is not at the start of the word |
The MD-CLI supports both command abbreviation and command completion. When typing a command, Tab, Spacebar, or Enter invokes auto-completion. If the text entered is enough to match a specific command, auto-completion completes the command. If the text entered is not sufficient to identify a specific command, pressing Tab or Spacebar displays options in alphabetical order matching the text entered.
The environment command-completion command controls what keystrokes can trigger command completion. Each keystroke is independently controlled with its own Boolean value.
![]() | Note: If Spacebar completion has multiple matches and also matches an keyword, the space is considered a separator and auto-completion is not triggered.
|
Variable parameter completion works only with the Tab key. All configured variables from the candidate and running configuration datastores are displayed. Line wrapping may occur for variables with long names. Parameters are displayed in alphabetical or numerical order. The variable parameter name is always displayed as the first line. In the following example, “interface-name” is the variable parameter name and “int-1” and “system” are configured names.
Some list elements have a default keyword defined, such as the router command, where the default keyword is “Base”. When the command completion parameters (enter, space, and tab) are at their default settings (true), and the initial input matches an element in the list and a unique command keyword, the matching keyword is completed instead of the variable.
For example, the router command has a default keyword defined as “Base”. If router “g” is created using the command configure router “g” (with quotation marks”), and there is an existing gtp protocol, the variable completion is as follows.
The following displays for router+Spacebar+Tab:
The following displays for router g+Tab:
Entering router g+Enter completes to router gtp and enters the router “Base” gtp context:
Similarly, router g+Spacebar completes to router gtp and enters the router “Base” gtp context when Enter is pressed:
To enter the context for router “g”, quotation marks are used to specify the variable:
If the command completion for enter is set to false, then router g+Enter allows the match to router “g”. Similarly, when the command completion for space is false, router g+Spacebar also matches to router “g” instead of the keyword gtp.
In the next example, the completion parameters are at the default settings of true. If the user intends to navigate to configure router isis, but enters configure router is+Enter, router “is” is created.
Entering router is+Tab in the configure context shows the “is” router, in addition to the keywords that begin with “is”:
Entering router is+Spacebar in the configure context shows the keywords that begin with “is”:
In this scenario, the entire “isis” keyword must be entered to navigate to the desired context:
For keyword-based leaf-lists, command completion displays all possible values, not only those that are configured. When deleting values in a leaf-list, only the values that are currently configured are displayed. In the following example, when defining the forwarding traffic classes, all keyword values are listed. When deleting the forwarding traffic classes, only the configured classes are displayed.
The explicit use of true for a Boolean element is optional, as true is the default value. The true keyword is enclosed in square brackets ([]).
When Tab is used for command completion with Boolean elements, the values of false and true are displayed, along with the names of possible elements that can follow. In the following example of the environment more command, the commands command-completion, console, message-severity-level, and so on, can be defined following the more command.
Variables, keywords, global commands, and configuration commands and units are separated by a blank line in the output, in the following order:
A single idle timeout applies to all CLI engines in a CLI session (classic and MD-CLI). The idle timeout can be modified to a value between 1 and 1440 minutes.
The following points apply.
A warning message is displayed when a session reaches one-half the value of the idle timeout, and another message is displayed when the idle timeout expires.
The idle timeout configured in the classic CLI affects all new sessions as well as the current session. However, the current session is only affected if the classic CLI engine is active when the idle timeout expires. Configuration changes via the MD-CLI or any other interface, including SNMP, only affect new sessions that begin after the change.
Output modifiers provide support for post-processing of CLI output. Output modifiers are specified using a pipe (|) character. The following points apply when using output modifiers.
The following options are supported for use with the pipe (|) match command:
The following example matches on the pattern autonomous-system in the tree detail under the configure router “Base” context, and starts the display with seven lines preceding the pattern match.
Regular expressions (REs) used by the MD-CLI engine are delimited by apostrophes (‘); for example, ‘.*’. REs cannot be delimited by double quotation marks (“); for example, “.*”.
MD-CLI REs are based on a subset of The Open Group Base Specifications Issue 7 and IEEE Std 1003.1-2008, 2016 Edition REs, as defined in chapter 9. MD-CLI REs only support Extended Regular Expression (ERE) notation as defined in section 9.4. Basic Regular Expression (BRE) notation as defined in section 9.3 is not supported.
In ERE notation, a backslash (\) before a special character is treated as a literal character. Backslashes are not supported before ( ) or { }, as they are in BREs to indicate a bracket expression or marked expression.
Table 6 describes the special characters that are supported in EREs.
Special character | Description |
. | Matches any single character |
* | Matches the preceding expression zero or more times |
? | Matches the preceding expression zero or one time |
+ | Matches the preceding expression one or more times |
[ ] | Matches a single character within the brackets |
[^] | Matches a single character not within the brackets |
^ | Matches the starting position |
$ | Matches the ending position |
( ) | Defines a marked subexpression |
{m,n} | Matches the preceding expression at least m and not more than n times |
{m} | Matches the preceding expression exactly m times |
{m, } | Matches the preceding expression at least m times |
{ ,n} | Matches the preceding expression not more than n times |
| | Matches either expression preceding or following the | |
\ | Treats the following character as a match criterion |
- | Separates the start and end of a range |
The following examples show the use of a bracket expression as a matching list expression.
The first output does not use any match expressions and therefore shows the entire output.
In this matching list expression, a match is any single character in the bracket expression, which in this case is 1, 3, or 5.
In this non-matching list expression, a match is any single character not in the bracket expression, that is, not 1, 2, or 4.
The range operator (-) can be used in a matching or non-matching list expression.
The alternation operator (|) can be used with or without a bracket expression to match against two or more alternative expressions.
Without a bracket expression, an exact match is attempted against two or more alternative expressions.
MD-CLI REs match on the output format of an element, as shown in the configuration. For example, if the value of an element is shown in hexadecimal in info output, a decimal RE will not match the value. In the following example, the Ethertype is entered in decimal format, but is displayed in hexadecimal. Matching on the decimal format does not find a match.
MD-CLI REs are not implicitly anchored. The ^ or $ anchoring special characters can be used, as in the following example.
This example uses the ^ anchor character to match on “group” preceded by four spaces at the beginning of the line.
This example uses the ^ anchor character to match on “group” preceded by eight spaces at the beginning of the line.
In the following configuration example using the compare command, the | match option filters out those commands to be deleted (configuration statements beginning with the minus sign (-)) and those to be added (configuration statements beginning with the plus sign (+)).
The backslash (\) is used to match the literal “+” character that denotes additions to the configuration seen in the compare command.
A character class expression is expressed as a character class name enclosed within bracket colon (“[:” and “:]”) delimiters. Table 7 defines the character class expressions.
Character Class | Characters matched (delimited by ‘ single quotation marks’) | Description |
[:alnum:] | ‘ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz 0123456789’ | Alphanumeric characters |
[:alpha:] | ‘ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz’ | Alphabetic characters |
[:blank:] | ‘ \t’ | Space and Tab |
[:cntrl:] | ‘\007\b\t\n\v\f\r\1\2\3\4\5\6\16\17\20 \21\22\23\24\25\26\27\30 \31\32\33\34\35\36\37\177’ | Control characters |
[:digit:] | ‘0123456789’ | Digits |
[:graph:] | ‘ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz 0123456789 !\"#$%&'()*+,-./:;<=>?@[\\]^_`{|}~’ | Visible characters |
[:lower:] | ‘abcdefghijklmnopqrstuvwxyz’ | Lowercase letters |
[:print:] | ‘ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz 0123456789!\"#$%&'()*+,-./:;<=>?@[\\]^_`{|}~ ’ | Visible characters and the Space character |
[:punct:] | ‘!\"#$%&'()*+,-./:;<=>?@[\\]^_`{|}~’ | Punctuation characters |
[:space:] | ‘\t\n\v\f\r ‘ | Whitespace (blank) characters |
[:upper:] | ‘ABCDEFGHIJKLMNOPQRSTUVWXYZ’ | Uppercase letters |
[:xdigit:] | ‘0123456789ABCDEFabcdef’ | Hexadecimal digits |
Character class expressions must be enclosed within brackets. The expression ‘[[:digit:]]’ is treated as an RE containing the character class “digit”, while ‘[:digit:]’ is treated as an RE matching “:”, “d”, “i”, “g”, or “t”.
Collating symbols and equivalence classes are not supported in MD-CLI REs.
The | count option displays the line count of the output.
![]() | Note: Error messages are not processed by output modifiers. They are always displayed and are not affected by the count or match modifiers. |
The | no-more option displays the output with pagination disabled. This option is similar to the environment more false setting, where the entire output text is printed without page interruptions.
Configuring a container navigates into the context. In the following example, the first container is aaa, and the next is diameter. All containers are marked with a “+”.
Alternatively, the same context can be entered on one line:
Configuring a leaf element maintains the present working context if there is no explicit opening brace. Entering an explicit opening brace navigates into the specified context.
Configuring a container navigates into the context.
Configuring an empty container or a list where the only children are keys does not navigate into the context. These elements are displayed with aggregated braces with a space ({ }) on the same line. It is possible to enter the element name with an opening brace; however, no options are available in this context.
For example, configuring the list element sdp-include with a key of “ref_group_name” does not change the existing context.
The back and top commands are used to navigate contexts, but it is also possible to use closing braces to navigate.
The behavior of an explicit closing brace depends on the contents of the current command line. If the command line contains an explicit opening brace, the closing brace exits to the parent context of the opening brace.
In the following example with an opening brace on the command line, the closing brace exits VPRN 1, and then enters the context of VPRN 2.
In the following example without an opening brace on the command line, the first closing brace exits interface “int1”, and the second closing brace exits VPRN 1 and enters the VPRN 2 context.
The exec command executes commands from a file as if the user typed or pasted the input into the MD-CLI without command completion. The syntax can be seen as follows:
The exec command:
The system executes the file as follows:
When using commands that switch between CLI engines within an executable file, the following commands are recommended:
![]() | Note:
|
The info command shows the configuration for the present context. The command can only be executed while in a configuration mode. By default, all configured parameters in the candidate configuration datastore are displayed.
Table 8 describes the info command options.
Option | Description |
[from] (candidate | running) | Specify the source datastore (default is from candidate) |
converted | Include converted configuration values from third party modules |
detail | Include default and unconfigured values in the output |
flat | Show the hierarchy on each line starting from the present working context |
full-context | Show the full hierarchy on each line |
inheritance | Include configuration inherited from configuration groups |
![]() | Note: The flat and full-context options are mutually exclusive. Valid option combinations (in any order) are:
|
The order of the configuration output is as follows:
The configuration output displays all elements that are configured, even if an element is set to the system default state or value.
In the following example, chassis has two key leafs (chassis-class (router) and chassis-number (9)). The double hash (##) indicates an unconfigured element or a dynamic default. Refer to section 1.4.6 for more information.
The following displays configuration information for configure log accounting-policy 5:
The detail option displays all data for the context, including default configurations.
The flat option displays the context of every element in the present working context on a single line. Braces ensure that the context stays in the present working context for copy and paste purposes.
The full-context option displays the full context of every element from the present working context on a single line.
The info command always displays all keys of the list on the same line. The first key of a list is unnamed in the MD-CLI, however, there are exceptions where the key is named and must be entered. (Refer to the online help for the correct syntax of the command, or the MD-CLI Command Reference Guide.) All other keys are named. For example, the collector list has two keys, ip-address and port. The name of the first key, ip-address, does not appear in the info display. The name of the second key and any subsequent keys are always displayed.
The classic CLI show commands can be used in the MD-CLI as well as in the classic CLI, in the following ways:
Classic CLI commands that are accessible in the MD-CLI show outputs of the same information and provide the same functionality in the MD-CLI as they do in the classic CLI. No additional outputs or enhancements are included in the MD-CLI.
![]() | Note: Follow the classic CLI context when using the show command. For example, route policy information is displayed using the show router policy command in both the MD-CLI and classic CLI engines, even though this information is configured in the configure policy-options context in the MD-CLI and in the configure router policy-options context in the classic CLI. |
The following classic CLI show commands are currently blocked in the MD-CLI:
The show command in the MD-CLI is applicable only in the operational root []. The /show command can be used from the root or any configuration context.
Output modifiers (match, count, and no-more) can also be used with the show command. See Using Output Modifiers.
The following tree shows the available commands in the administrative branch in the MD-CLI. The admin commands are available only in the operational mode of the MD-CLI, or can be executed with /admin from a configuration branch.
Table 9 describes the available commands in the MD-CLI admin tree.
Admin command | Description |
disconnect session-id session-id | Disconnect a user from a session, identified by a session identifier. The session identifiers can be obtained from the show system management-interface datastore-locks detail command. See section 1.4.13. |
reboot [card] (active | standby | upgrade) [now] | Reboot the active or standby CPM, or force an upgrade of the system boot ROMs. The now option forces a reboot immediately without an interactive confirmation. |
redundancy force-switchover [now] | Force a switchover to the standby CPM. The primary CPM reloads its software images and becomes the secondary CPM. The now option forces the switchover immediately. |
save [[file-url] string] | Save the running configuration to a configuration file. If a filename is not specified, the location is derived from bof.cfg. Note: Classic CLI admin save is blocked when the management interface configuration mode is model-driven. |
show configuration | Show the current running configuration |
There are two modes in the MD-CLI:
In both session modes, a candidate configuration exists, but the user only has access to the candidate configuration when configuration mode is entered.
The type of configuration mode is defined by the type of access to the candidate configuration, and must be specified when entering the explicit configuration workflow. Three configuration modes are currently defined:
In global configuration mode, the candidate configuration is shared among all configuration management interfaces. Consider the following when using global configuration mode:
In exclusive configuration mode, the candidate configuration is reserved for a single configuration management interface, with the following characteristics:
![]() | Note: Nokia recommends using exclusive configuration mode to prevent potential conflicts between multiple users making configuration changes to the candidate configuration at the same time. |
In read-only configuration mode, the candidate configuration can be viewed using a configuration management interface. In addition to all commands available in operational mode, read-only configuration mode has the following functions and limitations:
When a CLI session starts using the MD-CLI, it is in operational mode. To enter one of the available configuration modes, enter edit-config with one of the access types:
edit-config (exclusive | global | read-only)
To exit a configuration mode, enter the quit-config command.
If the session leaves global configuration mode, any uncommitted configuration changes exist are kept in the candidate configuration.
If the quit-config command is issued in exclusive configuration mode and uncommitted changes exist in the candidate configuration, the user is prompted to discard the changes. If the user enters “n”, the quit-config command is aborted and the session remains in exclusive configuration mode.
If the candidate configuration contains uncommitted changes from a previous MD-CLI session in global configuration mode, it is not possible to enter exclusive configuration mode until the uncommitted changes have been committed or discarded.
The quit-config command must be executed in the operational root within the configuration mode. The exit all command (or Ctrl-z) exits to the operational root level and the MD-CLI session leaves the configuration mode.
When an MD-CLI session is in one of the configuration modes (exclusive, global, or read-only), it is permitted, in certain situations, to transition to another configuration mode without issuing the quit-config command and re-entering configuration mode with the edit-config command.
From read-only configuration mode, it is possible to transition directly to either exclusive or global configuration mode. It is also possible to transition to read-only configuration mode from either exclusive or global configuration mode. However, direct transitions between exclusive and global configuration modes are not supported.
The edit-config command can be issued from any working context in configuration mode.
For configuring router information, there is a transactional (two-stage) configuration method, where changes are kept in the candidate configuration datastore. Changes are not immediately effective; they need to be activated by issuing the commit command. For other operations besides the router configuration, such as configuring the environment, the changes are immediate.
The behavior of the MD-CLI configuration method differs from the classic CLI, where changes in the classic model are applied immediately. Changes to the router configuration in the classic CLI are immediately activated in the running configuration, and must be made in the correct order or the configuration fails. The transactional behavior of the MD-CLI allows multiple configuration changes to be made, and the correct ordering of the changes is applied by the system when the configuration is activated.
In a transactional method, configuration is a two-step process in which configuration changes are made in a datastore called the candidate configuration datastore. When the configuration is committed, the changes are copied to the running configuration datastore and activated. In the classic CLI model, configuration changes are made in the running configuration and each change is activated immediately.
Figure 1 shows the flow of configuration changes from the candidate configuration datastore to the running configuration datastore.
The configuration workflow provides a clear beginning and end of configuration commands, achieved using the edit-config and quit-config commands. Refer to Entering and Exiting a Configuration Mode in the MD-CLI for more information about these commands.
The candidate configuration datastore is created and allows the user to make configuration changes to the running configuration datastore when the changes are committed.
The MD-CLI tree contains the following elements from the Nokia YANG models.
The following terms are also used:
In the following example, admin-state (leaf name), enable (enumerated value), and connect-retry (leaf name) are keywords, and “800” is a variable parameter.
Managing the router configuration using the MD-CLI involves accessing and configuring the appropriate elements (containers, lists, leafs, and leaf-lists).
The MD-CLI tree shows the commands and parameters (also known as elements) that are available, shown in a hierarchical structure as in Figure 2. Refer to the MD-CLI Command Reference Guide for more information.
A leaf is an element that does not contain any other elements and has a data type, for example, a string, an integer, or an IP address.
Key leafs may have an optional default value that can be used as shorthand notation where a certain default is assumed. For example, configure router bgp with no instance value expands to configure router “Base” bgp. Default values are implemented as follows:
Integer values can be entered in any of the following formats:
Integer values are displayed in decimal format, unless a different output format is specified internally by the system.
In this example, the dot1q-etype parameter is a hexadecimal output value. A decimal value can be entered, but the value is displayed in hexadecimal format.
![]() | Note: Unions of integer and enumerated values do not support binary or hexadecimal input. |
In this example of a command with a union of data types, the rate-limit command can have an integer value representing the rate limit (for periodic RADIUS Interim-Update messages), or it can be defined with the unlimited enumerated value. If a numerical value is entered for rate-limit, it must be entered as a decimal number.
A list is a sequence of list entries, and all keys of a list are entered on the same line as the list command. In general, the first key of a list is unnamed in the MD-CLI. All other keys are named. The name of the first key is shown in square brackets in ? help. Entering the name of the first key is optional when it is shown in brackets. In the following example, ip-address is the first key and port is the second key. Entering ip-address in the MD-CLI is optional; entering port and any subsequent key names is mandatory.
The IP address and port number can be entered in one of the following ways:
There are some exceptions where the first key of a list is named. In these cases, the key name must be entered. In the following example, the key name index must be entered.
Auto-completion does not select or complete the name of the first key if it is optional. In the following example for configure aaa diameter, the key name for node (origin-host) is optional as indicated by the square brackets, and is not auto-completed when Tab is entered.
If the name of the first key is optional and is not entered as part of the command, the key name can be used as the actual value of the key if it is enclosed in quotation marks.
If the optional key name is entered, it can be specified as the actual value of the key with or without the quotation marks.
For lists in which the leafs are all keys (“key-only lists”), the creation of a single entry returns the user to the same context; that is, the MD-CLI session does not enter the context of the list member. This allows the user to enter multiple list items without the need to exit after each item. For example, prefix is a list with a single leaf that is the key. After each prefix entry, the session maintains the same context and other prefix entries can be added without applying the back or exit command.
A leaf-list is an element that contains a sequence of values of a particular data type. Specifying a leaf-list entry in the MD-CLI is additive. New entries are added to existing entries and previous entries are not removed. If a duplicate entry is specified, the order remains. To minimize the number of CLI warnings, no message is displayed.
Single or multiple leaf-list entries can be added in a single command line with the use of brackets. For leaf-lists ordered by the system, the leaf-list entries are automatically reordered, as shown in the following example.
For leaf-lists ordered by the user, new entries are appended to the end of the leaf-list.
To reorder an ordered-by-user leaf-list, the leaf-list can be deleted and recreated using the desired order. Alternatively, the tilde (~) character can be used to replace a leaf-list, effectively deleting and recreating the leaf-list in one step.
If a leaf is defined by a number value and an associated unit, the user can enter the value in a different base unit than is defined. For example, if a timer is defined in seconds, it is possible to enter a value based on the number of minutes, or a combination of minutes and seconds. These dynamic units in the MD-CLI can be entered in a format that is converted into the base unit based on a conversion factor.
Static units that have no conversion factor must always be entered in the base unit value; for example, a unit of packets per second, or bit errors.
Units are supported for:
Dynamic units can be entered as a number in one of the following ways:
The input value is calculated based on the input of all input tuples and validated after Enter is pressed. For example, entering 200 minutes for connection-timer results in an error display, as 12000 seconds is not in the element range.
Entering a value followed by Space and Tab displays valid units for the value, as in the following example. For a value of 200 for connection-timer, the system displays valid unit possibilities, listed in alphabetical order.
If a unit is already present in the input, it is suppressed for any further input.
The unit names can be singular or plural, depending on the numerical value entered. For a numerical value of 1, the unit names displayed are their singular form.
Auto-completion is supported for valid units entered after a value.
Table 8, Table 10, and Table 11 list units that have a conversion factor that allows a leaf with a specific base unit to be defined in a dynamic unit. The valid unit keywords for each unit name are also provided.
Table 10 shows the valid inputs for memory sizes based on the dynamic unit.
Unit Name | Valid MD-CLI Input |
terabytes |
|
gigabytes |
|
megabytes |
|
kilobytes |
|
bytes |
|
Table 11 shows the valid inputs for rates of speed based on the dynamic unit.
Unit Name | Valid MD-CLI Input |
terabps (terabits per second) |
|
gigabps (gigabits per second |
|
megabps (megabits per second) |
|
kilobps (kilobits per second) |
|
bps (bits per second) |
|
Table 12 shows the valid inputs for time durations based on the dynamic unit.
Unit Name | Valid MD-CLI Input |
weeks |
|
days |
|
hours |
|
minutes |
|
seconds |
|
deciseconds |
|
centiseconds |
|
milliseconds |
|
microseconds |
|
nanoseconds |
|
picoseconds |
|
Table 13 shows the valid inputs for dates based on the time format.
Time Format | Valid MD-CLI Input |
“yyyy-mm-dd hh:mm[:ss] [TZ]” For example: “2018-06-01 13:12:59 EDT” | yyyy is RFC 3339 date-fullyear mm is RFC 3339 date-month dd is RFC 3339 date-mday hh is RFC 3339 time-hour mm is RFC 3339 time-minute, requires preceding zeros ss is RFC 3339 time-second, requires preceding zeros (optional) TZ is the time-zone name (optional) This format must be enclosed in double quotation marks. |
“[DAY] dd MON yyyy hh:mm[:ss] [TZ]” For example: “FRI 11 MAY 2018 13:21:11 EDT” | DAY is the name of the day of the week (SUN, MON, TUE, WED, THU, FR, SAT),(optional) dd is RFC 3339 date-mday MON is the name of the month (JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, DEC) yyyy is RFC 3339 date-fullyear hh is RFC 3339 time-hour mm is RFC 3339 time-minute, requires preceding zeros ss is RFC 3339 time-second, requires preceding zeros (optional) TZ is the time-zone name (optional) This format must be enclosed in double quotation marks. |
yyyy-mm-ddThh:mm:ss[.fr][(Z|(+|-)hh:mm)] For example: 2018-05-11T13:21:11-0400 or 2018-05-11T17:21:11Z | This format follows ISO 8601, and can be enclosed in double quotation marks. |
Flexible input is available for MAC and IPv6 addresses, where both uppercase and lowercase hexadecimal digits are accepted.
This example shows the hexadecimal digits entered in both uppercase and lowercase.
For MAC addresses, the dash (-) separator can also be used in place of the colon (:).
Flexible input is also available for other formatted MAC addresses, such as using dot notation:
The delete command removes explicit configuration and returns the element configuration to the system default state or value. If there is no defined default for an element, the element returns to an unconfigured state.
The delete command can be used to delete any configuration element, such as:
If an element has sub-elements (for example, a container with more containers and leafs), all of the sub-elements are also deleted as part of the parent deletion.
![]() | Note: If the configuration element to be removed does not exist, no warning messages are displayed. |
The following configuration example deletes three leafs; admin-state and connect-retry return to their default values, and description returns to an unconfigured state.
To remove a container, the delete command is specified before the container name. The following examples show the deletion of the node container from two different contexts.
This example removes the container from context configure aaa diameter:
This example removes the container from context configure aaa:
In both of the preceding examples above, the node container is returned to an unconfigured state, as indicated by the ##.
In the following example, the timers element is a container, which contains sub-elements that are also containers; the lsa-generate and spf-wait elements. The placement of the delete command determines whether the timers element (and all of its sub-elements) are deleted, or one of the sub-elements.
To delete the lsa-generate element and its parameters, the delete command is specified before the lsa-generate element. The info command shows that the spf-wait parameters are still configured.
If the delete command is placed before the timers element, all elements within the timers element are also deleted.
To remove a list entry, the delete operation is specified before the list name and the entry to be removed.
An explicit wildcard (*) deletes all members of a list.
If the list is a multi-key list, a combination of specific members and wildcards (*) can be used. In the following example, mep is a multikey list, where the keys are md-admin-name, ma-admin-name, and mep-id.
The following delete operation deletes all lists with mep-id of 5, regardless of the md-admin-name or ma-admin-name.
The following delete operation removes all lists where ma-admin-name is “ref3” and mep-id is 5.
The following delete operation removes all lists where md-admin-name is “ref1”.
To remove a leaf-list entry, the delete operation is specified before the leaf-list name and the entry to be removed.
Multiple leaf-list entries can be deleted in a single command with the use of brackets. The entries do not need to be in any specific order.
An explicit wildcard (*) deletes all members of a leaf-list.
The wildcard can optionally be enclosed in brackets.
Deleting all members of a leaf-list sets the list to the unconfigured state (as indicated in the info detail display by the “##”).
The output from the info commands can be copied and pasted and used as a direct input to another MD-CLI session, or loaded from a file.
The following example shows the output from the info command, displaying the following configuration for the profile of the user “guest1”.
The output can be copied and pasted to configure an identical profile for another user; for example, “guest2”. The working context must be at the same hierarchy level, as the info command output is context-sensitive.
Enter the context for configuring the profile for guest2:
Copy the info command output and paste each line into the command line:
The info command displays the configuration changes for profile “guest2”, which are identical to the configuration for profile “guest1”.
Similarly, the info flat command output can be copied and pasted for the user profile for “guest3”; for example:
The output from the info full-context command contains the full configuration path for the configuration statements. This output can be used to reconfigure the same user profile on another router, or to rebuild the user profile if it was deleted or discarded. The following example begins with a “guest1” user profile, which is subsequently deleted and re-added using the output from the info full-context command.
The following output shows the “guest1” user profile:
The “guest1” user profile is deleted, and the info full-context command after the delete shows no matches for profile “guest1”:
In the next step, the original full-context output for “guest1” is copied and pasted. Since the output contains the full configuration path, the statements can be pasted from any configuration context.
The displayed output from the compare command can also be used to copy and paste statements in the MD-CLI. See section 1.4.8.1 for information about using the compare command.
The compare command in the MD-CLI compares configurations and displays the difference in one output. The command can only be executed from within the configuration context.
Table 14 provides a description of the compare command options.
Option | Description |
[from] (candidate | running) | Specify the reference datastore to compare (default is from running) |
[to] (candidate | running) | Specify the datastore to compare against (default is to candidate) |
flat | Show the context starting from the present working context |
full-context | Show the context starting at the branch root |
lines number | Show the specified number of lines before and after the changed element |
summary | Suppress specific differences and display a summarized comparison |
The following characters are used at the beginning of the output lines, to indicate the status of the element in the configuration:
Because the compare command uses the default from running, the command compare to candidate is equivalent to compare from running to candidate. Executing compare to running, without specifying the from option is equivalent to compare from running to running, which shows no differences.
The following displays the output using the flat and full-context options.
The following example shows the difference between the compare and compare summary commands. The compare command shows the deletion and addition of configuration changes, each on its own line, and the compare summary command shows the configuration change summarized on one line with a ~ character.
In the following example, the compare command shows the timers that have been modified. After the commit command has been issued to add these to the running configuration, the lsa-generate container is deleted. The following displays the output for the compare command.
The compare command, using the candidate configuration as the reference, displays the same configuration statements with a preceding minus (-) character. These statements will be used in a subsequent copy and paste function to delete some of the configuration. The minus (-) character at the beginning of the configuration statement takes the place of the delete keyword.
In the next step, the lsa-generate parameters are deleted, using a copy and paste of the first three configuration statements:
The compare summary command shows that the deleted lsa-generate parameters are compressed to its highest container, shown with an ellipsis in braces ({}).
If the timers container is deleted, which holds both the lsa-generate and spf-wait containers, the compare summary command now shows the timers container as the highest deleted container:
The discard command in configuration mode cancels all changes made to the candidate configuration without impacting the running configuration or applications. The command is available only when the MD-CLI session is in a read/write configuration mode (global or exclusive configuration) and only from the top of the configuration branch (that is, /configure).
The following example shows the error that occurs when the discard operation is attempted from read-only configuration mode. The command is successful when the session is in global configuration mode, but only from the top of the configuration branch.
Uncommitted changes from a global configuration mode session are kept in the candidate configuration when the quit-config command is executed. However, when executing a quit-config command from exclusive configuration mode, uncommitted changes are discarded, and a confirmation message is displayed:
It is possible to discard the changes made by a session that obtained an explicit lock by disconnecting the remote session. Uncommitted changes from an exclusive configuration mode session are discarded when the session disconnects. See Viewing the Status of the Local Datastores for information about disconnecting a session.
The validate command verifies the logic, constraints, and completeness of the candidate configuration without activating any changes. A successful validation returns no errors. If the validation fails, detailed failure reasons are provided. The validate command can be executed from any working directory and in any configuration mode.
The commit command also runs validation on the configuration. Therefore, it is not necessary to execute the validate command as a separate step when committing the candidate configuration.
The commit command can be executed from any hierarchy level within any configuration branch.
When a commit operation is initiated, a validation is first performed on the candidate configuration.
With a successful validation, the changes are copied to the running configuration, which becomes the current, operational router configuration. The candidate configuration is reset to its initial state.
If the commit operation fails, an automatic rollback occurs, which returns the running state to the state before the commit was applied. An automatic rollback does not use a rollback checkpoint file, so is not dependent on persistency to be enabled. Instead, a list of changes is kept in memory until the automatic rollback is completed. The uncommitted changes remain in the candidate configuration.
Multiple users can make candidate changes in global configuration mode. All changes from all users are visible in the candidate configuration. A commit operation issued by one user activates all changes made by all users.
No indication is given to other users when a commit operation is issued by a user.
Exiting global configuration mode before committing the changes leaves the changes in the candidate configuration.
Only one user can obtain an exclusive lock and enter exclusive configuration mode at a time. Making changes to the candidate configuration and committing these changes can only be done via the session that is in exclusive configuration mode.
All uncommitted changes are discarded on exiting exclusive configuration mode. If uncommitted changes are present in the candidate configuration, a session cannot enter exclusive configuration mode, but it is possible to enter global configuration mode if no exclusive lock has already been obtained by another session.
Executing the commit command with no options performs the operation immediately. the confirmed option can be used to activate configuration changes without making them persistent, to give the user time to verify that the configuration is working as intended. By default, the commit confirmed command executes the commit operation with an automatic rollback of 10 minutes. Within this time, an explicit confirmation (commit confirmed accept) must be issued for the changes to become persistent. Other configuration commands issued during this time interval are blocked. All prompt displays a countdown at the end of the display,
If the initial commit fails, the commit confirmed operation is canceled and no timer is started.
The timeout option for the commit confirmed operation can override the default value of 10 minutes. While a commit confirmed timer is running, a subsequent commit confirmed or commit confirmed operation with a timeout option restarts the timer.
Once the commit confirmed operation is underway, the timer starts. A commit confirmed cancel command terminates an ongoing confirmed commit and immediately performs an automatic rollback to the previous state before the initial commit confirmed command was issued.
If the commit confirmed accept command is not issued within the specified timeout period after a successful commit, all changes are automatically discarded from the running configuration, and the candidate configuration maintains all uncommitted configuration changes.
The commit confirmed and commit confirmed accept or commit confirmed cancel commands must be executed from the same MD-CLI user session. Commit commands executed from another (global) session while the commit confirmed timer is running generate an error.
While the commit confirmed timer is running, the user can exit and re-enter global or exclusive mode within the same session. The commit confirmed timer keeps running, and can be seen from all sessions running in an MD-CLI engine.
If a logout is attempted from the session that issued the commit confirmed command, a user prompt displays to confirm the logout and automatic rollback.
A persistence identifier can be specified with the initial commit confirmed command. A commit confirmed accept or cancel command can then be executed from the same or a different MD-CLI user session, NETCONF, or gRPC session, from where the commit confirmed persist-id command was initiated. The persistence identifier must then be included with the subsequent commit confirmed commands. The persistence identifier is a user-defined string of up to 255 characters or an empty string (“”).
The MD-CLI asterisk prompt (*) is the uncommitted changes indicator that indicates the presence of changes in the candidate configuration datastore since the last commit. The configuration becomes persistent when it is saved to a local or remote location.
Explicit persistence is achieved by issuing the admin save command after candidate changes have been committed. The command has the following syntax:
admin save [file-url] file-name
where file-name is a character string specifying the location where the configuration is to be saved.
The MD-CLI has an implicit persistency option linked to the commit command: the auto-config-save command in configure system management-interface cli md-cli. When candidate configuration changes are successfully committed, the configuration is automatically saved if auto-config-save is set to true.
When auto-config-save is set to false, the admin save command must be issued to make the configuration persistent.
A rollback checkpoint is an MD-CLI configuration file that can be loaded in the candidate configuration with the rollback command.
A rollback checkpoint is created automatically after every successful commit when automatic save is enabled via the MD-CLI auto-config-save command.
A rollback checkpoint is also created if an operator issues the admin save command, regardless of the MD-CLI auto-config save setting.
The rollback command loads a previously saved MD-CLI configuration file in the candidate configuration. Loading the file does not automatically initiate a commit command, which means that the file can be examined before committing. This rollback command is the equivalent of a load full-replace of the configuration file, but is identified with a checkpoint identifier. If no identifier is specified, the latest saved configuration file identified with index identifier 0 is used as the default.
The rollback command is available only for the model-driven management interface configuration mode.
Configuration files loaded with the rollback checkpoint-id command are identified with a number that corresponds to the configuration file and location specified as primary-config in the active Boot Option File (BOF). For example, the configuration file executed for a rollback 3 command corresponds to the file named config.cfg.3. The checkpoint identifier 0 corresponds to the last saved configuration file and does not have a suffix. This is also the default when no checkpoint identifier is specified with the rollback command. By default, five configuration files are saved. The configuration-backups command can be used to save a different number of configuration files.
The //show bof command executed from the MD-CLI shows the name of the file as config.cfg.
In the MD-CLI, the rollback command references the same filename with an appended suffix of the checkpoint identifier, in this case, identifier 3:
The rollback command is available in global or exclusive configuration mode and can only be executed from the root of the configuration branch.
When the auto-config-save parameter is set to true, the rollback command (without an index) is the equivalent of executing the discard command for the current candidate configuration changes.
The following figures show the relationship between the candidate and running configurations, the commit command, the setting of the auto-config-save parameter, and the rollback checkpoint files.
In Figure 3, the auto-config-save parameter is set to true. With a successful commit, a rollback checkpoint is created.
In Figure 4, the auto-config-save parameter is set to false. The admin save command creates a rollback checkpoint of the running configuration before the commit. However, a rollback checkpoint is not created after the successful commit.
In Figure 5, the commit fails and no rollback checkpoint is created, regardless of the setting of the auto-config-save parameter.
The load command loads the contents of a local or remote file into the candidate configuration. The command can only be executed at the top of the configure region when the MD-CLI session is in global or exclusive configuration mode and does not result in a context change. The command can be issued regardless of whether uncommitted changes are present in the candidate configuration datastore.
The syntax of the load command is as follows:
load [mode] (full-replace | merge) [url] filename
The full-replace option replaces the current candidate configuration with the specified file.
The merge option merges the contents of the specified file into the candidate configuration. If there are conflicts, the configuration statements in the specified file override the existing configuration statements.
The file to be loaded is not a CLI script to be executed, so cannot include:
See Executing Commands with a File to perform such actions from a file.
If the loaded file encounters errors, parsing terminates at the first error. Statements before the error are loaded into the candidate configuration. Configuration statements in the loaded file are also subject to AAA command authorization. An authorization check failure also terminates the execution of further statements in the file.
The output from the info full-context or info commands can be copied and pasted into a load file. Both the full-replace and merge options support this type of content.
The following shows the output from the info full-context command. This output can be copied and pasted into a file; for example, cf1:\bgp.cfg.
From the MD-CLI, the //file type command displays the contents of the file:
The load merge command can be used to merge the contents of the file into the candidate configuration. The following example shows no current candidate configuration changes for BGP before the command is executed. The compare command shows the candidate configuration changes after the file is merged.
The output from the info flat command can be copied into a file; for example, cf1:\bgp2.cfg:
An additional context line is added to specify the context /configure router “Base” bgp, as shown in the file display:
The file is merged and the compare command shows the resulting candidate configuration changes.
The following shows the output from the info command. To use the output in a load file, the context must be added through a manual edit, similar to the edit of file bgp2.cfg in the preceding example, or use the output from the info full-context command.
The contents of the load file with the info output include the following:
The SR OS MD-CLI supports the creation of configuration templates called configuration groups, which can be applied at different branches in the configuration, where the configuration elements are inherited. This is shown in Figure 6.
The advantage of using configuration groups is that similar configurations can be grouped in a template that is applied at multiple branches in the configuration tree. Subsequent configuration updates are only required in one location. Using groups, configurations can be organized in a logical fashion, such as regional (East vs West) or functional (core-facing vs access-facing parameters). The result is a more compact configuration that is easier to maintain and that reduces the number of configuration and operational errors.
The following guidelines apply when creating configuration groups:
Configuration groups are created in the groups branch of the configuration tree.
Multiple configuration groups can be created, each with a unique name.
The configuration elements in a configuration group always start at a top-level configuration branch, such as router, qos, or card.
To match on a key of a list entry in a configuration group, an exact match or a regular expression match can be used.
With an exact match, configuration elements can only be inherited by the list entry that matches the specified key value. When no list entry is matched, a new list entry is created with the specified key value.
In the following example, interface “int-pe1-pe2” is an exact match. When the group is applied and IS-IS interface “int-pe1-pe2” exists in IS-IS instance 0, the interface-type leaf is inherited. If the IS-IS interface does not exist, it is created with the interface-type set to point-to-point.
With a regular expression match, configuration elements can be inherited by all list entries for which the key value matches the regular expression. A list entry cannot be created with a regular expression match.
In the following example, interface “<.*>” is a regular expression match that matches any interface name. When the group is applied, all configured IS-IS interfaces in IS-IS instance 0 inherit the interface-type leaf.
A regular expression match is specified as a string with the regular expression enclosed in angle brackets: “<regex-match>”.
The regular expression match is implicitly anchored: a ^ (match-starting position) is added at the beginning of the regular expression and a $ (match-ending position) is added at the end.
The regular expression is a subset of the Extended Regular Expression (ERE) notation as described in section 1.3.11.1.1.
For example:
With regular expressions, it is possible to create conflicting matches: two regular expression matches, or a regular expression match and an exact match, that both match on the same list entry. These conflicting matches are not supported and result in a validation error.
In the following example, both interface “<int-.*>” and “int-pe1-pe2” match interface “int-pe1-pe2”, so result in a conflict at validation:
To inherit configuration elements from a configuration group, apply the group in a branch of the configuration tree with the apply-groups statement. For example:
Configuration elements from the corresponding branches where the group is applied are inherited. In the following example, the configuration group “isis-3” has configuration elements in both the router isis interface and router isis level branch. Because the configuration group is applied at the router isis interface branch, only these configuration elements are inherited.
The resulting expanded configuration can be shown with the info inheritance command:
The following notes apply to configuration groups and the apply-groups statements:
Local configuration elements have precedence over configuration group inheritance.
In the following example, the configuration group “isis-1” contains the configuration element level-capability 1, which is not inherited because a corresponding local configuration element exists.
The resulting expanded configuration after inheritance is shown as follows:
Up to eight configuration groups can be applied to a configuration branch. The configuration order determines the inheritance precedence:
In the following example, both configuration groups “isis-1” and “isis-2” set an interface level 2 metric. Because configuration group “isis-2” is listed first in the apply-groups, its configuration elements have precedence. The interface-type configuration element is inherited from group “isis-1” because a corresponding configuration element is not present in group “isis-2” nor is it locally configured.
The resulting expanded configuration after inheritance is shown as follows:
Configuration groups can be applied at different hierarchical branches. The hierarchy determines the inheritance precedence.
Configuration elements in groups applied at a lower-level branch have precedence over configuration elements in groups applied at a higher-level branch.
In the following example, all configuration groups set an interface level 2 metric. Because configuration group “isis-3” is applied at the lowest level, its configuration elements have precedence. The interface-type configuration element is also inherited from group “isis-3” for the same reason. As explained earlier, the level-capability configuration element from group “isis-1” has lower precedence than the local configured value. The wide-metric-only configuration element from group “isis-3” is not inherited because the group is applied at the interface branch and only configuration elements at that level or lower can be inherited.
The resulting expanded configuration after inheritance is shown as follows:
![]() | Note: Inheritance rules for a leaf-list are the same as for a single leaf. It is not possible to add values to an existing leaf-list through configuration group inheritance. |
After configuring and applying configuration groups, the expanded configuration should be reviewed before commit. The expanded configuration at a configuration branch can be displayed with the info inheritance command. By default, this command displays the expanded candidate configuration. To display the expanded running configuration, use info running inheritance.
All statements that are inherited from a configuration group are tagged with a system comment.
Use the regular expression pattern match info inheritance | match '^[ ]*##' invert-match to suppress the system comments in the output of info inheritance.
![]() | Note: Conflicting matches are detected at validation. The info inheritance command may display an inherited configuration element that is part of a conflicting match criteria. |
User profiles can restrict the configuration branches that a user can change. When configuration groups are used, these user profiles should be enhanced to restrict the creation or inheritance of configuration elements in these branches.
In the following example, user admin2 has no access to the sap-egress configuration branch.
This is enforced via the following entry in the local user profile:
Using configuration groups, user admin2 can still create or change sap-egress QoS policies:
The result of the inheritance is not visible to user admin2 because the info command is also subject to the user profile rules.
The admin user who has full privileges can see the inherited configuration, which includes the sap-egress policy created by user admin2.
To prevent user admin2 from creating sap-egress QoS policies using configuration groups, the AAA profile of the user can be enhanced. For example, an entry can be added in the local user profile:
This configuration removes the privileges for user admin2 to create sap-egress QoS policies using configuration groups:
The following configuration is an example of configuring IS-IS interface parameters using configuration groups.
In this example, all backbone IS-IS interface configuration parameters are part of the “isis-bb-interface” configuration group. A regular expression match “<int-.*>” is used to match on all backbone IS-IS interface names that start with “int-“. The system loopback interface does not match the regular expression, so cannot inherit the configuration elements from the group.
The “isis-bb-interface” configuration group is applied at the router “Base”, IS-IS instance 0 branch. When a new IS-IS backbone interface is added with a name that starts with “int-“, it also inherits the configuration elements from the configuration group.
The resulting expanded configuration after inheritance is shown as follows:
The resulting expanded configuration after inheritance is shown as follows, without system comments:
An MD-CLI session in exclusive configuration mode acquires an explicit lock for both the global candidate and running configuration datastores. This is achieved by executing the edit-config exclusive command. An explicit lock can also be obtained via NETCONF or gRPC sessions. Refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide for more information.
To view the lock status of the datastores, the following show command is available:
show system management-interface datastore-locks [detail]
The detail option displays information about any model-driven interface session that impacts the datastore locks. MD-CLI read-only sessions, for example, do not impact the datastore locks.
A datastore lock that has been acquired by any model-driven session can be administratively removed by using the following admin command:
admin disconnect session-id session-id
For example, to disconnect the MD-CLI session indicated in the preceding show command output, issue the admin command as follows:
Disconnecting an MD-CLI session (or any model-driven session, including NETCONF and gRPC) that acquired a datastore lock has the following results:
The debug command is not natively supported in the MD-CLI. The command can be executed from the classic CLI. The // command can be used to switch to the classic CLI engine from the MD-CLI engine. Both debug and /debug are supported in the classic CLI.
The following MD-CLI commands can be used to log debug events to an active CLI session.
The following example shows the configuration for debug events to be stored in destination CLI log identifier 7. The log entries wrap at 50 entries (the configured value of max-entries).
After the commit command has been issued to include the log in the running configuration, the following tools command can be executed in the CLI session that will be used to display outputs of the debug events. Refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide for more information about the tools command.
The events can be displayed using the /show log command and cleared using the /clear log command.
To terminate the output of the logs to the CLI session, use the unsubscribe-from command as shown.
The discard command can be used only from the top level of the configuration branch. From any working context (including the configure context), the discard /configure command can be used.
However, the discard /configure command removes all configuration statements from the candidate configuration datastore. To discard changes from a specific context, the output from the compare command can be used to copy and paste configuration statements from within a working context.
By default, the compare command uses the running configuration datastore as the base reference. Therefore, any new configuration in the candidate configuration datastore is displayed with a preceding plus (+) sign. When the compare command uses the candidate configuration datastore as the base reference, the compare output displays any new configuration in the candidate configuration datastore with a preceding minus (-) sign, indicating that these configuration elements are not present in the running configuration datastore. These configuration statements preceded with a minus (-) sign can be used to discard configurations from the specific context from which the compare command was issued.
In the following configuration example, the lsa-generate timers are modified.
By default, the compare command shows the new configuration using the running configuration datastore as the reference:
The following shows the compare command output when the command is executed with the candidate configuration datastore as the reference.
To discard the max-lsa-wait and lsa-initial-wait timer changes, the first two lines from the compare command output can be copied and pasted while in the specified context. The info detail command shows that the timer changes have reverted to their default values.