Editing configuration
Configuration workflow
MD-CLI session modes
There are two modes in the MD-CLI:
operational
A user can run all commands to monitor or troubleshoot the router, but the router configuration cannot be changed.
configuration
A user can run all commands to monitor or troubleshoot the router. In private, exclusive, or global configuration mode, the router configuration can be changed. In read-only configuration mode, the user can only view the router configuration.
The first line of the user prompt indicates the active configuration mode. For example:
[pr:configure]
This indicates a user in private configuration mode (implicit configuration workflow).
(ex) [configure]
This indicates a user in exclusive configuration mode (explicit configuration workflow).
At login, an MD-CLI session always starts in operational mode. To configure the router, the user must enter a configuration mode using the explicit or implicit configuration workflow.
The configuration workflow (implicit or explicit) determines if the user is restricted to the configure branch or if the user can navigate freely while in configuration mode. Configuration workflows are detailed in Implicit and explicit configuration workflows.
The configuration mode (private, exclusive, global, or read-only) determines the interaction with other simultaneous configuration sessions. Candidate configuration modes are detailed in Candidate configuration modes.
Transactional configuration method
The MD-CLI transactional configuration method is a two-step process in which configuration changes are made in a candidate configuration. When the configuration is committed, the changes are copied to the running configuration and become active.
The following figure shows the flow of configuration changes from the candidate configuration to the running configuration.
Other non-router configuration operations, such as changing the MD-CLI session environment are active immediately.
The MD-CLI configuration method differs from the classic CLI in the following ways:
In the classic CLI, changes to the router configuration are immediately activated in the running configuration. A strict configuration order must be maintained or the configuration fails.
In the MD-CLI, the transactional configuration method allows multiple configuration changes to be made in any order in the candidate configuration. The system applies the correct ordering when the configuration is activated with the commit command.
Implicit and explicit configuration workflows
The MD-CLI supports two configuration workflows:
Implicit configuration workflow
Navigation is restricted to the configure branch and its descendants.
Operational commands require an absolute path and error when incomplete.
configure {private | exclusive | global | read-only} enters configuration mode and navigates in the configure branch. There is no default configuration mode.
exit all leaves configuration mode and navigates to the operational root.
Explicit configuration workflow
Navigation is unrestricted while in configuration mode.
Operational commands while in the configure branch require an absolute path and navigate when incomplete.
edit-config {private | exclusive | global | read-only} enters configuration mode without navigating. There is no default configuration mode.
quit-config leaves configuration mode without navigating. The quit-config command is not available in the configure branch.
The following table compares the implicit and explicit configuration workflows.
Implicit configuration workflow | Explicit configuration workflow | |
---|---|---|
Use |
User focused on configuration tasks in the configure branch |
Power user mode with unrestricted navigation capabilities |
Flexibility |
Run operational commands or configuration commands from the configure branch |
Run operational commands or configuration commands anywhere |
configure |
Enters configuration mode1 and navigates to the configure branch |
Navigates to the configure branch (after edit-config command) |
edit-config |
— |
Enters configuration mode1 |
exit all or Ctrl-Z or / |
Leaves configuration mode and navigates to the operational root |
Navigates to the operational root |
quit-config |
— |
Leaves configuration mode |
Commands that result in an action or display output |
Execute the command |
Execute the command |
Commands that navigate out of the configure branch |
Not allowed |
Navigate |
info and configuration commands in the configure branch |
Allowed |
Allowed |
info and configuration commands out of the configure branch |
Not allowed |
Allowed |
Using the implicit configuration workflow
In the implicit configuration workflow, navigation while in configuration mode is restricted to the configure branch and its descendants.
The configure {private | exclusive | global | read-only} command places the user session in the specified configuration mode and navigates to the top of the configuration tree (/configure).
First line indicated configuration mode
The first line of the session prompt indicates the configuration mode prepended to the context and separated with a colon.
[/]
A:admin@node-2# configure exclusive
INFO: CLI #2060: Entering exclusive configuration mode
INFO: CLI #2061: Uncommitted changes are discarded on configuration mode exit
[ex:/configure]
A:admin@node-2#
When the MD-CLI session is in operational mode, the configure command only accepts a configuration mode parameter and cannot be followed by a path to navigate nor by a configuration element to edit the router configuration.
MD-CLI session in operational mode
[/]
A:admin@node-2# configure exclusive router
^^^^^^
MINOR: CLI #2069: Operation not allowed - currently in operational mode
[/]
A:admin@node-2#
The following navigation commands leave configuration mode if they cause navigation outside the configuration branch:
-
back, or back with a number greater than the present working context depth
-
exit, or exit all
-
Ctrl-Z
-
/
-
}
Exiting the configuration mode
[ex:/configure router "Base"]
A:admin@node-2# exit all
INFO: CLI #2064: Exiting exclusive configuration mode
[/]
A:admin@node-2#
Commands that do not navigate outside the configure branch
Commands that do not navigate outside the configure branch or that result in an action or display output are allowed.
[ex:/configure]
A:admin@node-2# show uptime
System Up Time : 3 days, 00:27:49.35 (hr:min:sec)
[ex:/configure]
A:admin@node-2#
[ex:configure]
A:admin@node-2# /environment more false
[ex:/configure]
A:admin@node-2#
Commands that navigate outside the configure branch
Commands that navigate out of a configure branch are not allowed.
[ex:/configure]
A:admin@node-2# show router
MINOR: CLI #2069: Operation not allowed - cannot navigate out of configuration region
[ex:/configure]
A:admin@node-2#
[ex:/configure]
A:admin@node-2# tools dump
MINOR: CLI #2069: Operation not allowed - cannot navigate out of configuration region
[ex:/configure]
A:admin@node-2#
Using the explicit configuration workflow
In the explicit configuration workflow, navigation while in configuration mode is unrestricted. Operational and configuration commands can be executed from any context.
The edit-config {private | exclusive | global | read-only} command places the user session in the specified configuration mode. The present working context is not changed.
Showing configuration mode in the prompt
The first line of the session prompt indicates the configuration mode between round brackets.
[/show router]
A:admin@node-2# edit-config exclusive
INFO: CLI #2060: Entering exclusive configuration mode
INFO: CLI #2061: Uncommitted changes are discarded on configuration mode exit
(ex)[/show router]
A:admin@node-2#
When the MD-CLI session is in configuration mode, the configure command can be followed by a path to navigate or by a configuration element to edit the router configuration.
Command following by a path or configuration element
(ex)[/]
A:admin@node-2# show router
(ex)[/show router]
A:admin@node-2# /configure system time zone standard name utc
*(ex)[/show router]
A:admin@node-2# /configure router
*(ex)[/configure router "Base"]
A:admin@node-2#
Commands that result in an action or display output can be executed in the configure branch. Navigation outside the configure branch is allowed and does not exit the configuration mode.
Navigation outside the configure branch
(ex)[/configure router "Base"]
A:admin@node-2# show uptime
System Up Time : 8 days, 23:16:45.01 (hr:min:sec)
(ex)[/configure router "Base"]
A:admin@node-2# tools
(ex)[/tools]
A:admin@node-2#
Configuration commands, such as info and commit, can be executed outside the configure branch.
Executing commands outside the configure branch
(ex)[/tools]
A:admin@node-2# info
configure {
log {
{
---snip---
(ex)[/tools]
A:admin@node-2# commit
(ex)[/tools]
A:admin@node-2#
The quit-config command exits configuration mode and places the session in operational mode. The quit-config command must be executed from the operational root. The present working context does not change.
Using the quit-config command
(ex)[/tools]
A:admin@node-2# exit all
(ex)[/]
A:admin@node-2# quit-config
INFO: CLI #2064: Exiting exclusive configuration mode
Transitioning from an implicit to an explicit configuration workflow
An MD-CLI configuration session can transition from an implicit to an explicit configuration workflow using the edit-config command while in configuration mode.
Transitioning from an explicit to an implicit configuration workflow is not supported.
[/]
A:admin@node-2# configure exclusive
INFO: CLI #2060: Entering exclusive configuration mode
INFO: CLI #2061: Uncommitted changes are discarded on configuration mode exit
[ex:/configure]
A:admin@node-2# show
MINOR: CLI #2069: Operation not allowed - cannot navigate out of configuration region
[ex:/configure]
A:admin@node-2# edit-config exclusive
(ex)[/configure]
A:admin@node-2# show
(ex)[/show]
A:admin@node-2#
Candidate configuration modes
To configure the router using the MD-CLI, the user must enter a configuration mode using the explicit or implicit configuration workflow.
The configuration workflow (implicit or explicit) determines if the user is restricted to the configure branch or if the user can navigate freely while in configuration mode. For more information about configuration workflows, see Implicit and explicit configuration workflows.
The configuration mode determines the interaction with other simultaneous configuration sessions. Configuration mode overview provides an overview of the available configuration modes:
-
private configuration mode
See Private configuration mode for details.
-
exclusive configuration mode
See Exclusive configuration mode for details.
-
global configuration mode
See Global configuration mode for details.
-
read-only configuration mode
See Read-only configuration mode for details.
Private configuration mode | Exclusive configuration mode | Global configuration mode | Read-only configuration mode | |
---|---|---|---|---|
Candidate configuration accessed |
Private candidate configuration |
Global candidate configuration |
Global candidate configuration |
Global candidate configuration |
Single vs multiple users |
Multiple users can simultaneously configure their own private candidate |
Only one user can configure the global candidate |
Multiple users can simultaneously configure the shared global candidate |
Multiple users can have simultaneous read-only access to the global candidate |
Privacy |
User can see own changes. Changes are not visible for read-only sessions. |
User can see own changes. Changes are visible for read-only sessions. |
User can see changes from other global configuration sessions. Changes are visible for read-only sessions. |
Users can see changes from global or exclusive configuration sessions |
Commits |
Own changes are committed |
Own changes are committed. Commits from other configuration changes are blocked. |
Changes made by all global configuration sessions are committed |
Users cannot commit |
Update needed? |
Yes - baseline can become out-of-date when another private or global configuration session commits |
No - baseline is always up-to-date. Other configuration sessions cannot commit. |
Yes - baseline can become out-of-date when a private configuration session commits |
No - updates are not allowed in read-only configuration mode |
Multiple simultaneous candidate configurations
As introduced in Transactional configuration method, configuration changes are made in a candidate configuration and copied in the running configuration when the configuration changes are committed and become active.
This section describes:
-
how the running configuration and a candidate configuration interact using a running datastore, a baseline datastore, and a candidate datastore
-
how simultaneous configuration sessions access one or multiple candidate configurations as a function of their configuration mode
The following figure shows multiple candidate configurations.
The running configuration is the active configuration of the router and is stored in the running datastore. There is only one running configuration in the router and therefore, only one running datastore. The running datastore is always instantiated.
The candidate configuration is a working configuration that contains changes before they are activated in the router. A candidate configuration uses two datastores:
-
a baseline datastore that contains a snapshot copy of the running datastore at a specific moment in time
-
a candidate datastore that contains changes relative to its associated baseline datastore
Multiple candidate configurations can exist simultaneously in the router with one of the following:
-
a single global candidate configuration that is accessed by one of the following:
-
a single session in exclusive configuration mode
-
one or multiple sessions in global configuration mode
-
one or multiple sessions in read-only configuration mode
An exclusive and global configuration session are mutually exclusive. Read-only configuration sessions can coexist with an exclusive configuration session or with one or multiple global configuration sessions.
The global baseline datastore and global candidate datastore are always instantiated.
-
-
up to eight private candidate configurations. A private candidate configuration is accessed by a single session in private configuration mode. The private baseline datastore and private candidate datastore are instantiated when the user enters the private configuration mode and the datastores are deleted from the router when the user exits the private configuration mode.
-
one single private-exclusive candidate configuration. Only one exclusive session can be active in the router at a time: either a user-started exclusive configuration session accessing the global candidate configuration, or a system-started private-exclusive configuration session accessing a private candidate configuration, or a user-started private configuration session using NETCONF with the <lock> RPC sent to promote it to a private-exclusive configuration session. For more information, see Private-exclusive configuration session.
When a configuration session commits its candidate configuration, the router performs the following actions:
-
verifies the running configuration has not been changed by another configuration session
-
validates the candidate configuration by verifying the logic, constraints, and completeness of the candidate configuration
-
activates the candidate configuration by sending the new candidate configuration to the corresponding applications
After a successful commit, the changes are copied to the running datastore, the baseline datastore contains a new copy of the running datastore, and the candidate datastore is empty.
Furthermore, when simultaneous configuration sessions access different candidate configurations:
-
Multiple private configuration sessions each access their own private candidate configuration.
-
One or multiple private configuration sessions each access their own private candidate configuration and one or multiple global configuration sessions all access the global candidate configuration.
-
One or multiple private configuration sessions each access their own private candidate configuration and one exclusive configuration session accesses the global candidate configuration.
-
One or multiple private configuration sessions each access their own private candidate configuration and one private exclusive configuration session accesses a private candidate configuration.
Each configuration session adds changes in the candidate datastore relative to the baseline associated with the candidate configuration. The baseline datastore contains a snapshot copy of the running datastore at a specific time. Therefore, multiple, simultaneous configuration sessions that are active in the router and that access different candidate configurations have their own unique view of the candidate configuration and cannot see other users’ changes, as shown in the following figure.
Changes in a candidate configuration can only be committed when the running configuration has not been changed or touched after the baseline snapshot was taken. In other words, the baseline must be up to date to commit the changes.
The following figure shows how the baseline datastore of user-2’s candidate configuration is out-of-date after user-1 committed its changes. An exclamation mark (!) is shown in the prompt to indicate an out-of-date baseline status.
Because the baseline is out-of-date, user-2 must update its candidate configuration before committing. An update copies a new snapshot from the running datastore to the baseline datastore and merges the changes from the candidate datastore, as shown in the following figure.
With more than one user working on the same part of the configuration, conflicts can occur when committed changes of one user’s configuration session are merged into another user’s candidate configuration. A merge conflict occurs when a configuration element is added, deleted, or modified in the candidate configuration and the same configuration element is also added, deleted, or modified in the running configuration after the baseline snapshot was taken. With the update command, the router resolves each merge conflict and installs the result in the candidate configuration, as shown in the following figure.
When a commit operation is executed in a configuration session while the baseline is out-of-date, the router first attempts to automatically update the candidate configuration. If a merge conflict is detected, the commit operation is canceled, to allow the administrator to resolve the merge conflicts manually. The candidate configuration remains in the same state as before the commit operation.
In configuration mode, the administrator can use the following tools to check and resolve potential merge conflicts:
-
compare baseline running
This tool lists the changes that were made in the running datastore after a snapshot copy was stored in the baseline datastore.
-
compare baseline candidate or compare
This tool lists the candidate configuration changes.
-
update check
This tool performs a dry run update. The router reports all merge conflicts as if an update was performed. The candidate configuration, that is, the baseline candidate datastore, is not changed with this command.
Conflict detection and resolution is detailed in Updating the candidate configuration.
Private configuration mode
In private configuration mode, a private candidate configuration is reserved for editing by a single private configuration session. Each private configuration session works on its own copy of the running configuration. Only the changes made in the private configuration session are visible and can be committed. Private configuration mode can be used when multiple users are configuring simultaneously on different parts of the router configuration.
A private configuration session has the following characteristics:
-
Each private configuration session accesses its own private candidate configuration. The private candidate configuration is instantiated when the user enters private configuration mode and is deleted form the router when the user exits private configuration mode.
-
Changes can only be entered in its own private candidate configuration.
-
Configuration changes are visible only in the private candidate configuration in which the changes are entered.
-
Uncommitted changes in the private candidate configuration cannot be seen by other private, exclusive, global, or read-only configuration sessions.
-
When the commit command is issued, only those changes entered in its own private candidate configuration are committed.
-
When a private configuration session is started, a new private candidate configuration is instantiated and has no uncommitted changes.
-
When a user leaves private configuration mode, uncommitted changes are discarded and the private candidate configuration is deleted. The user is prompted for confirmation to exit when uncommitted changes are present.
For simultaneous configuration sessions:
-
Up to eight simultaneous private configuration sessions can coexist. Each private configuration session accesses its own private candidate configuration. Private candidate configurations can have uncommitted changes when another private configuration session starts. A private configuration session can edit and commit its private candidate configuration while another private configuration session is active.
-
An exclusive configuration session can coexist with a private configuration session. The private candidate configuration can have uncommitted changes when an exclusive configuration session starts. The exclusive session can edit and commit changes while a private configuration session is active. The private configuration session can still edit the private candidate configuration, but changes cannot be committed because the exclusive session holds a lock on the running datastore.
-
Multiple global configuration sessions can coexist with a private configuration session. A global configuration session accesses the global candidate configuration. The private candidate configuration can have uncommitted changes when the global configuration session starts.
-
Multiple read-only configuration sessions can coexist with a private configuration session. Read-only configuration sessions access the global candidate configuration. A read-only configuration session cannot view the changes in the private candidate configuration. The private candidate configuration can have uncommitted changes when a read-only configuration session starts.
Datastore interactions include the following characteristics:
-
The private baseline datastore becomes out-of-date when another private, exclusive, global, or private exclusive configuration session commits changes to the running datastore after the private baseline snapshot was taken. An out-of-date baseline is indicated in the prompt with an exclamation mark.
-
An update of the private candidate configuration is needed when its private baseline datastore is out-of-date. An update copies a new snapshot of the running datastore in the private baseline datastore and merges the changes from the private candidate datastore. Merge conflicts detected in a manual update are reported and resolved. Merge conflicts detected in an automatic update as part of a commit operation result in the cancellation of the commit operation.
-
A snapshot of the running datastore is copied in the private baseline datastore:
-
at instantiation of the private candidate configuration when a user enters the private configuration mode
-
when a manual update is performed
-
after a commit, when no merge conflicts are detected during the automatic update and the updated candidate configuration is valid
-
When entering private configuration mode, the following messages are displayed:
[/]
A:admin@node-2# configure private
INFO: CLI #2070: Entering private configuration mode
INFO: CLI #2061: Uncommitted changes are discarded on configuration mode exit
When leaving private configuration mode, the following messages are displayed:
-
without uncommitted changes in the private candidate configuration:
[pr:/configure] A:admin@node-2# exit all INFO: CLI #2074: Exiting private configuration mode
-
with uncommitted changes present in the private candidate configuration:
*[pr:/configure] A:admin@node-2# exit all INFO: CLI #2071: Uncommitted changes are present in the candidate configuration. Exiting private configuration mode will discard those changes. Discard uncommitted changes? [y,n] n INFO: CLI #2072: Exit private configuration mode canceled *[pr:/configure] A:admin@node-2# exit all INFO: CLI #2071: Uncommitted changes are present in the candidate configuration. Exiting private configuration mode will discard those changes. Discard uncommitted changes? [y,n] y WARNING: CLI #2073: Exiting private configuration mode - uncommitted changes are discarded
Exclusive configuration mode
In exclusive configuration mode, the global configuration is reserved for editing by a single read-write configuration session. In addition, the running datastore is locked such that no other configuration session can commit changes. Exclusive configuration mode can be used when important router configuration changes must be implemented that cannot be interrupted or delayed, and to avoid the risk of committing other users’ partial completed changes.
An exclusive configuration session has the following characteristics:
-
An exclusive configuration session accesses the global candidate configuration.
-
Only one user can enter exclusive configuration mode at a time.
-
Configuration changes in the global candidate can only be entered by the user in exclusive configuration mode.
-
Configuration changes in the global candidate are visible for read-only configuration sessions.
-
Changes in the global candidate configuration can only be committed by the user in exclusive configuration mode
-
Uncommitted changes cannot be present in the global candidate configuration when an exclusive configuration session starts.
-
Uncommitted changes are discarded from the global candidate configuration when a user leaves the exclusive configuration mode. The user is prompted for confirmation to exit when uncommitted changes are present.
For simultaneous configuration sessions:
-
Multiple private configuration sessions can coexist with an exclusive configuration session. Each private configuration session accesses its own private candidate configuration. The global candidate configuration can have uncommitted changes when a private configuration session starts. A private configuration session can edit its private candidate configuration but cannot commit the changes while an exclusive configuration session is active.
-
Only one exclusive configuration session can be active in the router at a time.
-
An exclusive and global configuration session are mutually exclusive.
-
Multiple read-only configuration sessions can coexist with an exclusive configuration session. Read-only configuration sessions access the same global candidate configuration. The global candidate configuration can have uncommitted changes when a read-only configuration session starts.
Datastore interactions include the following characteristics:
-
The global baseline datastore is always up to date. Commits from other configuration sessions are blocked while an exclusive configuration session is active.
-
An update of the global candidate configuration is not needed in exclusive configuration mode.
When entering exclusive configuration mode, the following messages are displayed:
-
with a global configuration session active:
[/] A:admin@node-2# configure exclusive MINOR: MGMT_CORE #2052: Exclusive datastore access unavailable - model-driven interface editing global candidate
-
with uncommitted changes present in the global candidate configuration:
[/] A:admin@node-2# configure exclusive MINOR: MGMT_CORE #2052: Exclusive datastore access unavailable - model-driven interface has uncommitted changes in global candidate
-
with a private configuration session active:
[/] A:admin@node-2# edit-config exclusive INFO: CLI #2060: Entering exclusive configuration mode INFO: CLI #2061: Uncommitted changes are discarded on configuration mode exit
-
MGMT_CORE #2052 is shown only when applicable.
-
To display the current active configuration sessions in the router, use the command show system management-interface configuration-sessions.
When leaving exclusive configuration mode, the following messages are displayed:
-
without uncommitted changes in the global candidate configuration:
[ex:/configure] A:admin@node-2# exit all INFO: CLI #2064: Exiting exclusive configuration mode
-
with uncommitted changes in the global candidate configuration:
*[ex:/configure] A:admin@node-2# exit all INFO: CLI #2063: Uncommitted changes are present in the candidate configuration. Exiting exclusive configuration mode will discard those changes. Discard uncommitted changes? [y,n] n INFO: CLI #2065: Exit exclusive configuration mode canceled *[ex:/configure] A:admin@node-2# exit all INFO: CLI #2063: Uncommitted changes are present in the candidate configuration. Exiting exclusive configuration mode will discard those changes. Discard uncommitted changes? [y,n] y WARNING: CLI #2062: Exiting exclusive configuration mode - uncommitted changes are discarded
Global configuration mode
In global configuration mode, the global configuration is shared with all global configuration sessions. When a user commits their changes, the changes from all users are also committed. Global configuration mode can be used when multiple users are working together on the same part of the router configuration but is generally not recommended because it can cause unintended configuration to be committed.
A global configuration session has the following characteristics:
-
A global configuration session accesses the global candidate configuration.
-
Multiple users can enter global configuration mode simultaneously.
-
Configuration changes made by one user are visible to all other users in global or read-only configuration mode. Configuration changes in private candidate configurations are not visible.
-
All changes in the global candidate configuration, from all users, are committed to the running configuration when one user commits the global candidate configuration.
-
Uncommitted changes can be present in the global candidate configuration when a global configuration session starts.
-
Uncommitted changes are kept in the global candidate configuration when a user leaves the global configuration mode.
For simultaneous configuration sessions:
-
Multiple private configuration sessions can coexist with a global configuration session. Each private configuration session accesses its own private candidate configuration. The global candidate configuration can have uncommitted changes when a private configuration session starts.
-
An exclusive and global configuration session are mutually exclusive.
-
Multiple global configuration sessions can coexist. All global configuration sessions access the same global candidate configuration. The global candidate configuration can have uncommitted changes when another global configuration session starts.
-
Multiple read-only configuration sessions can coexist with a global configuration session. Read-only configuration sessions access the same global candidate configuration. The global candidate configuration can have uncommitted changes when a read-only configuration session starts.
Datastore interactions include the following characteristics:
-
The global baseline datastore becomes out-of-date when another private or private exclusive configuration session commits changes to the running datastore after the global baseline snapshot was taken. An out-of-date baseline is indicated in the prompt with an exclamation mark.
-
An update of the global candidate configuration is needed when its global baseline datastore is out-of-date. An update copies a new snapshot of the running datastore in the global baseline datastore and merges the changes from the global candidate datastore. Merge conflicts detected in a manual update are reported and resolved. Merge conflicts detected in an automatic update as part of a commit operation result in the cancellation of the commit operation.
-
The baseline datastore tracks the running datastore, that is, changes in the running datastore are automatically copied in the baseline datastore:
-
after a router reboot
-
after a successful commit
-
after a discard with an up to date global baseline
-
-
A snapshot copy of the running datastore is copied in the global baseline datastore and tracking stops when the global candidate is touched, for example, when a configuration element has been added, deleted, or modified. A new snapshot of the running datastore is copied to the global baseline datastore when a manual update is performed.
When entering global configuration mode, the following messages are displayed:
[/]
A:admin@node-2# configure global
INFO: CLI #2054: Entering global configuration mode
INFO: CLI #2055: Uncommitted changes are present in the candidate configuration
INFO: CLI #2075: Other global configuration sessions are active
-
CLI #2055 and CLI #2075 are shown only when applicable.
-
To display the current active configuration sessions in the router, use the command show system management-interface configuration-sessions.
When leaving global configuration mode, the following messages are displayed:
*[gl:/configure]
A:admin@node-2# exit all
INFO: CLI #2056: Exiting global configuration mode
INFO: CLI #2057: Uncommitted changes are kept in the candidate configuration
Read-only configuration mode
In read-only configuration mode, no changes can be made to the global candidate configuration and no changes can be committed to the running configuration. Read-only configuration mode can be used when reviewing or monitoring configuration changes from other users in the global candidate configuration.
A read-only configuration session has the following characteristics:
-
A read-only configuration session accesses the global candidate configuration.
-
Multiple users can enter read-only configuration mode simultaneously.
-
All configuration changes in the global candidate configuration are visible. Configuration changes in private candidate configurations are not visible.
-
The global configuration cannot be edited and changes in the global configuration cannot be committed.
-
Uncommitted changes can be present in the global candidate configuration when a read-only configuration session starts.
-
Uncommitted changes are kept in the global candidate configuration when a user leaves a read-only configuration mode.
For simultaneous configuration sessions:
-
Multiple private configuration sessions can coexist with a read-only configuration session. Each private configuration session accesses its own private candidate configuration. The global candidate configuration can have uncommitted changes when a private configuration session starts.
-
An exclusive configuration session can coexist with a read-only configuration session. The exclusive configuration session accesses the same global candidate configuration. The global candidate configuration cannot have uncommitted changes when an exclusive configuration session starts.
-
Multiple global configuration sessions can coexist with a read-only configuration session. Global configuration sessions access the same global candidate configuration. The global candidate configuration can have uncommitted changes when another global configuration session starts.
-
Multiple read-only configuration sessions can coexist. Read-only configuration sessions access the same global candidate configuration. The global candidate configuration can have uncommitted changes when another read-only configuration session starts.
When entering read-only configuration mode, the following message is displayed:
[/]
A:admin@node-2# configure read-only
INFO: CLI #2066: Entering read-only configuration mode
When leaving read-only configuration mode, the following message is displayed:
*[ro:/configure]
A:admin@node-2# exit all
INFO: CLI #2067: Exiting read-only configuration mode
Transitioning between candidate configuration modes
Exclusive, global, and read-only configuration sessions that access the global candidate configuration can transition between these configuration modes without exiting and re-entering the configuration mode.
Transitions from and to private configuration mode are not allowed.
The following summarizes the configuration mode transitions and transitions to operational mode.
Configuration and operational mode transition |
To |
|||||
---|---|---|---|---|---|---|
Global |
Exclusive |
Read-only |
Private |
Operational mode |
||
From |
Global |
X2 |
Allowed; no other exclusive or global configuration session can be active; uncommitted changes are kept |
Allowed; uncommitted changes are kept |
X |
Allowed; uncommitted changes are kept |
Exclusive |
Allowed; uncommitted changes are discarded |
X2 |
Allowed; uncommitted changes are discarded |
X |
Allowed; uncommitted changes are discarded |
|
Read-only |
Allowed; no exclusive configuration session can be active; uncommitted changes are kept |
Allowed; no other exclusive or global configuration session can be active; uncommitted changes are kept |
X2 |
X |
Allowed; uncommitted changes are kept |
|
Private |
X |
X |
X |
X2 |
Allowed; uncommitted changes are discarded |
|
Operational mode |
Allowed |
Allowed |
Allowed |
Allowed |
X |
Transitioning from exclusive to global or read-only configuration mode causes the candidate changes to be discarded.
[/]
A:admin@node-2# edit-config exclusive
INFO: CLI #2060: Entering exclusive configuration mode
INFO: CLI #2061: Uncommitted changes are discarded on configuration mode exit
(ex)[/]
A:admin@node-2# configure router interface my-int
*(ex)[/configure router "Base" interface "my-int"]
A:admin@node-2# edit-config global
INFO: CLI #2063: Uncommitted changes are present in the candidate configuration.
Exiting exclusive configuration mode will discard those changes.
Discard uncommitted changes? [y,n] n
INFO: CLI #2065: Exit exclusive configuration mode canceled
*(ex)[/configure router "Base" interface "my-int"]
A:admin@node-2# edit-config read-only
INFO: CLI #2063: Uncommitted changes are present in the candidate configuration.
Exiting exclusive configuration mode will discard those changes.
Discard uncommitted changes? [y,n] y
WARNING: CLI #2062: Exiting exclusive configuration mode - uncommitted changes are discarded
INFO: CLI #2066: Entering read-only configuration mode
(ro)[/configure router "Base" interface "my-int"]
A:admin@node-2#
Switching from global or read-only to exclusive configuration mode is allowed when no other global or exclusive configuration session is active. Uncommitted changes in the global candidate configuration are kept.
In the following example, the admin disconnect command is used to disconnect another active global configuration session before the current session can switch to exclusive configuration.
[/]
A:admin@node-2# edit-config global
INFO: CLI #2054: Entering global configuration mode
INFO: CLI #2075: Other global configuration sessions are active
(gl)[/]
A:admin@node-2# configure router interface new-int
*(gl)[/configure router "Base" interface "new-int"]
A:admin@node-2# edit-config exclusive
MINOR: MGMT_CORE #2052: Exclusive datastore access unavailable - model-driven interface editing global candidate
*(gl)[/configure router "Base" interface "new-int"]
A:admin@node-2# show system management-interface configuration-sessions
===============================================================================
Session ID Region Datastore Lock State
Username Session Mode Idle Time
Session Type From
-------------------------------------------------------------------------------
#22 configure Candidate Unlocked
admin Global 0d 00:00:00
MD-CLI 135.244.144.235
23 configure Candidate Unlocked
user-1 Global 0d 00:00:42
MD-CLI 135.244.144.235
-------------------------------------------------------------------------------
Number of sessions: 2
'#' indicates the current active session
===============================================================================
*(gl)[/configure router "Base" interface "new-int"]
A:admin@node-2#
*(gl)[/configure router "Base" interface "new-int"]
A:admin@node-2# admin disconnect session-id 23
*(gl)[/configure router "Base" interface "new-int"]
A:admin@node-2# edit-config exclusive
INFO: CLI #2056: Exiting global configuration mode
INFO: CLI #2057: Uncommitted changes are kept in the candidate configuration
INFO: CLI #2060: Entering exclusive configuration mode
INFO: CLI #2061: Uncommitted changes are discarded on configuration mode exit
*(ex)[/configure router "Base" interface "new-int"]
A:admin@node-2#
Private-exclusive configuration session
A private-exclusive configuration session is reserved for system internal use and private candidate NETCONF sessions with an exclusive lock.
Router configuration changes are made via a private-exclusive configuration session as a result of the following scenarios:
-
One of the following actions occurs when in mixed configuration mode:
-
any configuration is performed in the classic CLI engine
-
a gNMI configuration operation
- a NETCONF session issuing the <lock> RPC while running in private candidate mode
-
-
One of the following actions occurs when in model-driven configuration mode:
-
a gNMI configuration operation
-
a password command execution which causes the system to update the configuration
- a NETCONF session issuing the <lock> RPC while running in private candidate mode
-
It is important to be aware that a private-exclusive configuration session can exist, as it interacts with other active configuration sessions in the following ways:
-
An exclusive configuration session and a private-exclusive configuration session are mutually exclusive, as they both require a lock on the running datastore.
-
The global candidate configuration and private candidate configuration can become out-of-date when changes are committed via a private-exclusive configuration session.
-
Commits from global and private configuration sessions are blocked when a private-exclusive configuration session is active.
-
A private-exclusive configuration session accesses its own private candidate configuration. Changes are not visible to other configuration sessions until they are committed and become active in the running configuration.
Restricting configuration mode sessions
It may be desirable to deny a user the ability to use specific configuration modes. For example, denying the use of exclusive configuration mode prevents the user from locking the configuration datastore, or denying the use of the global configuration mode forces the user to work in a private candidate datastore.
It is possible to use AAA to deny access to particular configuration modes, as illustrated in the following configuration example.
In this example, the user pr-user has profile admin-private. Entries 3 and 4 in the local profile effectively deny users in the admin-private profile from entering the exclusive configuration mode in the MD-CLI.
[ex:/configure system security aaa local-profiles profile "admin-private"]
A:admin@node-2# info detail
## cli-session-group
default-action permit-all
---snip---
entry 3 {
## apply-groups
## description
action deny
match "edit-config exclusive"
}
entry 4 {
## apply-groups
## description
action deny
match "configure exclusive"
}
[/]
A:pr-user@node-2# configure exclusive
MINOR: MGMT_CORE #2020: Permission denied - unauthorized use of 'configure'
[/]
A:pr-user@node-2# configure ?
configure
Configuration modes:
global - Enter global (shared) mode for candidate configuration.
private - Enter private mode for candidate configuration.
read-only - Enter read-only mode for candidate configuration.
- Enter a candidate li configuration mode
[/]
A:pr-user@node-2# edit-config exclusive
MINOR: MGMT_CORE #2020: Permission denied - unauthorized use of 'edit-config'
[/]
A:pr-user@node-2# edit-config ?
edit-config
Configuration modes:
global - Enter global (shared) mode for candidate configuration.
private - Enter private mode for candidate configuration.
read-only - Enter read-only mode for candidate configuration.
li - Enter a candidate li configuration mode
The following additional entries to the profile deny users from entering the global configuration mode in the MD-CLI.
[ex:configure system security aaa local-profiles profile "admin-pr"]
A:admin@node-2# info detail
---snip---
entry 5 {
## apply-groups
## description
action deny
match "configure global"
}
entry 6 {
## apply-groups
## description
action deny
match "edit-config global"
}
[]
A:pr-user@node-2# configure ?
configure
Configuration modes:
private - Enter private mode for candidate configuration.
read-only - Enter read-only mode for candidate configuration.
[]
A:pr-user@node-2# edit-config ?
edit-config
Configuration modes:
private - Enter private mode for candidate configuration.
read-only - Enter read-only mode for candidate configuration.
li - Enter a candidate li configuration mode
[]
A:pr-user@node-2# configure global
MINOR: MGMT_CORE #2020: Permission denied - unauthorized use of 'configure'
[]
A:pr-user@node-2# edit-config global
MINOR: MGMT_CORE #2020: Permission denied - unauthorized use of 'edit-config'
Modifying the configuration
To modify the router configuration using the MD-CLI, enter (private, exclusive, or global) configuration mode and use the available configuration commands as described in the 7450 ESS, 7750 SR, 7950 XRS, and VSR MD-CLI Command Reference Guide.
To add a new configuration or make changes to the existing configuration, see Adding configuration elements. To remove a particular configuration or to return a functionality to its default condition, see Deleting configuration elements.
-
apostrophe (')
-
asterisk (*)
-
hash (#)
-
opening bracket ([)
-
question mark (?)
-
space
Adding configuration elements
To add configuration statements using the MD-CLI, enter the command or parameter name with a valid value for the parameter as specified by the data type. For some parameters, it is sufficient to type the parameter name to set the parameter configuration.
The current configuration of a parameter is available via the info detail command, even if it is the default value or if the parameter is in an unconfigured state (indicated by ##). The display of default values allows an administrator to view the configuration, particularly in a multi-vendor network with different default settings. An operator may choose to explicitly configure a setting that persists instead of using the default, in case the default changes.
See the 7450 ESS, 7750 SR, 7950 XRS, and VSR MD-CLI Command Reference Guide for more information about configuration commands and their appropriate syntax.
Default values for key leafs
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 specified default is assumed. For example, configure router bgp with no instance value expands to configure router ‟Base” bgp. Default values are implemented as follows:
Default values cannot be used in a reference.
Multiple keys in a list can have default values.
The first, last, or any key in a list may have a default value.
If the first key has a default value, the other keys must be named keys.
Default values can be used multiple times in any combination; for example, configure router isis expands to configure router ‟Base” isis 0, and configure router foo isis expands to configure router ‟foo” isis 0.
The expansion is automatic and displayed in the command prompt context and pwc.
(ex)[/]
A:admin@node-2# configure router
(ex)[/configure router "Base"]
A:admin@node-2#
(ex)[/]
A:admin@node-2# configure router isis
(ex)[/configure router "Base" isis 0]
A:admin@node-2#
(ex)[/]
A:admin@node-2# configure router ospf
(ex)[/configure router "Base" ospf 0]
A:admin@node-2# pwc
Present Working Context:
configure
router "Base"
ospf 0
(ex)[/configure router "Base" ospf 0]
A:admin@node-2#
Entering integer values
Integer values can be entered in any of the following formats:
decimal
Enter an integer (whole number) without spaces; for example, 123456.
binary
Enter 0b followed by the binary value without spaces; for example, 0b1111000100100000. Negative values are not accepted.
hexadecimal
Enter 0x followed by the hexadecimal value in lowercase or uppercase without spaces; for example, 0x1E240 or 0x1e240. Negative values are not accepted.
Integer values are displayed in decimal format, unless a different output format is specified internally by the system.
Integer values displayed in decimal format
*[ex:/configure router "Base" bgp]
A:admin@node-2# connect-retry 0b100100101001
*[ex:/configure router "Base" bgp]
A:admin@node-2# info | match connect-retry
connect-retry 2345
*[ex:/configure router "Base" bgp]
A:admin@node-2# connect-retry 0xd80
*[ex:/configure router "Base" bgp]
A:admin@node-2# info | match connect-retry
connect-retry 3456
*[ex:/configure router "Base" bgp]
A:admin@node-2#
etype parameter is a hexadecimal output value
This example shows that a decimal value can be entered, but the value is displayed in hexadecimal format.
*[ex:/configure filter mac-filter "fn" entry 1 match]
A:admin@node-2# etype ?
etype <number>
<number> - <0x600..0xffff>
Ethernet type
*[ex:/configure filter mac-filter "fn" entry 1 match]
A:admin@node-2# etype 65535
*[ex:/configure filter mac-filter "fn" entry 1 match]
A:admin@node-2# info
etype 0xffff
Command with a union of data types
In the following example of a command with a union of data types, the pir command can have an integer value or it can be defined with the max enumerated value. If a numerical value is entered for pir, it must be entered as a decimal number.
*[ex:/configure qos sap-ingress "sstest" queue 8 rate]
A:admin@node-2# pir ?
pir (<number> | <keyword>)
<number> - <1..6400000000> - kilobps
<keyword> - max - kilobps
Default - max
Administrative PIR
*[ex:/configure qos sap-ingress "sstest" queue 8 rate]
A:admin@node-2# pir 88
*[ex:/configure qos sap-ingress "sstest" queue 8 rate]
A:admin@node-2# info
pir 88
*[ex:/configure qos sap-ingress "sstest" queue 8 rate]
A:admin@node-2# pir 0b0010
^^^^^^
MINOR: MGMT_CORE #2301: Invalid element value - 'pir' expected number '<1..6400000000>' (kilobps) or keyword 'max' (kilobps)
*[ex:/configure qos sap-ingress "sstest" queue 8 rate]
A:admin@node-2# info
pir 88
*[ex:/configure qos sap-ingress "sstest" queue 8 rate]
A:admin@node-2# pir 2
*[ex:/configure qos sap-ingress "sstest" queue 8 rate]
A:admin@node-2# info
pir 2
Configuring lists
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.
Configuring a list
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 name is mandatory.
*[ex:/configure cflowd]
A:admin@node-2# collector ?
[ip-address] (<unicast-ipv4-address> | <global-unicast-ipv6-address>)
<unicast-ipv4-address> - <d.d.d.d>
<global-unicast-ipv6-address> - (<x:x:x:x:x:x:x:x>|<x:x:x:x:x:x:d.d.d.d>)
IP address of the remote cflowd collector host
*[ex:/configure cflowd]
A:admin@node-2# collector 10.20.30.40 ?
port <number>
<number> - <1..65535>
UDP port number of the remote cflowd collector host
Entering IP address and port number
The IP address and port number can be entered in one of the following ways.
*[ex:/configure cflowd]
A:admin@node-2# collector ip-address 10.10.20.30 port 7
*[ex:/configure cflowd]
A:admin@node-2# collector 10.10.20.30 port 7
There are some exceptions where the first key of a list is named. In these cases, the key name must be entered.
Entering the key name
In the following example, the key name index must be entered.
*[ex:/configure cflowd collector 10.20.30.40 port 7 export-filter interface-list service]
A:admin@node-2# ies-interface ?
service-name <reference>
<reference> - <1..64 characters> - configure service ies <service-name>
Administrative service name
*[ex:/configure cflowd collector 10.20.30.40 port 7 export-filter interface-list service]
A:admin@node-2# ies-interface service-name svc-test interface-name ?
interface-name <reference>
<reference> - <1..32 - configure service ies <./service-name>
characters> interface <interface-name>
ies interface name
*[ex:/configure cflowd collector 10.20.30.40 port 7 export-filter interface-list service]
A:admin@node-2# ies-interface service-name svc-test interface-name int-name-test
*[ex:/configure cflowd collector 10.20.30.40 port 7 export-filter interface-list service]
A:admin@node-2# info
ies-interface service-name "svc-test" interface-name "int-name-test" { }
Auto-completion does not select or complete the name of the first key if it is optional.
Using an optional key name
In the following example, the key name for ma-admin-name is optional as indicated by the square brackets, and is not auto-completed when Tab is entered.
*[ex:/configure eth-cfm domain "dmtest"]
A:admin@node-2# association ?
[ma-admin-name] <string>
<string> - <1..64 characters>
Domain association name
*[ex:/configure eth-cfm domain "dmtest"]
A:admin@node-2# association Press Tab
<ma-admin-name>
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.
Enclosing the key name in quotation marks
*[ex:/configure eth-cfm domain "dmtest"]
A:admin@node-2# association "ma-admin-name"
*[ex:/configure eth-cfm domain "dmtest" association "ma-admin-name"]
A:admin@node-2# pwc
Present Working Context:
configure
eth-cfm
domain "dmtest"
association "ma-admin-name"
If the optional key name is entered, it can be specified as the actual value of the key with or without the quotation marks.
Specifying the optional key name as the actual value of the key
*[ex:/configure eth-cfm domain "dmtest"]
A:admin@node-2# association ma-admin-name ma-admin-name
*[ex:/configure eth-cfm domain "dmtest" association "ma-admin-name"]
A:admin@node-2# pwc
Present Working Context:
configure
eth-cfm
domain "dmtest"
association "ma-admin-name"
Users can enter the wildcard asterisk (*) character, a range, or a regular expression instead of a list key name to edit multiple elements with one command. See Using expressions in commands for more information.
Using the wildcard * character to enable all ports
[ex:/configure]
A:admin@node-2# port * admin-state enable
Using a range to enable a range of ports
[ex:/configure]
A:admin@node-2# port 1/1/[1..3] admin-state enable
[ex:/configure]
A:admin@node-2# port 1/1/[1,3,5] admin-state enable
System-ordered lists
For system-ordered lists, list entries are automatically reordered.
In the following example, the list is reordered based on the alphabetical order of the string name identifying the list instance.
[ex:/configure]
A:admin@node-2# eth-cfm ?
eth-cfm
apply-groups - Apply a configuration group at this level
apply-groups-exclude - Exclude a configuration group at this level
default-domain + Enter the default-domain context
domain + Enter the domain list instance
[ex:/configure]
A:admin@node-2# eth-cfm
[ex:/configure eth-cfm]
A:admin@node-2# domain ?
[md-admin-name] <string>
<string> - <1..64 characters>
Unique domain name
[ex:/configure eth-cfm]
A:admin@node-2# domain zero } domain two } domain four } domain five }
*[ex:/configure eth-cfm]
A:admin@node-2# info
domain "five" {
}
domain "four" {
}
domain "two" {
}
domain "zero" {
}
User-ordered lists
For user-ordered lists, new entries are appended to the end of the list.
New entries appended to the list
[ex:/configure router "Base"]
A:admin@node-2# apply-groups grp3
*[ex:/configure router "Base"]
A:admin@node-2# apply-groups grp1
*[ex:/configure router "Base"]
A:admin@node-2# apply-groups grp9
*[ex:/configure router "Base"]
A:admin@node-2# info
apply-groups ["grp3" "grp1" "grp9"]
*[ex:/configure router "Base"]
A:admin@node-2# apply-groups grp5
*[ex:/configure router "Base"]
A:admin@node-2# info
apply-groups ["grp3" "grp1" "grp9" "grp5"]
To reorder a user-ordered list, the list can be deleted and recreated using the specified order. Alternatively, the tilde (~) character can be used to replace a list, effectively deleting and recreating the list in one step.
Using the tilde (~) character to replace a user-ordered list
*[ex:/configure router "Base"]
A:admin@node-2# ~ apply-groups [grp1 grp3 grp5 grp8]
*[ex:/configure router "Base"]
A:admin@node-2# info
apply-groups ["grp1" "grp3" "grp5" "grp8"]
It is possible to insert entries into an existing user-ordered list by using the insert command.
List begins with two entries, named-entry ‟one” and named-entry ‟ten”
*[ex:/configure policy-options policy-statement "my-ordered-list"]
A:admin@node-2# entry-type named
*[ex:/configure policy-options policy-statement "my-ordered-list"]
A:admin@node-2# named-entry one
*[ex:/configure policy-options policy-statement "my-ordered-list" named-entry "one"]
A:admin@node-2# back
*[ex:/configure policy-options policy-statement "my-ordered-list"]
A:admin@node-2# named-entry ten
*[ex:/configure policy-options policy-statement "my-ordered-list" named-entry "ten"]
A:admin@node-2# back
*[ex:/configure policy-options policy-statement "my-ordered-list"]
A:admin@node-2# info
entry-type named
named-entry "one" {
}
named-entry "ten" {
}
insert command is used
*[ex:/configure policy-options policy-statement "my-ordered-list"]
A:admin@node-2# insert named-entry four ?
Global commands:
after - Insert a named-entry in the user-ordered list after
another specified named-entry
before - Insert a named-entry in the user-ordered list before
another specified named-entry
beginning - Insert a named-entry at the beginning of the user-
ordered list
end - Insert a named-entry at the end of the user-ordered list
*[ex:/configure policy-options policy-statement "my-ordered-list"]
A:admin@node-2# insert named-entry four after one
*[ex:/configure policy-options policy-statement "my-ordered-list"]
A:admin@node-2# insert named-entry six before ten
*[ex:/configure policy-options policy-statement "my-ordered-list"]
A:admin@node-2# info
entry-type named
named-entry "one" {
}
named-entry "four" {
}
named-entry "six" {
}
named-entry "ten" {
}
*[ex:/configure policy-options policy-statement "my-ordered-list"]
A:admin@node-2# insert named-entry zero beginning
*[ex:/configure policy-options policy-statement "my-ordered-list"]
A:admin@node-2# insert named-entry twenty end
*[ex:/configure policy-options policy-statement "my-ordered-list"]
A:admin@node-2# info
entry-type named
named-entry "zero" {
}
named-entry "one" {
}
named-entry "four" {
}
named-entry "six" {
}
named-entry "ten" {
}
named-entry "twenty" {
}
List entries can still be deleted
*[ex:/configure policy-options policy-statement "my-ordered-list"]
A:admin@node-2# delete named-entry six
*[ex:/configure policy-options policy-statement "my-ordered-list"]
A:admin@node-2# info
entry-type named
named-entry "zero" {
}
named-entry "one" {
}
named-entry "four" {
}
named-entry "ten" {
}
named-entry "twenty" {
}
Adding the { keystroke
The default behavior of the insert command is to return immediately to the present working context. To drop into the newly-inserted entry, add the { keystroke, as shown in the following example.
*[ex:/configure policy-options policy-statement "my-ordered-list"]
A:admin@node-2# insert named-entry five after four {
*[ex:/configure policy-options policy-statement "my-ordered-list" named-entry "five"]
A:admin@node-2#
Special handling for lists with all key leafs
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, station is a list with a single leaf that is the key. After each station entry, the session maintains the same context and other station entries can be added without applying the back or exit command.
*[ex:/configure router "Base" bgp monitor]
A:admin@node-2# ?
admin-state - Administrative state of BMP monitoring
all-stations - Send BMP messages to all configured stations
apply-groups - Apply a configuration group at this level
route-monitoring + Enter the route-monitoring context
station - Add a list entry for station
*[ex:/configure router "Base" bgp monitor]
A:admin@node-2# station stn1
*[ex:/configure router "Base" bgp monitor]
A:admin@node-2# station stn2
*[ex:/configure router "Base" bgp monitor]
A:admin@node-2# station stn3
*[ex:/configure router "Base" bgp monitor]
A:admin@node-2# info
station "stn1" { }
station "stn2" { }
station "stn3" { }
Configuring leaf-lists
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.
Single or multiple leaf-list entries can be added in a single command line with the use of brackets ([]).
System-ordered leaf-lists
For leaf-lists ordered by the system, the leaf-list entries are automatically reordered, as shown in the following example.
Leaf-list entries automatically reordered
*[ex:/configure port 1/1/2 ethernet eth-cfm mep md-admin-name "md-test" ma-admin-name "ma-test" mep-id 8 ais]
A:admin@node-2# client-meg-level ?
client-meg-level <value>
client-meg-level [<value>...] - 1..7 system-ordered values separated by spaces
enclosed by brackets
<value> - <number>
<number> - <1..7>
Client MEG level for AIS message generation
*[ex:/configure port 1/1/2 ethernet eth-cfm mep md-admin-name "md-test" ma-admin-name "ma-test" mep-id 8 ais]
A:admin@node-2# client-meg-level [7 5 2 3]
*[ex:/configure port 1/1/2 ethernet eth-cfm mep md-admin-name "md-test" ma-admin-name "ma-test" mep-id 8 ais]
A:admin@node-2# info
client-meg-level [2 3 5 7]
*[ex:/configure port 1/1/2 ethernet eth-cfm mep md-admin-name "md-test" ma-admin-name "ma-test" mep-id 8 ais]
A:admin@node-2# client-meg-level [4 6]
*[ex:/configure port 1/1/2 ethernet eth-cfm mep md-admin-name "md-test" ma-admin-name "ma-test" mep-id 8 ais]
A:admin@node-2# info
client-meg-level [2 3 4 5 6 7]
System-ordered leaf-list reordered
The following system-ordered leaf-list is reordered based on the enumerated value of the entered keywords.
*[ex:/configure policy-options policy-statement "s" entry 9 from]
A:admin@node-2# family ?
family <value>
family [<value>...] - 1..20 system-ordered values separated by spaces enclosed
by brackets
<value> - <keyword>
<keyword> - (ipv4|vpn-ipv4|ipv6|mcast-ipv4|vpn-ipv6|l2-vpn|mvpn-ipv4|mdt-
safi|ms-pw|flow-ipv4|route-target|mcast-vpn-ipv4|mvpn-ipv6|
flow-ipv6|evpn|mcast-ipv6|label-ipv4|label-ipv6|bgp-ls|mcast-
vpn-ipv6|sr-policy-ipv4|sr-policy-ipv6)
Address family as the match condition
*[ex:/configure policy-options policy-statement "s" entry 9 from]
A:admin@node-2# family [mcast-vpn-ipv4 bgp-ls l2-vpn]
*[ex:/configure policy-options policy-statement "s" entry 9 from]
A:admin@node-2# info
family [l2-vpn mcast-vpn-ipv4 bgp-ls]
User-ordered leaf-lists
For user-ordered leaf-lists, new entries are appended to the end of the leaf-list.
New entries appended to the end of the leaf-list
*[ex:/configure policy-options policy-statement "plcy_str" entry 29]
A:admin@node-2# from prefix-list [ plcy5 plcy1 ]
*[ex:/configure policy-options policy-statement "plcy_str" entry 29]
A:admin@node-2# info
from {
prefix-list ["plcy5" "plcy1"]
}
*[ex:/configure policy-options policy-statement "plcy_str" entry 29]
A:admin@node-2# from prefix-list plcy3
*[ex:/configure policy-options policy-statement "plcy_str" entry 29]
A:admin@node-2# info
from {
prefix-list ["plcy5" "plcy1" "plcy3"]
}
*[ex:/configure policy-options policy-statement "plcy_str" entry 29]
A:admin@node-2# from prefix-list plcy1
*[ex:/configure policy-options policy-statement "plcy_str" entry 29]
A:admin@node-2# info
from {
prefix-list ["plcy5" "plcy1" "plcy3"]
}
*[ex:/configure policy-options policy-statement "plcy_str" entry 29]
A:admin@node-2#
To reorder a user-ordered leaf-list, the leaf-list must be deleted and recreated using the specified order. Alternatively, the tilde (~) character can be used to replace a leaf-list, effectively deleting and recreating the leaf-list in one step.
Using the tilde (~) character to replace a user-ordered leaf-list
(ex)[/]
A:admin@node-2# configure router isis 5
*(ex)[/configure router "Base" isis 5]
A:admin@node-2# export-policy [test5 test3 test2]
*(ex)[/configure router "Base" isis 5]
A:admin@node-2# info
export-policy ["test5" "test3" "test2"]
*(ex)[/configure router "Base" isis 5]
A:admin@node-2# ~ export-policy [test1 test2 test3 test5]
*(ex)[/configure router "Base" isis 5]
A:admin@node-2# info
export-policy ["test1" "test2" "test3" "test5"]
*(ex)[/configure router "Base" isis 5]
A:admin@node-2#
Configuring leafs with units
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. The units for a command can be displayed using the units option for the info command.
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:
memory sizes, for example, bytes
rates, for example, bps
durations, for example, seconds
dates, for example, Tue, 01 Sep 2020 15:15:35 UTC
Dynamic units can be entered as a number in one of the following ways:
-
as a value without a unit
The value is interpreted as the defined base unit. Decimal, binary, and hexadecimal numbers are supported.
Entering transmit-interval 10 without specifying a unit
For example, transmit-interval has a base unit of deciseconds. Entering transmit-interval 10, without specifying a unit, configures the interval to 10 deciseconds.
[ex:/configure port 1/1/1 ethernet efm-oam]
A:admin@node-2# transmit-interval ?
transmit-interval <number>
<number> - <1..600> - deciseconds
Default - 10
Transmit interval of OAMPDUs
[ex:/configure port 1/1/1 ethernet efm-oam]
A:admin@node-2# transmit-interval 50
*[ex:/configure port 1/1/1 ethernet efm-oam]
A:admin@node-2# info
transmit-interval 50
The units for the leaf can be displayed using the units option of the info command:
-
as unique value-unit tuples
The units are separated by a space in any order, and the same unit cannot be used more than once. The value is interpreted as the specified unit and can only be entered as a decimal number.
Acceptable formats to enter 55 deciseconds for transmit-interval
For example, there are many acceptable formats to enter 55 deciseconds for transmit-interval, including the following.
*[ex:/configure port 1/1/1 ethernet efm-oam]
A:admin@node-2# info
transmit-interval 55
*[ex:/configure port 1/1/1 ethernet efm-oam]
A:admin@node-2# transmit-interval 5 seconds 5 deciseconds
*[ex:/configure port 1/1/1 ethernet efm-oam]
A:admin@node-2# info
transmit-interval 55
*[ex:/configure port 1/1/1 ethernet efm-oam]
A:admin@node-2# transmit-interval 5 seconds 500 milliseconds
*[ex:/configure port 1/1/1 ethernet efm-oam]
A:admin@node-2# info
transmit-interval 55
The configured value is displayed as a positive integer in the defined base unit. Because the unit for transmit-interval is defined as deciseconds, the value displayed in the info command is in deciseconds, regardless of the format in which it was entered.
*[ex:/configure port 1/1/1 ethernet efm-oam]
A:admin@node-2# info
transmit-interval 55
The input value is calculated based on the input of all input tuples and validated after Enter is pressed.
Calculated input value
For example, entering 900 (deciseconds) for transmit-interval results in an error display, as 900 deciseconds is not in the element range.
*[ex:/configure port 1/1/1 ethernet efm-oam]
A:admin@node-2# transmit-interval 900
^^^
MINOR: MGMT_CORE #2301: Invalid element value - 900 out of range 1..600
Displaying valid units for a value
Entering a value followed by Spacebar and Tab displays valid units for the value, as in the following example. For a value of 900 for transmit-interval, the system displays valid unit possibilities, listed in alphabetical order.
*[ex:/configure port 1/1/1 ethernet efm-oam]
A:admin@node-2# transmit-interval 900 Press Tab
milliseconds centiseconds
If a unit is already present in the input, it is suppressed for any further input.
Units already present are suppressed
*[ex:/configure port 1/1/1 ethernet efm-oam]
A:admin@node-2# transmit-interval 900 centiseconds 100 Press Tab
milliseconds deciseconds
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.
Unit names are singular or plural
*[ex:/configure port 1/1/1 ethernet efm-oam]
A:admin@node-2# transmit-interval 1 Press Tab
decisecond second minute
...
*[ex:/configure port 1/1/1 ethernet efm-oam]
A:admin@node-2# transmit-interval 10 Press Tab
centiseconds deciseconds seconds
Displaying units for a leaf
The units for the leaf can be displayed using the units option of the info command.
*[ex:/configure port 1/1/1 ethernet efm-oam]
A:admin@node-2# info
transmit-interval 50
*[ex:/configure port 1/1/1 ethernet efm-oam]
A:admin@node-2# info units
transmit-interval 50 deciseconds
Auto-completion is supported for valid units entered after a value.
The following tables 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.
Unit name | Valid MD-CLI input |
---|---|
bytes |
|
kilobytes |
|
megabytes |
|
gigabytes |
|
terabytes |
|
Unit name | Valid MD-CLI input |
---|---|
bps (bits per second) |
bps |
kilobps (kilobits per second) |
|
megabps (megabits per second) |
|
gigabps (gigabits per second |
|
terabps (terabits per second) |
|
petabps (petabits per second) |
|
exabps (exabits per second) |
|
zettabps (zettabits per second) |
|
Unit name | Valid MD-CLI input |
---|---|
picoseconds |
|
nanoseconds |
|
microseconds |
|
milliseconds |
|
centiseconds |
|
deciseconds |
|
seconds |
|
minutes |
|
hours |
|
days |
|
weeks |
|
The following table shows the valid inputs for dates based on the time format.
Date and 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 follows ISO 8601 and must be enclosed in quotation marks. |
‟[Day], dd Mon yyyy hh:mm[:ss] [TZ]” For example: ‟Tue, 01 Sep 2020 13:21:11 UTC” |
Day is the name of the day of the week (Sun, Mon, Tue, Wed, Thu, Fri, Sat), 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 follows RFC 1123 and must be enclosed in 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 RFC 3339 and can be enclosed in quotation marks. |
Flexible input for MAC and IPv6 addresses
Flexible input is available for MAC and IPv6 addresses, where both uppercase and lowercase hexadecimal digits are accepted.
Hexadecimal digits in an IPv6 address entered in both uppercase and lowercase
In this example, IPv6 addresses are displayed in lowercase hexadecimal digits using zero compression, according to RFC 5952, A Recommendation for IPv6 Address Text Representation.
*[ex:/configure service vprn "vprn1" dns]
A:admin@node-2# ipv6-source-address 2001:db8:aaa3::8a2e:3710:7335
*[ex:/configure service vprn "vprn1" dns]
A:admin@node-2# info
ipv6-source-address 2001:db8:aaa3::8a2e:3710:7335
For MAC addresses, a dash (-) separator can be used in place of a colon (:).
A dash (-) separator used in place of a colon (:)
*[ex:/configure qos sap-ingress "s" mac-criteria entry 5 match]
A:admin@node-2# dst-mac address aa-BB-cc-DD-eE-Ff
*[ex:/configure qos sap-ingress "s" mac-criteria entry 5 match]
A:admin@node-2# info
dst-mac {
address aa:bb:cc:dd:ee:ff
Flexible input available for MAC addresses using dot (.) notation
*[ex:/configure filter mac-filter "str" entry 33 match]
A:admin@node-2# dst-mac address aaBB.ccDD.eEFf
*[ex:/configure filter mac-filter "str" entry 33 match]
A:admin@node-2# info
dst-mac {
address aa:bb:cc:dd:ee:ff
}
*[ex:/configure filter mac-filter "str" entry 33 match]
A:admin@node-2#
Input translation
The MD-CLI supports the following input translation for UTF-8 character encoding:
curly quotation mark to ASCII quotation mark (")
curly apostrophe to ASCII apostrophe (')
hyphens and dashes, including minus, en dash, em dash, and others to ASCII minus (-)
The input translation allows copy and paste functionality from word processing applications that use UTF-8 curly quotation marks, hyphens, or dashes.
Deleting configuration elements
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:
leafs
containers
lists
leaf-lists
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.
Deleting leafs
The following configuration example deletes three leafs; admin-state and connect-retry return to their default values, and description returns to an unconfigured state.
*[ex:/configure router "Base" bgp]
A:admin@node-2# info
admin-state disable
description "BGP description"
connect-retry 65535
*[ex:/configure router "Base" bgp]
A:admin@node-2# delete admin-state
*[ex:/configure router "Base" bgp]
A:admin@node-2# delete description
*[ex:/configure router "Base" bgp]
A:admin@node-2# delete connect-retry
*[ex:/configure router "Base" bgp]
A:admin@node-2# info detail
admin-state enable
## description
connect-retry 120
keepalive 30
damping false
local-preference 100
loop-detect ignore-loop
---snip---
Deleting containers
To remove a container, the delete command is specified before the container name. The following examples show the deletion of a vprn instance from two different contexts.
Removes the instance from the context configure service vprn
*[ex:/configure service]
A:admin@node-2# info
vprn "vprn1" {
description "VPRN instance 01"
dns {
ipv6-source-address 2001:db8:aaa3::8a2e:3710:7335
}
bgp {
min-route-advertisement 50
}
interface "int1" {
ipv6 {
dhcp6 {
relay {
server ["2001:db8::" "2001:db9::" "2001:dba::" "2001:dc1::"]
}
}
}
}
}
*[ex:/configure service]
A:admin@node-2# delete vprn "vprn1"
[ex:/configure service]
A:admin@node-2# info detail | match vprn
## vprn
Shows the deletion of the instance from the context configure
*[ex:/configure service]
A:admin@node-2# info
vprn "vprn1" {
description "VPRN instance 01"
dns {
ipv6-source-address 2001:db8:aaa3::8a2e:3710:7335
}
bgp {
min-route-advertisement 50
}
interface "int1" {
ipv6 {
dhcp6 {
relay {
server ["2001:db8::" "2001:db9::" "2001:dba::" "2001:dc1::"]
}
}
}
}
}
*[ex:/configure service]
A:admin@node-2# back
*[ex:/configure]
A:admin@node-2# delete service vprn "vprn1"
[ex:/configure]
A:admin@node-2# service
[ex:/configure service]
A:admin@node-2# info detail | match vprn
## vprn
In the preceding examples, the container is returned to an unconfigured state, as indicated by the ##.
Placement of the delete command
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.
*[ex:/configure router "Base" ospf 0]
A:admin@node-2# info
timers {
lsa-generate {
max-lsa-wait 8000
lsa-initial-wait 10
lsa-second-wait 1000
}
spf-wait {
spf-max-wait 2000
spf-initial-wait 50
spf-second-wait 100
}
}
area 0.0.0.0 {
}
delete command placed before the lsa-generate element
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.
*[ex:/configure router "Base" ospf 0]
A:admin@node-2# timers delete lsa-generate
*[ex:/configure router "Base" ospf 0]
A:admin@node-2# info
timers {
spf-wait {
spf-max-wait 2000
spf-initial-wait 50
spf-second-wait 100
}
}
area 0.0.0.0 {
}
delete command placed before the timers element
If the delete command is placed before the timers element, all elements within the timers element are also deleted.
*[ex:/configure router "Base" ospf 0]
A:admin@node-2# info
timers {
lsa-generate {
max-lsa-wait 8000
lsa-initial-wait 10
lsa-second-wait 1000
}
spf-wait {
spf-max-wait 2000
spf-initial-wait 50
spf-second-wait 100
}
}
area 0.0.0.0 {
}
*[ex:/configure router "Base" ospf 0]
A:admin@node-2# delete timers
[ex:/configure router "Base" ospf 0]
A:admin@node-2# info
area 0.0.0.0 {
}
Deleting list entries and lists
To remove a list entry, the delete operation is specified before the list name and the entry to be removed.
Deleting a list entry
*[ex:/configure service]
A:admin@node-2# info | match pw-template
pw-template "pw-1" {
pw-template "pw-3" {
pw-template "pw-5" {
pw-template "pw-8" {
*[ex:/configure service]
A:admin@node-2# delete pw-template ‟pw-3”
*[ex:/configure service]
A:admin@node-2# info | match pw-template
pw-template "pw-1" {
pw-template "pw-5" {
pw-template "pw-8" {
*[ex:/configure service]
A:admin@node-2#
Explicit wildcard (*) deletes all members of a list
*[ex:/configure service]
A:admin@node-2# info | match pw-template
pw-template "pw-1" {
pw-template "pw-5" {
pw-template "pw-8" {
*[ex:/configure service]
A:admin@node-2# delete pw-template *
*[ex:/configure service]
A:admin@node-2# info | match pw-template
*[ex:/configure service]
A:admin@node-2#
If the list is a multi-key list, a combination of specific members and wildcards (*) can be used.
Multi-key list
In the following example, mep is a multikey list, where the keys are md-admin-name, ma-admin-name, and mep-id.
*[ex:/configure service epipe "svc-name" sap 1/1/4:1 eth-cfm]
A:admin@node-2# info
mep md-admin-name "ref1" ma-admin-name "ref2" mep-id 5 {
}
mep md-admin-name "ref1" ma-admin-name "ref3" mep-id 5 {
}
mep md-admin-name "ref6" ma-admin-name "ref3" mep-id 99 {
}
*[ex:/configure service epipe "svc-name" sap 1/1/4:1 eth-cfm]
A:admin@node-2#
Deleting all lists with mep-id of 5
The following delete operation deletes all lists with mep-id of 5, regardless of the md-admin-name or ma-admin-name.
*[ex:/configure service epipe "svc-name" sap 1/1/4:1 eth-cfm]
A:admin@node-2# delete mep md-admin-name * ma-admin-name * mep-id 5
*[ex:/configure service epipe "svc-name" sap 1/1/4:1 eth-cfm]
A:admin@node-2# info
mep md-admin-name "ref6" ma-admin-name "ref3" mep-id 99 {
}
*[ex:/configure service epipe "svc-name" sap 1/1/4:1 eth-cfm]
A:admin@node-2#
Deleting all lists where ma-admin-name is ‟ref3” and mep-id is 5
*[ex:/configure service epipe "svc-name" sap 1/1/4:1 eth-cfm]
A:admin@node-2# info
mep md-admin-name "ref1" ma-admin-name "ref2" mep-id 5 {
}
mep md-admin-name "ref1" ma-admin-name "ref3" mep-id 5 {
}
mep md-admin-name "ref6" ma-admin-name "ref3" mep-id 99 {
}
*[ex:/configure service epipe "svc-name" sap 1/1/4:1 eth-cfm]
A:admin@node-2# delete mep md-admin-name * ma-admin-name ‟ref3” mep-id 5
*[ex:/configure service epipe "svc-name" sap 1/1/4:1 eth-cfm]
A:admin@node-2# info
mep md-admin-name "ref1" ma-admin-name "ref2" mep-id 5 {
}
mep md-admin-name "ref6" ma-admin-name "ref3" mep-id 99 {
}
*[ex:/configure service epipe "svc-name" sap 1/1/4:1 eth-cfm]
A:admin@node-2#
Deleting all lists where md-admin-name is ‟ref1”
*[ex:/configure service epipe "svc-name" sap 1/1/4:1 eth-cfm]
A:admin@node-2# info
mep md-admin-name "ref1" ma-admin-name "ref2" mep-id 5 {
}
mep md-admin-name "ref1" ma-admin-name "ref3" mep-id 5 {
}
mep md-admin-name "ref6" ma-admin-name "ref3" mep-id 99 {
}
*[ex:/configure service epipe "svc-name" sap 1/1/4:1 eth-cfm]
A:admin@node-2# delete mep md-admin-name ‟ref1” ma-admin-name * mep-id *
*[ex:/configure service epipe "svc-name" sap 1/1/4:1 eth-cfm]
A:admin@node-2# info
mep md-admin-name "ref6" ma-admin-name "ref3" mep-id 99 {
}
*[ex:/configure service epipe "svc-name" sap 1/1/4:1 eth-cfm]
A:admin@node-2#
Deleting leaf-list entries and leaf-lists
To remove a leaf-list entry, the delete operation is specified before the leaf-list name and the entry to be removed.
Deleting a leaf-list entry
*[ex:/configure system security user-params local-user user "test" console]
A:admin@node-2# info
member ["profile-a" "profile-b" "profile-x"]
*[ex:/configure system security user-params local-user user "test" console]
A:admin@node-2# delete member ‟profile-a”
*[ex:/configure system security user-params local-user user "test" console]
A:admin@node-2# info
member ["profile-b" "profile-x"]
*[ex:/configure system security user-params local-user user "test" console]
A:admin@node-2#
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.
Deleting multiple leaf-list entries
*[ex:/configure system security user-params local-user user "test" console]
A:admin@node-2# info
member ["profile-a" "profile-b" "profile-f" "profile-x" "profile-c"]
*[ex:/configure system security user-params local-user user "test" console]
A:admin@node-2# delete member [‟profile-c” ‟profile-f”]
*[ex:/configure system security user-params local-user user "test" console]
A:admin@node-2# info
member ["profile-a" "profile-b" "profile-x"]
*[ex:/configure system security user-params local-user user "test" console]
A:admin@node-2#
Deleting all members of a leaf-list using an explicit wildcard (*)
*[ex:/configure system security user-params local-user user "test" console]
A:admin@node-2# info
member ["profile-b" "profile-x"]
*[ex:/configure system security user-params local-user user "test" console]
A:admin@node-2# delete member *
*[ex:/configure system security user-params local-user user "test" console]
A:admin@node-2# info
*[ex:/configure system security user-params local-user user "test" console]
A:admin@node-2#
Optionally using the wildcard enclosed in brackets
*[ex:/configure system security user-params local-user user "test" console]
A:admin@node-2# delete member [*]
Deleting all members of a leaf-list
Deleting all members of a leaf-list sets the list to the unconfigured state (as indicated in the info detail display by the ‟##”).
*[ex:/configure system security user-params local-user user "test" console]
A:admin@node-2# delete member *
*[ex:/configure system security user-params local-user user "test" console]
A:admin@node-2# info detail | match member
## member
*[ex:/configure system security user-params local-user user "test" console]
A:admin@node-2#
Copying configuration elements
Using copy and paste
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.
Configuring identical profiles
The following example shows the output from the info command, displaying the following configuration for the profile of the user ‟guest1”.
*[ex:/configure system security aaa local-profiles profile "guest1"]
A:admin@node-2# info
default-action permit-all
entry 10 {
action deny
match "configure system security"
}
entry 20 {
action deny
match "configure li"
}
entry 30 {
action deny
match "show li"
}
entry 40 {
action deny
match "tools"
}
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.
(ex)[/]
A:admin@node-2# configure system security aaa local-profiles profile guest2
*(ex)[/configure system security aaa local-profiles profile "guest2"]
A:admin@node-2#
Copy the info command output and paste each line into the command line.
*(ex)[/configure system security aaa local-profiles profile "guest2"]
A:admin@node-2# default-action permit-all
*(ex)[/configure system security aaa local-profiles profile "guest2"]
A:admin@node-2# entry 10 {
*(ex)[/configure system security aaa local-profiles profile "guest2" entry 10]
A:admin@node-2# action deny
*(ex)[/configure system security aaa local-profiles profile "guest2" entry 10]
A:admin@node-2# match "configure system security"
*(ex)[/configure system security aaa local-profiles profile "guest2" entry 10]
A:admin@node-2# }
*(ex)[/configure system security aaa local-profiles profile "guest2"]
A:admin@node-2# entry 20 {
*(ex)[/configure system security aaa local-profiles profile "guest2" entry 20]
A:admin@node-2# action deny
*(ex)[/configure system security aaa local-profiles profile "guest2" entry 20]
A:admin@node-2# match "configure li"
*(ex)[/configure system security aaa local-profiles profile "guest2" entry 20]
A:admin@node-2# }
*(ex)[/configure system security aaa local-profiles profile "guest2"]
A:admin@node-2# entry 30 {
*(ex)[/configure system security aaa local-profiles profile "guest2" entry 30]
A:admin@node-2# action deny
*(ex)[/configure system security aaa local-profiles profile "guest2" entry 30]
A:admin@node-2# match "show li"
*(ex)[/configure system security aaa local-profiles profile "guest2" entry 30]
A:admin@node-2# }
*(ex)[/configure system security aaa local-profiles profile "guest2"]
A:admin@node-2# entry 40 {
*(ex)[/configure system security aaa local-profiles profile "guest2" entry 40]
A:admin@node-2# action deny
*(ex)[/configure system security aaa local-profiles profile "guest2" entry 40]
A:admin@node-2# match "tools"
*(ex)[/configure system security aaa local-profiles profile "guest2" entry 40]
A:admin@node-2# }
*(ex)[/configure system security aaa local-profiles profile "guest2"]
A:admin@node-2#
The info command displays the configuration changes for profile ‟guest2”, which are identical to the configuration for profile ‟guest1”.
*(ex)[/configure system security aaa local-profiles profile "guest2"]
A:admin@node-2# info
default-action permit-all
entry 10 {
action deny
match "configure system security"
}
entry 20 {
action deny
match "configure li"
}
entry 30 {
action deny
match "show li"
}
entry 40 {
action deny
match "tools"
}
*(ex)[/configure system security aaa local-profiles profile "guest2"]
A:admin@node-2#
Similarly, the info flat command output can be copied and pasted for the user profile for ‟guest3”.
*(ex)[/configure system security aaa local-profiles profile "guest2"]
A:admin@node-2# info flat
default-action permit-all
entry 10 action deny
entry 10 match "configure system security"
entry 20 action deny
entry 20 match "configure li"
entry 30 action deny
entry 30 match "show li"
entry 40 action deny
entry 40 match "tools"
*(ex)[/configure system security aaa local-profiles profile "guest2"]
A:admin@node-2#
*(ex)[/configure system security aaa local-profiles profile "guest1"]
A:admin@node-2# /configure system security aaa local-profiles profile "guest3"
*(ex)[/configure system security aaa local-profiles profile "guest3"]
A:admin@node-2# default-action permit-all
*(ex)[/configure system security aaa local-profiles profile "guest3"]
A:admin@node-2# entry 10 action deny
*(ex)[/configure system security aaa local-profiles profile "guest3"]
A:admin@node-2# entry 10 match "configure system security"
*(ex)[/configure system security aaa local-profiles profile "guest3"]
A:admin@node-2# entry 20 action deny
*(ex)[/configure system security aaa local-profiles profile "guest3"]
A:admin@node-2# entry 20 match "configure li"
*(ex)[/configure system security aaa local-profiles profile "guest3"]
A:admin@node-2# entry 30 action deny
*(ex)[/configure system security aaa local-profiles profile "guest3"]
A:admin@node-2# entry 30 match "show li"
*(ex)[/configure system security aaa local-profiles profile "guest3"]
A:admin@node-2# entry 40 action deny
*(ex)[/configure system security aaa local-profiles profile "guest3"]
A:admin@node-2# entry 40 match "tools"
*(ex)[/configure system security aaa local-profiles profile "guest3"]
A:admin@node-2# info
default-action permit-all
entry 10 {
action deny
match "configure system security"
}
entry 20 {
action deny
match "configure li"
}
entry 30 {
action deny
match "show li"
}
entry 40 {
action deny
match "tools"
}
*(ex)[/configure system security aaa local-profiles profile "guest3"]
A:admin@node-2#
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.
Deleting and re-adding the ‟guest1” user profile
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.
*(ex)[/configure system security aaa local-profiles profile "guest1"]
A:admin@node-2# info full-context
/configure system security aaa local-profiles profile "guest1" default-action permit-all
/configure system security aaa local-profiles profile "guest1" entry 10 match "configure system security"
/configure system security aaa local-profiles profile "guest1" entry 10 action deny
/configure system security aaa local-profiles profile "guest1" entry 20 match "configure li"
/configure system security aaa local-profiles profile "guest1" entry 30 match "show li"
/configure system security aaa local-profiles profile "guest1" entry 30 action deny
/configure system security aaa local-profiles profile "guest1" entry 40 match "tools"
/configure system security aaa local-profiles profile "guest1" entry 40 action deny
The ‟guest1” user profile is deleted, and the info full-context command after the delete shows no matches for profile ‟guest1”:
*(ex)[/configure system security aaa local-profiles profile "guest1"]
A:admin@node-2# back
*(ex)[/configure system security aaa local-profiles]
A:admin@node-2# delete profile ‟guest1”
*(ex)[/configure system security aaa local-profiles]
A:admin@node-2# info full-context | match guest1
*(ex)[/configure system security aaa local-profiles]
A:admin@node-2#
In the next step, the original full-context output for ‟guest1” is copied and pasted. Because the output contains the full configuration path, the statements can be pasted from any configuration context.
*(ex)[/configure]
A:admin@node-2# /configure system security aaa local-profiles profile "guest1" entry 10 match "configure system security"
*(ex)[/configure system security aaa local-profiles profile "guest1"]
A:admin@node-2# /configure system security aaa local-profiles profile "guest1" entry 10 action deny
*(ex)[/configure system security aaa local-profiles profile "guest1"]
A:admin@node-2# /configure system security aaa local-profiles profile "guest1" entry 20 match "configure li"
*(ex)[/configure system security aaa local-profiles profile "guest1"]
A:admin@node-2# /configure system security aaa local-profiles profile "guest1" entry 30 match "show li"
*(ex)[/configure system security aaa local-profiles profile "guest1"]
A:admin@node-2# /configure system security aaa local-profiles profile "guest1" entry 30 action deny
*(ex)[/configure system security aaa local-profiles profile "guest1"]
A:admin@node-2# /configure system security aaa local-profiles profile "guest1" entry 40 match "tools"
*(ex)[/configure system security aaa local-profiles profile "guest1"]
A:admin@node-2# /configure system security aaa local-profiles profile "guest1" entry 40 action deny
*(ex)[/configure system security aaa local-profiles profile "guest1"]
A:admin@node-2# info
default-action permit-all
entry 10 {
action deny
match "configure system security"
}
entry 20 {
action deny
match "configure li"
}
entry 30 {
action deny
match "show li"
}
entry 40 {
action deny
match "tools"
}
*(ex)[/configure system security aaa local-profiles profile "guest1"]
A:admin@node-2#
The displayed output from the compare command can also be used to copy and paste statements in the MD-CLI. See Viewing the uncommitted configuration changes for information about using the compare command.
Using the copy command
The copy command copies elements in the candidate configuration. The source and destination elements must be the same type (such as containers, lists, or leaf elements) and must be at the same configuration level.
A copied element inherits all characteristics from the source element. If a container is copied to another container element, all child elements of the container are also copied.
Using the copy command
The following example shows the configuration of a BGP peer (neighbor 192.0.2.2). The copy command is used to deploy a new peering session (neighbor 192.0.2.200).
[ex:/configure router "Base" bgp]
A:admin@node-2# info flat neighbor "192.0.2.2"
group "mesh"
keepalive 10
local-preference 100
local-as as-number 65535
local-as private true
add-paths ipv4 send multipaths
add-paths ipv4 receive true
add-paths ipv6 send multipaths
add-paths ipv6 receive true
import policy ["ALLOW-ALL"]
export policy ["ALLOW-ALL"]
[ex:/configure router "Base" bgp]
A:admin@node-2# copy neighbor "192.0.2.2" to neighbor 192.0.2.200
*[ex:/configure router "Base" bgp]
A:admin@node-2# compare flat
+ neighbor "192.0.2.200" group "mesh"
+ neighbor "192.0.2.200" keepalive 10
+ neighbor "192.0.2.200" local-preference 100
+ neighbor "192.0.2.200" local-as as-number 65535
+ neighbor "192.0.2.200" local-as private true
+ neighbor "192.0.2.200" add-paths ipv4 send multipaths
+ neighbor "192.0.2.200" add-paths ipv4 receive true
+ neighbor "192.0.2.200" add-paths ipv6 send multipaths
+ neighbor "192.0.2.200" add-paths ipv6 receive true
+ neighbor "192.0.2.200" import policy ["ALLOW-ALL"]
+ neighbor "192.0.2.200" export policy ["ALLOW-ALL"]
configure policy-options policy-statement entry to
configure policy-options policy-statement named-entry to
configure oam-pm session mpls lsp rsvp-auto to
configure router mpls lsp to
configure subscriber-management local-user-db ipoe host host-identification encap-tag-range to
configure subscriber-management local-user-db ppp host host-identification encap-tag-range to
Copying configuration from one entry to another without the destination parameter
The following example copies entry "5" data to entry "10" after navigating into the context for entry "10".
*[ex:/configure policy-options policy-statement "s"]
A:admin@node-2# info
entry 5 {
to {
level 2
}
}
entry 10 {
}
*[ex:/configure policy-options policy-statement "s"]
A:admin@node-2# entry 10
*[ex:/configure policy-options policy-statement "s" entry 10]
A:admin@node-2# copy /configure policy-options policy-statement s entry 5
*[ex:/configure policy-options policy-statement "s" entry 10]
A:admin@node-2# info
to {
level 2
}
Using the rename command
The rename command renames a list key in the candidate configuration. Use the rename command instead of using the copy and delete commands for a list with a specific key.
When the rename command is used to rename a key for a user-ordered list, the system maintains the list order.
The rename command may be service-impacting, as the operations involve add and delete operations.
- Renaming a list key does not change references to the renamed key at other locations in the configuration. Changing the name of a list key without altering all references causes the MD-CLI candidate configuration to fail validation (when the validate or commit command is issued).
- Renaming a user-ordered list maintains the list order.
- pwc may also be used in the source to specify the present working context instead of a list key.
The following example shows the BGP neighbor 192.0.2.2 renamed to neighbor 192.0.2.200. The compare command displays the actions performed when the configuration is committed.
[ex:/configure router "Base" bgp]
A:admin@node-2# info flat neighbor "192.0.2.2"
group "mesh"
keepalive 10
local-preference 100
local-as as-number 65535
local-as private true
add-paths ipv4 send multipaths
add-paths ipv4 receive true
add-paths ipv6 send multipaths
add-paths ipv6 receive true
import policy ["ALLOW-ALL"]
export policy ["ALLOW-ALL"]
[ex:/configure router "Base" bgp]
A:admin@node-2# rename neighbor "192.0.2.2" to neighbor 192.0.2.200
*[ex:/configure router "Base" bgp]
A:admin@node-2# compare flat
- neighbor "192.0.2.2" group "mesh"
- neighbor "192.0.2.2" keepalive 10
- neighbor "192.0.2.2" local-preference 100
- neighbor "192.0.2.2" local-as as-number 65535
- neighbor "192.0.2.2" local-as private true
- neighbor "192.0.2.2" add-paths ipv4 send multipaths
- neighbor "192.0.2.2" add-paths ipv4 receive true
- neighbor "192.0.2.2" add-paths ipv6 send multipaths
- neighbor "192.0.2.2" add-paths ipv6 receive true
- neighbor "192.0.2.2" import policy ["ALLOW-ALL"]
- neighbor "192.0.2.2" export policy ["ALLOW-ALL"]
+ neighbor "192.0.2.200" group "mesh"
+ neighbor "192.0.2.200" keepalive 10
+ neighbor "192.0.2.200" local-preference 100
+ neighbor "192.0.2.200" local-as as-number 65535
+ neighbor "192.0.2.200" local-as private true
+ neighbor "192.0.2.200" add-paths ipv4 send multipaths
+ neighbor "192.0.2.200" add-paths ipv4 receive true
+ neighbor "192.0.2.200" add-paths ipv6 send multipaths
+ neighbor "192.0.2.200" add-paths ipv6 receive true
+ neighbor "192.0.2.200" import policy ["ALLOW-ALL"]
+ neighbor "192.0.2.200" export policy ["ALLOW-ALL"]
Replacing configuration elements
Use the following configuration mode command to match a pattern in candidate configuration values and replace matches with the specified pattern.
replace string with string
The default pattern match and replacement are strings. If the pattern includes a space, the pattern must be delimited by quotation marks ("). Regular expressions are delimited by apostrophes ('). For more information, see Using regular expressions.
If the replace operation introduces a syntax error, the operation is cancelled and replacements are discarded. Use the following option to specify that the replace operation continues even if there are syntax errors.
continue-on-error
Use the depth option to configure the depth of the replace operation from the present working context.
depth
For example, if the present working context is configure, the depths of the commands are:
- configure router = 1
- configure router description = 2
- configure router interface description = 3
Use the following option to ignore case in the pattern match.
ignore-case
The replace command accepts a path parameter on the input line to replace elements starting from the specified path. If a path is not specified, the command replaces elements from the present working context.
Global string replacement
In the following example, the name of route policy “RP EXPORT PEERING 64496” is replaced with “RP EXPORT PEERING 65536” globally in all contexts because the peer AS was changed from 64496 to 65536 (the peer AS change itself is not displayed for clarity).
[ex:/configure]
A:admin@node-2# replace “RP EXPORT PEERING 64496” with “RP EXPORT PEERING 65536”
INFO: CLI #2111: Replace - 3 replacements on 3 lines
*[ex:/configure]
A:admin@node-2# compare summary
policy-options {
- policy-statement “RP_EXPORT_PEERING 64496” { ... }
+ policy-statement “RP_EXPORT_PEERING 65536” {
---snip---
+ }
}
router “Base” {
bgp {
neighbor “10.81.195.10” {
export {
~ policy [“RP EXPORT PEERING 65536”]
}
}
neighbor "2001:db8::31d7:0:1" {
export {
~ policy [“RP EXPORT PEERING 65536”]
}
}
}
}
Number replacement
In the following example, the number 10 is replaced with 172 to change an IP address. The continue-on-error command is specified because the replace operation introduces a syntax error.
[ex:/configure router "Base" interface "system"]
A:admin@node-2# replace 10 with 172
MINOR: MGMT_CORE #2301: Invalid element value - 'ipv6-address' expected ipv6 address '(<x:x:x:x:x:x:x:x>|<x:x:x:x:x:x:d.d.d.d>)'
MINOR: MGMT_CORE #2510: Replace error - configure router "Base" interface "system" ipv6 address 2001:db8::94172:0:1
INFO: CLI #2110: Replace canceled
[ex:/configure router "Base" interface "system"]
A:admin@node-2# replace 10 with 172 continue-on-error
MINOR: MGMT_CORE #2301: Invalid element value - 'ipv6-address' expected ipv6 address '(<x:x:x:x:x:x:x:x>|<x:x:x:x:x:x:d.d.d.d>)'
MINOR: MGMT_CORE #2510: Replace error - configure router "Base" interface "system" ipv6 address 2001:db8::94172:0:1
INFO: CLI #2111: Replace - 1 replacement on 1 line
*[ex:/configure router "Base" interface "system"]
A:admin@node-2# compare
ipv4 {
primary {
- address 10.16.193.50
+ address 172.16.193.50
}
}
Regular expression capture groups and backreferences can also be used in replace command patterns using special characters:
- Capture group subexpressions in the match pattern that are enclosed in parentheses specify a group to match, which is stored as a numbered variable.
- Backreferences are specified in the replacement pattern, according to the
following rules:
- The \n character sequence inserts the group matched in the subexpression, where n is a digit from 1 to 9.
- An ampersand (&) character inserts the entire matched pattern.
- The backslash (\) and ampersand (&) characters must be escaped with a backslash (\) to be treated as a literal character.
IP address renumbering with capture group and backreference
The following example replaces the prefix 172.16.100 with 10.92.55 while keeping the last number 33 to renumber the IP address.
[ex:/configure router "Base" interface "My Interface"]
A:admin@node-2# replace '172\.16\.100\.(.*)' with '10.92.55.\1'
INFO: CLI #2111: Replace - 1 replacement on 1 line
*[ex:/configure router "Base" interface "My Interface"]
A:admin@node-2# compare
ipv4 {
primary {
- address 172.16.100.33
+ address 10.92.55.33
}
}
String insertion with match and backreference
The following example shows the use of the ampersand (&) character to insert the matched pattern to change the description of the interface without reentering it.
[ex:/configure router "Base" interface "My Interface"]
A:admin@node-2# replace '.*' with 'OLD &' description
INFO: CLI #2111: Replace - 1 replacement on 1 line
*[ex:/configure router "Base" interface "My Interface"]
A:admin@node-2# compare
- description "Important Interface"
+ description "OLD Important Interface"
The following usage guidelines apply to the replace command:
- The replace command may be service impacting if configuration is added or deleted.
- Nokia recommends executing the replace command on a candidate configuration that has no existing changes, so that only the replacements are displayed using the compare command.
- Multiple occurrences of the matched pattern on a single configuration line are replaced.
- Press Ctrl+C to cancel the replace operation and discard all replacements.
Commenting configuration elements
The user can add, modify, or delete comments to configuration elements using the annotate command. These comments are displayed directly before the element in the outputs of the info, compare, and admin save configuration commands.
Comments are supported in model-driven configuration mode in the configure, debug and li regions. They are not supported in the bof region.
The following usage guidelines apply to the annotate command:
- The input string is the mandatory configuration comment enclosed in quotation marks (").
- Newline separators (\n) may be entered in the comment string to display multiple comment lines.
- Comments are deleted if an empty string "" is entered. Partial deletion of a multiline comment is not supported.
- The input path is mandatory and is an absolute path (starting with /configure) or a path relative to the present working context. The key to a list entry must be specified in the path (or pwc to specify the present working context instead of a path).
- To be annotated, a command element must have an explicitly configured value.
Using the annotate command
[ex:/configure]
A:admin@node-2# router bgp connect-retry 42
*[ex:/configure]
A:admin@node-2# annotate "Line one for connect retry timer \n Line two indented" router bgp connect-retry
*[ex:/configure]
A:admin@node-2# compare /
configure {
router "Base" {
bgp {
+ # comment: Line one for connect retry timer
+ # comment: Line two indented
+ connect-retry 42
}
}
}
*[ex:/configure]
A:admin@node-2# annotate "" /configure router bgp connect-retry
*[ex:/configure]
A:admin@node-2# compare
router "Base" {
bgp {
+ connect-retry 42
}
}
Comments can also be entered using the "# comment: " notation and the following usage guidelines apply:
- To enter one or more comment lines, start the line with "# comment: ". The blank space after the hash (#) and the colon (:) is mandatory; otherwise, the comment is ignored.
- Optionally, to add multiple comment lines, use one "# comment: " with newline separators (\n).
- To delete comments, enter an empty comment "# comment: ".
- Partial deletion of a multiline comment is not supported. Entering "# comment: " deletes the entire comment.
A comment entry is ignored if a non-configuration element (such as a configuration or operational command) is entered following the comment.
Comments are not displayed in the info command output if any of the following options is used, even if they are used with other supported options:
- converted (and model)
- intended
Copying and pasting a configuration comment from an info command output maintains the association between the comment and element, with the assumption that the comment applies to the configuration element entered on the immediate next line.
Copying and pasting a configuration comment
[ex:/configure router "Base" bgp]
A:admin@node-2# # comment: Line one for connect-retry
[ex:/configure router "Base" bgp]
A:admin@node-2# # comment: Line two for connect-retry
[ex:/configure router "Base" bgp]
A:admin@node-2# connect-retry 98
*[ex:/configure router "Base" bgp]
A:admin@node-2# # comment: Separate this comment \nfor deterministic-med \n note the blank space
*[ex:/configure router "Base" bgp]
A:admin@node-2# best-path-selection deterministic-med false
*[ex:/configure router "Base" bgp]
A:admin@node-2# info
# comment: Line one for connect-retry
# comment: Line two for connect-retry
connect-retry 98
authentication-key "qvzYGrrZtXg2eqQbniwULbem+PvCH+iycONUiGK7/g== hash2"
ebgp-default-reject-policy {
import false
export false
}
best-path-selection {
# comment: Separate this comment
# comment: for deterministic-med
# comment: note the blank space
deterministic-med false
always-compare-med {
med-value on
strict-as false
}
---snip---
[/]
A:admin@node-2# admin show configuration /configure router bgp
# comment: Line one for connect-retry
# comment: Line two for connect-retry
connect-retry 98
authentication-key "qvzYGrrZtXg2eqQbniwULbem+PvCH+iycONUiGK7/g== hash2"
ebgp-default-reject-policy {
import false
export false
}
best-path-selection {
# comment: Separate this comment
# comment: for deterministic-med
# comment: note the blank space
deterministic-med false
always-compare-med {
med-value on
strict-as false
}
}
---snip---
Committing configuration changes
Viewing the uncommitted configuration changes
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.
The following characters are used at the beginning of the output lines, to indicate the status of the element in the configuration:
-
- (minus)
indicates the element is only in the first (from) configuration, displayed first
-
+ (plus)
indicates the element is only in the second (to) configuration, displayed second
-
(space)
indicates the element is unchanged
-
~ (tilde)
new value of the element that changed (only used in the summary option)
-
{...}
indicates deleted elements compressed to its highest container (only used in the summary option)
Using + (plus)
*[ex:/configure]
A:admin@node-2# compare
log {
+ accounting-policy 5 {
+ description "For SIO statistics"
+ collection-interval 69
+ include-system-info true
+ record service-ingress-octets
+ }
+ accounting-policy 8 {
+ }
}
Executing the compare to running command
Executing compare to running, without specifying the from option is equivalent to compare from running to running, which shows no differences.
*[ex:/configure]
A:admin@node-2# compare to running
*[ex:/configure]
A:admin@node-2# compare to candidate
log {
+ accounting-policy 5 {
+ description "For SIO statistics"
+ collection-interval 69
+ include-system-info true
+ record service-ingress-octets
+ }
+ accounting-policy 8 {
+ }
}
*[ex:/configure]
A:admin@node-2# compare from running to candidate
log {
+ accounting-policy 5 {
+ description "For SIO statistics"
+ collection-interval 69
+ include-system-info true
+ record service-ingress-octets
+ }
+ accounting-policy 8 {
+ }
}
Output using the flat and full-context options
*[ex:/configure]
A:admin@node-2# compare flat
+ log accounting-policy 5 description "For SIO statistics"
+ log accounting-policy 5 collection-interval 69
+ log accounting-policy 5 include-system-info true
+ log accounting-policy 5 record service-ingress-octets
+ log { accounting-policy 8 }
*[ex:/configure]
A:admin@node-2# compare full-context
+ /configure log accounting-policy 5 description "For SIO statistics"
+ /configure log accounting-policy 5 collection-interval 69
+ /configure log accounting-policy 5 include-system-info true
+ /configure log accounting-policy 5 record service-ingress-octets
+ /configure log { accounting-policy 8 }
Difference between compare and compare summary commands
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.
*[ex:/configure]
A:admin@node-2# compare
router "Base" {
interface "system" {
ipv4 {
primary {
- address 10.1.1.1
+ address 10.243.5.96
}
}
}
}
*[ex:/configure]
A:admin@node-2# compare summary
router "Base" {
interface "system" {
ipv4 {
primary {
~ address 10.243.5.96
}
}
}
}
Required configuration changes using the compare summary command
*[ex:/configure policy-options policy-statement "example-policy-statement"]
A:admin@node-2# compare summary
~ insert named-entry "two" after "one"
~ insert named-entry "three" after "two"
+ named-entry "two" {
+ description "Example addition"
+ action {
+ action-type accept
+ }
+ }
summary netconf-rpc keywords with the compare command
The following example shows the use of the summary netconf-rpc keywords with the compare command to generate an RPC that is used in a network automation environment to achieve the required configuration changes.
*[ex:/configure policy-options policy-statement "example-policy-statement"]
A:admin@node-2# compare netconf-rpc summary
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:yang="urn:ietf:params:xml:ns:yang:1">
<edit-config>
<target><candidate/></target>
<config>
<configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf" xmlns:nokia-attr="urn:nokia.com:sros:ns:yang:sr:attributes">
<policy-options>
<policy-statement>
<name>example-policy-statement</name>
<named-entry operation="merge" yang:insert="after" yang:key="[entry-name='one']">
<entry-name>two</entry-name>
</named-entry>
<named-entry operation="merge" yang:insert="after" yang:key="[entry-name='two']">
<entry-name>three</entry-name>
</named-entry>
<named-entry>
<entry-name>two</entry-name>
<description>Example addition</description>
<action>
<action-type>accept</action-type>
</action>
</named-entry>
</policy-statement>
</policy-options>
</configure>
</config>
</edit-config>
</rpc>
The use of the summary netconf-rpc options with the compare command provides an edit-config NETCONF RPC back to the YANG modeled root of the tree. With third-party YANG models, such as OpenConfig, the output is displayed when the compare summary netconf-rpc command is executed from within the /configure openconfig branch (or sub-branches) or from the absolute root (/). That is, third-party models are not shown when the command is executed with the /configure path.
Using the summary netconf-rpc option
*[ex:/configure]
A:admin@node-2# compare summary
system {
~ name "newtest"
}
+ openconfig {
+ lldp {
+ config {
+ hello-timer 99
+ }
+ }
+ }
*[ex:/configure]
A:admin@node-2# compare summary netconf-rpc
<rpc message-id="3" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:yang="urn:ietf:params:xml:ns:yang:1">
<edit-config>
<target><candidate/></target>
<config>
<configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf" xmlns:nokia-attr="urn:nokia.com:sros:ns:yang:sr:attributes">
<system>
<name>newtest</name>
</system>
</configure>
</config>
</edit-config>
</rpc>
*[ex:/configure]
A:admin@node-2# compare summary netconf-rpc /configure
<rpc message-id="4" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:yang="urn:ietf:params:xml:ns:yang:1">
<edit-config>
<target><candidate/></target>
<config>
<configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf" xmlns:nokia-attr="urn:nokia.com:sros:ns:yang:sr:attributes">
<system>
<name>newtest</name>
</system>
</configure>
</config>
</edit-config>
</rpc>
*[ex:/configure]
A:admin@node-2# compare summary netconf-rpc /
<rpc message-id="5" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:yang="urn:ietf:params:xml:ns:yang:1">
<edit-config>
<target><candidate/></target>
<config>
<configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf" xmlns:nokia-attr="urn:nokia.com:sros:ns:yang:sr:attributes">
<system>
<name>newtest</name>
</system>
</configure>
<lldp xmlns="http://openconfig.net/yang/lldp">
<config>
<hello-timer>99</hello-timer>
</config>
</lldp>
</config>
</edit-config>
</rpc>
*[ex:/configure openconfig]
A:admin@node-2# compare summary netconf-rpc
<rpc message-id="6" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:yang="urn:ietf:params:xml:ns:yang:1">
<edit-config>
<target><candidate/></target>
<config>
<lldp xmlns="http://openconfig.net/yang/lldp">
<config>
<hello-timer>99</hello-timer>
</config>
</lldp>
</config>
</edit-config>
</rpc>
Using the compare outputs to copy and paste
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 output from the compare summary netconf-rpc command cannot be entered into the MD-CLI using copy and paste.
- The output from UNIX diff of configuration commands can be entered into the MD-CLI using copy and paste when displayed with diff --unchanged-line-format="" --old-line-format='-%L' --new-line-format='+%L' FILE1 FILE2.
Output for the compare command
*[ex:/configure router "Base" ospf 0 timers]
A:admin@node-2# compare
+ lsa-generate {
+ max-lsa-wait 500000
+ lsa-initial-wait 100000
+ lsa-second-wait 200000
+ }
+ spf-wait {
+ spf-max-wait 120000
+ spf-initial-wait 50000
+ spf-second-wait 60000
+ }
compare command displays with a preceding minus
The compare command, using the candidate configuration as the reference, displays the same configuration statements with a preceding minus (-). These statements are used in a subsequent copy and paste function to delete some of the configuration. The minus (-) at the beginning of the configuration statement takes the place of the delete keyword.
*[ex:/configure router "Base" ospf 0 timers]
A:admin@node-2# compare from candidate to running full-context
- /configure router "Base" ospf 0 timers lsa-generate max-lsa-wait 500000
- /configure router "Base" ospf 0 timers lsa-generate lsa-initial-wait 100000
- /configure router "Base" ospf 0 timers lsa-generate lsa-second-wait 200000
- /configure router "Base" ospf 0 timers spf-wait spf-max-wait 120000
- /configure router "Base" ospf 0 timers spf-wait spf-initial-wait 50000
- /configure router "Base" ospf 0 timers spf-wait spf-second-wait 60000
*[ex:/configure router "Base" ospf 0 timers]
A:admin@node-2# validate
*[ex:/configure router "Base" ospf 0 timers]
A:admin@node-2# commit
lsa-generate commands are deleted
In the next step, the lsa-generate commands are deleted, using a copy and paste of the first three configuration statements:
[ex:/configure]
A:admin@node-2# - /configure router "Base" ospf 0 timers lsa-generate max-lsa-wait 500000
*[ex:/configure]
A:admin@node-2# - /configure router "Base" ospf 0 timers lsa-generate lsa-initial-wait 100000
*[ex:/configure]
A:admin@node-2# - /configure router "Base" ospf 0 timers lsa-generate lsa-second-wait 200000
Deleted lsa-generate parameters are compressed
The compare summary command shows that the deleted lsa-generate parameters are compressed to its highest container, shown with an ellipsis in braces ({}).
*[ex:/configure]
A:admin@node-2# compare summary
router "Base" {
ospf 0 {
timers {
- lsa-generate { ... }
}
}
}
compare summary command shows the timers container as highest deleted container
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.
*[ex:/configure router "Base" ospf 0]
A:admin@node-2# delete timers
*[ex:configure router "Base" ospf 0]
A:admin@node-2# compare
- timers {
- lsa-generate {
- max-lsa-wait 500000
- lsa-initial-wait 100000
- lsa-second-wait 200000
- }
- spf-wait {
- spf-max-wait 120000
- spf-initial-wait 50000
- spf-second-wait 60000
- }
- }
*[ex:/configure router "Base" ospf 0]
A:admin@node-2# compare summary
- timers { ... }
*[ex:/configure router "Base" ospf 0]
A:admin@node-2#
Discarding configuration changes
The discard command in configuration mode cancels 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 (private, exclusive, or global configuration mode).
discard operation error message
An error message is displayed when the discard operation is attempted from read-only configuration mode.
*(ro)[/configure]
A:admin@node-2# compare
log {
+ accounting-policy 5 {
+ description "For SIO statistics"
+ collection-interval 69
+ include-system-info true
+ record service-ingress-octets
+ }
+ accounting-policy 8 {
+ }
}
*(ro)[/configure]
A:admin@node-2# discard
MINOR: CLI #2069: Operation not allowed - currently in read-only mode
Uncommitted changes from a global configuration session are kept in the candidate configuration when leaving configuration mode. Uncommitted changes from an exclusive or private configuration session are discarded when leaving configuration mode and a confirmation message is displayed:
Behavior of uncommitted changes
*(ex)[/]
A:admin@node-2# quit-config
INFO: CLI #2063: Uncommitted changes are present in the candidate configuration.
Exiting exclusive configuration mode will discard those changes.
Discard uncommitted changes? [y,n] y
WARNING: CLI #2062: Exiting exclusive configuration mode - uncommitted changes are discarded
INFO: CLI #2064: Exiting exclusive configuration mode
The discard command accepts a path parameter on the input line to discard candidate changes starting from the specified path. If a path is not specified, the command discards candidate changes from the present working context.
Discarding candidate changes by specifying the absolute path
In the following example, from the configure system context, the configure router ‟Base” bgp candidate changes can be discarded by specifying the absolute path.
*[ex:/configure system]
A:admin@node-2# compare /configure
log {
+ log-id 55 {
+ }
}
+ router "Base" {
+ bgp {
+ group "group-1" {
+ admin-state enable
+ connect-retry 999
+ }
+ }
+ }
system {
- name "node-2"
+ name "test-name"
}
*[ex:/configure system]
A:admin@node-2# discard /configure router "Base" bgp
*[ex:/configure system]
A:admin@node-2# compare /configure
log {
+ log-id 55 {
+ }
}
system {
- name "node-2"
+ name "test-name"
}
Issuing the discard command without a path parameter removes candidate changes
From the configure system context, issuing the discard command without a path parameter removes candidate changes starting from the configure system context (the present working context).
*[ex:/configure system]
A:admin@node-2# compare /configure
log {
+ log-id 55 {
+ }
}
system {
- name "node-2"
+ name "test-name"
}
*[ex:/configure system]
A:admin@node-2# discard
*[ex:/configure system]
A:admin@node-2# compare /configure
log {
+ log-id 55 {
+ }
}
Changes made by a session that obtained an explicit lock can be discarded 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.
Validating the candidate configuration
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.
*(ro)[/]
A:admin@node-2# compare
log {
+ accounting-policy 7 {
+ description "seven"
+ collection-interval 77
+ }
}
*(ro)[/]
A:admin@node-2# validate
*(ro)[/]
*(ex)[/]
A:admin@node-2# compare
+ eth-cfm {
+ domain "mdn" {
+ association "man" {
+ ccm-interval 10ms
+ }
+ }
+ }
*(ex)[/]
A:admin@node-2# validate
MINOR: MGMT_CORE #236: configure eth-cfm domain "mdn" level - Missing mandatory fields
MINOR: ETH_CFM #12: configure eth-cfm domain "mdn" format - Inconsistent Value error - One of dns, mac, name or format must be provided
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.
Updating the candidate configuration
As described in Multiple simultaneous candidate configurations, a candidate configuration uses two datastores:
-
a baseline datastore that contains a snapshot copy of the running configuration at a specific time
-
a candidate datastore that contains changes relative to its associated baseline datastore
For a private candidate configuration, access by MD-CLI sessions in private configuration mode, a snapshot of the running configuration is copied in the private baseline datastore:
-
when a private candidate configuration is instantiated, when a user enters the private configuration mode
-
when a manual update is performed
-
after a commit, when no merge conflicts are detected during the automatic update and the updated candidate configuration is valid
For the global candidate configuration, accessed by MD-CLI sessions in global and exclusive configuration mode, a tracking mechanism exists.
-
The baseline datastore tracks the running datastore, that is, changes in the running datastore are automatically copied in the baseline datastore:
-
after a router reboot
-
after a successful commit
-
after a discard with an up-to-date global baseline
-
-
Tracking stops and a snapshot of the running datastore is copied in the global baseline datastore when the global candidate is touched (for example, a configuration element is added, deleted, or modified). A new snapshot of the running datastore is copied in the global baseline datastore when a manual update is performed.
With two simultaneous active configuration sessions that access different candidate configurations, a commit from one configuration session changes the running configuration and causes the candidate configuration of the other session to be out of date and must be updated.
To update a candidate configuration, the following tasks are performed:
-
A new snapshot of the running configuration is copied in the baseline datastore.
-
The candidate configuration changes are merged in the new baseline:
-
The changes in the candidate datastore are applied to the new baseline datastore.
-
Merge conflicts are detected and resolved. A merge conflict occurs when a configuration element is added, deleted, or modified in the candidate configuration and the same configuration element was also added, deleted, or modified in the running configuration after the baseline snapshot was taken.
-
The resulting changes are stored in the candidate datastore as new changes relative to the updated baseline.
-
An update can be performed manually with the update command. The update must be executed at the configuration root (/configure). Merge conflicts are reported and resolved according to the conflict resolution rules. The update command does not provide output when no conflicts are detected.
Merge conflict reported in an update
+ /configure router "Base" interface "int-1" ipv4 primary address 10.2.3.4
## address - exists with different value: address 10.1.2.3 - change updated: replace existing value
The first line lists the candidate configuration change that caused the merge conflict, in this case, adding an interface IPv4 address.
The second line describes the merge conflict and starts with a double hash (##) followed by the description:
-
A merge conflict is detected for the configuration element address.
-
The address already exists in the running configuration, but has a different value.
-
The candidate configuration change as shown on the first line is updated; instead of adding an interface address, the interface address is replaced.
An update is automatically started when the candidate configuration is committed. The commit is canceled when merge conflicts are detected to give the administrator the opportunity to resolve the conflicts before committing again. The update, in this case, is not executed, the candidate configuration is unchanged, and the baseline datastore is not updated.
The update check command performs a dry-run update of the candidate configuration. Merge conflicts are reported the same way as for the update command, but the update is not executed. The update check command must be executed at the configuration root (/configure) or it can be executed in any configure branch descendant as update check /configure.
Example update scenario with merge conflicts
The private candidate configuration of user-1 is out of date. The running configuration has interface backbone-1 configured. The private baseline datastore does not have the interface configured. The interface backbone-1 configured by user-1 has a different address in its candidate configuration.
Update scenario with merge conflicts
!*[pr:/configure router "Base"]
A:user-1@node-2# info running
interface "backbone-1" {
ipv4 {
primary {
address 192.168.2.2
prefix-length 24
}
}
}
!*[pr:/configure router "Base"]
A:user-1@node-2# info baseline
!*[pr:/configure router "Base"]
A:user-1@node-2# info
interface "backbone-1" {
ipv4 {
primary {
address 192.168.1.1
prefix-length 24
}
}
}
The following is a list of changes entered in the private candidate configuration of user-1.
!*[pr:/configure router "Base"]
A:user-1@node-2# compare baseline candidate full-context summary
+ /configure router "Base" interface "backbone-1" { }
+ /configure router "Base" interface "backbone-1" { ipv4 primary }
+ /configure router "Base" interface "backbone-1" ipv4 primary address 192.168.1.1
+ /configure router "Base" interface "backbone-1" ipv4 primary prefix-length 24
A commit command starts an automatic update. Because merge conflicts are detected, the commit is canceled:
!*[pr:/configure router "Base"]
A:user-1@node-2# commit
MINOR: MGMT_CORE #2703: Commit canceled - conflicts detected, use update
A dry-run update detects the merge conflicts without executing the update. Each configuration element that is changed in both the candidate configuration and the running configuration after the last baseline snapshot was taken results in a conflict and is reported.
!*[pr:/configure]
A:user-1@node-2# update check
+ /configure router "Base" { interface "backbone-1" }
## interface "backbone-1" { } - already exists - change removed
+ /configure router "Base" { interface "backbone-1" ipv4 primary }
## primary { } - already exists - change removed
+ /configure router "Base" interface "backbone-1" ipv4 primary address 192.168.1.1
## address - exists with different value: address 192.168.2.2 - change updated: replace existing value
+ /configure router "Base" interface "backbone-1" ipv4 primary prefix-length 24
## prefix-length - exists with same value - change removed
After verifying that the merge conflict resolution is acceptable, the update can be executed. The reporting is the same as for a dry-run update.
!*[pr:/configure]
A:user-1@node-2# update
+ /configure router "Base" { interface "backbone-1" }
## interface "backbone-1" { } - already exists - change removed
+ /configure router "Base" { interface "backbone-1" ipv4 primary }
## primary { } - already exists - change removed
+ /configure router "Base" interface "backbone-1" ipv4 primary address 192.168.1.1
## address - exists with different value: address 192.168.2.2 - change updated: replace existing value
+ /configure router "Base" interface "backbone-1" ipv4 primary prefix-length 24
## prefix-length - exists with same value - change removed
The candidate configuration is now updated: the baseline datastore equals the running datastore and the candidate datastore contains the updated list of changes as described in the update report.
*[pr:/configure router "Base"]
A:user-1@node-2# compare baseline candidate
interface "backbone-1" {
ipv4 {
primary {
- address 192.168.2.2
+ address 192.168.1.1
}
}
}
*[pr:/configure router "Base"]
A:user-1@node-2# info
interface "backbone-1" {
ipv4 {
primary {
address 192.168.1.1
prefix-length 24
}
}
}
*[pr:/configure router "Base"]
A:user-1@node-2# info baseline
interface "backbone-1" {
ipv4 {
primary {
address 192.168.2.2
prefix-length 24
}
}
}
*[pr:/configure router "Base"]
A:user-1@node-2# info running
interface "backbone-1" {
ipv4 {
primary {
address 192.168.2.2
prefix-length 24
}
}
}
Example update scenario without merge conflicts
The private candidate configuration of user-1 is out-of-date. The running configuration has interface backbone-1 configured. The private baseline datastore does not have the interface configured. The interface backbone-2 is configured by user-1.
Update scenario without merge conflicts
!*[pr:/configure router "Base"]
A:user-1@node-2# info running
interface "backbone-1" {
ipv4 {
primary {
address 192.168.1.1
prefix-length 24
}
}
}
!*[pr:/configure router "Base"]
A:user-1@node-2# info baseline
!*[pr:/configure router "Base"]
A:user-1@node-2# info
interface "backbone-2" {
ipv4 {
primary {
address 192.168.2.2
prefix-length 24
}
}
}
The following shows the list of changes entered in the private candidate configuration of user-1.
!*[pr:/configure]
A:user-1@node-2# compare baseline candidate full-context summary
+ /configure router "Base" interface "backbone-2" ipv4 primary
+ /configure router "Base" interface "backbone-2" ipv4 primary address 192.168.2.2
+ /configure router "Base" interface "backbone-2" ipv4 primary prefix-length 24
A dry-run update detects merge conflicts without executing the update. There are no conflicts detected in this case.
!*[pr:/configure]
A:user-1@node-2# update check
A commit operation starts an automatic update. Without merge conflicts, the commit succeeds.
!*[pr:/configure]
A:user-1@node-2# commit
[pr:/configure]
A:user-1@node-2#
After a commit operation, the candidate configuration is updated; the baseline datastore equals the running datastore and the candidate datastore is empty.
[pr:/configure]
A:user-1@node-2# compare baseline candidate
[pr:/configure]
A:user-1@node-2# compare baseline running
[pr:/configure router "Base"]
A:user-1@node-2# info
interface "backbone-1" {
ipv4 {
primary {
address 192.168.1.1
prefix-length 24
}
}
}
interface "backbone-2" {
ipv4 {
primary {
address 192.168.2.2
prefix-length 24
}
}
}
Committing the candidate configuration
The commit command can be executed from any hierarchy level within any configuration branch.
When a commit operation is initiated while the baseline is out-of-date, the router first attempts to update the candidate configuration. If a merge conflict is detected, the commit operation is canceled to allow the administrator to resolve the merge conflicts manually.
Canceled commit operation
!*[pr:/configure]
A:admin@node-2# commit
MINOR: MGMT_CORE #2703: Commit canceled - conflicts detected, use update
!*[pr:/configure]
A:admin@node-2#
The update is executed and the commit operation proceeds when no merge conflict is detected. See Updating the candidate configuration for information about the update process.
Validation is subsequently 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; an empty candidate datastore and an up-to-date baseline.
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.
For information about the commit history, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide, "Commit History" section.
Optional comment added to the commit operation
[pr:/configure system time]
A:admin@node-2# info
prefer-local-time true
[pr:/configure system time]
A:admin@node-2# prefer-local-time false
*[pr:/configure system time]
A:admin@node-2# commit comment "Revert to use UTC time."
[pr:/configure system time]
A:admin@node-2# info
prefer-local-time false
Using the commit confirmed command
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.
While the commit confirmed timer is running, the remaining time before an automatic rollback is shown before each prompt of all active MD-CLI sessions.
commit confirmed timer
*[ex:/configure log accounting-policy 5]
A:admin@node-2# commit confirmed
INFO: CLI #2090: Commit confirmed - automatic rollback in 9 minutes 59 seconds
[ex:/configure log accounting-policy 5]
A:admin@node-2#
INFO: CLI #2090: Commit confirmed - automatic rollback in 9 minutes 47 seconds
[ex:/configure log accounting-policy 5]
A:admin@node-2# pwc
Present Working Context:
configure
log
accounting-policy 5
INFO: CLI #2090: Commit confirmed - automatic rollback in 9 minutes 45 seconds
[ex:/configure log accounting-policy 5]
A:admin@node-2# back
INFO: CLI #2090: Commit confirmed - automatic rollback in 9 minutes 41 seconds
[ex:/configure log]
A:admin@node-2# accounting-policy 9
MINOR: MGMT_CORE #2604: Commit confirmed in progress - changes to the candidate configuration are not allowed
INFO: CLI #2090: Commit confirmed - automatic rollback in 9 minutes 38 seconds
[ex:/configure log]
A:admin@node-2#
INFO: CLI #2090: Commit confirmed - automatic rollback in 8 minutes 44 seconds
[ex:/configure log]
A:admin@node-2#
If the initial commit fails, the commit confirmed operation is canceled and no timer is started.
When the initial commit fails
*[ex:/configure log accounting-policy 5]
A:admin@node-2# collection-interval 3
*[ex:/configure log accounting-policy 5]
A:admin@node-2# commit confirmed
MINOR: LOG #12: configure log accounting-policy 5 collection-interval - Inconsistent Value error - Minimum value is 5 minutes for this record type.
*[ex:/configure log accounting-policy 5]
A:admin@node-2#
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.
Using the timeout option
*[ex:/configure log accounting-policy 5]
A:admin@node-2# commit confirmed
INFO: CLI #2090: Commit confirmed - automatic rollback in 10 minutes
[ex:/configure log accounting-policy 5]
A:admin@node-2# commit confirmed 33
INFO: CLI #2090: Commit confirmed - automatic rollback in 33 minutes
[ex:/configure log accounting-policy 5]
A:admin@node-2#
After 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.
Non-persistent operation
The commit confirmed and commit confirmed accept or commit confirmed cancel commands must be executed from the same MD-CLI configuration session. Commit commands executed from another configuration session while the commit confirmed timer is running generate an error.
Leaving the configuration mode or logging out from the MD-CLI session cancels the ongoing commit confirmed and starts an automatic rollback. The user must acknowledge the request to exit configuration mode or logout.
*[ex:/configure]
A:admin@node-2# commit confirmed
INFO: CLI #2090: Commit confirmed - automatic rollback in 9 minutes 59 seconds
[ex:/configure]
A:admin@node-2# exit all
INFO: CLI #2095: Commit confirmed in progress - exiting configuration mode will cancel the commit confirmed and start configuration rollback
Cancel commit confirmed and rollback immediately? [y,n] n
INFO: CLI #2065: Exit exclusive configuration mode canceled
INFO: CLI #2090: Commit confirmed - automatic rollback in 9 minutes 45 seconds
[ex:/configure]
A:admin@node-2# logout
INFO: CLI #2095: Commit confirmed in progress - logout will cancel the commit confirmed and start configuration rollback
Cancel commit confirmed and rollback immediately? [y,n] n
INFO: CLI #2100: Logout canceled
INFO: CLI #2090: Commit confirmed - automatic rollback in 9 minutes 37 seconds
[ex:/configure]
A:admin@node-2#
Persistent identifier
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 configuration or NETCONF 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 (‟”).
*[ex:/configure]
A:admin@node-2# commit confirmed persist-id my-commit
INFO: CLI #2090: Commit confirmed - automatic rollback in 10 minutes
[ex:/configure]
A:admin@node-2# commit confirmed cancel
MINOR: MGMT_CORE #2603: Commit confirmed - persist-id expected
INFO: CLI #2090: Commit confirmed - automatic rollback in 9 minutes 53 seconds
[ex:/configure]
A:admin@node-2# commit confirmed accept
MINOR: MGMT_CORE #2603: Commit confirmed - persist-id expected
INFO: CLI #2090: Commit confirmed - automatic rollback in 9 minutes 45 seconds
[ex:/configure]
A:admin@node-2# commit confirmed cancel persist-id my-commit
*[ex:/configure]
A:admin@node-2#
Saving changes
The running configuration can be saved to a local or remote file location with the admin save [url] location command, where location is a character string specifying the local or remote location where the configuration is to be saved.
To make the running configuration persistent, the configuration should be saved to the startup configuration location specified in the Boot Options File (BOF) as bof configuration primary-location. This is achieved with the admin save command without specifying a location.
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.
The configuration is saved automatically after every successful commit when automatic save is enabled via the MD-CLI, NETCONF, or gRPC auto-config-save commands. Nokia recommends that the auto-config-save values are configured the same for all model-driven interfaces.
The configuration is also saved if an operator issues the admin save command, regardless of the auto-config-save settings.
When auto-config-save is set to false, the admin save command must be issued to make the configuration persistent.
Automatic save enabled
[ex:/configure system management-interface cli md-cli]
A:admin@node-2# info detail auto-config-save
auto-config-save true
Rolling back the configuration from a saved configuration file
The rollback command loads a previously saved configuration file to the candidate configuration. Loading the file does not automatically initiate a commit command, and the candidate can be examined before committing. The rollback command is the equivalent of a load full-replace with the configuration file, and is specified by a saved configuration number or a commit history identifier. The keyword startup and saved configuration number 0 correspond to the last saved configuration file (config.cfg). This is also the default when the file is not specified with the rollback command.
The rollback command is available only in model-driven management interface configuration mode and can only be executed from the root of the configuration branch.
Configuration files loaded with the rollback commit-id command are identified with a number that corresponds to the commit history identifier and location specified by the bof configuration primary-location command in the active CPM's Boot Option File (BOF).
By default, 50 configuration files are saved. The configuration-backups command can be used to save a different number of configuration files.
[ex:/configure system management-interface configuration-save]
A:admin@node-2# info detail
## apply-groups
## apply-groups-exclude
configuration-backups 50
incremental-saves false
[ex:/configure system management-interface configuration-save]
A:admin@node-2# configuration-backups ?
configuration-backups <number>
<number> - <1..200>
Default - 50
Maximum number of configuration versions maintained
Displaying the name of the configuration file
The admin show configuration bof command shows the name of the file as config.cfg.
[/]
A:admin@node-2# admin show configuration bof | match primary-location
primary-location "cf3:\config.cfg"
Executing the rollback command to the configuration saved before the last one
[ex:/configure]
A:admin@node-2# rollback 1
Loaded 306 lines in 0.4 seconds from file "cf3:\config.cfg.1"
Executing the rollback command to the configuration saved three times before the last one
[ex:/configure]
A:admin@node-2# rollback 3
Loaded 306 lines in 0.4 seconds from file "cf3:\config.cfg.3"
Executing the rollback command with a commit history identifier
[ex:/configure]
A:admin@node-2# rollback Press Tab
<commit-id>
4
Committed 2022-02-01T11:13:38.7-05:00 by admin (MD-CLI) 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."
Committed 2022-02-01T10:56:01.3-05:00 by system (MD-CLI) from Console
Log "System booted version 22.2.R1."
Location "cf3:\config.cfg.2"
Configuration file executed for a rollback commit-id 3 command
The configuration file loaded for a rollback commit-id 3 command corresponds to the file location in commit history identifier 3.
rollback command references the file in the location of the commit history identifier
In the MD-CLI, the rollback commit-id command references the file in the location of the commit history identifier, in this case, identifier 3.
[ex:/configure]
A:admin@node-2# rollback commit-id 3
Executed 386 lines in 0.4 seconds from file cf3:\config.cfg.3
The startup option of the rollback command loads the contents of the current admin save file set with the primary configuration and not the version of the startup file that was booted.
When auto-config-save 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 saved configuration files.
In the following figure, auto-config-save is set to true. With a successful commit, a commit history entry is created and the configuration file is saved.
In the following figure, auto-config-save is set to false. The admin save command saves the running configuration before the commit is issued. However, a commit entry is created without saving the configuration.
In the following figure, the commit fails and no commit history entry or saved configuration file is created, regardless of the auto-config-save setting.
Loading configuration from a file or interactively
The load command loads the contents of an interactive scratchpad or a file into the candidate configuration. A configuration file can be local or remote.
The load command can only be executed at the top of the configure region when loading from a file. The contents of the file must start from the root of the configuration. The MD-CLI session must be in private, exclusive, or global configuration mode. Loading from a file does not result in a context change.
The load command is present working context (pwc) aware and can be executed from any context in the configuration tree. Interactive loading requires the input configuration to be correct from the pwc. See Loading configuration interactively for more information about interactive loading.
The load command can be executed regardless of whether uncommitted changes are present in the candidate configuration datastore.
The full-replace option replaces the current candidate configuration with the specified file. The merge option merges the contents of the specified file or interactive input into the candidate configuration. If there are conflicts, the configuration statements in the specified file or interactive input override the existing configuration statements. The configuration to be loaded is not the same as a CLI script to be executed and cannot include the following statements:
MD-CLI commands such as commit, delete, or tools
navigation commands such as exit, back, or top
See Executing commands from a file to perform such actions from a file.
If the loaded file or interactive input encounters errors, parsing terminates at the first error. When using the load command with a file, statements before the error are loaded into the candidate configuration. If an error occurs using the load command interactively, no input configuration statements are incorporated into the candidate configuration.
Configuration statements in the loaded configuration are also subject to AAA command authorization. An authorization check failure terminates the execution of further statements in the input.
Using info outputs in load files
The plain text 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.
Output from the info full-context command
This output can be copied and pasted into a file; for example, cf3:\testbgp.cfg.
*[ro:/configure router "Base" bgp]
A:admin@node-2# info full-context
/configure router "Base" bgp neighbor "192.168.89.8" group "external"
/configure router "Base" bgp neighbor "192.168.89.8" prefix-limit ipv4 maximum 200
/configure router "Base" bgp neighbor "192.168.89.8" prefix-limit ipv4 log-only true
/configure router "Base" bgp neighbor "192.168.89.8" prefix-limit ipv4 threshold 80
*[ro:/configure router "Base" bgp]
A:admin@node-2# info full-context > cf3:testbgp.cfg
[/]
A:admin@node-2# file list
Volume in drive cf3 on slot A is .
Volume in drive cf3 on slot A is formatted as FAT32
Directory of cf3:\
10/24/2019 04:02a <DIR> .ssh/
01/01/1980 12:00a 170 NVRAM.DAT
01/01/1980 12:00a 679 bof.cfg
10/24/2019 04:02a 314 nvsys.info
10/24/2019 04:02a 1 restcntr.txt
10/27/2019 02:57p 257 testbgp.cfg
5 File(s) 1421 bytes.
1 Dir(s) 0 bytes free.
From the MD-CLI, the file show command displays the contents of the file
[/]
A:admin@node-2# file show cf3:testbgp.cfg
File: testbgp.cfg
-------------------------------------------------------------------------------
/configure router "Base" bgp neighbor "192.168.89.8" group "external"
/configure router "Base" bgp neighbor "192.168.89.8" prefix-limit ipv4 maximum 200
/configure router "Base" bgp neighbor "192.168.89.8" prefix-limit ipv4 log-only true
/configure router "Base" bgp neighbor "192.168.89.8" prefix-limit ipv4 threshold 80
===============================================================================
Using the load merge command
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.
[ex:/configure]
A:admin@node-2# load merge cf3:testbgp.cfg
Loaded 5 lines in 0.0 seconds from file cf3:\testbgp.cfg
*[ex:/configure]
A:admin@node-2# compare
router "Base" {
bgp {
+ group "external" {
+ }
+ neighbor "192.168.89.8" {
+ group "external"
+ prefix-limit ipv4 {
+ maximum 200
+ log-only true
+ threshold 80
+ }
+ }
}
}
This output can also be copied into a file.
*[ro:/configure router "Base" bgp]
A:admin@node-2# info flat
neighbor "192.168.89.8" group "external"
neighbor "192.168.89.8" prefix-limit ipv4 maximum 200
neighbor "192.168.89.8" prefix-limit ipv4 log-only true
neighbor "192.168.89.8" prefix-limit ipv4 threshold 80
*[ro:/configure router "Base" bgp]
A:admin@node-2# info flat > cf3:testbgp.cfg
*[ro:/configure router "Base" bgp]
A:admin@node-2# file show cf3:testbgp.cfg
File: testbgp.cfg
-------------------------------------------------------------------------------
neighbor "192.168.89.8" group "external"
neighbor "192.168.89.8" prefix-limit ipv4 maximum 200
neighbor "192.168.89.8" prefix-limit ipv4 log-only true
neighbor "192.168.89.8" prefix-limit ipv4 threshold 80
===============================================================================
Adding a line to specify the context
An additional context line is added, through a manual edit, to specify the context /configure router ‟Base” bgp, as shown in the file display.
*[ro:/configure router "Base" bgp]
A:admin@node-2# file show cf3:testbgp.cfg
File: testbgp.cfg
-------------------------------------------------------------------------------
/configure router bgp
neighbor "192.168.89.8" group "external"
neighbor "192.168.89.8" prefix-limit ipv4 maximum 200
neighbor "192.168.89.8" prefix-limit ipv4 log-only true
neighbor "192.168.89.8" prefix-limit ipv4 threshold 80
===============================================================================
compare command shows candidate configuration changes
The file is merged and the compare command shows the resulting candidate configuration changes.
[ex:/configure router "Base" bgp]
A:admin@node-2# info
[ex:/configure router "Base" bgp]
A:admin@node-2# top
[ex:/configure]
A:admin@node-2# load merge cf3:testbgp.cfg
Loaded 6 lines in 0.0 seconds from file cf3:\testbgp.cfg
*[ex:/configure]
A:admin@node-2# compare
router "Base" {
bgp {
+ group "external" {
+ }
+ neighbor "192.168.89.8" {
+ group "external"
+ prefix-limit ipv4 {
+ maximum 200
+ log-only true
+ threshold 80
+ }
+ }
}
}
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 the testbgp.cfg file in the preceding example, or use the output from the info full-context command.
*[ro:/configure router "Base" bgp]
A:admin@node-2# info
group "external" {
}
neighbor "192.168.89.8" {
group "external"
prefix-limit ipv4 {
maximum 200
log-only true
threshold 80
}
}
Contents of the load file with the info output
/configure router "Base" bgp
group "external" {
}
neighbor "192.168.89.8" {
group "external"
prefix-limit ipv4 {
maximum 200
log-only true
threshold 80
}
}
Loading configuration interactively
The load command supports an interactive input scratchpad when operating in merge mode.
When the load merge interactive command is executed, a temporary scratchpad is presented to the user. Line numbers displayed on the left side of the input aid with troubleshooting if errors occur in the input.
The interactive option of the merge command can be used anywhere the load command is supported, including the root (/) of the configure, debug, or li region.
Input prompt in an interactive load merge scratchpad
(pr)[/configure]
A:admin@node-2# load merge interactive
Interactive configuration input started. Syntax checking will be performed when configuration entry is complete.
Use Ctrl-D or enter EOF on a newline to conclude entry and start processing the entered configuration.
Use Ctrl-C to exit.
1>
All input is accepted into the scratchpad and processed at the end of the interactive session.
The input can be made in standard MD-CLI format, such as the output of the info, info full-context, or the compare command.
The interactive session ends in one of the following ways:
- Ctrl-C ends the interactive session and discards all input without processing
- Ctrl-D ends the interactive session and attempts to process the input and apply the input to the candidate configuration.
- EOF at the beginning of a new line without any other input on the line ends the interactive session and attempts to apply the input to the candidate configuration.
The system processes the input in the order of input. Parsing stops at the first error encountered and the system reports the error, referencing the line number in the input.
If no errors are found, the system merges the input configuration into the current candidate configuration. The changes take effect when the commit command is executed.
load merge interactive session from /configure
[ex:/configure]
A:admin@node-2# load merge interactive
Interactive configuration input started. Syntax checking will be performed when configuration entry is complete.
Use Ctrl-D or enter EOF on a newline to conclude entry and start processing the entered configuration.
Use Ctrl-C to exit.
1> system
2> name main_router
3> contact "Head office"
4> EOF
Loaded 3 lines in 0.0 seconds
*[ex:/configure]
A:admin@node-2# compare
system {
+ contact "Head office"
+ name "main_router"
}
load merge interactive session using compare output
[ex:/configure system]
A:admin@node-2# load merge interactive
Interactive configuration input started. Syntax checking will be performed when configuration entry is complete.
Use Ctrl-D or enter EOF on a newline to conclude entry and start processing the entered configuration.
Use Ctrl-C to exit.
1> + contact "Head office"
2> - name "node-2"
3> + name "main_router"
4>
5> EOF
Loaded 4 lines in 0.0 seconds
*[ex:/configure system]
A:admin@node-2# compare
+ contact "Head office"
- name "node-2"
+ name "main_router"
load merge interactive session with errors
[ex:/configure]
A:admin@node-2# load merge interactive
Interactive configuration input started. Syntax checking will be performed when configuration entry is complete.
Use Ctrl-D or enter EOF on a newline to conclude entry and start processing the entered configuration.
Use Ctrl-C to exit.
1> system
2> name new_router
3> first incorrect entry "This flags an error"
4> second incorrect entry "Another error"
5> EOF
MINOR: MGMT_CORE #2201: Unknown element - 'first'
MINOR: MGMT_CORE #2502: Configuration load failed - error on line 3 - 'first incorrect entry "This flags an error"'
[ex:/configure router "Base"]
A:admin@node-2# load merge interactive
Interactive configuration input started. Syntax checking will be performed when configuration entry is complete.
Use Ctrl-D or enter EOF on a newline to conclude entry and start processing the entered configuration.
Use Ctrl-C to exit.
1> interface "base-1-1" {
2> port 1/1/3:1
3> ipv6 {
4> link-local-address {
5> address fe80::1
6> duplicate-address-detection false
7> }
8> address 2500::1 {
9> prefix-length 64
10> duplicate-address-detection false
11> }
12> vrrp 1 {
13> backup [2500::10 fe80::1:1]
14> message-interval 5
15> mac 00:00:5e:00:02:01
16> priority 130
17> ping-reply true
18> oper-group "op-v6LI-1"
19> bfd-liveness {
20> dest-ip 2000::2
21> service-name "100"
22> interface-name "bfd-1-1"
23> }
24> }
25> }
26> }
27>
28> Ctrl-D
MINOR: MGMT_CORE #2301: Invalid element value - 5 out of range 10..4095
MINOR: MGMT_CORE #2502: Configuration load failed - error on line 14 - 'message-interval 5'
Using configuration groups
The 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 the following figure.
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.
Configuration groups are supported for all configuration branches and its descendants, which includes the configuration groups definition and applying the groups with the apply-groups command.
Creating configuration groups
Configuration groups are created in the groups branch of the configuration tree.
(ex)[configure]
A:admin@node-2# info
groups {
group "isis-backbone" {
router "Base" {
isis "0" {
interface "int-pe1-pe2" {
hello-authentication-key "KrbVPnF6Dg13PM/biw6ErHmrkAHk hash"
hello-authentication-type message-digest
hello-authentication true
interface-type point-to-point
}
}
}
}
}
Multiple configuration groups can be created, each with a unique name.
(ex)[configure]
A:admin@node-2# info
groups {
group "isis-access" {
router "Base" {
# configuration elements
}
}
group "isis-backbone” {
router "Base" {
# configuration elements
}
}
group "qos-backbone” {
card "1" {
# configuration elements
}
port "1/1/1" {
# configuration elements
}
qos {
# configuration elements
}
router "Base" {
# configuration elements
}
}
}
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.
Exact match
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.
(ex)[configure]
A:admin@node-2# info
groups {
group "isis-backbone" {
router "Base" {
isis "0" {
interface "int-pe1-pe2" {
interface-type point-to-point
}
}
}
}
}
Regular expression match
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.
(ex)[configure]
A:admin@node-2# info
groups {
group "isis-backbone" {
router "Base" {
isis "0" {
interface "<.*>" {
interface-type point-to-point
}
}
}
}
}
Regular expression match format
A regular expression match is specified as a string with the regular expression enclosed in quotation marks and 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 Using regular expressions.
For example:
interface ‟<int-.*>” — matches all interfaces that start with ‟int-”
interface ‟<.*>” — matches all interfaces
interface ‟<.*pe[1-3].*>” — matches all interfaces that have ‟pe1”, ‟pe2”, or ‟pe3” in their name
A regular expression match on an encrypted leaf is restricted to a match all: ‟<.*>”. Any other string enclosed in angle brackets (‟<string>”) is accepted as an exact match for the encrypted leaf and displayed as a hashed value in the configuration.
Conflicting match criteria within a configuration group
With a regular expression match, a match criteria conflict can occur if two regular expressions match or if a regular expression and an exact match both match on the same list entry. Conflicting matches within a configuration group are not supported and result in a validation error.
In the following configuration example, both interface ‟<int-.*>” and interface ‟int-pe1-pe2” match isis 0 interface ‟int-pe1-pe2”. At validation, this results in a configuration group inheritance failure because of conflicting match criteria:
(ex)[configure]
A:admin@node-2# info
groups {
group "isis-backbone" {
router "Base" {
isis "0" {
interface "<int-.*>" {
interface-type point-to-point
level-capability 2
}
interface "int-pe1-pe2" {
level 2 {
hello-interval 1
}
}
}
}
}
}
---snip---
router "Base" {
---snip---
isis 0 {
apply-groups ["isis-backbone"]
---snip---
interface "int-pe1-pe2" {
---snip---
}
}
}
(ex)[configure]
A:admin@node-2# validate
MINOR: MGMT_CORE #2901: configure router "Base" isis 0 interface "int-pe1-pe2" - Configuration group inheritance failed - conflicting match criteria within group "isis-backbone"
Conflicting match criteria within a configuration group can be avoided by applying multiple configuration groups.
*(ex)[configure]
A:admin@node-2# info
groups {
group "isis-backbone-common" {
router "Base" {
isis "0" {
interface "<int-.*>" {
interface-type point-to-point
level-capability 2
}
}
}
}
group "isis-backbone-custom" {
router "Base" {
isis "0" {
interface "int-pe1-pe2" {
level 2 {
hello-interval 1
}
}
}
}
}
}
---snip---
router "Base" {
---snip---
isis 0 {
apply-groups ["isis-backbone-custom" "isis-backbone-common"]
---snip---
interface "int-pe1-pe2" {
---snip---
}
}
}
*(ex)[configure router "Base" isis 0]
A:admin@node-2# validate
*(ex)[configure router "Base" isis 0]
A:admin@node-2# info inheritance
apply-groups ["isis-backbone-custom" "isis-backbone-common"]
interface "int-pe1-pe2" {
## 'interface-type' inherited from group "isis-backbone-common"
interface-type point-to-point
## 'level-capability' inherited from group "isis-backbone-common"
level-capability 2
level 2 {
## 'hello-interval' inherited from group "isis-backbone-custom"
hello-interval 1
}
}
Applying configuration groups
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:
(ex)[configure router "Base" isis 0]
A:admin@node-2# info
apply-groups ["isis-1"]
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.
(ex)[configure]
A:admin@node-2# info
groups {
group "isis-3" {
router "Base" {
isis "0" {
interface "<int-.*>" {
interface-type point-to-point
level "2" {
metric 30
}
}
level "2" {
wide-metrics-only true
}
}
}
}
}
---snip---
router "Base" {
isis 0 {
admin-state enable
level-capability 2
area-address [49.0001.0001]
interface "int-pe1-pe2" {
apply-groups ["isis-3"]
}
}
}
The resulting expanded configuration can be shown with the info inheritance command:
(ex)[configure]
A:admin@node-2# info inheritance
router "Base" {
isis 0 {
admin-state enable
level-capability 2
area-address [49.0001.0001]
interface "int-pe1-pe2" {
apply-groups ["isis-3"]
## 'interface-type' inherited from group "isis-3"
interface-type point-to-point
level 2 {
## 'metric' inherited from group "isis-3"
metric 30
}
}
}
}
The following notes apply to configuration groups and the apply-groups statements:
configuration groups cannot be nested; therefore, apply-groups statements cannot be part of a configuration group
configuration groups that are not applied in the configuration do not functionally change the configuration
configuration groups and apply-groups statements are part of the running configuration and are saved in the MD-CLI configuration file
the apply-groups statement can be configured in the configuration root (that is, /configure) but is not displayed in the online help for the context
Inheritance rules
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.
(ex)[configure]
A:admin@node-2# info
groups {
group "isis-1" {
router "Base" {
isis "0" {
level-capability 1
interface "<int-.*>" {
interface-type point-to-point
level "2" {
metric 10
}
}
}
}
}
}
---snip---
router "Base" {
isis 0 {
apply-groups ["isis-1"]
admin-state enable
level-capability 2
area-address [49.0001.0001]
interface "int-pe1-pe2" {
}
}
}
The resulting expanded configuration after inheritance is shown as follows:
(ex)[configure]
A:admin@node-2# info inheritance
router "Base" {
isis 0 {
apply-groups ["isis-1"]
admin-state enable
level-capability 2
area-address [49.0001.0001]
interface "int-pe1-pe2" {
## 'interface-type' inherited from group "isis-1"
interface-type point-to-point
level 2 {
## 'metric' inherited from group "isis-1"
metric 10
}
}
}
}
Up to eight configuration groups can be applied to a configuration branch. The configuration order determines the inheritance precedence:
configuration elements in the first listed group have the highest precedence
configuration elements in the last listed group have the lowest precedence
In the following example, both configuration groups ‟isis-1” and ‟isis-2” set an interface level 2metric. 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.
(ex)[configure]
A:admin@node-2# info
groups {
group "isis-1" {
router "Base" {
isis "0" {
level-capability 1
interface "<int-.*>" {
interface-type point-to-point
level "2" {
metric 10
}
}
}
}
}
group "isis-2" {
router "Base" {
isis "0" {
interface "<int-.*>" {
level "2" {
metric 20
}
}
}
}
}
}
---snip---
router "Base" {
isis 0 {
apply-groups ["isis-2" "isis-1"]
admin-state enable
level-capability 2
area-address [49.0001.0001]
interface "int-pe1-pe2" {
}
}
}
The resulting expanded configuration after inheritance is shown as follows:
(ex)[configure]
A:admin@node-2# info inheritance
router "Base" {
isis 0 {
apply-groups ["isis-2" "isis-1"]
admin-state enable
level-capability 2
area-address [49.0001.0001]
interface "int-pe1-pe2" {
## 'interface-type' inherited from group "isis-1"
interface-type point-to-point
level 2 {
## 'metric' inherited from group "isis-2"
metric 20
}
}
}
}
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 described earlier, the level-capability configuration element from group ‟isis-1” has lower precedence than the local configured value. The wide-metrics-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.
(ex)[configure]
A:admin@node-2# info
groups {
group "isis-1" {
router "Base" {
isis "0" {
level-capability 1
interface "<int-.*>" {
interface-type point-to-point
level "2" {
metric 10
}
}
}
}
}
group "isis-2" {
router "Base" {
isis "0" {
interface "<int-.*>" {
level "2" {
metric 20
}
}
}
}
}
group "isis-3" {
router "Base" {
isis "0" {
interface "<int-.*>" {
interface-type point-to-point
level "2" {
metric 30
}
}
level "2" {
wide-metrics-only true
}
}
}
}
}
---snip---
router "Base" {
isis 0 {
apply-groups ["isis-2" "isis-1"]
admin-state enable
level-capability 2
area-address [49.0001.0001]
interface "int-pe1-pe2" {
apply-groups ["isis-3"]
}
}
}
The resulting expanded configuration after inheritance is shown as follows:
(ex)[configure]
A:admin@node-2# info inheritance
router "Base" {
isis 0 {
apply-groups ["isis-2" "isis-1"]
admin-state enable
level-capability 2
area-address [49.0001.0001]
interface "int-pe1-pe2" {
apply-groups ["isis-3"]
## 'interface-type' inherited from group "isis-3"
interface-type point-to-point
level 2 {
## 'metric' inherited from group "isis-3"
metric 30
}
}
}
}
Inheritance rules for leaf-lists are the same as for a single leaf, whether the list is a system-ordered leaf list (for example, configure router interface interface-name if-attribute admin-group value) or a user-ordered leaf list (for example, configure router bgp export policy value). The entire leaf-list is inherited, and it is not possible to add values to an existing leaf-list through configuration group inheritance.
Inheritance rules for user-ordered lists (for example, configure policy-options policy-statement name named-entry entry-name) are:
list order is ignored for user-ordered list entry matching
unmatched list entries in the configuration group definition and its descendant configuration elements are inherited in the locally-configured user-ordered list. Newly-created list entries are appended at the end in the order they appear in the configuration group definition.
descendant configuration elements of matched user-ordered list entries are candidates for inheritance
Disabling inheritance
The apply-groups-exclude statement disables configuration inheritance for up to eight configuration groups in a configuration hierarchy. Configuration elements from the specified groups are not inherited in that branch. Disabling configuration inheritance for a configuration group only affects the configuration if that configuration group is applied at a higher-level branch in the configuration tree.
In the following example, configuration group ‟isis-1” is applied at the /configure router ‟Base” isis 0 context, but inheritance for that group is disabled for interface ‟int-pe1-ce1”.
[ex:configure groups]
A:admin@node-2# info
group "isis-1" {
router "Base" {
isis 0 {
interface "<int-.*>" {
interface-type point-to-point
level-capability 2
}
level 2 {
wide-metrics-only true
}
}
}
}
[ex:configure groups]
A:admin@node-2# /configure router isis
[ex:configure router "Base" isis 0]
A:admin@node-2# info
apply-groups ["isis-1"]
admin-state enable
area-address [49.0001.0001]
interface "int-pe1-ce1" {
apply-groups-exclude ["isis-1"]
passive true
}
interface "int-pe1-pe2" {
}
interface "int-pe1-pe3" {
}
In the resulting expanded configuration, the interface parameters specified in the configuration group ‟isis-1” are not applied for interface ‟int-pe1-ce1”:
[ex:configure router "Base" isis 0]
A:admin@node-2# info inheritance
apply-groups ["isis-1"]
admin-state enable
area-address [49.0001.0001]
interface "int-pe1-ce1" {
apply-groups-exclude ["isis-1"]
passive true
}
interface "int-pe1-pe2" {
## 'interface-type' inherited from group "isis-1"
interface-type point-to-point
## 'level-capability' inherited from group "isis-1"
level-capability 2
}
interface "int-pe1-pe3" {
## 'interface-type' inherited from group "isis-1"
interface-type point-to-point
## 'level-capability' inherited from group "isis-1"
level-capability 2
}
level 2 {
## 'wide-metrics-only' inherited from group "isis-1"
wide-metrics-only true
}
The following configuration guidelines apply to the apply-groups-exclude statement.
This statement cannot be included in a configuration group.
The statement is included in the running configuration and saved in the MD-CLI configuration file.
The statement cannot be configured at the configuration root (/configure).
Displaying the expanded configuration
After configuring and applying configuration groups, the expanded configuration should be reviewed before the configuration is committed. The expanded configuration 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.
(ex)[configure router "Base" isis 0 interface "int-pe1-pe2"]
A:admin@node-2# info inheritance
## 'interface-type' inherited from group "isis-1"
interface-type point-to-point
level 2 {
## 'metric' inherited from group "isis-2"
metric 20
}
Use the regular expression pattern match info inheritance | match '^[ ]*##' invert-match to suppress the system comments in the output of info inheritance.
(ex)[configure router "Base" isis 0 interface "int-pe1-pe2"]
A:admin@node-2# info inheritance | match '^[ ]*##' invert-match
interface-type point-to-point
level 2 {
metric 20
}
Conflicting matches are detected at validation. The info inheritance command may display an inherited configuration element in the candidate that is part of a conflicting match criteria.
The expanded running configuration can also be displayed with the info intended command. This command displays the intended configuration datastore as specified in RFC 8342, Network Management Datastore Architecture (NMDA) as follows:
the groups, apply-groups, and apply-groups-exclude configuration statements are suppressed
the expanded configuration with all statements that are inherited from a configuration group is displayed without the ## system comments
(ex)[configure router "Base" isis 0 interface "int-pe1-pe2"]
A:admin@node-2# info intended
interface-type point-to-point
level 2 {
metric 20
}
Authentication, Authorization, and Accounting (AAA) in configuration groups
User profiles can restrict the configuration branches that a user can change. Denied and read-only configuration branches in user profiles automatically prohibit inheritance of these branches via configuration groups.
To restrict a user from viewing, creating, or editing configuration branches inside a configuration group, an explicit entry for the configuration group must be added in the user profile.
In the following example, user admin2 has no access to the sap-ingress configuration branch.
(ex)[configure qos]
A:admin2@node-2# sap-ingress high-bw
MINOR: MGMT_CORE #2020: Permission denied - unauthorized use of 'sap-ingress'
This is enforced via the following entry in the local user profile:
(ro)[configure system security aaa local-profiles profile "restricted-admin"]
A:admin@node-2# info
---snip---
entry 200 {
match "configure qos sap-ingress"
action deny
}
The same entry prohibits configuration group inheritance for user admin2.
[ex:configure groups]
A:admin2@node-2# info
group "grp-1" {
qos {
sap-ingress "high-bw" {
queue 1 {
rate {
pir 200000
}
}
fc "be" {
queue 1
}
}
}
}
[ex:configure]
A:admin2@node-2# /configure qos apply-groups "grp-1"
MINOR: MGMT_CORE #2020: configure qos sap-ingress "high-bw" - Permission denied
User admin2 can still view, create, or change sap-ingress QoS policies inside a configuration group if the changes do not result in configuration group inheritance of the sap-ingress QoS policy.
User admin2 cannot see the result of configuration group inheritance of a sap-ingress QoS policy because the info command is subject to the AAA rules defined in the user profile.
[ex:configure groups]
A:admin2@node-2# info
group "grp-1" {
qos {
sap-ingress "high-bw" {
queue 1 {
rate {
pir 200000
}
}
fc "be" {
queue 1
}
}
}
}
[ex:configure groups]
A:admin2@node-2# /configure qos
[ex:configure qos]
A:admin2@node-2# info inheritance
apply-groups ["grp-1"]
md-auto-id {
qos-policy-id-range {
start 65000
end 65535
}
}
An administrative user with full privileges can see the inherited configuration, which includes the sap-ingress QoS policy created by user admin2.
[ro:configure qos]
A:admin@node-2# info inheritance
apply-groups ["grp-1"]
md-auto-id {
qos-policy-id-range {
start 65000
end 65535
}
}
## 'sap-ingress "high-bw"' inherited from group "grp-1"
sap-ingress "high-bw" {
## 'queue 1' inherited from group "grp-1"
queue 1 {
## 'rate' inherited from group "grp-1"
rate {
## 'pir' inherited from group "grp-1"
pir 200000
}
}
## 'fc "be"' inherited from group "grp-1"
fc "be" {
## 'queue' inherited from group "grp-1"
queue 1
}
}
To prevent user admin2 from viewing, creating, or changing sap-ingress QoS policies inside a configuration group, an explicit entry for the configuration group must be added to the AAA user profile.
[ex:configure system security aaa local-profiles profile "restricted-admin"]
A:admin@node-2# info
---snip---
entry 200 {
match "configure qos sap-ingress"
action deny
}
entry 201 {
match "configure groups group qos sap-ingress"
action deny
}
This configuration removes the privileges for user admin2 to view, create, or change sap-ingress QoS policies inside a configuration group.
[ex:configure groups]
A:admin2@node-2# info
group "grp-1" {
qos {
}
}
[ex:configure groups]
A:admin2@node-2# group "grp-1" qos sap-ingress "high-bw"
MINOR: MGMT_CORE #2020: Permission denied - unauthorized use of 'sap-ingress'
Configuration group example
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.
(ex)[configure]
A:admin@node-2# info
groups {
group "isis-bb-interface" {
router "Base" {
isis "0" {
interface "<int-.*>" {
hello-authentication-key "KrbVPnF6Dg13PM/biw6ErHmrkAHk hash"
hello-authentication-type message-digest
hello-padding adaptive
hello-authentication true
interface-type point-to-point
}
}
}
}
}
---snip---
router "Base" {
isis 0 {
apply-groups ["isis-bb-interface"]
admin-state enable
ipv4-routing true
ipv6-routing native
level-capability 2
area-address [49.0001.0001]
multi-topology {
ipv6-unicast true
}
interface "int-pe1-pe2" {
}
interface "int-pe1-pe3" {
}
interface "system" {
passive true
}
level 2 {
wide-metrics-only true
}
}
}
The resulting expanded configuration after inheritance is shown as follows:
(ex)[configure router "Base" isis 0]
A:admin@node-2# info inheritance
apply-groups ["isis-bb-interface"]
admin-state enable
ipv4-routing true
ipv6-routing native
level-capability 2
area-address [49.0001.0001]
multi-topology {
ipv6-unicast true
}
interface "int-pe1-pe2" {
## 'hello-authentication-key' inherited from group "isis-bb-interface"
hello-authentication-key "KrbVPnF6Dg13PM/biw6ErHmrkAHk hash"
## 'hello-authentication-type' inherited from group "isis-bb-interface"
hello-authentication-type message-digest
## 'hello-padding' inherited from group "isis-bb-interface"
hello-padding adaptive
## 'hello-authentication' inherited from group "isis-bb-interface"
hello-authentication true
## 'interface-type' inherited from group "isis-bb-interface"
interface-type point-to-point
}
interface "int-pe1-pe3" {
## 'hello-authentication-key' inherited from group "isis-bb-interface"
hello-authentication-key "KrbVPnF6Dg13PM/biw6ErHmrkAHk hash"
## 'hello-authentication-type' inherited from group "isis-bb-interface"
hello-authentication-type message-digest
## 'hello-padding' inherited from group "isis-bb-interface"
hello-padding adaptive
## 'hello-authentication' inherited from group "isis-bb-interface"
hello-authentication true
## 'interface-type' inherited from group "isis-bb-interface"
interface-type point-to-point
}
interface "system" {
passive true
}
level 2 {
wide-metrics-only true
}
The resulting expanded configuration after inheritance is shown as follows, without system comments:
(ex)[configure router "Base" isis 0]
A:admin@node-2# info inheritance | match '^[ ]*##' invert-match
apply-groups ["isis-bb-interface"]
admin-state enable
ipv4-routing true
ipv6-routing native
level-capability 2
area-address [49.0001.0001]
multi-topology {
ipv6-unicast true
}
interface "int-pe1-pe2" {
hello-authentication-key "KrbVPnF6Dg13PM/biw6ErHmrkAHk hash"
hello-authentication-type message-digest
hello-padding adaptive
hello-authentication true
interface-type point-to-point
}
interface "int-pe1-pe3" {
hello-authentication-key "KrbVPnF6Dg13PM/biw6ErHmrkAHk hash"
hello-authentication-type message-digest
hello-padding adaptive
hello-authentication true
interface-type point-to-point
}
interface "system" {
passive true
}
level 2 {
wide-metrics-only true
}
Caveats
The following restrictions apply to configuration groups.
Configuration groups are available only in model-driven management interface configuration mode and for configuration elements in the Nokia YANG models.
When configuration groups are used with NETCONF, the <get-config> operation returns the pre-expanded configuration, including the configuration groups definitions and the apply-groups configuration elements. The expanded configuration, including the inherited configuration elements but excluding the configuration groups definitions and the apply-groups configuration elements, can be returned using the <get-data> operation on the intended datastore.
When configuration groups are used with gNMI, the Get RPC command returns the pre-expanded configuration, including the configuration groups definitions and apply-groups configuration elements. The expanded configuration, including the inherited configuration elements, cannot be returned with gNMI.
For more information about NETCONF and gNMI, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide.
Viewing the status of the local datastores
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 configure exclusive command (in the implicit configuration workflow) or the edit-config exclusive command (in the explicit configuration workflow).
An explicit lock can also be obtained via:
-
NETCONF or gRPC sessions. See the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide for more information.
a private exclusive configuration session. See Private-exclusive configuration session for more information.
To view the lock status of the datastores, the following show command is available:
show system management-interface datastore-locks [detail]
Using the detail option to display information
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.
(ro)[/]
A:admin@node-2# show system management-interface datastore-locks detail
===============================================================================
Session ID Region Datastore Lock State
Username Session Mode Idle Time
Session Type From
-------------------------------------------------------------------------------
69 configure Candidate, Running Locked
admin Exclusive 0d 00:01:48
MD-CLI 192.168.144.87
-------------------------------------------------------------------------------
Number of sessions: 1
'#' indicates the current active session
===============================================================================
Using the configuration-sessions command to display information
The configuration-sessions command displays the same information as the datastore-locks detail command, but for all configuration sessions regardless of whether the session has a lock on the datastore.
(ro)[/]
A:admin@node-2# show system management-interface configuration-sessions
===============================================================================
Session ID Region Datastore Lock State
Username Session Mode Idle Time
Session Type From
-------------------------------------------------------------------------------
#65 configure Candidate Unlocked
admin Private 0d 00:00:00
MD-CLI 192.168.144.87
66 configure Candidate Unlocked
admin Private 0d 00:05:41
MD-CLI 192.168.144.87
67 configure Candidate Unlocked
admin Private 0d 00:05:08
MD-CLI 192.168.144.87
68 configure Candidate Unlocked
admin Read-Only 0d 00:02:25
MD-CLI 192.168.144.87
69 configure Candidate, Running Locked
admin Exclusive 0d 00:01:54
MD-CLI 192.168.144.87
-------------------------------------------------------------------------------
Number of sessions: 5
'#' indicates the current active session
===============================================================================
Unlocking a locked datastore
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:
[/]
A:admin@node-2# admin disconnect session-id 10
Disconnecting an MD-CLI session (or any model-driven session, including NETCONF and gRPC) that acquired a datastore lock has the following results:
-
Any uncommitted changes in the candidate configuration datastore are discarded.
-
The session is terminated.
-
The explicit lock is released.