MD-CLI USER GUIDE Configuring in the MD-CLI

RELEASE 20.7.R1

4 Configuring in the MD-CLI

4.1 Configuration Workflow

4.1.1 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] — indicates a user in private configuration mode (implicit

configuration workflow)
• (ex) [configure] — 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.

Issue: 01 3HE 15820 AAAD TQZZA 01 95

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

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

Figure 2 shows the flow of configuration changes from the candidate configuration to
the running configuration.

Figure 2 Flow of Configuration Changes

make changes candidate commit running

configuration configuration

sw0480

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.

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

96 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

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

Table 17 compares the implicit and explicit configuration workflows.

Table 17 Implicit and Explicit Configuration Mode Features

Implicit Configuration Explicit Configuration

Workflow Workflow

Use User focused on Power user mode with

configuration tasks in the unrestricted navigation
configure branch capabilities

Flexibility Run operational commands Run operational commands

or configuration commands or configuration commands
from the configure branch anywhere

configure Enters configuration mode 1 Navigates to the configure

and navigates to the branch (after edit-config
configure branch command)

edit-config — Enters configuration mode 1

exit all or CTRL-z or / Leaves configuration mode Navigates to the operational

and navigates to the root
operational root

quit-config — Leaves configuration mode

Commands that result in an Execute the command Execute the command

action or display output

Commands that navigate Not allowed Navigate

out of the configure branch

Issue: 01 3HE 15820 AAAD TQZZA 01 97

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

Table 17 Implicit and Explicit Configuration Mode Features (Continued)

Implicit Configuration Explicit Configuration

Workflow Workflow
info and configuration Allowed Allowed
commands in the configure
branch

info and configuration Not allowed Allowed

commands out of the
configure branch

Notes:

1. Requires specifying the configuration mode (private | exclusive | global | read-

only)

4.1.3.1 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). 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.

[]
A:admin@node-2# configure exclusive router
^^^^^^
MINOR: CLI #2069: Operation not allowed - currently in operational mode

[]
A:admin@node-2#

98 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

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
•/
•}
[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 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 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#

Issue: 01 3HE 15820 AAAD TQZZA 01 99

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

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

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

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

100 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

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

(ex)[tools]
A:admin@node-2# exit all

(ex)[]
A:admin@node-2# quit-config
INFO: CLI #2064: Exiting exclusive configuration mode

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

[]
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#

Transitioning from an explicit to an implicit configuration workflow is not supported.

Issue: 01 3HE 15820 AAAD TQZZA 01 101

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

4.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 detailed information about configuration workflows, see Implicit and Explicit
Configuration Workflows.

The configuration mode determines the interaction with other simultaneous

configuration sessions. Table 18 provides an overview of the available configuration
modes:

• private configuration mode — see Private Configuration Mode for details

• exclusive configuration mode — see Exclusive Configuration Mode for details
• global configuration mode — see Global Configuration Mode for details
• read-only configuration mode — see Read-Only Configuration Mode for details

Table 18 Configuration Mode Overview

Private Exclusive Global Read-only

Configuration Mode Configuration Mode Configuration Mode Configuration Mode

Candidate Private candidate Global candidate Global candidate Global candidate

configuration configuration configuration configuration configuration
accessed

Single vs Multiple users can Only one user can Multiple users can Multiple users can
multiple simultaneously configure the global simultaneously have simultaneous
users configure their own candidate configure the shared read-only access to
private candidate global candidate the global candidate

Privacy User can see own User can see own User can see Users can see
changes. changes. changes from other changes from global
Changes are not Changes are visible global configuration or exclusive
visible for read-only for read-only sessions. configuration
sessions. sessions. Changes are visible sessions
for read-only
sessions.

Commits Own changes are Own changes are Changes made by all Users cannot commit
committed committed. global configuration
Commits from other sessions are
configuration changes committed
are blocked.

102 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

Table 18 Configuration Mode Overview (Continued)

Private Exclusive Global Read-only

Configuration Mode Configuration Mode Configuration Mode Configuration Mode
Update Yes - baseline can No - baseline is Yes - baseline can No - updates are not
needed? become out-of-date always up-to-date. become out-of-date allowed in read-only
when another private Other configuration when a private configuration mode
or global sessions cannot configuration session
configuration session commit. commits
commits

Note: Private configuration mode should not be used in the MD-CLI when the router is also
configured using NETCONF or gRPC for the following reasons:

• private candidate configurations are not visible over NETCONF or gRPC

• an equivalent function of the MD-CLI update command to manage an out-of-date
baseline is not available in NETCONF or gRPC

4.2.1 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

Figure 3 shows multiple candidate configurations.

Issue: 01 3HE 15820 AAAD TQZZA 01 103

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

Figure 3 Multiple Candidate Configurations

running
commit commit

snapshot, snapshot, track

update update
private read-only
configuration mode active configuration configuration mode
ro: ro:
private ro: global ro:
private
private
gl:
candidate baseline
private ex: baseline candidate gl:
pr: baseline candidate
pr : baseline candidate candidate configuration
pr: exclusive global
configuration mode configuration mode
private
exclusive candidate configuration
(system use only)

Contains changes relative to its A snapshot of the running configuration

associated baseline datastore at a particular moment in time
candidate baseline

sw0637

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

given 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 configuration session is mutually exclusive with a global
configuration session. Read-only configuration sessions can co-exist with an
exclusive configuration session or with one or multiple global configuration
sessions.

104 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

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 for system use only. 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. For more information, see Exclusive Private
Configuration Session.

When a configuration session commits its candidate configuration, the router

performs the following actions:

• verifies the running configuration has not been changed by another

configuration session
• validates the candidate configuration by verifying the logic, constraints, and
completeness of the candidate configuration
• activates the candidate configuration by sending the new candidate
configuration to the corresponding applications

After a successful commit, the changes are copied to the running datastore, the
baseline datastore contains a new copy of the running datastore, and the candidate
datastore is empty.

Furthermore, when simultaneous configuration sessions access different candidate

configurations:

• multiple private configuration sessions each access their own private candidate
configuration
• one or multiple private configuration sessions each access their own private
candidate configuration and one or multiple global configuration sessions all
accessing the global candidate configuration
• one or multiple private configuration sessions each access their own private
candidate configuration and one exclusive configuration session accessing the
global candidate configuration
• one or multiple private configuration sessions each access their own private
candidate configuration and one private exclusive configuration session
accessing a private candidate configuration

Issue: 01 3HE 15820 AAAD TQZZA 01 105

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

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 given 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 Figure 4.

Figure 4 Simultaneous Configuration Sessions

[ro:configure router “Base”]
A:admin@pe1# info running
interface “system” {
snapshot snapshot
description “loopback”
}

running configuration

*[pr:configure router “Base”] *[pr:configure router “Base”]

A:user-1@pe1# info candidate A:user-2@pe1# info candidate
interface “int-1” { interface “int-2” {
description “interface 1” description “interface 2”
port 1/1/4 port 1/1/10
} }
interface “system” { interface “system” {
description “loopback” user-1 and user-2 description “loopback”
cannot see each
} }
other’s changes
private candidate configuration 1 private candidate configuration 2
sw0638

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.

Figure 5 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.

106 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

Figure 5 Simultaneous Configuration Sessions - Baseline Out-of-Date

[ro:configure router “Base”]
The baseline datastore of private candidate
A:admin@pe1# info running configuration 2 is out-of-date because user-1’s
commit interface “int-1” { commit touched the running datastore after the
description “interface 1” baseline datastore snapshot copy was taken
port 1/1/4
}
*[pr:configure router “Base”] interface “system” {
A:user-1@pe1# commit description “loopback”
}
[pr:configure router “Base”]
A:user-1@pe1# info baseline running configuration
interface “int-1” { !*[pr:configure router “Base”]
description “interface 1” A:user-2@pe1# info baseline
port 1/1/4 interface “system” {
} description “loopback”
interface “system” { }
description “loopback”
} !*[pr:configure router “Base”]
The baseline datastore of A:user-2@pe1# info candidate
[pr:configure router “Base”] private candidate configuration 1 interface “int-2” {
A:user-1@pe1# info candidate is up-to-date after a commit description “interface 2”
interface “int-1” { !–baseline status port 1/1/10
description “interface 1” indicator in the prompt }
port 1/1/4 interface “system” {
} description “loopback”
interface “system” { }
description “loopback”
} private candidate configuration 2

private candidate configuration 1

sw0639

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 Figure 6.

Figure 6 Simultaneous Configuration Sessions - Update

!*[pr:configure router “Base”] private candidate configuration 1
running configuration A:user-2@pe1# info baseline
interface “system” { *[pr:configure router “Base”]
[ro:configure router “Base”] A:user-2@pe1# info baseline
description “loopback”
A:admin@pe1# info running interface “int-1” {
}
interface “int-1” { description “interface 1”
description “interface 1” port 1/1/4
!*[pr:configure router “Base”]
port 1/1/4 }
A:user-2@pe1# info candidate
} interface “system” {
interface “int-2” {
interface “system” { description “loopback”
description “interface 2”
description “loopback” }
port 1/1/10
}
}
interface “system” { *[pr:configure router “Base”]
description “loopback” A:user-2@pe1# info candidate
} interface “int-1” {
!*[pr:configure router “Base”] description “interface 1”
update port 1/1/4
A:user-2@pe1# update/configure
}
interface “int-2” {
description “interface 2”
port 1/1/10
After an update, the baseline datastore contains a new }
copy of the running datastore and the changes are interface “system” {
merged in the candidate datastore. The baseline status description “loopback”
indicator (!) is no longer present in the prompt. }

sw0640

Issue: 01 3HE 15820 AAAD TQZZA 01 107

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

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

Figure 7 Simultaneous Configuration Sessions - Merge Conflict

running configuration !*[pr:configure router “Base”]
[ro:configure router “Base”] A:user-2@pe1# info baseline
A:admin@pe1# info running interface “int-backbone” {
interface “int-backbone” { }
admin-state enable
} !*[pr:configure router “Base”]
A:user-2@pe1# compare baseline candidate full-context
+ /configure router “Base” interface “int-backbone” admin-state disable
commit
!*[pr:configure router “Base”]
A:user-2@pe1# update/configure
update
+ /configure router “Base” interface “int-backbone” admin-state disable
## admin-state-exists with different value: admin-state enable-change
updated: replace existing value

*[pr:configure router “Base”] *[pr:configure router “Base”]

A:user-1@pe1# commit A:user-2@pe1# info baseline
interface “int-backbone” { A merge conflict is detected during update: the configuration
[pr:configure router “Base”] admin-state-enable element admin-state was added with a different value in the
A:user-1@pe1# info baseline } running configuration after the baseline snapshot was taken
interface “int-backbone” {
admin-state enable *[pr:configure router “Base”]
} A:user-2@pe1# compare baseline candidate
interface “int-backbone” {
[pr:configure router “Base”] - admin-state enable
A:user-1@pe1# info candidate + admin-state disable
interface “int-backbone” { }
admin-state enable The merge conflict is resolved by replacing the
} existing value

private candidate configuration 1 private candidate configuration 2 sw0641

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 - list the changes that were made in the running
datastore since a snapshot copy was stored in the baseline datastore
• compare baseline candidate or compare - list the candidate configuration
changes
• update check - perform 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.

108 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

Conflict detection and resolution is detailed in Updating the Candidate Configuration.

4.2.2 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 co-exist. 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.

Issue: 01 3HE 15820 AAAD TQZZA 01 109

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

• An exclusive configuration session can co-exist 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 co-exist 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 co-exist 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

110 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

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

Note: Private configuration mode should not be used in the MD-CLI when the router is also
configured using NETCONF or gRPC for the following reasons:

• private candidate configurations are not visible over NETCONF or gRPC

• an equivalent function of the MD-CLI update command to manage an out-of-date
baseline is not available in NETCONF or gRPC

4.2.3 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:

Issue: 01 3HE 15820 AAAD TQZZA 01 111

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

• 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 co-exist 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.
• Global configuration sessions are mutually exclusive with an exclusive
configuration session.
• Multiple read-only configuration sessions can co-exist 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-

112 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

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. E
xiting exclusive configuration mode will discard those changes.

Discard uncommitted changes? [y,n] y

WARNING: CLI #2062: Exiting exclusive configuration mode -
uncommitted changes are discarded

Issue: 01 3HE 15820 AAAD TQZZA 01 113

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

4.2.4 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 co-exist 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 configuration session is mutually exclusive with a global
configuration session.
• Multiple global configuration sessions can co-exist. 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 co-exist 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:

114 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

• 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

Issue: 01 3HE 15820 AAAD TQZZA 01 115

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

Note: CLI #2057 is shown only when applicable.

4.2.5 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 co-exist 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 co-exist 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 co-exist 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.

116 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

• Multiple read-only configuration sessions can co-exist. 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

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

Figure 8 summarizes the configuration mode transitions and transitions to

operational mode.

Issue: 01 3HE 15820 AAAD TQZZA 01 117

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

Figure 8 Configuration and Operational Mode Transitions

Configuration and To
Operational Mode
Global Exclusive Read-Only Private Operational
Transition
Mode

Global X1 Allowed, no Allowed, X Allowed,

other exclusive uncommitted uncommitted
or global changes are changes are
configuration kept kept
session can
be active,
uncommitted
changes are
kept

Exclusive Allowed, X1 Allowed, X Allowed,

uncommitted uncommitted uncommitted
changes are changes are changes are
discarded discarded discarded

From Read-Only Allowed, no Allowed, no X1 X Allowed,

exclusive other exclusive uncommitted
configuration or global changes are
session can configuration kept
be active, session can
uncommitted be active,
changes are uncommitted
kept changes are
kept

Private X X X X1 Allowed,
uncommitted
changes are
discarded

Operational Allowed Allowed Allowed Allowed X

Mode
sw0654
Note: 1. Allowed, but no functional value.

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"]

118 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

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

Issue: 01 3HE 15820 AAAD TQZZA 01 119

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

*(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#

4.2.7 Exclusive Private Configuration Session

An exclusive private configuration session is reserved for system internal use.

Note: Exclusive private is not a configuration mode. An MD-CLI session cannot enter an
exclusive private configuration mode.

Router configuration changes are made via an exclusive private configuration

session as a result of the following scenarios.

• The management interface configuration mode is set to mixed, with one of the
following actions:
- an SNMP set operation
- any (immediate) configuration performed in the classic CLI engine
- a gNMI configuration operation
• The management interface configuration mode is set to model-driven, with the
following action:
- a gNMI configuration operation

It is important to be aware that an exclusive private 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 configurations can
become out-of-date when changes are committed via an exclusive private
configuration session.
• Commits from global and private configuration sessions are blocked when an
exclusive private configuration session is active.

120 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

• An exclusive private 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.

4.2.8 Restricting Configuration Mode Sessions

It may be desirable to deny a user the ability to use certain 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

Issue: 01 3HE 15820 AAAD TQZZA 01 121

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

[]
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

122 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

[]
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'

Issue: 01 3HE 15820 AAAD TQZZA 01 123

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

4.3 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, and 7950 XRS 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.

124 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

4.4 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 rather than using
the default, in case the default changes.

Refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR MD-CLI Command
Reference Guide for configuration commands and their appropriate syntax.

4.4.1 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 certain default is assumed. For example, configure router bgp with no
instance value expands to configure router “Base” bgp. Default values are
implemented as follows:

• 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#

Issue: 01 3HE 15820 AAAD TQZZA 01 125

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

(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#

4.4.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.
*(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

126 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

*(ex)[configure router "Base" bgp]

A:admin@node-2#

In this example, the etype parameter is a hexadecimal output value. 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.

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)

Issue: 01 3HE 15820 AAAD TQZZA 01 127

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

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

4.4.3 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. In the
following example, ip-address is the first key and port is the second key. Entering
ip-address in the MD-CLI is optional; entering port and any subsequent key names
is mandatory.

*[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 on the remote Cflowd collector host to receive the exported
Cflowd data

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. In the following example, the key name index must be
entered.

128 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

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

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

*[ex:configure eth-cfm domain "dmtest"]

A:admin@node-2# association "ma-admin-name"

*[pr:configure eth-cfm domain "dmtest" association "ma-admin-name"]

A:admin@node-2# pwc
Present Working Context:
configure

Issue: 01 3HE 15820 AAAD TQZZA 01 129

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

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.

*[ex:configure eth-cfm domain "dmtest"]

A:admin@node-2# association ma-admin-name ma-admin-name

*[pr: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"

4.4.3.1 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

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" {

130 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

}
domain "zero" {
}

4.4.3.2 User-Ordered Lists

For user-ordered lists, new entries are appended to the end of 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 desired
order. Alternatively, the tilde (~) character can be used to replace a list, effectively
deleting and recreating the list in one step.

*[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.

In the following configuration example, the 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"]

Issue: 01 3HE 15820 AAAD TQZZA 01 131

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

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" {
}

The insert command is used with the following commands:

*[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" {

132 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

}
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" {
}

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#

4.4.3.3 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]

Issue: 01 3HE 15820 AAAD TQZZA 01 133

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

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" { }

4.4.4 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 ([]).

4.4.4.1 System-Ordered Leaf-Lists

For leaf-lists ordered by the system, the leaf-list entries are automatically reordered,
as shown in the following example.

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

134 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

*[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]

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)

Match address families to this 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]

4.4.4.2 User-Ordered Leaf-Lists

For user-ordered leaf-lists, new entries are 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 {

Issue: 01 3HE 15820 AAAD TQZZA 01 135

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

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 can be deleted and recreated using
the desired order. Alternatively, the tilde (~) character can be used to replace a leaf-
list, effectively deleting and recreating the leaf-list in one step.

(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#

136 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

4.4.5 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, FRI 11 MAY 2018 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. 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:

Issue: 01 3HE 15820 AAAD TQZZA 01 137

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

• 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. 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. For example, entering 900 (deciseconds) for transmit-interval
results in an error display, as 990 deciseconds is not in the element range.

*[ex:configure port 1/1/1 ethernet efm-oam]

A:admin@node-2# transmit-interval 950
^^^
MINOR: MGMT_CORE #2301: Invalid element value - 900 out of range 1..600

Entering a value followed by Space 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.

*[ex:configure port 1/1/1 ethernet efm-oam]

138 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

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.

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

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.

Table 19, Table 20, and Table 21 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 19 shows the valid inputs for memory sizes based on the dynamic unit.

Table 19 Dynamic Units for Memory Sizes

Unit Name Valid MD-CLI Input

bytes • bytes
• byte

kilobytes • kilobytes
• kilobytes
• kbytes
• kbyte

Issue: 01 3HE 15820 AAAD TQZZA 01 139

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

Table 19 Dynamic Units for Memory Sizes (Continued)

Unit Name Valid MD-CLI Input

megabytes • megabytes
• megabyte
• mbytes
• mbyte

gigabytes • gigabytes
• gigabyte
• gbytes
• gbyte

terabytes • terabytes
• terabyte
• tbytes
• tbyte

Table 20 shows the valid inputs for rates of speed based on the dynamic unit.

Table 20 Dynamic Units for Rates

Unit Name Valid MD-CLI Input

bps (bits per second) • bps

kilobps (kilobits per second) • kilobps

• kbps

megabps (megabits per • megabps

second) • mbps

gigabps (gigabits per • gigabps

second • gbps

terabps (terabits per • terabps

second) • tbps

petabps (petabits per • petabps

second) • pbps

exabps (exabits per • exabps

second) • ebps

zettabps (zettabits per • zettabps

second) • zbps

140 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

Table 21 shows the valid inputs for time durations based on the dynamic unit.

Table 21 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

Issue: 01 3HE 15820 AAAD TQZZA 01 141

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

Table 21 Dynamic Units for Duration (Continued)

Unit Name Valid MD-CLI Input

hours • hours
• hour
• hrs
• hr

days • days
• day

weeks • weeks
• week
• wks
• wk

Table 22 shows the valid inputs for dates based on the time format.

Table 22 Dynamic Units for Dates and Time

Date and Time Format Valid MD-CLI Input

“yyyy-mm-dd hh:mm[:ss] [TZ]” yyyy is RFC 3339 date-fullyear

mm is RFC 3339 date-month
For example: “2018-06-01 13:12:59 EDT” 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.

142 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

Table 22 Dynamic Units for Dates and Time (Continued)

Date and Time Format Valid MD-CLI Input

“[DAY] dd MON yyyy hh:mm[:ss] [TZ]” DAY is the name of the day of the week (SUN, MON, TUE,
WED, THU, FR, SAT),(optional)
For example: “FRI 11 MAY 2018 13:21:11 EDT” 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)] This format follows RFC 3339 and can be enclosed in

quotation marks.
For example: 2018-05-11T13:21:11-0400
or
2018-05-11T17:21:11Z

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

This example shows the hexadecimal digits in an IPv6 address entered in both
uppercase and lowercase. 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, the dash (-) separator can also be used in place of the 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

Issue: 01 3HE 15820 AAAD TQZZA 01 143

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

*[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 is also 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#

4.4.7 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 sign, en dash, em dash, and others to
ASCII hyphen-minus (-)

The input translation allows copy and paste functionality from word processing
applications that use UTF-8 curly quotation marks, hyphens, or dashes.

144 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

4.5 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: The minus sign (-) 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.

4.5.1 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

Issue: 01 3HE 15820 AAAD TQZZA 01 145

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

*(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---

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

This example removes the instance from 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

This example shows the deletion of the instance from context configure:

*[ex:configure service]
A:admin@node-2# info
vprn "vprn1" {
description "VPRN instance 01"
dns {

146 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

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

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 {
}

Issue: 01 3HE 15820 AAAD TQZZA 01 147

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

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 {
}

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 {
}

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

148 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

*(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#

An 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. 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#

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]

Issue: 01 3HE 15820 AAAD TQZZA 01 149

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

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#

The following delete operation removes 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#

The following delete operation removes 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#

150 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

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

*(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.

*(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#

An explicit wildcard (*) deletes all members of a leaf-list.

*(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#

The wildcard can optionally be enclosed in brackets.

*(ex)[configure system security user-params local-user user "test" console]

Issue: 01 3HE 15820 AAAD TQZZA 01 151

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

A:admin@node-2# delete member [*]

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#

152 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

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

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.

Enter the context for configuring the profile for guest2:

(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"

Issue: 01 3HE 15820 AAAD TQZZA 01 153

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

*(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 {

154 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

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”; for example:

*(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"

Issue: 01 3HE 15820 AAAD TQZZA 01 155

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

*(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. The following example begins with a “guest1” user profile, which is
subsequently deleted and re-added using the output from the info full-context
command.

The following output shows the “guest1” user profile:

*(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 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 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 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 action deny
/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#

156 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

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.
Since the output contains the full configuration path, the statements can be pasted
from any configuration context.

*(ex)[configure system security aaa local-profiles]

A:admin@node-2# top

*(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

Issue: 01 3HE 15820 AAAD TQZZA 01 157

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

*(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#

*(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.

158 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

4.7 Committing a Configuration

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

— compare [[from] string] [[to] string] [lines number] [summary] [flat | full-context]

[ex:configure]
A:admin@node-2# compare ?

compare [[from] <string>] [[to] <string>]

[[from] <string>]
<string> - (baseline|candidate|rollback <number>|running|startup|url
<string>)
Default - baseline

Source configuration from which to compare

[[to] <string>]
<string> - (baseline|candidate|rollback <number>|running|startup|url
<string>)
Default - candidate

Configuration to compare against source configuration

flat - Show the context from the pwc on each line

full-context - Show the full context on each line
lines - Number of lines of context to display before and after
summary - Suppress specific differences and display a summary

Table 23 provides a description of the compare command options.

Issue: 01 3HE 15820 AAAD TQZZA 01 159

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

Table 23 Compare Command Options

Option Description

[from] string Specify the reference datastore or configuration source to

compare (default is from baseline). Options are:
• baseline
• candidate
• rollback checkpoint-id
• running
• url string
• startup

[to] string Specify the datastore or configuration source to compare

against (default is to candidate). Options are:
• baseline
• candidate
• rollback checkpoint-id
• running
• url string
• startup

flat Show the context starting from the present working context

full-context Show the context starting at the branch root

lines number Show the specified number of lines before and after the
changed element

summary Suppress specific differences and display a summarized

comparison

The following characters are used at the beginning of the output lines, to indicate the
status of the element in the configuration:

• - (minus) — element is only in the first (from) configuration, displayed first

• + (plus) — element is only in the second (to) configuration, displayed second
• (space) — element is unchanged
• ~ (tilde) — new value of the element that changed (only used in the summary
option)
• {...} — deleted elements compressed to its highest container (only used in the
summary option)
*(ex)[configure]
A:admin@node-2# compare
log {
+ accounting-policy 5 {

160 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

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

Because the compare command uses the default from running, the command
compare to candidate is equivalent to compare from running to candidate.
Executing compare to running, without specifying the from option is equivalent to
compare from running to running, which shows no differences.

*(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 {
+ }
}

The following displays the output using the flat and full-context options.

*(ex)[configure]
A:admin@node-2# compare flat
+ log { accounting-policy 5 }

Issue: 01 3HE 15820 AAAD TQZZA 01 161

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

+ 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#

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 1.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
}
}
}
}

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

162 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

4.7.1.1 Using the compare Outputs to Copy and Paste

In the following example, the compare command shows the timers that have been
modified. After the commit command has been issued to add these to the running
configuration, the lsa-generate container is deleted. The following displays the
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
+ }

The compare command, using the candidate configuration as the reference,

displays the same configuration statements with a preceding minus (-) character.
These statements will be used in a subsequent copy and paste function to delete
some of the configuration. The minus (-) character at the beginning of the
configuration statement takes the place of the delete keyword.

*(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

In the next step, the lsa-generate parameters 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]

Issue: 01 3HE 15820 AAAD TQZZA 01 163

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

A:admin@node-2# - /configure router "Base" ospf 0 timers lsa-generate lsa-second-

wait 200000

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 { ... }
}
}
}

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#

4.7.2 Discarding Configuration Changes

The discard command in configuration mode cancels all changes made to the
candidate configuration without impacting the running configuration or applications.
The command is available only when the MD-CLI session is in a read/write
configuration mode (private, exclusive, or global configuration mode) and only from
the top of the configure branch (that is, /configure).

164 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

The following example shows the error that occurs when the discard operation is
attempted from read-only configuration mode. The command is successful when the
session is in global configuration mode, but only from the top of the configuration
branch.

*(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

*(ro)[configure]
A:admin@node-2# exit

*(ro)[]
A:admin@node-2# quit-config
INFO: CLI #2067: Exiting read-only configuration mode

[]
A:admin@node-2# edit-config global
INFO: CLI #2054: Entering global configuration mode
INFO: CLI #2055: Uncommitted changes are present in the candidate configuration

*(ex)[]
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 {
+ }
}

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

*(ex)[configure log]
A:admin@node-2# discard
MINOR: MGMT_CORE #2203: Invalid element - 'discard' not allowed in 'log'

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

(ex)[configure log]

Issue: 01 3HE 15820 AAAD TQZZA 01 165

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

A:admin@node-2# compare

(ex)[configure log]
A:admin@node-2#

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:

*(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

It is possible to discard the changes made by a session that obtained an explicit lock
by disconnecting the remote session. Uncommitted changes from an exclusive
configuration mode session are discarded when the session disconnects. See
Viewing the Status of the Local Datastores for information about disconnecting a
session.

4.7.3 Validating the Candidate Configuration

The validate command verifies the logic, constraints, and completeness of the
candidate configuration without activating any changes. A successful validation
returns no errors. If the validation fails, detailed failure reasons are provided. The
validate command can be executed from any working directory and in any
configuration mode.

*(ro)[]
A:admin@node-2# compare
log {
+ accounting-policy 7 {
+ description "seven"
+ collection-interval 77
+ }
}

*(ro)[]
A:admin@node-2# validate

*(ro)[]

*(ex)[]

166 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

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.

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

Issue: 01 3HE 15820 AAAD TQZZA 01 167

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

• The baseline datastore tracks the running datastore, that is, changes in the
running datastore are automatically copied in the baseline datastore:
- after a router reboot
- after a successful commit
- after a discard with an up-to-date global baseline
• Tracking stops and a snapshot of the running datastore is copied in the global
baseline datastore when the global candidate is touched (for example, a
configuration element is added, deleted, or modified). A new snapshot of the
running datastore is copied in the global baseline datastore when a manual
update is performed.

With two simultaneous active configuration sessions that access different candidate
configurations, a commit from one configuration session changes the running
configuration and causes the candidate configuration of the other session to be out
of date and must be updated.

To update a candidate configuration, the following tasks are performed.

• a new snapshot of the running configuration is copied in the baseline datastore

• the candidate configuration changes are merged in the new baseline:
- The changes in the candidate datastore are applied to the new baseline
datastore.
- Merge conflicts are detected and resolved. A merge conflict occurs when a
configuration element is added, deleted, or modified in the candidate
configuration and the same configuration element was also added, deleted,
or modified in the running configuration after the baseline snapshot was
taken.
- The resulting changes are stored in the candidate datastore as new
changes relative to the updated baseline.

An update can be performed manually with the update command. The update must
be executed at the configuration root (/configure). Merge conflicts are reported and
resolved according to the conflict resolution rules. The update command does not
provide output when no conflicts are detected.

The following is an example of a 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.

168 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

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.

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

!*[pr:configure router "Base"]

A:user-1@node-2# info running
interface "backbone-1" {
ipv4 {
primary {
address 10.2.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 10.1.1.1

Issue: 01 3HE 15820 AAAD TQZZA 01 169

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

prefix-length 24
}
}
}

The following is the 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 10.1.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 10.1.1.1

## address - exists with different value: address 10.2.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 10.1.1.1

170 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

## address - exists with different value: address 10.2.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 10.2.2.2
+ address 10.1.1.1
}
}
}

*[pr:configure router "Base"]

A:user-1@node-2# info
interface "backbone-1" {
ipv4 {
primary {
address 10.1.1.1
prefix-length 24
}
}
}

*[pr:configure router "Base"]

A:user-1@node-2# info baseline
interface "backbone-1" {
ipv4 {
primary {
address 10.2.2.2
prefix-length 24
}
}
}

*[pr:configure router "Base"]

A:user-1@node-2# info running
interface "backbone-1" {
ipv4 {
primary {
address 10.2.2.2
prefix-length 24
}
}
}

Issue: 01 3HE 15820 AAAD TQZZA 01 171

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

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

!*[pr:configure router "Base"]

A:user-1@node-2# info running
interface "backbone-1" {
ipv4 {
primary {
address 10.1.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 10.2.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 10.2.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#

172 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

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 10.1.1.1
prefix-length 24
}
}
}
interface "backbone-2" {
ipv4 {
primary {
address 10.2.2.2
prefix-length 24
}
}
}

4.7.5 Committing the Candidate Configuration

The commit command can be executed from any hierarchy level within any
configuration branch.

— commit
— confirmed
— [timeout] minutes
— accept
— cancel
— persist-id string

Issue: 01 3HE 15820 AAAD TQZZA 01 173

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

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. When a merge conflict is detected,
the commit operation is canceled to allow the administrator to resolve the merge
conflicts manually.

!*[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 the update process.

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

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

174 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

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.

*(gl)[configure log accounting-policy 5]

A:admin@node-2# commit confirmed

INFO: CLI #2090: Commit confirmed - automatic rollback in 9 minutes 59 seconds

(gl)[configure log accounting-policy 5]
A:admin@node-2#

INFO: CLI #2090: Commit confirmed - automatic rollback in 9 minutes 47 seconds

(gl)[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

(gl)[configure log accounting-policy 5]
A:admin@node-2# back

INFO: CLI #2090: Commit confirmed - automatic rollback in 9 minutes 41 seconds

(gl)[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

(gl)[configure log]
A:admin@node-2#

INFO: CLI #2090: Commit confirmed - automatic rollback in 8 minutes 44 seconds

(gl)[configure log]
A:admin@node-2#

If the initial commit fails, the commit confirmed operation is canceled and no timer
is started.

*(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.

Issue: 01 3HE 15820 AAAD TQZZA 01 175

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

*(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#

Once the commit confirmed operation is underway, the timer starts. A commit
confirmed cancel command terminates an ongoing confirmed commit and
immediately performs an automatic rollback to the previous state before the initial
commit confirmed command was issued.

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

4.7.5.1.1 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)[]

176 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

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

4.7.5.1.2 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#

Issue: 01 3HE 15820 AAAD TQZZA 01 177

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

4.8 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
primary-config. This is achieved with the admin save command without specifying
a location that defaults to the BOF primary-config.

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.

*(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
}

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

178 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

4.9 Rolling Back a Configuration from a

Checkpoint File
A rollback checkpoint is an MD-CLI configuration file that can be loaded in the
candidate configuration with the rollback command.

A rollback checkpoint is created automatically after every successful commit when

automatic save is enabled via the MD-CLI auto-config-save command.

*(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
}

A rollback checkpoint is also created if an operator issues the admin save

command, regardless of the MD-CLI auto-config save setting.

The rollback command loads a previously saved MD-CLI configuration file to the
candidate configuration. Loading the file does not automatically initiate a commit
command, which means that the file can be examined before committing. This
rollback command is the equivalent of a load full-replace of the configuration file,
but is identified with a checkpoint identifier. If no identifier is specified, the latest
saved configuration file identified with index identifier 0 is used as the default.

The rollback command is available only for the model-driven management

interface configuration mode.

[ex:configure]
A:admin@node-2# rollback ?

rollback

[checkpoint] (<number> | <keyword>)

<number> - <0..200>
<keyword> - startup

ID corresponding to the configuration file to roll back

[checkpoint] - ID corresponding to the configuration file to roll back

Issue: 01 3HE 15820 AAAD TQZZA 01 179

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

Configuration files loaded with the rollback checkpoint command are identified with
a number that corresponds to the configuration file and location specified as primary-
config in the active Boot Option File (BOF). For example, the configuration file
executed for a rollback 3 command corresponds to the file named config.cfg.3. The
checkpoint identifier 0 corresponds to the last saved configuration file and does not
have a suffix. This is also the default when no checkpoint identifier is specified with
the rollback command. By default, five configuration files are saved. The
configuration-backups command can be used to save a different number of
configuration files.

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

[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

The //show bof command executed from the MD-CLI shows the name of the file as
config.cfg.

(ro)[]
A:admin@node-2# //show bof
INFO: CLI #2051: Switching to the classic CLI engine
A:node-2# /show bof
===============================================================================
BOF (Memory)
===============================================================================
primary-image ---snip---
primary-config ---snip---/config.cfg
license-file ---snip---/license

In the MD-CLI, the rollback command references the same filename with an
appended suffix of the checkpoint identifier, in this case, identifier 3:

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

The rollback command is available in global or exclusive configuration mode and

can only be executed from the root of the configuration branch.

180 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

When the auto-config-save parameter is set to true, the rollback command

(without an index) is the equivalent of executing the discard command for the current
candidate configuration changes.

The following figures show the relationship between the candidate and running
configurations, the commit command, the setting of the auto-config-save
parameter, and the rollback checkpoint files.

In Figure 9, the auto-config-save parameter is set to true. With a successful

commit, a rollback checkpoint is created.

Figure 9 Successful Commit with auto-config-save true

uncommitted
changes rollback checkpoint
candidate running A
configuration configuration
datastore datastore

activation in rollback checkpoint

progress B
candidate commit running
configuration configuration
datastore datastore
activation
complete
rollback checkpoint C
candidate commit running
configuration configuration
datastore datastore
auto-config-save true

rollback checkpoint
D
candidate commit running
configuration complete configuration
datastore datastore
sw0482

In Figure 10, the auto-config-save parameter is set to false. The admin save
command creates a rollback checkpoint of the running configuration before the
commit. However, a rollback checkpoint is not created after the successful commit.

Issue: 01 3HE 15820 AAAD TQZZA 01 181

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

Figure 10 Successful commit with auto-config-save false

uncommitted
changes rollback checkpoint
candidate running A
configuration configuration
datastore datastore
auto-config-save false

rollback checkpoint B
candidate running admin save
configuration configuration
datastore datastore
activation
complete
rollback checkpoint C
candidate commit running
configuration configuration
datastore datastore

rollback checkpoint
D
candidate commit running
configuration complete configuration
datastore datastore
sw0483

In Figure 11, the commit fails and no rollback checkpoint is created, regardless of the
setting of the auto-config-save parameter.

Figure 11 Failed commit

uncommitted
changes rollback checkpoint
candidate running A
configuration configuration
datastore datastore
auto-config-save false

activation in rollback checkpoint

progress B
candidate commit running
configuration configuration
datastore datastore

rollback checkpoint C
automatic
candidate commit running rollback
configuration configuration
datastore datastore

rollback checkpoint
D
candidate commit running
configuration complete configuration
datastore datastore
sw0484

182 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

4.10 Loading a Configuration File

The load command loads the contents of a local or remote file into the candidate
configuration. The command can only be executed at the top of the configure region
when the MD-CLI session is in private, exclusive, or global configuration mode and
does not result in a context change. The command can be issued regardless of
whether uncommitted changes are present in the candidate configuration datastore.

The syntax of the load command is as follows:

load [mode] (full-replace | merge) [url] filename

The full-replace option replaces the current candidate configuration with the
specified file.

The merge option merges the contents of the specified file into the candidate
configuration. If there are conflicts, the configuration statements in the specified file
override the existing configuration statements.

The file to be loaded is not a CLI script to be executed and cannot include:

• 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 encounters errors, parsing terminates at the first error. Statements
before the error are loaded into the candidate configuration. Configuration
statements in the loaded file are also subject to AAA command authorization. An
authorization check failure also terminates the execution of further statements in the
file.

Note: If the router fails to boot due to an invalid configuration syntax, it is recommended to
correct the syntax and reboot the router, which also reloads persistent indices. This
procedure is preferred over using load full-replace to restore the configuration without a
reboot.

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

Issue: 01 3HE 15820 AAAD TQZZA 01 183

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

The following shows the 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

*(ex)[configure router "Base" bgp]

A:admin@node-2# //file dir
INFO: CLI #2051: Switching to the classic CLI engine
*A:node-2# /file dir

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.

INFO: CLI #2052: Switching to the MD-CLI engine

From the MD-CLI, the //file type command displays the contents of the file:

*[ro:configure router "Base" bgp]

A:admin@node-2# //file type cf3:testbgp.cfg
INFO: CLI #2051: Switching to the classic CLI engine
*A:node-2>config>profile# /file type 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

===============================================================================

184 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

INFO: CLI #2052: Switching to the MD-CLI engine

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

The output from the info flat command 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 type cf3:testbgp.cfg
INFO: CLI #2051: Switching to the classic CLI engine
*A:node-2>config>profile# /file type 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

===============================================================================

Issue: 01 3HE 15820 AAAD TQZZA 01 185

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

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 type cf3:testbgp.cfg
INFO: CLI #2051: Switching to the classic CLI engine
*A:node-2>config>profile# /file type 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

===============================================================================

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

The following shows the output from the info command. To use the output in a load
file, the context must be added through a manual edit, similar to the edit of file
testbgp.cfg in the preceding example, or use the output from the info full-context
command.

*[ro:configure router "Base" bgp]

A:admin@node-2# info

186 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

group "external" {
}
neighbor "192.168.89.8" {
group "external"
prefix-limit ipv4 {
maximum 200
log-only true
threshold 80
}
}

The contents of the load file with the info output include the following:

/configure router "Base" bgp

group "external" {
}
neighbor "192.168.89.8" {
group "external"
prefix-limit ipv4 {
maximum 200
log-only true
threshold 80
}
}

Issue: 01 3HE 15820 AAAD TQZZA 01 187

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

4.11 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 Figure 12.

Figure 12 Configuration Groups

configure {
configuration group
groups {
group "isis-1" {
router "Base" {
isis "0" {
match
interface "<int-.*>" {
interface-type point-to-point
level "2" {
metric 10
snip

configure { apply-groups
router "Base" {
isis 0 {
apply-groups ["isis-1"]
interface "int-pe1-pe2" {
}
snip

configure { expanded configuration

router "Base" {
isis 0 {
interface "int-pe1-pe2" {
inheritance interface-type point-to-point
level "2" {
snip metric 10
sw0481

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.

188 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

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

Issue: 01 3HE 15820 AAAD TQZZA 01 189

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

To match on a key of a list entry in a configuration group, an exact match or a regular

expression match can be used.

4.11.1.1 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
}
}
}
}
}

4.11.1.2 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
}

190 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

}
}
}
}

4.11.1.2.1 Regular Expression Match Format

A regular expression match is specified as a string with the regular expression

enclosed in angle brackets: “<regex-match>”.

The regular expression match is implicitly anchored: a ^ (match-starting position) is

added at the beginning of the regular expression and a $ (match-ending position) is
added at the end.

The regular expression is a subset of the Extended Regular Expression (ERE)

notation as described in Using Regular Expressions with | match.

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.

4.11.1.3 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" {

Issue: 01 3HE 15820 AAAD TQZZA 01 191

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

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" {

192 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

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

4.11.2 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"]

Issue: 01 3HE 15820 AAAD TQZZA 01 193

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

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

194 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

}
}
}
}

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

4.11.3 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" {
}

Issue: 01 3HE 15820 AAAD TQZZA 01 195

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

}
}

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 2 metric. Because configuration group “isis-2” is listed first in the
apply-groups, its configuration elements have precedence. The interface-type
configuration element is inherited from group “isis-1” because a corresponding
configuration element is not present in group “isis-2” nor is it locally configured.

(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" {

196 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

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.

Issue: 01 3HE 15820 AAAD TQZZA 01 197

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

In the following example, all configuration groups set an interface level 2 metric.
Because configuration group “isis-3” is applied at the lowest level, its configuration
elements have precedence. The interface-type configuration element is also
inherited from group “isis-3” for the same reason. As explained earlier, the level-
capability configuration element from group “isis-1” has lower precedence than the
local configured value. The wide-metric-only configuration element from group
“isis-3” is not inherited because the group is applied at the interface branch and only
configuration elements at that level or lower can be inherited.

(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 {

198 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

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

Issue: 01 3HE 15820 AAAD TQZZA 01 199

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

4.11.4 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 and apply-groups 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
}

200 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

4.11.5 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

Issue: 01 3HE 15820 AAAD TQZZA 01 201

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

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 {

202 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

## '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'

4.11.6 Configuration Group Example

The following configuration is an example of configuring IS-IS interface parameters
using configuration groups.

Issue: 01 3HE 15820 AAAD TQZZA 01 203

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

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

204 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

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
}

Issue: 01 3HE 15820 AAAD TQZZA 01 205

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

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
}

4.11.7 Caveats
The following caveats 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, refer to the 7450 ESS, 7750 SR,
7950 XRS, and VSR System Management Guide.

206 3HE 15820 AAAD TQZZA 01 Issue: 01

MD-CLI USER GUIDE Configuring in the MD-CLI
RELEASE 20.7.R1

4.12 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. Refer to the 7450 ESS, 7750 SR, 7950 XRS, and
VSR System Management Guide for more information.
• a private exclusive configuration session. See Exclusive Private 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]

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
===============================================================================

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

Issue: 01 3HE 15820 AAAD TQZZA 01 207

Configuring in the MD-CLI MD-CLI USER GUIDE
RELEASE 20.7.R1

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
===============================================================================

4.12.1 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

208 3HE 15820 AAAD TQZZA 01 Issue: 01