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.

Figure 1. Flow of configuration changes

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.

Table 1. Implicit and explicit configuration mode features

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:

Table 2. Configuration mode overview

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.

Figure 2. 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:

  1. verifies the running configuration has not been changed by another configuration session

  2. validates the candidate configuration by verifying the logic, constraints, and completeness of the candidate configuration

  3. 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.

Figure 3. Simultaneous configuration sessions

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.

Figure 4. Simultaneous configuration sessions - baseline out-of-date

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.

Figure 5. Simultaneous configuration sessions - update

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.

Figure 6. Simultaneous configuration sessions - merge conflict

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
Note: To display the current active configuration sessions in the router, use the command show system management-interface configuration-sessions.

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
    
Note:
  • 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
Note:
  • 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
Note: CLI #2057 is shown only when applicable.

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.

Table 3. Configuration and operational mode transitions

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.

Note: Private-exclusive is not a configuration mode. Users cannot enter a private-exclusive configuration mode in the MD-CLI.

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.

Note: When entering commands in the MD-CLI, whether from a load file or explicitly in the CLI prompt, all input after a hash (#) is treated as a comment and is ignored.
Note: When used in a string in the MD-CLI, the following special characters must be enclosed in quotation marks ("):
  • space

  • hash (#)

  • opening bracket ([)

  • apostrophe (')

  • question mark (?)

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

Note: Unions of integer and enumerated values do not support binary or hexadecimal input.

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"

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.

Table 4. Dynamic units for memory sizes
Unit name Valid MD-CLI input

bytes

  • bytes

  • byte

kilobytes

  • kilobytes

  • kilobytes

  • kbytes

  • kbyte

megabytes

  • megabytes

  • megabyte

  • mbytes

  • mbyte

gigabytes

  • gigabytes

  • gigabyte

  • gbytes

  • gbyte

terabytes

  • terabytes

  • terabyte

  • tbytes

  • tbyte

Table 5. Dynamic units for rates
Unit name Valid MD-CLI input

bps (bits per second)

bps

kilobps (kilobits per second)

  • kilobps

  • kbps

megabps (megabits per second)

  • megabps

  • mbps

gigabps (gigabits per second

  • gigabps

  • gbps

terabps (terabits per second)

  • terabps

  • tbps

petabps (petabits per second)

  • petabps

  • pbps

exabps (exabits per second)

  • exabps

  • ebps

zettabps (zettabits per second)

  • zettabps

  • zbps

Table 6. Dynamic units for duration
Unit name Valid MD-CLI input

picoseconds

  • picoseconds

  • picosecond

  • psecs

  • psec

nanoseconds

  • nanoseconds

  • nanosecond

  • nsecs

  • nsec

microseconds

  • microseconds

  • microsecond

  • usecs

  • usec

milliseconds

  • milliseconds

  • millisecond

  • msecs

  • msec

centiseconds

  • centiseconds

  • centisecond

  • csecs

  • csec

deciseconds

  • deciseconds

  • decisecond

  • dsecs

  • dsec

seconds

  • seconds

  • second

  • secs

  • sec

minutes

  • minutes

  • minute

  • mins

  • min

hours

  • hours

  • hour

  • hrs

  • hr

days

  • days

  • day

weeks

  • weeks

  • week

  • wks

  • wk

The following table shows the valid inputs for dates based on the time format.

Table 7. Dynamic units for dates and time
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.

Note: Minus (-) can be used instead of the delete command.

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.

Note: If the configuration element to be removed does not exist, no warning messages are displayed.

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

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 { }
    /configure system security aaa local-profiles profile "guest1" entry 10 { action deny }
    /configure system security aaa local-profiles profile "guest1" entry 10 { match "configure system security" }
    /configure system security aaa local-profiles profile "guest1" entry 20 { }
    /configure system security aaa local-profiles profile "guest1" entry 20 { 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 { }
    /configure system security aaa local-profiles profile "guest1" entry 30 { action deny }
    /configure system security aaa local-profiles profile "guest1" entry 30 { match "show li" }
    /configure system security aaa local-profiles profile "guest1" entry 40 { }
    /configure system security aaa local-profiles profile "guest1" entry 40 { action deny }
    /configure system security aaa local-profiles profile "guest1" entry 40 { match "tools" }

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" default-action permit-all

*[ex:/configure]
A:admin@node-2#     /configure system security aaa local-profiles profile "guest1" entry 10 { }

*[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 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 20 { }

*[ex:/configure system security aaa local-profiles profile "guest1"]
A:admin@node-2#     /configure system security aaa local-profiles profile "guest1" entry 20 { 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 { }

*[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 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 40 { }

*[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#     /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# 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 allows elements to be duplicated for use within an MD-CLI 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 { }
    local-as { as-number 65535 }
    local-as { private true }
    add-paths { }
    add-paths { ipv4 }
    add-paths { ipv4 send multipaths }
    add-paths { ipv4 receive true }
    add-paths { ipv6 }
    add-paths { ipv6 send multipaths }
    add-paths { ipv6 receive true }
    import { }
    import { policy ["ALLOW-ALL"] }
    export { }
    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" { }
+   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 }
+   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 }
+   neighbor "192.0.2.200" { import policy ["ALLOW-ALL"] }
+   neighbor "192.0.2.200" { export }
+   neighbor "192.0.2.200" { export policy ["ALLOW-ALL"] }
Note: pwc may also be used in the source or destination to specify the present working context instead of a path.
Note: The copy command includes the to keyword, which is always evaluated as an MD-CLI keyword. Therefore, contexts that include the command to cannot be copied as in the above examples. It is possible to copy the element by navigating to the destination context and omitting the destination parameter (that is, defaulting to the present working context). Examples where this limitation applies include:
  • 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 allows a list key to be renamed within the transactional MD-CLI configuration interface. Use the rename command instead of an 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.

Note:
  • 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 or destination to specify the present working context instead of a list key.

The following example shows the BGP neighbor 200.200.200.200 renamed to neighbor 200.200.200.33. The compare command displays the actions performed when the configuration is committed.

[ex:/configure router "Base" bgp]
A:admin@node-2# info flat neighbor "200.200.200.200"
    group "mesh"
    keepalive 10
    local-preference 100
    local-as { }
    local-as { as-number 65535 }
    local-as { private true }
    add-paths { }
    add-paths { ipv4 }
    add-paths { ipv4 send multipaths }
    add-paths { ipv4 receive true }
    add-paths { ipv6 }
    add-paths { ipv6 send multipaths }
    add-paths { ipv6 receive true }
    import { }
    import { policy ["ALLOW-ALL"] }
    export { }
    export { policy ["ALLOW-ALL"] }

[ex:/configure router "Base" bgp]
A:admin@node-2# rename neighbor "200.200.200.200" to 200.200.200.33

*[ex:/configure router "Base" bgp]
A:admin@node-2# compare flat
+   neighbor "200.200.200.33" { }
+   neighbor "200.200.200.33" { group "mesh" }
+   neighbor "200.200.200.33" { keepalive 10 }
+   neighbor "200.200.200.33" { local-preference 100 }
+   neighbor "200.200.200.33" { local-as as-number 65535 }
+   neighbor "200.200.200.33" { local-as private true }
+   neighbor "200.200.200.33" { add-paths }
+   neighbor "200.200.200.33" { add-paths ipv4 send multipaths }
+   neighbor "200.200.200.33" { add-paths ipv4 receive true }
+   neighbor "200.200.200.33" { add-paths ipv6 send multipaths }
+   neighbor "200.200.200.33" { add-paths ipv6 receive true }
+   neighbor "200.200.200.33" { import }
+   neighbor "200.200.200.33" { import policy ["ALLOW-ALL"] }
+   neighbor "200.200.200.33" { export }
+   neighbor "200.200.200.33" { export policy ["ALLOW-ALL"] }
-   neighbor "200.200.200.200" { }
-   neighbor "200.200.200.200" { group "mesh" }
-   neighbor "200.200.200.200" { keepalive 10 }
-   neighbor "200.200.200.200" { local-preference 100 }
-   neighbor "200.200.200.200" { local-as as-number 65535 }
-   neighbor "200.200.200.200" { local-as private true }
-   neighbor "200.200.200.200" { add-paths }
-   neighbor "200.200.200.200" { add-paths ipv4 send multipaths }
-   neighbor "200.200.200.200" { add-paths ipv4 receive true }
-   neighbor "200.200.200.200" { add-paths ipv6 send multipaths }
-   neighbor "200.200.200.200" { add-paths ipv6 receive true }
-   neighbor "200.200.200.200" { import }
-   neighbor "200.200.200.200" { import policy ["ALLOW-ALL"] }
-   neighbor "200.200.200.200" { export }
-   neighbor "200.200.200.200" { export policy ["ALLOW-ALL"] }

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 and li regions. They are not supported in the bof region.

The following usage guidelines apply to the annotate command:

  • 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.
  • 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 37

*[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 37
            }
        }
    }

*[ex:/configure]
A:admin@node-2# annotate "" /configure router bgp connect-retry

*[ex:/configure]
A:admin@node-2# compare
    router "Base" {
        bgp {
+           connect-retry 37
        }
    }

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).
  • Comments are deleted if an empty comment "# comment: " is entered.
  • 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
  • json
  • xml

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 a configuration

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 {
+       }
    }
Note: The +/-/~ output from the compare command can be copied and pasted, or loaded from a file. See Using the compare outputs to copy and paste for an example.

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 }
+   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 }
+   /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 }

*[ex:/configure]
A:admin@node-2#

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)[/]
A:admin@node-2# compare
    router "Base" {
        interface "system" {
            ipv4 {
                primary {
-                   address 10.1.1.1
+                   address 10.243.5.96
                }
            }
        }
    }

*(ex)[/]
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.

Note:
  • 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.

Note: The validate command does not detect configuration constraints that can only be determined when the candidate is committed, such as a syntactically correct configuration with invalid internal application dependencies, or out of resource conditions.
*(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

*(ex)[/]
A:admin@node-2#

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:

  1. A new snapshot of the running configuration is copied in the baseline datastore.

  2. The candidate configuration changes are merged in the new baseline:

    1. The changes in the candidate datastore are applied to the new baseline datastore.

    2. 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.

    3. 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" { }
+   /configure router "Base" { interface "backbone-2" }
+   /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

!*[pr:/configure]
A:user-1@node-2#

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.

Note: The confirmed option of the commit command is only available for the configure configuration region.

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.

If the commit confirmed accept command is not issued within the specified timeout period after a successful commit, all changes are automatically discarded from the running configuration. If the configuration session from which the commit confirmed was initiated is still active, the candidate configuration maintains all uncommitted configuration changes.

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)[/]
A:admin@node-2# commit confirmed
INFO: CLI #2090: Commit confirmed - automatic rollback in 10 minutes
(ex)[/]
A:admin@test-node# exit all

INFO: CLI #2090: Commit confirmed - automatic rollback in 9 minutes 55 seconds
(ex)[/]
A:admin@test-node# quit-config
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 #2076: Exit global configuration mode canceled

INFO: CLI #2090: Commit confirmed - automatic rollback in 9 minutes 48 seconds
(ex)[/]
A:admin@test-node# 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] y
WARNING: CLI #2077: Exiting global configuration mode - commit confirmed canceled
INFO: CLI #2057: Uncommitted changes are kept in the candidate configuration
Persistent identifier
Note: In private configuration mode, commit confirmed with a persistent identifier cannot be used. Instead, use the non-persistent commit confirmed command.

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.

When auto-config-save is set to false, the admin save command must be issued to make the configuration persistent.

*[ex:/configure system management-interface]
A:admin@node-2# info detail
    
---snip---
        md-cli {
            auto-config-save true
            environment {
                more true
                time-display local
                command-completion {
                    enter true
                    space true
                    tab true
                }

Performing configuration rollback from a saved configuration file

A saved configuration file can be loaded to the candidate configuration with the rollback command.

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.

Automatic save enabled

*[ex:/configure system management-interface]
A:admin@node-2# info detail
    
---snip---
    
        md-cli {
            auto-config-save true
            environment {
                more true
                time-display local
                command-completion {
                    enter true
                    space true
                    tab true
                }

The configuration is also saved if an operator issues the admin save command, regardless of the auto-config save settings.

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 of the configuration file, but is identified with the commit history identifier. If no identifier is specified, the last saved configuration file in the most recent commit history entry is used as the default.

The rollback command is available only in model-driven management interface configuration mode.

Executing the rollback command


[ex:/configure]
A:admin@node-2# rollback Press Tab

<commit-id>
startup
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 files loaded with the rollback command are identified with a number that corresponds to the commit history identifier and location specified configured by the bof configuration primary-location command in the active CPM’s Boot Option File (BOF).

Configuration file executed for a rollback 3 command

For example, the configuration file executed for a rollback 3 command corresponds to the file location in commit history identifier 3. The keyword startup and commit history identifier 0 correspond to the last saved configuration file. This is also the default when no identifier is specified with the rollback command. By default, five configuration files are saved. The configuration-backups command can be used to save a different number of configuration files.

[ex:/configure system management-interface configuration-save]
A:admin@node-2# info detail
 ## apply-groups
 ## apply-groups-exclude
    configuration-backups 5

[ex:/configure system management-interface configuration-save]
A:admin@node-2# configuration-backups

 configuration-backups <number>
 <number>  - <1..200>
 Default   - 5

    Maximum number of backup versions maintained

Name of the configuration file is displayed

The admin show configuration bof command is executed from the MD-CLI and 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"

---snip---

rollback command references the file in the location of the commit history identifier

In the MD-CLI, the rollback command references the file in the location of the commit history identifier, in this case, identifier 3.

[ex:/configure]
A:admin@node-2# rollback 3
Executed 386 lines in 0.4 seconds from file cf3:\config.cfg.3

The rollback command can only be executed from the root of the configuration branch.

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.

Figure 7. Successful commit with auto-config-save true

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.

Figure 8. Successful commit with auto-config-save false

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.

Figure 9. Failed commit

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.

Note: If the router fails to boot because of an invalid configuration syntax, Nokia recommends to correct the syntax and reboot the router, which also reloads persistent indexes. This procedure is preferred over using load full-replace to restore the configuration without a reboot.

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 group "external" { }
    /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

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 group "external" { }
    /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
    group "external" { }
    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
-------------------------------------------------------------------------------
    group "external" { }
    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
    group "external" { }
    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

[ex:/configure]
A:admin@node-2# load merge interactive
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
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
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
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
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'

[ex:/configure router "Base"]
A:admin@node-2#

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 Configuration Groups.

Figure 10. Configuration Groups

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-backbone" {
            router "Base" {
                # configuration elements
            }
        }
        group "isis-access” {
            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

Note:

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-metric-only configuration element from group ‟isis-3” is not inherited because the group is applied at the interface branch and only configuration elements at that level or lower can be inherited.

(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
    }
Note:

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 {
        action deny
match "configure qos sap-ingress"
    }

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 {
        action deny
        match "configure qos sap-ingress"
    }
    entry 201 {
        action deny
match "configure groups group qos sap-ingress"

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.

1 Requires specifying the configuration mode (private | exclusive | global | read-only)
2 Allowed, but no functional value