Editing configuration

There are two modes in the MD-CLI:

• operational

  A user can run all commands to monitor or troubleshoot the router, but the router configuration cannot be changed.

• configuration

  A user can run all commands to monitor or troubleshoot the router. In private, exclusive, or global configuration mode, the router configuration can be changed. In read-only configuration mode, the user can only view the router configuration.

The first line of the user prompt indicates the active configuration mode. For example:

• [pr:configure]

  This indicates a user in private configuration mode (implicit configuration workflow).

• (ex) [configure]

  This indicates a user in exclusive configuration mode (explicit configuration workflow).

At login, an MD-CLI session always starts in operational mode. To configure the router, the user must enter a configuration mode using the explicit or implicit configuration workflow.

The configuration workflow (implicit or explicit) determines if the user is restricted to the configure branch or if the user can navigate freely while in configuration mode. Configuration workflows are detailed in Implicit and explicit configuration workflows.

The configuration mode (private, exclusive, global, or read-only) determines the interaction with other simultaneous configuration sessions. Candidate configuration modes are detailed in Candidate configuration modes.

The MD-CLI transactional configuration method is a two-step process in which configuration changes are made in a candidate configuration. When the configuration is committed, the changes are copied to the running configuration and become active.

The following figure shows the flow of configuration changes from the candidate configuration to the running configuration.

Other non-router configuration operations, such as changing the MD-CLI session environment are active immediately.

The MD-CLI configuration method differs from the classic CLI in the following ways:

• In the classic CLI, changes to the router configuration are immediately activated in the running configuration. A strict configuration order must be maintained or the configuration fails.

• In the MD-CLI, the transactional configuration method allows multiple configuration changes to be made in any order in the candidate configuration. The system applies the correct ordering when the configuration is activated with the commit command.

The MD-CLI supports two configuration workflows:

• Implicit configuration workflow

  • Navigation is restricted to the configure branch and its descendants.

  • Operational commands require an absolute path and error when incomplete.

  • configure {private | exclusive | global | read-only} enters configuration mode and navigates in the configure branch. There is no default configuration mode.

  • exit all leaves configuration mode and navigates to the operational root.

• Explicit configuration workflow

  • Navigation is unrestricted while in configuration mode.

  • Operational commands while in the configure branch require an absolute path and navigate when incomplete.

  • edit-config {private | exclusive | global | read-only} enters configuration mode without navigating. There is no default configuration mode.

  • quit-config leaves configuration mode without navigating. The quit-config command is not available in the configure branch.

The following table compares the implicit and explicit configuration workflows.

As introduced in Transactional configuration method, configuration changes are made in a candidate configuration and copied in the running configuration when the configuration changes are committed and become active.

This section describes:

• how the running configuration and a candidate configuration interact using a running datastore, a baseline datastore, and a candidate datastore

• how simultaneous configuration sessions access one or multiple candidate configurations as a function of their configuration mode

The following figure shows multiple candidate configurations.

The running configuration is the active configuration of the router and is stored in the running datastore. There is only one running configuration in the router and therefore, only one running datastore. The running datastore is always instantiated.

The candidate configuration is a working configuration that contains changes before they are activated in the router. A candidate configuration uses two datastores:

• a baseline datastore that contains a snapshot copy of the running datastore at a specific moment in time

• a candidate datastore that contains changes relative to its associated baseline datastore

Multiple candidate configurations can exist simultaneously in the router with one of the following:

• a single global candidate configuration that is accessed by one of the following:

  • a single session in exclusive configuration mode

  • one or multiple sessions in global configuration mode

  • one or multiple sessions in read-only configuration mode

  An exclusive and global configuration session are mutually exclusive. Read-only configuration sessions can coexist with an exclusive configuration session or with one or multiple global configuration sessions.

  The global baseline datastore and global candidate datastore are always instantiated.

• up to eight private candidate configurations. A private candidate configuration is accessed by a single session in private configuration mode. The private baseline datastore and private candidate datastore are instantiated when the user enters the private configuration mode and the datastores are deleted from the router when the user exits the private configuration mode.

• one single private-exclusive candidate configuration. Only one exclusive session can be active in the router at a time: either a user-started exclusive configuration session accessing the global candidate configuration, or a system-started private-exclusive configuration session accessing a private candidate configuration, or a user-started private configuration session using NETCONF with the <lock> RPC sent to promote it to a private-exclusive configuration session. For more information, see Private-exclusive configuration session.

When a configuration session commits its candidate configuration, the router performs the following actions:

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

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

3. activates the candidate configuration by sending the new candidate configuration to the corresponding applications

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

Furthermore, when simultaneous configuration sessions access different candidate configurations:

• Multiple private configuration sessions each access their own private candidate configuration.

• One or multiple private configuration sessions each access their own private candidate configuration and one or multiple global configuration sessions all access the global candidate configuration.

• One or multiple private configuration sessions each access their own private candidate configuration and one exclusive configuration session accesses the global candidate configuration.

• One or multiple private configuration sessions each access their own private candidate configuration and one private exclusive configuration session accesses a private candidate configuration.

Each configuration session adds changes in the candidate datastore relative to the baseline associated with the candidate configuration. The baseline datastore contains a snapshot copy of the running datastore at a specific time. Therefore, multiple, simultaneous configuration sessions that are active in the router and that access different candidate configurations have their own unique view of the candidate configuration and cannot see other users’ changes, as shown in the following figure.

Changes in a candidate configuration can only be committed when the running configuration has not been changed or touched after the baseline snapshot was taken. In other words, the baseline must be up to date to commit the changes.

The following figure shows how the baseline datastore of user-2’s candidate configuration is out-of-date after user-1 committed its changes. An exclamation mark (!) is shown in the prompt to indicate an out-of-date baseline status.

Because the baseline is out-of-date, user-2 must update its candidate configuration before committing. An update copies a new snapshot from the running datastore to the baseline datastore and merges the changes from the candidate datastore, as shown in the following figure.

With more than one user working on the same part of the configuration, conflicts can occur when committed changes of one user’s configuration session are merged into another user’s candidate configuration. A merge conflict occurs when a configuration element is added, deleted, or modified in the candidate configuration and the same configuration element is also added, deleted, or modified in the running configuration after the baseline snapshot was taken. With the update command, the router resolves each merge conflict and installs the result in the candidate configuration, as shown in the following figure.

When a commit operation is executed in a configuration session while the baseline is out-of-date, the router first attempts to automatically update the candidate configuration. If a merge conflict is detected, the commit operation is canceled, to allow the administrator to resolve the merge conflicts manually. The candidate configuration remains in the same state as before the commit operation.

In configuration mode, the administrator can use the following tools to check and resolve potential merge conflicts:

• compare baseline running

  This tool lists the changes that were made in the running datastore after a snapshot copy was stored in the baseline datastore.

• compare baseline candidate or compare

  This tool lists the candidate configuration changes.

• update check

  This tool performs a dry run update. The router reports all merge conflicts as if an update was performed. The candidate configuration, that is, the baseline candidate datastore, is not changed with this command.

Conflict detection and resolution is detailed in Updating the candidate configuration.

In private configuration mode, a private candidate configuration is reserved for editing by a single private configuration session. Each private configuration session works on its own copy of the running configuration. Only the changes made in the private configuration session are visible and can be committed. Private configuration mode can be used when multiple users are configuring simultaneously on different parts of the router configuration.

A private configuration session has the following characteristics:

• Each private configuration session accesses its own private candidate configuration. The private candidate configuration is instantiated when the user enters private configuration mode and is deleted form the router when the user exits private configuration mode.

• Changes can only be entered in its own private candidate configuration.

• Configuration changes are visible only in the private candidate configuration in which the changes are entered.

• Uncommitted changes in the private candidate configuration cannot be seen by other private, exclusive, global, or read-only configuration sessions.

• When the commit command is issued, only those changes entered in its own private candidate configuration are committed.

• When a private configuration session is started, a new private candidate configuration is instantiated and has no uncommitted changes.

• When a user leaves private configuration mode, uncommitted changes are discarded and the private candidate configuration is deleted. The user is prompted for confirmation to exit when uncommitted changes are present.

For simultaneous configuration sessions:

• Up to eight simultaneous private configuration sessions can coexist. Each private configuration session accesses its own private candidate configuration. Private candidate configurations can have uncommitted changes when another private configuration session starts. A private configuration session can edit and commit its private candidate configuration while another private configuration session is active.

• An exclusive configuration session can coexist with a private configuration session. The private candidate configuration can have uncommitted changes when an exclusive configuration session starts. The exclusive session can edit and commit changes while a private configuration session is active. The private configuration session can still edit the private candidate configuration, but changes cannot be committed because the exclusive session holds a lock on the running datastore.

• Multiple global configuration sessions can coexist with a private configuration session. A global configuration session accesses the global candidate configuration. The private candidate configuration can have uncommitted changes when the global configuration session starts.

• Multiple read-only configuration sessions can coexist with a private configuration session. Read-only configuration sessions access the global candidate configuration. A read-only configuration session cannot view the changes in the private candidate configuration. The private candidate configuration can have uncommitted changes when a read-only configuration session starts.

Datastore interactions include the following characteristics:

• The private baseline datastore becomes out-of-date when another private, exclusive, global, or private exclusive configuration session commits changes to the running datastore after the private baseline snapshot was taken. An out-of-date baseline is indicated in the prompt with an exclamation mark.

• An update of the private candidate configuration is needed when its private baseline datastore is out-of-date. An update copies a new snapshot of the running datastore in the private baseline datastore and merges the changes from the private candidate datastore. Merge conflicts detected in a manual update are reported and resolved. Merge conflicts detected in an automatic update as part of a commit operation result in the cancellation of the commit operation.

• A snapshot of the running datastore is copied in the private baseline datastore:

  • at instantiation of the private candidate configuration when a user enters the private configuration mode

  • when a manual update is performed

  • after a commit, when no merge conflicts are detected during the automatic update and the updated candidate configuration is valid

When entering private configuration mode, the following messages are displayed:

[/]
A:admin@node-2# configure private
INFO: CLI #2070: Entering private configuration mode
INFO: CLI #2061: Uncommitted changes are discarded on configuration mode exit

When leaving private configuration mode, the following messages are displayed:

• without uncommitted changes in the private candidate configuration:

  [pr:/configure]
  A:admin@node-2# exit all
  INFO: CLI #2074: Exiting private configuration mode
  

• with uncommitted changes present in the private candidate configuration:

  *[pr:/configure]
  A:admin@node-2# exit all
  INFO: CLI #2071: Uncommitted changes are present in the candidate configuration.    
  Exiting private configuration mode will discard those changes.
  
  Discard uncommitted changes? [y,n] n
  INFO: CLI #2072: Exit private configuration mode canceled
  
  *[pr:/configure]
  A:admin@node-2# exit all
  INFO: CLI #2071: Uncommitted changes are present in the candidate configuration.    
  Exiting private configuration mode will discard those changes.
  
  Discard uncommitted changes? [y,n] y
  WARNING: CLI #2073: Exiting private configuration mode - uncommitted changes are discarded
  

In exclusive configuration mode, the global configuration is reserved for editing by a single read-write configuration session. In addition, the running datastore is locked such that no other configuration session can commit changes. Exclusive configuration mode can be used when important router configuration changes must be implemented that cannot be interrupted or delayed, and to avoid the risk of committing other users’ partial completed changes.

An exclusive configuration session has the following characteristics:

• An exclusive configuration session accesses the global candidate configuration.

• Only one user can enter exclusive configuration mode at a time.

• Configuration changes in the global candidate can only be entered by the user in exclusive configuration mode.

• Configuration changes in the global candidate are visible for read-only configuration sessions.

• Changes in the global candidate configuration can only be committed by the user in exclusive configuration mode

• Uncommitted changes cannot be present in the global candidate configuration when an exclusive configuration session starts.

• Uncommitted changes are discarded from the global candidate configuration when a user leaves the exclusive configuration mode. The user is prompted for confirmation to exit when uncommitted changes are present.

For simultaneous configuration sessions:

• Multiple private configuration sessions can coexist with an exclusive configuration session. Each private configuration session accesses its own private candidate configuration. The global candidate configuration can have uncommitted changes when a private configuration session starts. A private configuration session can edit its private candidate configuration but cannot commit the changes while an exclusive configuration session is active.

• Only one exclusive configuration session can be active in the router at a time.

• An exclusive and global configuration session are mutually exclusive.

• Multiple read-only configuration sessions can coexist with an exclusive configuration session. Read-only configuration sessions access the same global candidate configuration. The global candidate configuration can have uncommitted changes when a read-only configuration session starts.

Datastore interactions include the following characteristics:

• The global baseline datastore is always up to date. Commits from other configuration sessions are blocked while an exclusive configuration session is active.

• An update of the global candidate configuration is not needed in exclusive configuration mode.

When entering exclusive configuration mode, the following messages are displayed:

• with a global configuration session active:

  [/]
  A:admin@node-2# configure exclusive
  MINOR: MGMT_CORE #2052: Exclusive datastore access unavailable - model-driven interface editing global candidate
  

• with uncommitted changes present in the global candidate configuration:

  [/]
  A:admin@node-2# configure exclusive
  MINOR: MGMT_CORE #2052: Exclusive datastore access unavailable - model-driven interface has uncommitted changes in global candidate
  

• with a private configuration session active:

  [/]
  A:admin@node-2# edit-config exclusive
  INFO: CLI #2060: Entering exclusive configuration mode
  INFO: CLI #2061: Uncommitted changes are discarded on configuration mode exit
  

When leaving exclusive configuration mode, the following messages are displayed:

• without uncommitted changes in the global candidate configuration:

  [ex:/configure]
  A:admin@node-2# exit all
  INFO: CLI #2064: Exiting exclusive configuration mode
  

• with uncommitted changes in the global candidate configuration:

  *[ex:/configure]
  A:admin@node-2# exit all
  INFO: CLI #2063: Uncommitted changes are present in the candidate configuration.    
  Exiting exclusive configuration mode will discard those changes.
  
  Discard uncommitted changes? [y,n] n
  INFO: CLI #2065: Exit exclusive configuration mode canceled
  
  *[ex:/configure]
  A:admin@node-2# exit all
  INFO: CLI #2063: Uncommitted changes are present in the candidate configuration.   
  Exiting exclusive configuration mode will discard those changes.
  
  Discard uncommitted changes? [y,n] y
  WARNING: CLI #2062: Exiting exclusive configuration mode - uncommitted changes are   discarded
  

In global configuration mode, the global configuration is shared with all global configuration sessions. When a user commits their changes, the changes from all users are also committed. Global configuration mode can be used when multiple users are working together on the same part of the router configuration but is generally not recommended because it can cause unintended configuration to be committed.

A global configuration session has the following characteristics:

• A global configuration session accesses the global candidate configuration.

• Multiple users can enter global configuration mode simultaneously.

• Configuration changes made by one user are visible to all other users in global or read-only configuration mode. Configuration changes in private candidate configurations are not visible.

• All changes in the global candidate configuration, from all users, are committed to the running configuration when one user commits the global candidate configuration.

• Uncommitted changes can be present in the global candidate configuration when a global configuration session starts.

• Uncommitted changes are kept in the global candidate configuration when a user leaves the global configuration mode.

For simultaneous configuration sessions:

• Multiple private configuration sessions can coexist with a global configuration session. Each private configuration session accesses its own private candidate configuration. The global candidate configuration can have uncommitted changes when a private configuration session starts.

• An exclusive and global configuration session are mutually exclusive.

• Multiple global configuration sessions can coexist. All global configuration sessions access the same global candidate configuration. The global candidate configuration can have uncommitted changes when another global configuration session starts.

• Multiple read-only configuration sessions can coexist with a global configuration session. Read-only configuration sessions access the same global candidate configuration. The global candidate configuration can have uncommitted changes when a read-only configuration session starts.

Datastore interactions include the following characteristics:

• The global baseline datastore becomes out-of-date when another private or private exclusive configuration session commits changes to the running datastore after the global baseline snapshot was taken. An out-of-date baseline is indicated in the prompt with an exclamation mark.

• An update of the global candidate configuration is needed when its global baseline datastore is out-of-date. An update copies a new snapshot of the running datastore in the global baseline datastore and merges the changes from the global candidate datastore. Merge conflicts detected in a manual update are reported and resolved. Merge conflicts detected in an automatic update as part of a commit operation result in the cancellation of the commit operation.

• The baseline datastore tracks the running datastore, that is, changes in the running datastore are automatically copied in the baseline datastore:

  • after a router reboot

  • after a successful commit

  • after a discard with an up to date global baseline

• A snapshot copy of the running datastore is copied in the global baseline datastore and tracking stops when the global candidate is touched, for example, when a configuration element has been added, deleted, or modified. A new snapshot of the running datastore is copied to the global baseline datastore when a manual update is performed.

When entering global configuration mode, the following messages are displayed:

[/]
A:admin@node-2# configure global
INFO: CLI #2054: Entering global configuration mode
INFO: CLI #2055: Uncommitted changes are present in the candidate configuration
INFO: CLI #2075: Other global configuration sessions are active

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

In read-only configuration mode, no changes can be made to the global candidate configuration and no changes can be committed to the running configuration. Read-only configuration mode can be used when reviewing or monitoring configuration changes from other users in the global candidate configuration.

A read-only configuration session has the following characteristics:

• A read-only configuration session accesses the global candidate configuration.

• Multiple users can enter read-only configuration mode simultaneously.

• All configuration changes in the global candidate configuration are visible. Configuration changes in private candidate configurations are not visible.

• The global configuration cannot be edited and changes in the global configuration cannot be committed.

• Uncommitted changes can be present in the global candidate configuration when a read-only configuration session starts.

• Uncommitted changes are kept in the global candidate configuration when a user leaves a read-only configuration mode.

For simultaneous configuration sessions:

• Multiple private configuration sessions can coexist with a read-only configuration session. Each private configuration session accesses its own private candidate configuration. The global candidate configuration can have uncommitted changes when a private configuration session starts.

• An exclusive configuration session can coexist with a read-only configuration session. The exclusive configuration session accesses the same global candidate configuration. The global candidate configuration cannot have uncommitted changes when an exclusive configuration session starts.

• Multiple global configuration sessions can coexist with a read-only configuration session. Global configuration sessions access the same global candidate configuration. The global candidate configuration can have uncommitted changes when another global configuration session starts.

• Multiple read-only configuration sessions can coexist. Read-only configuration sessions access the same global candidate configuration. The global candidate configuration can have uncommitted changes when another read-only configuration session starts.

When entering read-only configuration mode, the following message is displayed:

[/]
A:admin@node-2# configure read-only
INFO: CLI #2066: Entering read-only configuration mode

When leaving read-only configuration mode, the following message is displayed:

*[ro:/configure]
A:admin@node-2# exit all
INFO: CLI #2067: Exiting read-only configuration mode

Exclusive, global, and read-only configuration sessions that access the global candidate configuration can transition between these configuration modes without exiting and re-entering the configuration mode.

Transitions from and to private configuration mode are not allowed.

The following summarizes the configuration mode transitions and transitions to operational mode.

[/]
A:admin@node-2# edit-config exclusive
INFO: CLI #2060: Entering exclusive configuration mode
INFO: CLI #2061: Uncommitted changes are discarded on configuration mode exit

(ex)[/]
A:admin@node-2# configure router interface my-int

*(ex)[/configure router "Base" interface "my-int"]
A:admin@node-2# edit-config global
INFO: CLI #2063: Uncommitted changes are present in the candidate configuration.    
Exiting exclusive configuration mode will discard those changes.

Discard uncommitted changes? [y,n] n
INFO: CLI #2065: Exit exclusive configuration mode canceled

*(ex)[/configure router "Base" interface "my-int"]
A:admin@node-2# edit-config read-only
INFO: CLI #2063: Uncommitted changes are present in the candidate configuration.    
Exiting exclusive configuration mode will discard those changes.

Discard uncommitted changes? [y,n] y
WARNING: CLI #2062: Exiting exclusive configuration mode - uncommitted changes are discarded
INFO: CLI #2066: Entering read-only configuration mode

(ro)[/configure router "Base" interface "my-int"]
A:admin@node-2#

[/]
A:admin@node-2# edit-config global
INFO: CLI #2054: Entering global configuration mode
INFO: CLI #2075: Other global configuration sessions are active

(gl)[/]
A:admin@node-2# configure router interface new-int

*(gl)[/configure router "Base" interface "new-int"]
A:admin@node-2# edit-config exclusive
MINOR: MGMT_CORE #2052: Exclusive datastore access unavailable - model-driven interface editing global candidate

*(gl)[/configure router "Base" interface "new-int"]
A:admin@node-2# show system management-interface configuration-sessions
===============================================================================
Session ID  Region                 Datastore                     Lock State
   Username                        Session Mode                  Idle Time
   Session Type                    From
-------------------------------------------------------------------------------
#22         configure              Candidate                     Unlocked
   admin                           Global                        0d 00:00:00
   MD-CLI                          135.244.144.235
 23         configure              Candidate                     Unlocked
   user-1                          Global                        0d 00:00:42
   MD-CLI                          135.244.144.235
-------------------------------------------------------------------------------
Number of sessions: 2
'#' indicates the current active session
===============================================================================

*(gl)[/configure router "Base" interface "new-int"]
A:admin@node-2#

*(gl)[/configure router "Base" interface "new-int"]
A:admin@node-2# admin disconnect session-id 23

*(gl)[/configure router "Base" interface "new-int"]
A:admin@node-2# edit-config exclusive
INFO: CLI #2056: Exiting global configuration mode
INFO: CLI #2057: Uncommitted changes are kept in the candidate configuration
INFO: CLI #2060: Entering exclusive configuration mode
INFO: CLI #2061: Uncommitted changes are discarded on configuration mode exit

*(ex)[/configure router "Base" interface "new-int"]
A:admin@node-2#

A private-exclusive configuration session is reserved for system internal use and private candidate NETCONF sessions with an exclusive lock.

Router configuration changes are made via a private-exclusive configuration session as a result of the following scenarios:

• One of the following actions occurs when in mixed configuration mode:

  • any configuration is performed in the classic CLI engine

  • a gNMI configuration operation

  • a NETCONF session issuing the <lock> RPC while running in private candidate mode

• One of the following actions occurs when in model-driven configuration mode:

  • a gNMI configuration operation

  • a password command execution which causes the system to update the configuration

  • a NETCONF session issuing the <lock> RPC while running in private candidate mode

It is important to be aware that a private-exclusive configuration session can exist, as it interacts with other active configuration sessions in the following ways:

• An exclusive configuration session and a private-exclusive configuration session are mutually exclusive, as they both require a lock on the running datastore.

• The global candidate configuration and private candidate configuration can become out-of-date when changes are committed via a private-exclusive configuration session.

• Commits from global and private configuration sessions are blocked when a private-exclusive configuration session is active.

• A private-exclusive configuration session accesses its own private candidate configuration. Changes are not visible to other configuration sessions until they are committed and become active in the running configuration.

It may be desirable to deny a user the ability to use specific configuration modes. For example, denying the use of exclusive configuration mode prevents the user from locking the configuration datastore, or denying the use of the global configuration mode forces the user to work in a private candidate datastore.

It is possible to use AAA to deny access to particular configuration modes, as illustrated in the following configuration example.

[ex:/configure system security aaa local-profiles profile "admin-private"]
A:admin@node-2# info detail
## cli-session-group
    default-action permit-all
---snip---
    entry 3 {
     ## apply-groups
     ## description
        action deny
        match "edit-config exclusive"
    }
    entry 4 {
     ## apply-groups
     ## description
        action deny
        match "configure exclusive"
    }

[/]
A:pr-user@node-2# configure exclusive
MINOR: MGMT_CORE #2020: Permission denied - unauthorized use of 'configure'
[/]
A:pr-user@node-2# configure ?

 configure

 Configuration modes:
 global               - Enter global (shared) mode for candidate configuration.
 private              - Enter private mode for candidate configuration.
 read-only            - Enter read-only mode for candidate configuration.

          - Enter a candidate li configuration mode

[/]
A:pr-user@node-2# edit-config exclusive
MINOR: MGMT_CORE #2020: Permission denied - unauthorized use of 'edit-config'

[/]
A:pr-user@node-2# edit-config ?

 edit-config

 Configuration modes:
 global               - Enter global (shared) mode for candidate configuration.
 private              - Enter private mode for candidate configuration.
 read-only            - Enter read-only mode for candidate configuration.

 li                   - Enter a candidate li configuration mode

[ex:configure system security aaa local-profiles profile "admin-pr"]
A:admin@node-2# info detail

---snip---

    entry 5 {
     ## apply-groups
     ## description
        action deny
        match "configure global"
    }
    entry 6 {
     ## apply-groups
     ## description
        action deny
        match "edit-config global"
    }

[]
A:pr-user@node-2# configure ?

 configure

 Configuration modes:
 private              - Enter private mode for candidate configuration.
 read-only            - Enter read-only mode for candidate configuration.

[]
A:pr-user@node-2# edit-config ?

 edit-config

 Configuration modes:
 private              - Enter private mode for candidate configuration.
 read-only            - Enter read-only mode for candidate configuration.

 li                   - Enter a candidate li configuration mode

[]
A:pr-user@node-2# configure global
MINOR: MGMT_CORE #2020: Permission denied - unauthorized use of 'configure'

[]
A:pr-user@node-2# edit-config global
MINOR: MGMT_CORE #2020: Permission denied - unauthorized use of 'edit-config'

A leaf is an element that does not contain any other elements and has a data type, for example, a string, an integer, or an IP address.

Key leafs may have an optional default value that can be used as shorthand notation where a specified default is assumed. For example, configure router bgp with no instance value expands to configure router ‟Base” bgp. Default values are implemented as follows:

• Default values cannot be used in a reference.

• Multiple keys in a list can have default values.

• The first, last, or any key in a list may have a default value.

• If the first key has a default value, the other keys must be named keys.

• Default values can be used multiple times in any combination; for example, configure router isis expands to configure router ‟Base” isis 0, and configure router foo isis expands to configure router ‟foo” isis 0.

• The expansion is automatic and displayed in the command prompt context and pwc.

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

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

(ex)[/]
A:admin@node-2# configure router isis

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

(ex)[/]
A:admin@node-2# configure router ospf

(ex)[/configure router "Base" ospf 0]
A:admin@node-2# pwc

Present Working Context:
  configure
  router "Base"
  ospf 0

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

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

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

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

*[ex:/configure qos sap-ingress "sstest" queue 8 rate]
A:admin@node-2# pir ? 

 pir (<number> | <keyword>)
 <number>  - <1..6400000000> - kilobps
 <keyword> - max             - kilobps
 Default   - max

    Administrative PIR

*[ex:/configure qos sap-ingress "sstest" queue 8 rate]
A:admin@node-2# pir 88

*[ex:/configure qos sap-ingress "sstest" queue 8 rate]
A:admin@node-2# info
    pir 88

*[ex:/configure qos sap-ingress "sstest" queue 8 rate]
A:admin@node-2# pir 0b0010
                    ^^^^^^
MINOR: MGMT_CORE #2301: Invalid element value - 'pir' expected number '<1..6400000000>' (kilobps) or keyword 'max' (kilobps)

*[ex:/configure qos sap-ingress "sstest" queue 8 rate]
A:admin@node-2# info
    pir 88

*[ex:/configure qos sap-ingress "sstest" queue 8 rate]
A:admin@node-2# pir 2

*[ex:/configure qos sap-ingress "sstest" queue 8 rate]
A:admin@node-2# info
    pir 2

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.

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

 [ip-address] (<unicast-ipv4-address> | <global-unicast-ipv6-address>)
 <unicast-ipv4-address>        - <d.d.d.d>
 <global-unicast-ipv6-address> - (<x:x:x:x:x:x:x:x>|<x:x:x:x:x:x:d.d.d.d>)

    IP address of the remote cflowd collector host

*[ex:/configure cflowd]
A:admin@node-2# collector 10.20.30.40 ?

 port <number>
 <number> - <1..65535>

    UDP port number of the remote cflowd collector host
 

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

*[ex:/configure cflowd collector 10.20.30.40 port 7 export-filter interface-list service]
A:admin@node-2# ies-interface ?

 service-name <reference>
 <reference> - <1..64 characters> - configure service ies <service-name>

    Administrative service name

*[ex:/configure cflowd collector 10.20.30.40 port 7 export-filter interface-list service]
A:admin@node-2# ies-interface service-name svc-test interface-name ?

 interface-name <reference>
 <reference> - <1..32            - configure service ies <./service-name>
                characters>         interface <interface-name>

    ies interface name

*[ex:/configure cflowd collector 10.20.30.40 port 7 export-filter interface-list service]
A:admin@node-2# ies-interface service-name svc-test interface-name int-name-test

*[ex:/configure cflowd collector 10.20.30.40 port 7 export-filter interface-list service]
A:admin@node-2# info
    ies-interface service-name "svc-test" interface-name "int-name-test" { }

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

*[ex:/configure eth-cfm domain "dmtest"]
A:admin@node-2# association "ma-admin-name"

*[ex:/configure eth-cfm domain "dmtest" association "ma-admin-name"]
A:admin@node-2# pwc
Present Working Context:
  configure
  eth-cfm
  domain "dmtest"
  association "ma-admin-name"

*[ex:/configure eth-cfm domain "dmtest"]
A:admin@node-2# association ma-admin-name ma-admin-name

*[ex:/configure eth-cfm domain "dmtest" association "ma-admin-name"]
A:admin@node-2# pwc
Present Working Context:
  configure
  eth-cfm
  domain "dmtest"
  association "ma-admin-name"

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

If a leaf is defined by a number value and an associated unit, the user can enter the value in a different base unit than is defined. For example, if a timer is defined in seconds, it is possible to enter a value based on the number of minutes, or a combination of minutes and seconds. These dynamic units in the MD-CLI can be entered in a format that is converted into the base unit based on a conversion factor. The units for a command can be displayed using the units option for the info command.

Static units that have no conversion factor must always be entered in the base unit value; for example, a unit of packets per second, or bit errors.

Units are supported for:

• memory sizes, for example, bytes

• rates, for example, bps

• durations, for example, seconds

• dates, for example, Tue, 01 Sep 2020 15:15:35 UTC

Dynamic units can be entered as a number in one of the following ways:

• as a value without a unit

  The value is interpreted as the defined base unit. Decimal, binary, and hexadecimal numbers are supported.

[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

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

*[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 900
                                  ^^^
MINOR: MGMT_CORE #2301: Invalid element value - 900 out of range 1..600

*[ex:/configure port 1/1/1 ethernet efm-oam]
A:admin@node-2# transmit-interval 900 Press Tab
 
 milliseconds  centiseconds

*[ex:/configure port 1/1/1 ethernet efm-oam]
A:admin@node-2# transmit-interval 900 centiseconds 100 Press Tab

 milliseconds  deciseconds

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

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

Flexible input is available for MAC and IPv6 addresses, where both uppercase and lowercase hexadecimal digits are accepted.

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

*[ex:/configure qos sap-ingress "s" mac-criteria entry 5 match]
A:admin@node-2# dst-mac address aa-BB-cc-DD-eE-Ff

*[ex:/configure qos sap-ingress "s" mac-criteria entry 5 match]
A:admin@node-2# info
    dst-mac {
        address aa:bb:cc:dd:ee:ff

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

The MD-CLI supports the following input translation for UTF-8 character encoding:

• curly quotation mark to ASCII quotation mark (")

• curly apostrophe to ASCII apostrophe (')

• hyphens and dashes, including minus, en dash, em dash, and others to ASCII minus (-)

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

The following configuration example deletes three leafs; admin-state and connect-retry return to their default values, and description returns to an unconfigured state.

*[ex:/configure router "Base" bgp]
A:admin@node-2# info
    admin-state disable
    description "BGP description"
    connect-retry 65535

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

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

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

*[ex:/configure router "Base" bgp]
A:admin@node-2# info detail
    admin-state enable
 ## description
    connect-retry 120
    keepalive 30
    damping false
    local-preference 100
    loop-detect ignore-loop
---snip---

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.

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

*[ex:/configure service]
A:admin@node-2# info
    vprn "vprn1" {
        description "VPRN instance 01"
        dns {
            ipv6-source-address 2001:db8:aaa3::8a2e:3710:7335
        }
        bgp {
            min-route-advertisement 50
        }
        interface "int1" {
            ipv6 {
                dhcp6 {
                    relay {
                        server ["2001:db8::" "2001:db9::" "2001:dba::" "2001:dc1::"]
                    }
                }
            }
        }
    }

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

*[ex:/configure]
A:admin@node-2# delete service vprn "vprn1"

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

[ex:/configure service]
A:admin@node-2# info detail | match vprn
 ## vprn

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

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

To remove a list entry, the delete operation is specified before the list name and the entry to be removed.

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

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

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

*[ex:/configure service epipe "svc-name" sap 1/1/4:1 eth-cfm]
A:admin@node-2# delete mep md-admin-name * ma-admin-name * mep-id 5

*[ex:/configure service epipe "svc-name" sap 1/1/4:1 eth-cfm]
A:admin@node-2# info
    mep md-admin-name "ref6" ma-admin-name "ref3" mep-id 99 {
    }

*[ex:/configure service epipe "svc-name" sap 1/1/4:1 eth-cfm]
A:admin@node-2#

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

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

The copy command allows elements to be duplicated for use within an MD-CLI configuration. The source and destination elements must be the same type (such as containers, lists, or leaf elements) and must be at the same configuration level.

A copied element inherits all characteristics from the source element. If a container is copied to another container element, all child elements of the container are also copied.

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

[ex:/configure router "Base" bgp]
A:admin@node-2# copy neighbor "192.0.2.2" to neighbor 192.0.2.200

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

*[ex:/configure policy-options policy-statement "s"]
A:admin@node-2# info
    entry 5 {
        to {
            level 2
        }
    }
    entry 10 {
    }

*[ex:/configure policy-options policy-statement "s"]
A:admin@node-2# entry 10

*[ex:/configure policy-options policy-statement "s" entry 10]
A:admin@node-2# copy /configure policy-options policy-statement s entry 5

*[ex:/configure policy-options policy-statement "s" entry 10]
A:admin@node-2# info
    to {
        level 2
    }

The rename command allows a list key to be renamed within the transactional MD-CLI configuration interface. Use the rename command instead of an using the copy and delete commands for a list with a specific key.

When the rename command is used to rename a key for a user-ordered list, the system maintains the list order.

The rename command may be service-impacting, as the operations involve add and delete operations.

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

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

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

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.

*[ex:/configure]
A:admin@node-2# compare
    log {
+       accounting-policy 5 {
+           description "For SIO statistics"
+           collection-interval 69
+           include-system-info true
+           record service-ingress-octets
+       }
+       accounting-policy 8 {
+       }
    }

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

*[ex:/configure]
A:admin@node-2# compare flat
+   log { accounting-policy 5 }
+   log accounting-policy 5 description "For SIO statistics"
+   log accounting-policy 5 collection-interval 69
+   log accounting-policy 5 include-system-info true
+   log accounting-policy 5 record service-ingress-octets
+   log { accounting-policy 8 }

*[ex:/configure]
A:admin@node-2# compare full-context
+   /configure log { accounting-policy 5 }
+   /configure log accounting-policy 5 description "For SIO statistics"
+   /configure log accounting-policy 5 collection-interval 69
+   /configure log accounting-policy 5 include-system-info true
+   /configure log accounting-policy 5 record service-ingress-octets
+   /configure log { accounting-policy 8 }

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

*(ex)[/]
A:admin@node-2# compare
    router "Base" {
        interface "system" {
            ipv4 {
                primary {
-                   address 10.1.1.1
+                   address 10.243.5.96
                }
            }
        }
    }

*(ex)[/]
A:admin@node-2# compare summary
    router "Base" {
        interface "system" {
            ipv4 {
                primary {
~                   address 10.243.5.96
                }
            }
        }
    }

*[ex:/configure policy-options policy-statement "example-policy-statement"]
A:admin@node-2# compare summary
~   insert named-entry "two" after "one"
~   insert named-entry "three" after "two"
+   named-entry "two" {
+       description "Example addition"
+       action {
+           action-type accept
+       }
+   }

*[ex:/configure policy-options policy-statement "example-policy-statement"]
A:admin@node-2# compare netconf-rpc summary
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:yang="urn:ietf:params:xml:ns:yang:1">
    <edit-config>
        <target><candidate/></target>
        <config>
            <configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf" xmlns:nokia-attr="urn:nokia.com:sros:ns:yang:sr:attributes">
                <policy-options>
                    <policy-statement>
                        <name>example-policy-statement</name>
                        <named-entry operation="merge" yang:insert="after" yang:key="[entry-name='one']">
                            <entry-name>two</entry-name>
                        </named-entry>
                        <named-entry operation="merge" yang:insert="after" yang:key="[entry-name='two']">
                            <entry-name>three</entry-name>
                        </named-entry>
                        <named-entry>
                            <entry-name>two</entry-name>
                            <description>Example addition</description>
                            <action>
                                <action-type>accept</action-type>
                            </action>
                        </named-entry>
                    </policy-statement>
                </policy-options>
            </configure>
        </config>
    </edit-config>
</rpc>

*[ex:/configure]
A:admin@node-2# compare summary
    system {
~       name "newtest"
    }
+   openconfig {
+       lldp {
+           config {
+               hello-timer 99
+           }
+       }
+   }

*[ex:/configure]
A:admin@node-2# compare summary netconf-rpc
<rpc message-id="3" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:yang="urn:ietf:params:xml:ns:yang:1">
    <edit-config>
        <target><candidate/></target>
        <config>
            <configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf" xmlns:nokia-attr="urn:nokia.com:sros:ns:yang:sr:attributes">
                <system>
                    <name>newtest</name>
                </system>
            </configure>
        </config>
    </edit-config>
</rpc>

*[ex:/configure]
A:admin@node-2# compare summary netconf-rpc /configure
<rpc message-id="4" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:yang="urn:ietf:params:xml:ns:yang:1">
    <edit-config>
        <target><candidate/></target>
        <config>
            <configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf" xmlns:nokia-attr="urn:nokia.com:sros:ns:yang:sr:attributes">
                <system>
                    <name>newtest</name>
                </system>
            </configure>
        </config>
    </edit-config>
</rpc>

*[ex:/configure]
A:admin@node-2# compare summary netconf-rpc /
<rpc message-id="5" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:yang="urn:ietf:params:xml:ns:yang:1">
    <edit-config>
        <target><candidate/></target>
        <config>
            <configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf" xmlns:nokia-attr="urn:nokia.com:sros:ns:yang:sr:attributes">
                <system>
                    <name>newtest</name>
                </system>
            </configure>
            <lldp xmlns="http://openconfig.net/yang/lldp">
                <config>
                    <hello-timer>99</hello-timer>
                </config>
            </lldp>
        </config>
    </edit-config>
</rpc>

*[ex:/configure openconfig]
A:admin@node-2# compare summary netconf-rpc
<rpc message-id="6" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:yang="urn:ietf:params:xml:ns:yang:1">
    <edit-config>
        <target><candidate/></target>
        <config>
            <lldp xmlns="http://openconfig.net/yang/lldp">
                <config>
                    <hello-timer>99</hello-timer>
                </config>
            </lldp>
        </config>
    </edit-config>
</rpc>

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

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

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

*[ex:/configure system]
A:admin@node-2# compare /configure
    log {
+       log-id 55 {
+       }
    }
+   router "Base" {
+       bgp {
+           group "group-1" {
+               admin-state enable
+               connect-retry 999
+           }
+       }
+   }
    system {
-       name "node-2"
+       name "test-name"
    }

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

*[ex:/configure system]
A:admin@node-2# compare /configure
    log {
+       log-id 55 {
+       }
    }
    system {
-       name "node-2"
+       name "test-name"
    }

*[ex:/configure system]
A:admin@node-2# compare /configure
    log {
+       log-id 55 {
+       }
    }
    system {
-       name "node-2"
+       name "test-name"
    }

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

*[ex:/configure system]
A:admin@node-2# compare /configure
    log {
+       log-id 55 {
+       }
    }

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

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

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

*(ro)[/]

*(ex)[/]
A:admin@node-2# compare
+   eth-cfm {
+       domain "mdn" {
+           association "man" {
+               ccm-interval 10ms
+           }
+       }
+   }

*(ex)[/]
A:admin@node-2# validate
MINOR: MGMT_CORE #236: configure eth-cfm domain "mdn" level - Missing mandatory  fields
MINOR: ETH_CFM #12: configure eth-cfm domain "mdn" format - Inconsistent Value error - One of dns, mac, name or format must be provided

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

As described in Multiple simultaneous candidate configurations, a candidate configuration uses two datastores:

• a baseline datastore that contains a snapshot copy of the running configuration at a specific time

• a candidate datastore that contains changes relative to its associated baseline datastore

For a private candidate configuration, access by MD-CLI sessions in private configuration mode, a snapshot of the running configuration is copied in the private baseline datastore:

• when a private candidate configuration is instantiated, when a user enters the private configuration mode

• when a manual update is performed

• after a commit, when no merge conflicts are detected during the automatic update and the updated candidate configuration is valid

For the global candidate configuration, accessed by MD-CLI sessions in global and exclusive configuration mode, a tracking mechanism exists.

• The baseline datastore tracks the running datastore, that is, changes in the running datastore are automatically copied in the baseline datastore:

  • after a router reboot

  • after a successful commit

  • after a discard with an up-to-date global baseline

• Tracking stops and a snapshot of the running datastore is copied in the global baseline datastore when the global candidate is touched (for example, a configuration element is added, deleted, or modified). A new snapshot of the running datastore is copied in the global baseline datastore when a manual update is performed.

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

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

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

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

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

   2. Merge conflicts are detected and resolved. A merge conflict occurs when a configuration element is added, deleted, or modified in the candidate configuration and the same configuration element was also added, deleted, or modified in the running configuration after the baseline snapshot was taken.

   3. The resulting changes are stored in the candidate datastore as new changes relative to the updated baseline.

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

+   /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 commit command can be executed from any hierarchy level within any configuration branch.

When a commit operation is initiated while the baseline is out-of-date, the router first attempts to update the candidate configuration. If a merge conflict is detected, the commit operation is canceled to allow the administrator to resolve the merge conflicts manually.

!*[pr:/configure]
A:admin@node-2# commit
MINOR: MGMT_CORE #2703: Commit canceled - conflicts detected, use update

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

[pr:/configure system time]
A:admin@node-2# info
    prefer-local-time true

[pr:/configure system time]
A:admin@node-2# prefer-local-time false

*[pr:/configure system time]
A:admin@node-2# commit comment "Revert to use UTC time."

[pr:/configure system time]
A:admin@node-2# info
    prefer-local-time false

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.

*[ro:/configure router "Base" bgp]
A:admin@node-2# info full-context
    /configure router "Base" bgp group "external" { }
    /configure router "Base" bgp neighbor "192.168.89.8" group "external"
    /configure router "Base" bgp neighbor "192.168.89.8" prefix-limit ipv4 maximum 200
    /configure router "Base" bgp neighbor "192.168.89.8" prefix-limit ipv4 log-only  true
    /configure router "Base" bgp neighbor "192.168.89.8" prefix-limit ipv4    threshold 80

A:admin@node-2# info full-context > cf3:testbgp.cfg

[/]
A:admin@node-2# file list

Volume in drive cf3 on slot A is .

Volume in drive cf3 on slot A is formatted as FAT32

Directory of cf3:\

10/24/2019  04:02a      <DIR>          .ssh/
01/01/1980  12:00a                 170 NVRAM.DAT
01/01/1980  12:00a                 679 bof.cfg
10/24/2019  04:02a                 314 nvsys.info
10/24/2019  04:02a                   1 restcntr.txt
10/27/2019  02:57p                 257 testbgp.cfg
               5 File(s)                   1421 bytes.
               1 Dir(s)                       0 bytes free.

[/]
A:admin@node-2# file show cf3:testbgp.cfg
File: testbgp.cfg
-------------------------------------------------------------------------------
    /configure router "Base" bgp group "external" { }
    /configure router "Base" bgp neighbor "192.168.89.8" group "external"
    /configure router "Base" bgp neighbor "192.168.89.8" prefix-limit ipv4 maximum  200
    /configure router "Base" bgp neighbor "192.168.89.8" prefix-limit ipv4 log-only  true
    /configure router "Base" bgp neighbor "192.168.89.8" prefix-limit ipv4 threshold 80

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

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

*[ro:/configure router "Base" bgp]
A:admin@node-2# info flat
    group "external" { }
    neighbor "192.168.89.8" group "external"
    neighbor "192.168.89.8" prefix-limit ipv4 maximum 200
    neighbor "192.168.89.8" prefix-limit ipv4 log-only true
    neighbor "192.168.89.8" prefix-limit ipv4 threshold 80

*[ro:/configure router "Base" bgp]
A:admin@node-2# info flat > cf3:testbgp.cfg

*[ro:/configure router "Base" bgp]
A:admin@node-2# file show cf3:testbgp.cfg
File: testbgp.cfg
-------------------------------------------------------------------------------
    group "external" { }
    neighbor "192.168.89.8" group "external"
    neighbor "192.168.89.8" prefix-limit ipv4 maximum 200
    neighbor "192.168.89.8" prefix-limit ipv4 log-only true
    neighbor "192.168.89.8" prefix-limit ipv4 threshold 80

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

*[ro:/configure router "Base" bgp]
A:admin@node-2# file show cf3:testbgp.cfg
File: testbgp.cfg
-------------------------------------------------------------------------------
/configure router bgp
    group "external" { }
    neighbor "192.168.89.8" group "external"
    neighbor "192.168.89.8" prefix-limit ipv4 maximum 200
    neighbor "192.168.89.8" prefix-limit ipv4 log-only true
    neighbor "192.168.89.8" prefix-limit ipv4 threshold 80

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

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

*[ro:/configure router "Base" bgp]
A:admin@node-2# info
    group "external" {
    }
    neighbor "192.168.89.8" {
        group "external"
        prefix-limit ipv4 {
            maximum 200
            log-only true
            threshold 80
        }
    }

/configure router "Base" bgp
    group "external" {
    }
    neighbor "192.168.89.8" {
        group "external"
        prefix-limit ipv4 {
            maximum 200
            log-only true
            threshold 80
        }
    }

The load command supports an interactive input scratchpad when operating in merge mode.

When the load merge interactive command is executed, a temporary scratchpad is presented to the user. Line numbers displayed on the left side of the input aid with troubleshooting if errors occur in the input.

The interactive option of the merge command can be used anywhere the load command is supported, including the root (/) of the configure, debug, or li region.

[ex:/configure]
A:admin@node-2# load merge interactive
1> 

[ex:/configure]
A:admin@node-2# load merge interactive
1> system
2>    name main_router
3>    contact "Head office"
4> EOF
Loaded 3 lines in 0.0 seconds

*[ex:/configure]
A:admin@node-2# compare
    system {
+       contact "Head office"
+       name "main_router"
    }

[ex:/configure system]
A:admin@node-2# load merge interactive
1> +   contact "Head office"
2> -   name "node-2"
3> +   name "main_router"
4>
5> EOF
Loaded 4 lines in 0.0 seconds

*[ex:/configure system]
A:admin@node-2# compare
+   contact "Head office"
-   name "node-2"
+   name "main_router"

[ex:/configure]
A:admin@node-2# load merge interactive
1> system
2> name new_router
3> first incorrect entry "This flags an error"
4> second incorrect entry "Another error"
5> EOF
MINOR: MGMT_CORE #2201: Unknown element - 'first'
MINOR: MGMT_CORE #2502: Configuration load failed - error on line 3 - 'first incorrect entry "This flags an error"'

[ex:/configure router "Base"]
A:admin@node-2# load merge interactive
1> interface "base-1-1" {
2> port 1/1/3:1
3> ipv6 {
4> link-local-address {
5> address fe80::1
6> duplicate-address-detection false
7> }
8> address 2500::1 {
9> prefix-length 64
10> duplicate-address-detection false
11> }
12> vrrp 1 {
13> backup [2500::10 fe80::1:1]
14> message-interval 5
15> mac 00:00:5e:00:02:01
16> priority 130
17> ping-reply true
18> oper-group "op-v6LI-1"
19> bfd-liveness {
20> dest-ip 2000::2
21> service-name "100"
22> interface-name "bfd-1-1"
23> }
24> }
25> }
26> }
27>
28> Ctrl-D
MINOR: MGMT_CORE #2301: Invalid element value - 5 out of range 10..4095
MINOR: MGMT_CORE #2502: Configuration load failed - error on line 14 - 'message-interval 5'

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

Configuration groups are created in the groups branch of the configuration tree.

(ex)[configure]
A:admin@node-2# info
    groups {
        group "isis-backbone" {
            router "Base" {
                isis "0" {
                    interface "int-pe1-pe2" {
                        hello-authentication-key "KrbVPnF6Dg13PM/biw6ErHmrkAHk" hash
                        hello-authentication-type message-digest
                        hello-authentication true
                        interface-type point-to-point
                    }
                }
            }
        }
    }

Multiple configuration groups can be created, each with a unique name.

(ex)[configure]
A:admin@node-2# info
    groups {
        group "isis-backbone" {
            router "Base" {
                # configuration elements
            }
        }
        group "isis-access” {
            router "Base" {
                # configuration elements
            }
        }      
        group "qos-backbone” {
            card "1" {
                # configuration elements
            }
            port "1/1/1" {
                # configuration elements
            }
            qos {
                # configuration elements
            }
            router "Base" {
                # configuration elements
            }
        }      
    }

The configuration elements in a configuration group always start at a top-level configuration branch, such as router, qos, or card.

To match on a key of a list entry in a configuration group, an exact match or a regular expression match can be used.

To inherit configuration elements from a configuration group, apply the group in a branch of the configuration tree with the apply-groups statement. For example:

(ex)[configure router "Base" isis 0]
A:admin@node-2# info
    apply-groups ["isis-1"]

Configuration elements from the corresponding branches where the group is applied are inherited. In the following example, the configuration group ‟isis-3” has configuration elements in both the router isis interface and router isis level branch. Because the configuration group is applied at the router isis interface branch, only these configuration elements are inherited.

(ex)[configure]
A:admin@node-2# info
    groups {
        group "isis-3" {
            router "Base" {
                isis "0" {
                    interface "<int-.*>" {
                        interface-type point-to-point
                        level "2" {
                            metric 30
                        }
                    }
                    level "2" {
                        wide-metrics-only true
                    }
                }
            }
        }
    }

---snip---

   router "Base" {
        isis 0 {
            admin-state enable
            level-capability 2
            area-address [49.0001.0001]
            interface "int-pe1-pe2" {
                apply-groups ["isis-3"]
            }
        }
    }

The resulting expanded configuration can be shown with the info inheritance command:

(ex)[configure]
A:admin@node-2# info inheritance
   router "Base" {
        isis 0 {
            admin-state enable
            level-capability 2
            area-address [49.0001.0001]
            interface "int-pe1-pe2" {
                apply-groups ["isis-3"]
                ## 'interface-type' inherited from group "isis-3"
interface-type point-to-point
                level 2 {
                    ## 'metric' inherited from group "isis-3"
metric 30
                }
            }
        }
    }

The following notes apply to configuration groups and the apply-groups statements:

• configuration groups cannot be nested; therefore, apply-groups statements cannot be part of a configuration group

• configuration groups that are not applied in the configuration do not functionally change the configuration

• configuration groups and apply-groups statements are part of the running configuration and are saved in the MD-CLI configuration file

• the apply-groups statement can be configured in the configuration root (that is, /configure) but is not displayed in the online help for the context

Local configuration elements have precedence over configuration group inheritance.

In the following example, the configuration group ‟isis-1” contains the configuration element level-capability 1, which is not inherited because a corresponding local configuration element exists.

(ex)[configure]
A:admin@node-2# info
    groups {
        group "isis-1" {
            router "Base" {
                isis "0" {
                    level-capability 1
                    interface "<int-.*>" {
                        interface-type point-to-point
                        level "2" {
                            metric 10
                        }
                    }
                }
            }
        }
    }

---snip---

   router "Base" {
        isis 0 {
            apply-groups ["isis-1"]
            admin-state enable
            level-capability 2
            area-address [49.0001.0001]
            interface "int-pe1-pe2" {
            }
        }
    }

The resulting expanded configuration after inheritance is shown as follows:

(ex)[configure]
A:admin@node-2# info inheritance
   router "Base" {
        isis 0 {
            apply-groups ["isis-1"]
            admin-state enable
            level-capability 2
            area-address [49.0001.0001]
            interface "int-pe1-pe2" {
                ## 'interface-type' inherited from group "isis-1"
interface-type point-to-point
                level 2 {
                    ## 'metric' inherited from group "isis-1"
metric 10
                }
            }
        }
    }

Up to eight configuration groups can be applied to a configuration branch. The configuration order determines the inheritance precedence:

• configuration elements in the first listed group have the highest precedence

• configuration elements in the last listed group have the lowest precedence

In the following example, both configuration groups ‟isis-1” and ‟isis-2” set an interface level 2metric. Because configuration group ‟isis-2” is listed first in the apply-groups, its configuration elements have precedence. The interface-type configuration element is inherited from group ‟isis-1” because a corresponding configuration element is not present in group ‟isis-2” nor is it locally configured.

(ex)[configure]
A:admin@node-2# info
    groups {
        group "isis-1" {
            router "Base" {
                isis "0" {
                    level-capability 1
                    interface "<int-.*>" {
                        interface-type point-to-point
                        level "2" {
                            metric 10
                        }
                    }
                }
            }
        }
        group "isis-2" {
            router "Base" {
                isis "0" {
                    interface "<int-.*>" {
                        level "2" {
                            metric 20
                        }
                    }
                }
            }
        }
    }

---snip---

   router "Base" {
        isis 0 {
            apply-groups ["isis-2" "isis-1"]
            admin-state enable
            level-capability 2
            area-address [49.0001.0001]
            interface "int-pe1-pe2" {
            }
        }
    }

The resulting expanded configuration after inheritance is shown as follows:

(ex)[configure]
A:admin@node-2# info inheritance
   router "Base" {
        isis 0 {
            apply-groups ["isis-2" "isis-1"]
            admin-state enable
            level-capability 2
            area-address [49.0001.0001]
            interface "int-pe1-pe2" {
                ## 'interface-type' inherited from group "isis-1"
interface-type point-to-point
                level 2 {
                    ## 'metric' inherited from group "isis-2"
metric 20
                }
            }
        }
    }

Configuration groups can be applied at different hierarchical branches. The hierarchy determines the inheritance precedence.

Configuration elements in groups applied at a lower-level branch have precedence over configuration elements in groups applied at a higher-level branch.

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

(ex)[configure]
A:admin@node-2# info
    groups {
        group "isis-1" {
            router "Base" {
                isis "0" {
                    level-capability 1
                    interface "<int-.*>" {
                        interface-type point-to-point
                        level "2" {
                            metric 10
                        }
                    }
                }
            }
        }
        group "isis-2" {
            router "Base" {
                isis "0" {
                    interface "<int-.*>" {
                        level "2" {
                            metric 20
                        }
                    }
                }
            }
        }
        group "isis-3" {
            router "Base" {
                isis "0" {
                    interface "<int-.*>" {
                        interface-type point-to-point
                        level "2" {
                            metric 30
                        }
                    }
                    level "2" {
                        wide-metrics-only true
                    }
                }
            }
        }
    }

---snip---

   router "Base" {
        isis 0 {
            apply-groups ["isis-2" "isis-1"]
            admin-state enable
            level-capability 2
            area-address [49.0001.0001]
            interface "int-pe1-pe2" {
                apply-groups ["isis-3"]
            }
        }
    }

The resulting expanded configuration after inheritance is shown as follows:

(ex)[configure]
A:admin@node-2# info inheritance
   router "Base" {
        isis 0 {
            apply-groups ["isis-2" "isis-1"]
            admin-state enable
            level-capability 2
            area-address [49.0001.0001]
            interface "int-pe1-pe2" {
                apply-groups ["isis-3"]
                ## 'interface-type' inherited from group "isis-3"
interface-type point-to-point
                level 2 {
                    ## 'metric' inherited from group "isis-3"
metric 30
                }
            }
        }
    }

Inheritance rules for leaf-lists are the same as for a single leaf, whether the list is a system-ordered leaf list (for example, configure router interface interface-name if-attribute admin-group value) or a user-ordered leaf list (for example, configure router bgp export policy value). The entire leaf-list is inherited, and it is not possible to add values to an existing leaf-list through configuration group inheritance.

Inheritance rules for user-ordered lists (for example, configure policy-options policy-statement name named-entry entry-name) are:

• list order is ignored for user-ordered list entry matching

• unmatched list entries in the configuration group definition and its descendant configuration elements are inherited in the locally-configured user-ordered list. Newly-created list entries are appended at the end in the order they appear in the configuration group definition.

• descendant configuration elements of matched user-ordered list entries are candidates for inheritance

The apply-groups-exclude statement disables configuration inheritance for up to eight configuration groups in a configuration hierarchy. Configuration elements from the specified groups are not inherited in that branch. Disabling configuration inheritance for a configuration group only affects the configuration if that configuration group is applied at a higher-level branch in the configuration tree.

In the following example, configuration group ‟isis-1” is applied at the /configure router ‟Base” isis 0 context, but inheritance for that group is disabled for interface ‟int-pe1-ce1”.

[ex:configure groups]
A:admin@node-2# info
    group "isis-1" {
        router "Base" {
            isis 0 {
                interface "<int-.*>" {
                    interface-type point-to-point
                    level-capability 2
                }
                level 2 {
                    wide-metrics-only true
                }
            }
        }
    }

[ex:configure groups]
A:admin@node-2# /configure router isis

[ex:configure router "Base" isis 0]
A:admin@node-2# info
    apply-groups ["isis-1"]
    admin-state enable
    area-address [49.0001.0001]
    interface "int-pe1-ce1" {
        apply-groups-exclude ["isis-1"]
        passive true
    }
    interface "int-pe1-pe2" {
    }
    interface "int-pe1-pe3" {
    }

In the resulting expanded configuration, the interface parameters specified in the configuration group ‟isis-1” are not applied for interface ‟int-pe1-ce1”:

[ex:configure router "Base" isis 0]
A:admin@node-2# info inheritance
    apply-groups ["isis-1"]
    admin-state enable
    area-address [49.0001.0001]
    interface "int-pe1-ce1" {
        apply-groups-exclude ["isis-1"]
        passive true
    }
    interface "int-pe1-pe2" {
        ## 'interface-type' inherited from group "isis-1"
        interface-type point-to-point
        ## 'level-capability' inherited from group "isis-1"
        level-capability 2
    }
    interface "int-pe1-pe3" {
        ## 'interface-type' inherited from group "isis-1"
        interface-type point-to-point
        ## 'level-capability' inherited from group "isis-1"
        level-capability 2
    }
    level 2 {
        ## 'wide-metrics-only' inherited from group "isis-1"
        wide-metrics-only true
    }

The following configuration guidelines apply to the apply-groups-exclude statement.

• This statement cannot be included in a configuration group.

• The statement is included in the running configuration and saved in the MD-CLI configuration file.

• The statement cannot be configured at the configuration root (/configure).

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
    }

The expanded running configuration can also be displayed with the info intended command. This command displays the intended configuration datastore as specified in RFC 8342, Network Management Datastore Architecture (NMDA) as follows:

• the groups, apply-groups, and apply-groups-exclude configuration statements are suppressed

• the expanded configuration with all statements that are inherited from a configuration group is displayed without the ## system comments

(ex)[configure router "Base" isis 0 interface "int-pe1-pe2"]
A:admin@node-2# info intended
    interface-type point-to-point
    level 2 {
        metric 20
    }

User profiles can restrict the configuration branches that a user can change. Denied and read-only configuration branches in user profiles automatically prohibit inheritance of these branches via configuration groups.

To restrict a user from viewing, creating, or editing configuration branches inside a configuration group, an explicit entry for the configuration group must be added in the user profile.

In the following example, user admin2 has no access to the sap-ingress configuration branch.

(ex)[configure qos]
A:admin2@node-2# sap-ingress high-bw
MINOR: MGMT_CORE #2020: Permission denied - unauthorized use of 'sap-ingress'

This is enforced via the following entry in the local user profile:

(ro)[configure system security aaa local-profiles profile "restricted-admin"]
A:admin@node-2# info

---snip---

    entry 200 {
        action deny
match "configure qos sap-ingress"
    }

The same entry prohibits configuration group inheritance for user admin2.

[ex:configure groups]
A:admin2@node-2# info
    group "grp-1" {
        qos {
            sap-ingress "high-bw" {
                queue 1 {
                    rate {
                        pir 200000
                    }
                }
                fc "be" {
                    queue 1
                }
            }
        }
    }
[ex:configure]
A:admin2@node-2# /configure qos apply-groups "grp-1"
MINOR: MGMT_CORE #2020: configure qos sap-ingress "high-bw" - Permission denied

User admin2 can still view, create, or change sap-ingress QoS policies inside a configuration group if the changes do not result in configuration group inheritance of the sap-ingress QoS policy.

User admin2 cannot see the result of configuration group inheritance of a sap-ingress QoS policy because the info command is subject to the AAA rules defined in the user profile.

[ex:configure groups]
A:admin2@node-2# info
    group "grp-1" {
        qos {
            sap-ingress "high-bw" {
                queue 1 {
                    rate {
                        pir 200000
                    }
                }
                fc "be" {
                    queue 1
                }
            }
        }
    }

[ex:configure groups]
A:admin2@node-2# /configure qos

[ex:configure qos]
A:admin2@node-2# info inheritance
    apply-groups ["grp-1"]
    md-auto-id {
        qos-policy-id-range {
            start 65000
            end 65535
        }
    }

An administrative user with full privileges can see the inherited configuration, which includes the sap-ingress QoS policy created by user admin2.

[ro:configure qos]
A:admin@node-2# info inheritance
    apply-groups ["grp-1"]
    md-auto-id {
        qos-policy-id-range {
            start 65000
            end 65535
        }
    }
    ## 'sap-ingress "high-bw"' inherited from group "grp-1"
    sap-ingress "high-bw" {
        ## 'queue 1' inherited from group "grp-1"
        queue 1 {
            ## 'rate' inherited from group "grp-1"
            rate {
                ## 'pir' inherited from group "grp-1"
                pir 200000
            }
        }
        ## 'fc "be"' inherited from group "grp-1"
        fc "be" {
            ## 'queue' inherited from group "grp-1"
            queue 1
        }
    }

To prevent user admin2 from viewing, creating, or changing sap-ingress QoS policies inside a configuration group, an explicit entry for the configuration group must be added to the AAA user profile.

[ex:configure system security aaa local-profiles profile "restricted-admin"]
A:admin@node-2# info

---snip---

    entry 200 {
        action deny
        match "configure qos sap-ingress"
    }
    entry 201 {
        action deny
match "configure groups group qos sap-ingress"

This configuration removes the privileges for user admin2 to view, create, or change sap-ingress QoS policies inside a configuration group.

[ex:configure groups]
A:admin2@node-2# info
    group "grp-1" {
        qos {
        }
    }

[ex:configure groups]
A:admin2@node-2# group "grp-1" qos sap-ingress "high-bw"
MINOR: MGMT_CORE #2020: Permission denied - unauthorized use of 'sap-ingress'

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

In this example, all backbone IS-IS interface configuration parameters are part of the ‟isis-bb-interface” configuration group. A regular expression match ‟<int-.*>” is used to match on all backbone IS-IS interface names that start with ‟int-‟. The system loopback interface does not match the regular expression, so cannot inherit the configuration elements from the group.

The ‟isis-bb-interface” configuration group is applied at the router ‟Base”, IS-IS instance 0 branch. When a new IS-IS backbone interface is added with a name that starts with ‟int-‟, it also inherits the configuration elements from the configuration group.

(ex)[configure]
A:admin@node-2# info
    groups {
        group "isis-bb-interface" {
            router "Base" {
                isis "0" {
                    interface "<int-.*>" {
                        hello-authentication-key "KrbVPnF6Dg13PM/biw6ErHmrkAHk" hash
                        hello-authentication-type message-digest
                        hello-padding adaptive
                        hello-authentication true
                        interface-type point-to-point
                    }
                }
            }
        }
    }

---snip---

    router "Base" {
        isis 0 {
            apply-groups ["isis-bb-interface"]
            admin-state enable
            ipv4-routing true
            ipv6-routing native
            level-capability 2
            area-address [49.0001.0001]
            multi-topology {
                ipv6-unicast true
            }
            interface "int-pe1-pe2" {
            }
            interface "int-pe1-pe3" {
            }
            interface "system" {
                passive true
            }
            level 2 {
                wide-metrics-only true
            }
        }
    }

The resulting expanded configuration after inheritance is shown as follows:

(ex)[configure router "Base" isis 0]
A:admin@node-2# info inheritance
    apply-groups ["isis-bb-interface"]
    admin-state enable
    ipv4-routing true
    ipv6-routing native
    level-capability 2
    area-address [49.0001.0001]
    multi-topology {
        ipv6-unicast true
    }
    interface "int-pe1-pe2" {
        ## 'hello-authentication-key' inherited from group "isis-bb-interface"
        hello-authentication-key "KrbVPnF6Dg13PM/biw6ErHmrkAHk" hash
        ## 'hello-authentication-type' inherited from group "isis-bb-interface"
        hello-authentication-type message-digest
        ## 'hello-padding' inherited from group "isis-bb-interface"
        hello-padding adaptive
        ## 'hello-authentication' inherited from group "isis-bb-interface"
        hello-authentication true
        ## 'interface-type' inherited from group "isis-bb-interface"
        interface-type point-to-point
    }
    interface "int-pe1-pe3" {
        ## 'hello-authentication-key' inherited from group "isis-bb-interface"
        hello-authentication-key "KrbVPnF6Dg13PM/biw6ErHmrkAHk" hash
        ## 'hello-authentication-type' inherited from group "isis-bb-interface"
        hello-authentication-type message-digest
        ## 'hello-padding' inherited from group "isis-bb-interface"
        hello-padding adaptive
        ## 'hello-authentication' inherited from group "isis-bb-interface"
        hello-authentication true
        ## 'interface-type' inherited from group "isis-bb-interface"
        interface-type point-to-point
    }
    interface "system" {
        passive true
    }
    level 2 {
        wide-metrics-only true
    }

The resulting expanded configuration after inheritance is shown as follows, without system comments:

(ex)[configure router "Base" isis 0]
A:admin@node-2# info inheritance | match '^[ ]*##' invert-match
    apply-groups ["isis-bb-interface"]
    admin-state enable
    ipv4-routing true
    ipv6-routing native
    level-capability 2
    area-address [49.0001.0001]
    multi-topology {
        ipv6-unicast true
    }
    interface "int-pe1-pe2" {
        hello-authentication-key "KrbVPnF6Dg13PM/biw6ErHmrkAHk" hash
        hello-authentication-type message-digest
        hello-padding adaptive
        hello-authentication true
        interface-type point-to-point
    }
    interface "int-pe1-pe3" {
        hello-authentication-key "KrbVPnF6Dg13PM/biw6ErHmrkAHk" hash
        hello-authentication-type message-digest
        hello-padding adaptive
        hello-authentication true
        interface-type point-to-point
    }
    interface "system" {
        passive true
    }
    level 2 {
        wide-metrics-only true
    }

The following restrictions apply to configuration groups.

• Configuration groups are available only in model-driven management interface configuration mode and for configuration elements in the Nokia YANG models.

• When configuration groups are used with NETCONF, the <get-config> operation returns the pre-expanded configuration, including the configuration groups definitions and the apply-groups configuration elements. The expanded configuration, including the inherited configuration elements but excluding the configuration groups definitions and the apply-groups configuration elements, can be returned using the <get-data> operation on the intended datastore.

• When configuration groups are used with gNMI, the Get RPC command returns the pre-expanded configuration, including the configuration groups definitions and apply-groups configuration elements. The expanded configuration, including the inherited configuration elements, cannot be returned with gNMI.

For more information about NETCONF and gNMI, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide.

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

[/]
A:admin@node-2# admin disconnect session-id 10