1. Using the MD-CLI

This guide provides information about the Model-Driven Command Line Interface (MD-CLI).

This guide is organized into functional sections and provides concepts and descriptions of the MD-CLI environment, the configuration workflow, and the syntax and command usage within the MD-CLI. It also describes how the MD-CLI interacts with the classic CLI to perform non-configuration operations.

For a list of unsupported features by platform and chassis, refer to the SR OS R16.0.Rx Software Release Notes, part number 3HE 14220 000x TQZZA.

Command outputs shown in this guide are examples only; actual outputs may differ depending on supported functionality and user configuration.

Note:

This guide generically covers Release 16.0.R1 content and may contain some content that will be released in later maintenance loads. Refer to the SR OS R16.0.Rx Software Release Notes, part number 3HE 14220 000x TQZZA, for information about features supported in each load of the Release 16.0.R1 software.

1.1. MD-CLI Overview

All references to the term ‘CLI’ in the SR OS user documentation are generally referring to the classic CLI. The classic CLI is the CLI that has been supported in SR OS from the initial introduction of SR OS.

The MD-CLI is a management interface that can be used to manage Nokia SR OS routers. Some of the benefits of the MD-CLI include:

  1. follows the model-driven networking strategy, based on common YANG models for a structured configuration. Consistency is maintained between the MD-CLI, NETCONF, and the gRPC model-driven interfaces.
  2. uses the transactional configuration method which uses a candidate configuration to hold the current configuration changes before they are applied to the running configuration, and avoids configuration ordering requirements
  3. provides multiuser candidate configuration modes (global, exclusive, and read-only) that control access to the configuration, allowing a user exclusive access to the configuration such that no other configuration changes can be made
  4. allows the use of configuration groups with flexible templates that simplify the configuration process by applying the template instead of repeating the same configuration

For more information about NETCONF and gRPC, refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide.

1.2. Controlling the Management Interface Configuration Mode

Refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide for information about the management interface configuration mode.

1.2.1. Setting the Management Interface Configuration Mode

SR OS routers can be in different management interface configuration modes, which affects the management interfaces that can be used to configure the router. The following interfaces are available for configuration on SR OS:

  1. classic (default) — configuration via the classic CLI and SNMP, no model-driven interfaces are supported
  2. model-driven — configuration via model-driven interfaces, including NETCONF with Nokia YANG models, the MD-CLI, or gRPC, read-only access via the classic CLI and SNMP

1.2.1.1. Enabling the MD-CLI from the Classic CLI

The CLI engine refers to the CLI environment that is being used in a user session (for example, console, Telnet, or SSH) to configure and operate the router.

To enable the MD-CLI engine from the classic CLI, perform the following steps:

  1. Set the configuration mode to model-driven and leave cli-engine unconfigured.
    A:node-2>config>system>management-interface# configuration-mode model-driven
  2. Log out and start a new CLI session to access the MD-CLI engine.
    A:node-2>config>system>management-interface# logout

When a new user session begins, the MD-CLI engine is available and the MD-CLI prompt is displayed.

[]
A:admin@node-2#

When the configuration mode is changed to model-driven, the following applies:

  1. the configuration mode becomes immediately active
  2. access to configuration in the classic CLI is read-only (no modification)
  3. access to show configuration in the classic CLI is still available

1.2.1.2. Switching Between the Classic CLI and MD-CLI Engines

A single CLI command is available in both the classic CLI and MD-CLI engines to switch between the two engines in a user session. When authorized (cli-engine list contains both classic-cli and md-cli), the CLI engine switch command (“//”, the double forward slash) can be executed from any CLI context in both engines to switch to the other CLI engine.

A:node-2# //
INFO: CLI #2052: Switching to the MD-CLI engine
 
[]
A:admin@node-2# //
INFO: CLI #2051: Switching to the classic CLI engine
A:node-2#

The context in which the CLI engine switch command is executed is saved when toggling between CLI engines and returns to the same context when toggling back.

[]
A:admin@node-2# edit-config read-only
INFO: CLI #2066: Entering read-only configuration mode
 
(ro)[]
A:admin@node-2# configure router
 
(ro)[configure router "Base"]
A:admin@node-2# //
INFO: CLI #2051: Switching to the classic CLI engine
A:node-2# configure system management-interface
A:node-2>config>system>management-interface# //
INFO: CLI #2052: Switching to the MD-CLI engine
 
(ro)[configure router "Base"]
A:admin@node-2# //
INFO: CLI #2051: Switching to the classic CLI engine
A:node-2>config>system>management-interface#

If switching engines is not authorized (when cli-engine is only [classic-cli] or [md-cli]), the command is rejected.

A:node-2# //
MINOR: CLI #2053 Switching CLI engine is not authorized
A:node-2#

1.2.1.2.1. Executing Classic CLI Commands from the MD-CLI Engine

When switching engines is authorized, all classic CLI engine commands can be executed from the MD-CLI engine. Entering a classic CLI engine command preceded by the “//” command executes the command in the classic CLI engine and returns immediately to the MD-CLI engine. The MD-CLI context is preserved before the switch to the classic CLI engine, and the context is restored when the session returns to the MD-CLI engine. In the following example, the classic CLI command is executed from the configure aaa context in the MD-CLI. When the session returns to the MD-CLI engine, it is returned to the same context.

(ex)[configure aaa]
A:admin@node-2# //show router interface
INFO: CLI #2051: Switching to the classic CLI engine
A:node-2# /show router interface
 
===============================================================================
Interface Table (Router: Base)
===============================================================================
Interface-Name                   Adm       Opr(v4/v6)  Mode    Port/SapId
   IP-Address                                                  PfxState
-------------------------------------------------------------------------------
node-3                           Up        Down/Down   Network n/a
   -                                                           -
node-4                           Up        Down/Down   Network n/a
   -                                                           -
node-5                           Up        Down/Down   Network n/a
   -                                                           -
system                           Up        Up/Down     Network system
   10.10.10.1/32                                               n/a
-------------------------------------------------------------------------------
Interfaces : 4
===============================================================================
INFO: CLI #2052: Switching to the MD-CLI engine
 
(ex)[configure aaa]
A:admin@node-2#

It is acceptable to have a space between “//” and the CLI command. For example, //show users and // show users are equivalent commands.

User interactions, such as pagination, confirmation, or control characters (for example, CTRL-c to abort an ongoing command execution), are supported during CLI command execution. The CLI engine is switched back to the MD-CLI engine just before the CLI command prompt would normally appear.

(ex)[configure aaa]
A:admin@node-2# //ping 10.20.30.40
INFO: CLI #2051: Switching to the classic CLI engine
A:node-2# /ping 10.20.30.40
PING 10.20.30.40 56 data bytes
No route to destination. Address: 10.20.30.40, Router: Base
 
//Press CTRL-c
 
^C
ping aborted by user
 
---- 10.20.30.40 PING Statistics ----
1 packet transmitted, 0 packets received, 100% packet loss
INFO: CLI #2052: Switching to the MD-CLI engine
 
(ex)[configure aaa]
A:admin@node-2#

Executing MD-CLI commands from the classic CLI engine works in the same way as described for executing classic CLI commands from the MD-CLI engine.

1.2.1.2.2. MD-CLI and Classic CLI Engine Interactions

The following describes MD-CLI engine interactions with the classic CLI when using the “//” command:

  1. uncommitted changes in the MD-CLI are kept when switching to the classic CLI
  2. “//” appears in the history of the CLI engine where it is executed
    []
    A:admin@node-2# //
    INFO: CLI #2051: Switching to the classic CLI engine
    A:node-2# history
       1 history
    A:node-2# //
    INFO: CLI #2052: Switching to the MD-CLI engine
    []
    A:admin@node-2# history
           1 //
    []
    A:admin@node-2#
  3. “//command” appears in the history of both CLI engines
    []
    A:admin@node-2# //show time
    INFO: CLI #2051: Switching to the classic CLI engine
    A:node-2# /show time
    Tue Mar 13 19:52:37 UTC 2018
    INFO: CLI #2052: Switching to the MD-CLI engine
    []
    A:admin@node-2# history
           1 //show time
    []
    A:admin@node-2# //
    INFO: CLI #2051: Switching to the classic CLI engine
    A:node-2# history
       1 /show time
       2 history
    A:node-2#
  4. command completion, ? help, and redirection are not supported for the command following the “//”
  5. all control characters added on the same line when entering a “//” command have an effect on the CLI engine where they are entered
    []
    A:admin@node-2# //show system information //Press CTRL-w   # stay in MD-CLI engine
                                                               # delete word
    []
    A:admin@node-2# //show system information //Press CTRL-c   # stay in MD-CLI engine
                                                               # abort current command
    []
    A:admin@node-2#
    CTRL-z is the equivalent of Enter and exit all. When used on a command line with “//”, CTRL-z is the equivalent of just pressing Enter. Because the originating CLI engine is no longer available, exit all can no longer be executed.
    []
    A:admin@node-2# //show router policy //Press CTRL-z
    INFO: CLI #2051: Switching to the classic CLI engine
    A:node-2# /show router policy 
     
    ===============================================================================
    Route Policies
    ===============================================================================
    Policy                           Description
    -------------------------------------------------------------------------------
    BNG_internal
    all_loopbacks
    default_route
    -------------------------------------------------------------------------------
    Policies : 3
    ===============================================================================
    INFO: CLI #2052: Switching to the MD-CLI engine
     
    []
    A:admin@node-2#

A command history is maintained per CLI engine. CLI commands executed in the MD-CLI do not appear in the classic CLI history. CLI commands executed in the classic CLI do not appear in the MD-CLI history.

1.2.1.2.3. Switching to the Classic CLI Engine

The /!classic-cli command is available in both the classic CLI and MD-CLI engines to explicitly switch to the classic CLI engine in a session, as long as classic-cli is an authorized CLI engine. If switching to the classic CLI engine is not authorized, the command is rejected. Issuing the /!classic-cli command in the classic CLI engine has no effect.

The /!classic-cli switch command can be executed from any CLI context in both engines and the context is preserved for both engines. When the command is executed, the session enters the last saved working context of the classic CLI engine.

A:node-2>config>system>management-interface# //
INFO: CLI #2052: Switching to the MD-CLI engine
 
(ex)[configure router "Base" bgp]
A:admin@node-2# /!classic-cli
INFO: CLI #2051: Switching to the classic CLI engine
A:node-2>config>system>management-interface#

1.2.1.2.4. Switching to the MD-CLI Engine

The /!md-cli command is available in both the classic CLI and MD-CLI engines to explicitly switch to the MD-CLI engine in a session, as long as md-cli is an authorized CLI engine. If switching to the MD-CLI engine is not authorized, the command is rejected. Issuing the /!md-cli command in the MD-CLI engine has no effect.

The /!md-cli switch command can be executed from any CLI context in both engines and the context is preserved for both engines. When the command is executed, the session enters the last saved working context of the MD-CLI engine.

(ex)[configure router "Base" bgp]
A:admin@node-2# /!classic-cli
INFO: CLI #2051: Switching to the classic CLI engine
A:node-2>config>system>management-interface# /!md-cli
INFO: CLI #2052: Switching to the MD-CLI engine
 
(ex)[configure router "Base" bgp]
A:admin@node-2#

The /!md-cli and /!classic-cli commands can be useful when executing commands from a file, allowing the file to be executed in either CLI engine and ensuring the commands are run in the intended CLI engine.

1.3. Navigating in the MD-CLI

1.3.1. The MD-CLI Command Prompt

The MD-CLI command prompt displays on two lines. The first line contains the following information:

  1. uncommitted changes indicator
    This indicator displays an asterisk (*) to indicate uncommitted configuration changes when in configuration mode.
  2. configuration mode reference
    When in configuration mode, a configuration mode reference is displayed in round brackets. The configuration mode reference can be one of the following:
    1. gl — global mode
    2. ex — exclusive mode
    3. ro — read-only mode
  3. context
    The present working context is displayed in square brackets ([]) when in operational or configuration mode.

The format of the first line is as follows:

<uncommitted changes indicator> (<configuration mode>) [context]

Examples:

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

The second line contains the following information:

  1. CPM
    The active CPM slot can be A or B on 7750 SR routers, and A,B,C, or D on 7950 XRS routers.
  2. user
    The user is the name of the current user for this session.
  3. name
    The name is the system name, as configured with the configure system name command. The system name can change dynamically during the session if it is configured to a different name.

The format of the second line is as follows:

CPM:user@name#

The following examples display the two-line prompt in different modes.

  1. prompt in operational mode
    []
    A:admin@my-system#
  2. prompt in the operational root, with exclusive configuration mode
    (ex)[]
    A:admin@my-system#
  3. prompt in operational mode show router bgp
    [show router "Base" bgp]
    A:admin@my-system#
  4. prompt in exclusive configuration mode configure router bgp
    (ex)[configure router "Base" bgp]
    A:admin@my-system#
  5. prompt in exclusive configuration mode configure router bgp with uncommitted changes
    *(ex)[configure router "Base" bgp]
    A:admin@my-system#

1.3.2. Environment Commands

The following portion of the MD-CLI command tree displays commands related to the environment variables.

— configure
— system
— management-interface
— cli
— md-cli
— environment
— command-completion
— enter ([true] | false)
— space ([true] | false)
— tab ([true] | false)
— console
— length <24..512>
— width <80..512>
— message-severity-level
— cli (warning | info)
— more ([true] | false)
— progress-indicator
— admin-state (enable | disable)
— delay <0..10000>
— type <dots>
— prompt
— context ([true] | false)
— newline ([true] | false)
— timestamp ([true] | false)
— uncommitted-changes-indicator ([true] | false)
— time-display (local | utc)

The environment configuration for the MD-CLI is available in both the classic CLI and in the MD-CLI, but the configuration applies only to MD-CLI sessions.

In the MD-CLI:

(ex)[configure system management-interface cli md-cli environment]
A:admin@node-2#
 command-completion   + Configuration of keystrokes to trigger command
                        completion.
 console              + Configuration of console parameters.
 message-severity-    + Configuration of messages severity.
  level
 more                 - Controls paging of the output text.
 progress-indicator   + Settings for progress indicator during command execution
 prompt               + Controls content of displayed prompt
 time-display         - Specify time zone to be used, when displaying timestamp
                        before prompt.

In the classic CLI:

*A:node-2>config>system>management-interface>cli>md>env#
      command-comple* + Configure keystrokes to trigger command completion
      console         + Configure console parameters
      message-severi* + Configure messages severity
 [no] more            - Configure paging of the output text
      progress-indic* + Settings for progress indicator during command
                        execution
      prompt          + Configure content of displayed prompt
      time-display    - Specify whether timestamp should be displayed in UTC or
                        local time
*A:node-2>config>system>management-interface>cli>md>env#

Changes made to the environment configuration apply only to new sessions and do not affect current sessions.

1.3.2.1. Customizing Per-Session Environment Settings

The environment can be customized for all sessions in the configuration under the configure system management-interface cli md-cli environment context, or per session using the environment command. When a new MD-CLI session is started, the per-session environment configuration is copied from the global environment configuration. Changes made to the global environment configuration after the session begins apply only to new sessions and do not affect current sessions. Changes made to the environment parameters for a session apply only for that session.

The per-session environment is accessed by entering environment at the operational root or with /environment from any other mode or context. Changes made in the per-session environment are immediate.

The info command displays the difference between the per-session environment and the configured global environment parameters. Therefore, for a new MD-CLI session, the info command has no output, as the per-session environment is the same as the global environment. The info detail command displays the current values in the global environment for all parameters.

1.3.2.2. Customizing the Session Prompt

1.3.2.2.1. Customizing the Uncommitted Changes Indicator

As the default setting of the environment configuration, the uncommitted changes indicator is displayed as part of the command prompt. This setting can be modified per session or it can be changed for all MD-CLI sessions by changing the environment configuration.

The uncommitted-changes-indicator command under the environment prompt context suppresses or displays the change indicator for an MD-CLI session. Environment changes are applied immediately and are lost when the session disconnects.

*[environment prompt]
A:admin@node-2# uncommitted-changes-indicator false
 
[environment prompt]
A:admin@node-2#
 
[environment prompt]
A:admin@node-2# uncommitted-changes-indicator true
 
*[environment prompt]
A:admin@node-2#

1.3.2.2.2. Customizing the Line Preceding the Command Prompt

By default, a blank line precedes the command prompt. This setting can be modified for each MD-CLI session.

The newline command under the environment prompt context suppresses or displays a new line before the prompt.

 
[]
A:admin@node-2# environment prompt
 
[environment prompt]
A:admin@node-2# newline false
[environment prompt]
A:admin@node-2# newline true
 
[environment prompt]
A:admin@node-2#

1.3.2.2.3. Customizing the Context Information in the Command Prompt

By default, the context is displayed in the command prompt. This setting can be modified for each MD-CLI session.

The context command under the environment prompt context suppresses or displays the current context.

[environment prompt]
A:admin@node-2# context false
 
[]
A:admin@node-2# context true
 
[environment prompt]
A:admin@node-2#

1.3.2.2.4. Customizing the Timestamp

By default, the timestamp is not displayed before the command prompt. This setting can be modified for each MD-CLI session.

The timestamp command under the environment prompt context suppresses or displays the timestamp.

[environment prompt]
A:admin@node-2# timestamp true
 
SUN 10 JUNE 2018 23:09:51 UTC
[environment prompt]
A:admin@node-2# timestamp false
 
[environment prompt]
A:admin@node-2#

The environment time-display command configures the time zone display to UTC or local time (as configured in configure system time).

[environment]
A:admin@node-2# time-display ?
 time-display <keyword>
 
 <keyword> - (local|utc)
 
 Specify time zone to be used, when displaying timestamp before prompt.
 
 Value 'local' indicates that the local time zone is used.
 
 Value 'utc' indicates that Coordinated Universal Time (UTC) is used.

1.3.2.3. Customizing the Progress Indicator

The progress indicator appears on the line immediately following the command and disappears when the MD-CLI command completes or when output is available to display. The indicator is a display of dynamically changing dots.

(ex)[configure]
A:admin@node-2# compare
...                    // <- progress indicator displays here as dots

The delay interval can be configured with the delay command or the indicator can be disabled with the admin-state disable command under the environment progress-indicator context. For example, the user can disable the progress indicator for logged sessions.

[environment progress-indicator]
A:admin@node-2#
 admin-state          - Administrative state of progress indicator.
 delay                - Delay before progress indicator is displayed.
 type                 - Controls the progress indicator output style.
 
[environment progress-indicator]
A:admin@node-2#

1.3.2.4. Customizing the more Setting

The environment more command enables pagination when configured to true and disables pagination when configured to false. With pagination enabled, the display output can be paused and continued, based on the “Press Q to quit, Enter to print next line or any other key to print next page” message at the bottom of the screen.

[]
A:admin@node-2# environment more true
[]
A:admin@node-2# show system security profile user-profile-name administrative  
===============================================================================
User Profile
===============================================================================
 
User Profile          : administrative
Def. Action           : permit-all
LI                    : no
Netconf Kill
Authorization         : no
Netconf Lock
Authorization         : no
gRPC gNMI
Capabilities RPC
Authorization         : yes
gRPC gNMI Get RPC
Authorization         : yes
gRPC gNMI Set RPC
Authorization         : yes
gRPC gNMI Subscribe
RPC Authorization     : yes
-------------------------------------------------------------------------------
Cli Session Group     : no
Press Q to quit, Enter to print next line or any other key to print next page.

The pagination setting can be overridden by using | no-more for a single command. As with pagination disabled, the output is displayed completely without any prompts to continue.

[]
A:admin@node-2# show system security profile user-profile-name administrative | no-more

1.3.2.5. Customizing the Console Settings

The default size for a console window is 24 lines long by 80 characters wide. The environment console command can be used to change these settings.

(ex)[environment]
A:admin@node-2# console ?
 console
 
 length               - Controls number of lines displayed on the screen.
 width                - Controls number of columns displayed on the screen.

1.3.2.6. Customizing the Message Level Security Settings

The INFO: CLI messages are displayed by default. The environment message-security-level command suppresses the INFO messages by changing the setting to warning.

SUN 10 JUNE 2018 23:09:51 UTC
(ex)[environment message-severity-level]
A:admin@node-2# cli ?
 cli <keyword>
 
 <keyword> - (warning|info)
 
 Specifies the threshold for CLI messages.

Following are examples of INFO: CLI messages that are suppressed when the setting is changed to warning:

INFO: CLI #2051: Switching to the classic CLI engine
INFO: CLI #2052: Switching to the MD-CLI engine
INFO: CLI #2054: Entering global configuration mode
INFO: CLI #2056: Exiting global configuration mode 
INFO: CLI #2055: Uncommitted changes are present in the candidate configuration
INFO: CLI #2057: Uncommitted changes are kept in the candidate configuration

1.3.2.7. Preventing Changes to Environment Settings

The environment datastore is subject to AAA command authorization. A user can be prevented from modifying the global environment settings or the per-session environment settings, or both.

In the following configuration output, entry 113 blocks user “tstuser” from modifying the global environment settings. In addition, entry 114 prevents the user from changing the per-session environment settings.

(ro)[configure system security aaa local-profiles profile "tstuser"]
A:admin@node-2# info
    default-action permit-all
    entry 113 {
        action deny
        match "configure system management-interface cli md-cli environment"
    }
    entry 114 {
        action deny
        match "environment"
    }
(ex)[configure system management-interface cli md-cli environment]
A:tstuser@node-2# prompt timestamp
MINOR: MGMT_CORE #2020: Permission denied
 
(ex)[configure system management-interface cli md-cli environment]
A:tstuser@node-2# /environment
MINOR: MGMT_CORE #2020: Permission denied
 
(ex)[configure system management-interface cli md-cli environment]
A:tstuser@node-2#

1.3.3. Using Online Help

A short help description is displayed immediately when the question mark (?) is entered (without needing to press Return). The following displays help from the operational root level.

[]
A:admin@node-2# ?
 admin                + Enter the administrative context for system operations
 clear                + Clear statistics or reset operational state
 configure            + Enter the configuration context
 environment          + Enter the environment configuration context
 show                 + Show operational information
 tools                + Enter the tools context for troubleshooting and
                        debugging
 Global commands:
 back                 - Move back one or more levels
 commit               - Commit changes to the running datastore
 compare              - Show changes between datastores
 discard              - Discard changes in the candidate datastore
 edit-config          - Enter a candidate configuration mode
 exec                 - Execute commands from a file
 exit                 - Return to the previous working context or to the
                        operational root
 history              - Show the most recently entered commands
 info                 - Show the configuration from the present working context
 load                 - Load a configuration from a file
 logout               - Exit the CLI session
 pwc                  - Show the present working context
 quit-config          - Leave the candidate configuration mode
 rollback             - Rollback to a previous configuration
 top                  - Move to the top level of the context
 tree                 - Show the command tree under the present working context
 validate             - Validate changes in the candidate datastore

The help results may depend on the cursor position. For example, the output may differ when a “?” is entered with a space preceding it:

(ex)[]
A:admin@node-2# configure card?
 card <slot-number>
 [slot-number]        - The unique value which identifies this IOM slot within
                        a chassis in the system.
 
 Immutable fields     - card-type
 
 admin-state          - Administratively enable/disable the I/O module.
 card-type            - Add/remove an I/O module to/from the device
                        configuration for the slot
 fail-on-error        - Configure the behavior of the card state when an error
                        is detected.
 fp                   + The list of IOM forwarding plane parameters.
 level                - Provisions the functional level of the I/O module for
                        this slot.
 mda                  + The list of Media Dependant Adapters.
 named-pool-mode      - Enable/Disable named pool mode (card reset required).
 reset-on-            - Configure the behavior of the card state when a fatal
  recoverable-error     memory parity error is detected on a Q-chip of the card.
 virtual-scheduler-   + The container of card virtual scheduler adjustment
  adjustment            parameters.
 
(ex)[]
A:admin@node-2# configure card ?
 [slot-number] <iom card slot>
 
 <iom card slot> - <iom>
 
 The unique value which identifies this IOM slot within a chassis in the system.
 
(ex)[]
A:admin@node-2# configure card

1.3.3.1. Indicators in the Online Help

Table 1 describes the meaning of the indicators displayed in the online help.

Table 1:  Root Commands  

Symbol

Description

+

Indicates a container or list

-

Indicates a leaf, a leaf-list, a list or container with no leafs, or a global command (if in the operational root)

^

Indicates a mandatory element (an element that must be configured before the configuration is considered valid)

In the following help display example, admin-state, local-address, and router-instance are leafs, mcs-peer is a container, and address and sync-tag are mandatory elements.

(ex)[configure]
A:admin@node-2# aaa diameter-peer-policy plcyname proxy ?
 proxy
 
 admin-state          - Administrative state of Diameter proxy.
 local-address        - Source IP address on which Diameter proxy is listening
                        for client connections.
 mcs-peer             + Multi-Chassis Synchronization peer in Diameter multi-
                        chassis redundancy
 router-instance      - Routing context associated with Diameter proxy.
 
(ex)[configure]
A:admin@node-2# aaa diameter-peer-policy plcyname proxy mcs-peer ?
 mcs-peer
 
 address              ^ IPv4 address of the Multi-Chassis Synchronization
                        protocol (MCS) peer.
 sync-tag             ^ Synchronization tag shared by Multi-Chassis
                        Synchronization protocol (MCS) peers.
 
(ex)[configure]
A:admin@node-2# aaa diameter-peer-policy plcyname proxy mcs-peer

1.3.3.1.1. Descriptions and Format Guidelines for Leafs and Leaf-lists

When online help is entered for a leaf or leaf-list, a short description of the element is displayed after the element type. The valid input values for the element are also listed, as shown in the following examples.

The description string for the VPRN service can have a length of 1 to 80 characters:

*(ex)[configure service vprn "5"]
A:admin@node-2# description ?
 
 description <string>
 
 <string> - <1..80 characters>
 
 Specify service description.

The ? help for the autonomous-system parameter lists the valid number range, followed by a short description of the parameter:

*(ex)[configure service vprn "5"]
A:admin@node-6# autonomous-system ?
 autonomous-system <number>
 
 <number> - <1..4294967295>
 
 The autonomous system number to be advertised to this peer.
 
 This value MUST be set before BGP can be activated.

A parameter value may have a unit type associated with it, as shown in the following example of the cbs parameter:

(ex)[configure port 1/1/1 access ingress pool "default"]
A:admin@node-2# resv-cbs cbs ?
 cbs <number>
 
 <number> - <0..100> - percent
 
 Configure the percentage of pool size reserved for CBS.
 For network, the default value is computed as the sum of the CBS request by
 the entities using the pool.
 
 For access, the default value is 30%.

This example shows a parameter that is a reference to another parameter. This slope-policy parameter refers to the slope policy name that is configured through the configure qos slope-policy context. The name is a string of 1 to 32 characters.

(ex)[configure port 1/1/1 access ingress pool "default"]
A:admin@node-2# slope-policy ?
 slope-policy <reference>
 
 <reference> - <1..32 characters> - configure qos slope-policy <slope-policy-
                                     name>
 
 Configure the slope policy.

1.3.3.1.2. Immutable Elements

An immutable element can only be configured in the transaction in which the parent element is created. It cannot be modified while the parent element exists. Any modification to an immutable element in model-driven interfaces causes SR OS to automatically delete the parent element and recreate it with the new value for the immutable element.

Immutable elements are identified in the online help, as seen in the following examples:

*(ex)[configure service vpls "5"]
A:admin@node-2#?
 
 Immutable fields     - service-id, customer, vpn-id, etree, m-vpls, pbb-type
 
 admin-state          - Enable/disable service.
 bgp                  + Configure BGP common information.
 bgp-ad               + Enable BGP AD information.
 bgp-evpn             + Enable BGP EVPN information.
 bgp-mh-site          + BGP multi-homing site information.
 bgp-vpls             +
 capture-sap          + Capture SAP.
 customer             ^ Specify service customer identifier.
 description          - Specify service description.
 endpoint             + Configure endpoint information.
 etree                - Specify whether etree mode is enabled.
 fdb                  + Forwarding data-base information.
 gsmp                 + GSMP connections maintained in this service
 igmp-host-tracking   + Configure IGMP host tracking parameters.
 igmp-snooping        + Configure IGMP on this service.
 interface            + Configure interface parameters.
 load-balancing       + Configure load-balancing information.
 m-vpls               - Specify whether this is a management VPLS.
 
<snip>
*(ex)[configure service vpls "5"]
A:admin@node-2# customer ?
 customer <reference>
 
 <reference> - <1..64 characters> - configure service customer <customer-name>
 
 'customer' is: mandatory, immutable
 
 Specify service customer identifier.

Immutable elements also exist in the classic CLI. They are parameters that are on the command line with the create keyword. For example, in the following classic CLI command, all the parameters shown here on the command line are immutable. These parameters cannot be changed without deleting and recreating the service.

[]
A:admin@node-2# //
INFO: CLI #2051: Switching to the classic CLI engine
A:node-2# configure service vpls
  - no vpls <service-id>
  - vpls <service-id> [customer <customer-id>] [create] [vpn <vpn-id>] [m-vpls] [b-vpls|i-vpls] [etree] [name <name>]

1.3.3.1.3. Optional Indicators in the Online Help

The following help display is an example of optional indicators:

A:admin@node-2# port ?
 [port-id] (<port> | <connector> | <connector port> | <pxc port>)
 
 <port>           - <slot>/<mda>/<port>
 <connector>      - <slot>/<mda>/c<connector>
 <connector port> - <slot>/<mda>/c<connector>/<connector-port>
 <pxc port>       - pxc-<id>.[a|b]
 
 The identifier which uniquely identifies the port.
 
(ex)[configure]
A:admin@node-2# port

The square brackets ([]) around port-id indicate that the port-id keyword is optional when entering the command.

The angle brackets (<>) indicate a variable name and the pipe (|) indicates a choice. In the preceding example, the correct format of the port command contains one of four options: a port, a connector, a connector port, or a PXC port.

In the preceding example, any of the following would be valid formats for the port command:

port 1/1/1
port port-id 1/1/1
port port-id 1/1/c2
port 1/1/c1/5
port pxc-1.b

1.3.4. Operational Root and Global Commands

The commands in Table 2 are available at the operational root level of the MD-CLI hierarchy.

Table 2:  Operational Root Commands  

Command

Description

admin

Enter the administrative context for system operations

clear

Clear statistics or reset operational state

configure

Enter the configuration context

environment

Enter the environment configuration context

show

Show operational information

tools

Enter the tools context for troubleshooting and debugging

The global commands in Table 3 are available from various levels of the MD-CLI hierarchy.

Table 3:  Global Commands  

Command

Description

back

Move back one or more levels

edit-config

Enter a candidate configuration mode

exec

Execute commands from a file

exit

Return to the previous context or to the operational root

history

Show the most recently entered commands

logout

Exit the CLI session

pwc

Show the present working context

quit-config

Leave the candidate configuration mode

top

Move to the top level of the context

tree

Show the command tree under the present working context

Table 4 lists configuration commands that are available in configuration mode.

Table 4:  Configuration Commands  

Command

Description

commit

Commit changes to the running datastore

compare

Show changes between datastores

delete

Delete configuration from the candidate datastore

discard

Discard changes in the candidate datastore

info

Show the running configuration from the present working context

load

Load a configuration from a file

rollback

Rollback to a previous configuration

validate

Validate changes in the candidate datastore

1.3.5. Navigating the MD-CLI Hierarchy Levels

The following commands can be used to navigate the MD-CLI hierarchy (context) levels:

  1. pwc
    The pwc command shows the present working context with all keyword and variable parameters. The pwc previous command displays the previous working context.
    (ex)[configure]
    A:admin@node-2# card 1 fp 2
     
    *(ex)[configure card 1 fp 2]
    A:admin@node-2# egress
     
    *(ex)[configure card 1 fp 2 egress]
    A:admin@node-2# wred-queue-control
     
    *(ex)[configure card 1 fp 2 egress wred-queue-control]
    A:admin@node-2# buffer-allocation
     
    *(ex)[configure card 1 fp 2 egress wred-queue-control buffer-allocation]
    A:admin@node-2# pwc
    Present Working Context:
      configure
      card 1
      fp 2
      egress
      wred-queue-control
      buffer-allocation
     
    *(ex)[configure card 1 fp 2 egress wred-queue-control buffer-allocation]
    A:admin@node-2# pwc previous
    Previous Working Context:
      configure
      card 1
      fp 2
      egress
      wred-queue-control
     
    *(ex)[configure card 1 fp 2 egress wred-queue-control buffer-allocation]
    A:admin@node-2#
  2. back
    The back command can be used to go back one or more levels. If no parameter value is specified for the number of levels to go back, the default is one level. Using back at the top of the current command tree moves the context to the operational root level. If the number of levels specified is greater than the current depth, the context moves to the operational root.
    *(ex)[configure card 1 fp 2 egress wred-queue-control buffer-allocation]
    A:admin@node-2# back
     
    *(ex)[configure card 1 fp 2 egress wred-queue-control]
    A:admin@node-2# back 2
     
    *(ex)[configure card 1 fp 2]
    A:admin@node-2# back 5
     
    *(ex)[]
    A:admin@node-2#
  3. top
    The top command moves the context to the top of the current command tree without exiting the mode. This command can be used instead of executing the back command a number of times to move to the top of the command tree.
    *(ex)[]
    A:admin@node-2# configure
     
    *(ex)[configure]
    A:admin@node-2# card 1 fp 2
     
    *(ex)[configure card 1 fp 2]
    A:admin@node-2# egress
     
    *(ex)[configure card 1 fp 2 egress]
    A:admin@node-2# wred-queue-control
     
    *(ex)[configure card 1 fp 2 egress wred-queue-control]
    A:admin@node-2# top
     
    *(ex)[configure]
    A:admin@node-2#
  4. exit
    The exit command moves the context to the previous context in the current command tree. If the previous context was up one level, the exit command functions similarly to the back command. Using exit all moves the context to the operational root. Using exit at the operational root has no effect. To log out of the system, the logout command must be used.
    *(ex)[configure]
    A:admin@node-2# card 1 fp 2
     
    *(ex)[configure card 1 fp 2]
    A:admin@node-2# egress
     
    *(ex)[configure card 1 fp 2 egress]
    A:admin@node-2# wred-queue-control
     
    *(ex)[configure card 1 fp 2 egress wred-queue-control]
    A:admin@node-2# exit
     
    *(ex)[configure card 1 fp 2 egress]
    A:admin@node-2# exit all
     
    *(ex)[]
    A:admin@node-2#

1.3.6. Using the tree Command

The tree command displays the command tree under the present working context, excluding the present working context element. Hierarchy is indicated with a pipe (|) and a “+-- “ separator precedes each element. The tree output is in alphabetical order of elements.

(ro)[configure aaa]
A:admin@cses-V27# tree
+-- acct-on-off-group
|   +-- description
+-- diameter
|   +-- node
|       +-- connection-timer
|       +-- description
|       +-- ipv4-source-address
|       +-- ipv6-source-address
|       +-- origin-realm
|       +-- peer
|       |   +-- address
|       |   +-- admin-state
|       |   +-- connection-timer
|       |   +-- destination-host
|       |   +-- preference
|       |   +-- watchdog-timer
|       +-- python-policy
|       +-- router
+-- diameter-peer-policy
|   +-- applications
|   |   +-- gx
|   |   +-- gy
|   |   +-- nasreq
|   +-- connection-timer
|   +-- description
|   +-- ipv4-source-address
|   +-- ipv6-source-address
|   +-- origin-host
|   +-- origin-realm
|   +-- peer
|   |   +-- address
|   |   +-- admin-state
|   |   +-- connection-timer
|   |   +-- destination-host
|   |   +-- destination-realm
|   |   +-- preference
|   |   +-- transaction-timer
|   |   +-- transport
|   |   |   +-- port-number
|   |   +-- watchdog-timer
|   +-- proxy
|   |   +-- admin-state
|   |   +-- local-address
|   |   +-- mcs-peer
|   |   |   +-- address
|   |   |   +-- sync-tag
 
<snip>
 
(ro)[configure aaa]
A:admin@node-2# top
 
(ro)[configure]
A:admin@node-2# tree
+-- aaa
|   +-- acct-on-off-group
|   |   +-- description
|   +-- diameter
|   |   +-- node
|   |       +-- connection-timer
|   |       +-- description
|   |       +-- ipv4-source-address
|   |       +-- ipv6-source-address
|   |       +-- origin-realm
|   |       +-- peer
|   |       |   +-- address
|   |       |   +-- admin-state
|   |       |   +-- connection-timer
|   |       |   +-- destination-host
|   |       |   +-- preference
|   |       |   +-- watchdog-timer
|   |       +-- python-policy
|   |       +-- router
|   +-- diameter-peer-policy
|   |   +-- applications
|   |   |   +-- gx
|   |   |   +-- gy
 
<snip>
 
(ro)[configure]
A:admin@node-2# exit
 
(ro)[]
A:admin@node-2# tree
+-- admin
|   +-- disconnect
|   |   +-- session-id
|   +-- reboot
|   |   +-- card
|   |   +-- now
|   +-- redundancy
|   |   +-- force-switchover
|   |       +-- now
|   +-- save
|   |   +-- file-url
|   +-- show
|       +-- configuration
+-- back
+-- clear
|   +-- aaa
|   |   +-- diameter-peer-policy
|   |   |   +-- client-side-peer-ip
|   |   |   +-- peer
|   |   |   +-- port
|   |   |   +-- proxy
|   |   |   +-- statistics
|   |   +-- isa-radius-policy
|   |   |   +-- statistics
|   |   +-- l2tp-accounting-policy
|   |   |   +-- statistics
|   |   +-- radius-server-policy
|   |   |   +-- acct-session-id
|   |   |   +-- msg-buffer
|   |   |   +-- msg-buffer-only
|   |   |   +-- server
|   |   |   +-- statistics
|   |   +-- route-downloader
|   |       +-- family
|   |       +-- router
|   |       +-- service-name
|   |       +-- statistics
|   +-- application-assurance
|   |   +-- group
|   |   |   +-- cflowd
|   |   |   +-- event-log
|   |   |   +-- gtp
|   |   |   +-- statistics
|   |   |   +-- status
|   |   +-- radius-accounting-policy
|   |       +-- server
 
<snip>

1.3.6.1. Using the Flat Option

The flat option displays the command hierarchy under the present working context on one line, excluding the present working context element.

(ro)[]
A:admin@node-2# tree flat
admin
admin disconnect
admin disconnect session-id
admin reboot
admin reboot card
admin reboot now
admin redundancy
admin redundancy force-switchover
admin redundancy force-switchover now
admin save
admin save file-url
admin show
admin show configuration
back
clear
clear aaa
clear aaa diameter-peer-policy
clear aaa diameter-peer-policy client-side-peer-ip
clear aaa diameter-peer-policy peer
clear aaa diameter-peer-policy port
clear aaa diameter-peer-policy proxy
clear aaa diameter-peer-policy statistics
clear aaa isa-radius-policy
Press Q to quit, Enter to print next line or any other key to print next page.

1.3.6.2. Using the Detail Option

The detail option displays all key and field values in the output on every line.

(ro)[]
A:admin@node-2# tree detail
+-- admin
|   +-- disconnect
|   |   +-- session-id <number>
|   +-- reboot
|   |   +-- card <keyword>
|   |   +-- now
|   +-- redundancy
|   |   +-- force-switchover
|   |       +-- now
|   +-- save
|   |   +-- file-url <string>
|   +-- show
|       +-- configuration
+-- back <number>
+-- clear
|   +-- aaa
|   |   +-- diameter-peer-policy <string>
|   |   |   +-- client-side-peer-ip <string>
|   |   |   +-- peer <string>
|   |   |   +-- port <number>
|   |   |   +-- proxy <boolean>
|   |   |   +-- statistics <boolean>
|   |   +-- isa-radius-policy <string>

The flat and detail options can be combined in any order.

(ro)[]
A:admin@node-2# tree flat detail
admin
admin disconnect
admin disconnect session-id <number>
admin reboot
admin reboot card <keyword>
admin reboot now
admin redundancy
admin redundancy force-switchover
admin redundancy force-switchover now
admin save
admin save file-url <string>
admin show
admin show configuration
back <number>
clear
clear aaa
clear aaa diameter-peer-policy <string>
clear aaa diameter-peer-policy <string> client-side-peer-ip <string>
clear aaa diameter-peer-policy <string> peer <string>
clear aaa diameter-peer-policy <string> port <number>
clear aaa diameter-peer-policy <string> proxy <boolean>
clear aaa diameter-peer-policy <string> statistics <boolean>
clear aaa isa-radius-policy <string>

1.3.7. Using Control Characters and Editing Keystrokes on the Command Line

Table 5 lists the control characters and keystrokes available to execute and edit commands.

Table 5:  Control Characters  

Command

Description

/ (Slash)

Return to the operational root (equivalent to exit all) if used without parameters

Navigate into context or set the value and remain in current context if used at the beginning of a line (equivalent to exit all, and then the command)

CTRL-z

Execute command and return to the operational root (equivalent to Enter and exit all)

CTRL-c

Abort the pending command

CTRL-d

Delete the current character

CTRL-h

Delete the current character and move the cursor left

CTRL-u

Delete text up to the cursor and preserve the character under the cursor

CTRL-k

Delete text after the cursor. The character under the cursor is not preserved.

CTRL-a (or Home)

Move to the beginning of the line

CTRL-e (or End)

Move to the end of the line

CTRL-p (or Up arrow)

Display prior command from history

CTRL-n (or Down arrow)

Display next command from history

CTRL-b (or Left arrow)

Move the cursor one space to the left

CTRL-f (or Right arrow)

Move the cursor one space to the right

CTRL-w

Delete the word up to the cursor

ESC+b

Move back one word, or to the beginning of the current word if the cursor is not at the start of the word

1.3.8. Using Command Completion

The MD-CLI supports both command abbreviation and command completion. When typing a command, Tab, Spacebar, or Enter invokes auto-completion. If the text entered is enough to match a specific command, auto-completion completes the command. If the text entered is not sufficient to identify a specific command, pressing Tab or Spacebar displays options in alphabetical order matching the text entered.

The environment command-completion command controls what keystrokes can trigger command completion. Each keystroke is independently controlled with its own Boolean value.

(ex)[environment command-completion]
A:admin@node-2# info detail
    enter true
    space true
    tab true
 
(ex)[environment command-completion]
A:admin@node-2#
Note:

If Spacebar completion has multiple matches and also matches an keyword, the space is considered a separator and auto-completion is not triggered.

  1. configure por+Spacebar displays auto-completion results
  2. configure port+Spacebar inserts a space and suppresses auto-completion results
  3. configure por+Tab displays auto-completion results
  4. configure port+Tab displays auto-completion results

1.3.8.1. Variable Parameter Completion

Variable parameter completion works only with the Tab key. All configured variables from the candidate and running configuration datastores are displayed. Line wrapping may occur for variables with long names. Parameters are displayed in alphabetical or numerical order. The variable parameter name is always displayed as the first line. In the following example, “interface-name” is the variable parameter name and “int-1” and “system” are configured names.

*(ex)[configure router "Base"]
A:admin@node-2# interface //Press Tab
 <interface-name>
 "int-1"
 "system"
 
*(ex)[configure router "Base"]
A:admin@node-2# interface

1.3.8.1.1. Completion for Lists with a Default Keyword

Some list elements have a default keyword defined, such as the router command, where the default keyword is “Base”. When the command completion parameters (enter, space, and tab) are at their default settings (true), and the initial input matches an element in the list and a unique command keyword, the matching keyword is completed instead of the variable.

For example, the router command has a default keyword defined as “Base”. If router “g” is created using the command configure router “g” (with quotation marks”), and there is an existing gtp protocol, the variable completion is as follows.

The following displays for router+Spacebar+Tab:

*(ex)[configure]
A:admin@node-2# router  //Press Tab
 <router-instance>
 "Base"
 "g"
 "management"
 
 aggregates            allow-icmp-redirect   allow-icmp6-redirect
 autonomous-system     bgp                   class-forwarding
 confederation         description           dhcp-server
 ecmp                  entropy-label         fib-priority
 firewall              flowspec              gtp
 icmp-tunneling        igmp                  interface
 ipv6                  isa-service-chaining  isis
 l2tp                  ldp                   leak-export
 leak-export-limit     lsp-bfd               mc-maximum-routes
 mld                   mpls                  mpls-labels
 mss-adjust            mtrace2               multicast-info-policy
...

The following displays for router g+Tab:

*(ex)[configure]
A:admin@node-2# router g //Press Tab
 "g"
 
 gtp

Entering router g+Enter completes to router gtp and enters the router “Base” gtp context:

*(ex)[configure]
A:admin@node-2# router g //Press Enter
 
*(ex)[configure]
A:admin@node-2# router gtp
 
*(ex)[configure router "Base" gtp]
A:admin@node-2#

Similarly, router g+Spacebar completes to router gtp and enters the router “Base” gtp context when Enter is pressed:

*(ex)[configure]
A:admin@node-2# router g //Press Space //Press Enter
 
*(ex)[configure]
A:admin@node-2# router gtp
 
*(ex)[configure router "Base" gtp]
A:admin@node-2#

To enter the context for router “g”, quotation marks are used to specify the variable:

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

If the command completion for enter is set to false, then router g+Enter allows the match to router “g”. Similarly, when the command completion for space is false, router g+Spacebar also matches to router “g” instead of the keyword gtp.

*(ex)[environment command-completion]
A:admin@node-2# info detail
    enter true
    space true
    tab true
 
*(ex)[environment command-completion]
A:admin@node-2# enter false
 
*(ex)[environment command-completion]
A:admin@node-2# space false
 
*(ex)[environment command-completion]
A:admin@node-2#
 
*(ex)[]
A:admin@node-2# configure
 
*(ex)[configure]
A:admin@node-2# router g//Press Enter
 
*(ex)[configure router "g"]
A:admin@node-2# back
 
*(ex)[configure]
A:admin@node-2# router g//Press Spacebar+Enter
 
*(ex)[configure router "g"]
A:admin@node-2#

In the next example, the completion parameters are at the default settings of true. If the user intends to navigate to configure router isis, but enters configure router is+Enter, router “is” is created.

(ex)[configure]
A:admin@node-2# router is //Press Enter
 
*(ex)[configure router "is"]
A:admin@node-2#

Entering router is+Tab in the configure context shows the “is” router, in addition to the keywords that begin with “is”:

*(ex)[configure]
A:admin@node-2# router is //Press Tab
 "is"
 
 isa-service-chaining  isis
 
*(ex)[configure]
A:admin@node-2# router is

Entering router is+Spacebar in the configure context shows the keywords that begin with “is”:

*(ex)[configure]
A:admin@node-2# router is //Space
 isa-service-chaining  isis
 
*(ex)[configure]
A:admin@node-2# router is

In this scenario, the entire “isis” keyword must be entered to navigate to the desired context:

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

1.3.8.1.2. Completion for Keyword-based Leaf-lists

For keyword-based leaf-lists, command completion displays all possible values, not only those that are configured. When deleting values in a leaf-list, only the values that are currently configured are displayed. In the following example, when defining the forwarding traffic classes, all keyword values are listed. When deleting the forwarding traffic classes, only the configured classes are displayed.

*(ex)[configure mirror mirror-source "mrsc" subscriber "subscr-str"]
A:admin@node-2# fc //Press Tab
 <fc>
 af
 be
 ef
 h1
 h2
 l1
 l2
 nc
 
*(ex)[configure mirror mirror-source "mrsc" subscriber "subscr-str"]
A:admin@node-2# fc [ef h2 l2 af]
 
*(ex)[configure mirror mirror-source "mrsc" subscriber "subscr-str"]
A:admin@node-2# info
    fc [l2 af h2 ef]
 
*(ex)[configure mirror mirror-source "mrsc" subscriber "subscr-str"]
A:admin@node-2# delete fc //Press Tab
 <fc>
 *
 af
 ef
 h2
 l2
 
*(ex)[configure mirror mirror-source "mrsc" subscriber "subscr-str"]
A:admin@node-2# delete fc

1.3.8.1.3. Completion for Boolean Elements

The explicit use of true for a Boolean element is optional, as true is the default value. The true keyword is enclosed in square brackets ([]).

(ex)[environment]
A:admin@node-2# more ?
 more <boolean>
 
 <boolean> - ([true]|false)
 
 Controls paging of the output text.

When Tab is used for command completion with Boolean elements, the values of false and true are displayed, along with the names of possible elements that can follow. In the following example of the environment more command, the commands command-completion, console, message-severity-level, and so on, can be defined following the more command.

(ex)[environment]
A:admin@node-2# more //Press Tab
 false
 true
 
 command-completion     console                message-severity-level
 progress-indicator     prompt                 time-display
 
 delete
 
(ex)[environment]
A:admin@node-2# more

1.3.9. Displaying Available Commands using Tab

Variables, keywords, global commands, and configuration commands and units are separated by a blank line in the output, in the following order:

  1. values or units (mutually exclusive)
  2. keywords
  3. global commands
  4. configuration commands
(ro)[configure aaa diameter]
A:admin@node-2#//Press Tab
 node
 
 back         delete       edit-config  exec         exit         history
 kernel       logout       pwc          shell        top          tree
 
 compare      info         validate
 
(ro)[configure aaa diameter]
A:admin@node-2#

1.3.10. Modifying the Idle Timeout Value for CLI Sessions

A single idle timeout applies to all CLI engines in a CLI session (classic and MD-CLI). The idle timeout can be modified to a value between 1 and 1440 minutes.

The following points apply.

  1. The idle timeout only affects new CLI sessions. Existing and current sessions retain the previous idle timeout.
  2. The idle timeout can be disabled by setting the value to none.
  3. The “Idle time” column in the show users display is reset after an action in either CLI engine.
    []
    A:admin@node-2# show users
    ===============================================================================
    User                             Type      Login time           Idle time
      From
    ===============================================================================
                                     Console         --             0d 05:50:44
      --
    admin                            SSHv2     20JUN2018 13:28:21   0d 03:22:18
      192.168.100.001
    admin                            SSHv2     20JUN2018 16:50:35   0d 00:00:03
      192.168.100.002
    -------------------------------------------------------------------------------
    Number of users : 2
    ===============================================================================

A warning message is displayed when a session reaches one-half the value of the idle timeout, and another message is displayed when the idle timeout expires.

1.3.10.1. Idle Timeout Interaction with the Classic CLI

The idle timeout configured in the classic CLI affects all new sessions as well as the current session. However, the current session is only affected if the classic CLI engine is active when the idle timeout expires. Configuration changes via the MD-CLI or any other interface, including SNMP, only affect new sessions that begin after the change.

1.3.11. Using Output Modifiers

Output modifiers provide support for post-processing of CLI output. Output modifiers are specified using a pipe (|) character. The following points apply when using output modifiers.

  1. Output modifiers can be appended to any CLI command in any command context.
  2. Output modifiers work across soft line breaks (visual lines) that are wrapped due to the terminal width; for example, using match or count. They do not work across hard line breaks (logical lines).
  3. Modifiers can be combined in any order. No hard limit exists for the number of combinations. Output is processed linearly and there is little impact on the system performance except to the operator session that entered the modifier combination.

1.3.11.1. Using | match Options

The following options are supported for use with the pipe (|) match command:

  1. ignore-case — specifies to ignore case in pattern match
  2. invert-match — specifies to invert the pattern match selection
  3. max-count — specifies the maximum number of displayed matches
  4. post-lines — specifies the number of lines to display following the matched line
  5. pre-lines — specifies the number of lines to display preceding the matched line

The following example matches on the pattern autonomous-system in the tree detail under the configure router “Base” context, and starts the display with seven lines preceding the pattern match.

(ex)[configure router "Base"]
A:admin@node-2# tree detail | match autonomous-system pre-lines 7
|       +-- community <string>
|       +-- description <string>
|       +-- indirect <unicast ipv4 address or global unicast ipv6 address>
|       +-- local-preference <number>
|       +-- summary-only <boolean>
+-- allow-icmp-redirect <boolean>
+-- allow-icmp6-redirect <boolean>
+-- autonomous-system <number>
 
(ex)[configure router "Base"]
A:admin@node-2#

1.3.11.1.1. Using Regular Expressions with | match

Regular expressions (REs) used by the MD-CLI engine are delimited by apostrophes (‘); for example, ‘.*’. REs cannot be delimited by double quotation marks (“); for example, “.*”.

MD-CLI REs are based on a subset of The Open Group Base Specifications Issue 7 and IEEE Std 1003.1-2008, 2016 Edition REs, as defined in chapter 9. MD-CLI REs only support Extended Regular Expression (ERE) notation as defined in section 9.4. Basic Regular Expression (BRE) notation as defined in section 9.3 is not supported.

In ERE notation, a backslash (\) before a special character is treated as a literal character. Backslashes are not supported before ( ) or { }, as they are in BREs to indicate a bracket expression or marked expression.

Table 6 describes the special characters that are supported in EREs.

Table 6:  Special Characters in Extended Regular Expressions 

Special character

Description

.

Matches any single character

*

Matches the preceding expression zero or more times

?

Matches the preceding expression zero or one time

+

Matches the preceding expression one or more times

[ ]

Matches a single character within the brackets

[^]

Matches a single character not within the brackets

^

Matches the starting position

$

Matches the ending position

( )

Defines a marked subexpression

{m,n}

Matches the preceding expression at least m and not more than n times

{m}

Matches the preceding expression exactly m times

{m, }

Matches the preceding expression at least m times

{ ,n}

Matches the preceding expression not more than n times

|

Matches either expression preceding or following the |

\

Treats the following character as a match criterion

-

Separates the start and end of a range

The following examples show the use of a bracket expression as a matching list expression.

The first output does not use any match expressions and therefore shows the entire output.

*(gl)[]
A:admin@node-2# show port
===============================================================================
Ports on Slot 1
===============================================================================
Port          Admin Link Port    Cfg  Oper LAG/ Port Port Port   C/QS/S/XFP/
Id            State      State   MTU  MTU  Bndl Mode Encp Type   MDIMDX
-------------------------------------------------------------------------------
1/1/1         Down  No   Ghost   8704 8704    - netw null xcme
1/1/2         Up    No   Ghost   1514 1514    - accs null xcme
1/1/3         Up    No   Ghost   1514 1514    - accs null xcme
1/1/4         Up    No   Ghost   1514 1514    - accs null xcme
1/1/5         Up    No   Ghost   1514 1514    - accs null xcme
1/1/6         Down  No   Ghost   8704 8704    - netw null xcme
1/1/7         Down  No   Ghost   8704 8704    - netw null xcme
1/1/8         Down  No   Ghost   8704 8704    - netw null xcme
1/1/9         Down  No   Ghost   8704 8704    - netw null xcme
1/1/10        Down  No   Ghost   8704 8704    - netw null xcme
1/1/11        Down  No   Ghost   8704 8704    - netw null xcme
1/1/12        Down  No   Ghost   8704 8704    - netw null xcme
1/2/1         Up    No   Ghost   8704 8704    - netw null xcme
1/2/2         Up    No   Ghost   1514 1514    - accs null xcme
1/2/3         Up    No   Ghost   1514 1514    - accs null xcme
1/2/4         Down  No   Ghost   8704 8704    - netw null xcme
Press Q to quit, Enter to print next line or any other key to print next page.

In this matching list expression, a match is any single character in the bracket expression, which in this case is 1, 3, or 5.

*(gl)[]
A:admin@node-2# show port | match '1/1/[135]'
1/1/1         Down  No   Ghost   8704 8704    - netw null xcme
1/1/3         Up    No   Ghost   1514 1514    - accs null xcme
1/1/5         Up    No   Ghost   1514 1514    - accs null xcme
1/1/10        Down  No   Ghost   8704 8704    - netw null xcme
1/1/11        Down  No   Ghost   8704 8704    - netw null xcme
1/1/12        Down  No   Ghost   8704 8704    - netw null xcme

In this non-matching list expression, a match is any single character not in the bracket expression, that is, not 1, 2, or 4.

*(gl)[]
A:admin@node-2# show port | match '1/1/[^124]'
1/1/3         Up    No   Ghost   1514 1514    - accs null xcme
1/1/5         Up    No   Ghost   1514 1514    - accs null xcme
1/1/6         Down  No   Ghost   8704 8704    - netw null xcme
1/1/7         Down  No   Ghost   8704 8704    - netw null xcme
1/1/8         Down  No   Ghost   8704 8704    - netw null xcme
1/1/9         Down  No   Ghost   8704 8704    - netw null xcme

The range operator (-) can be used in a matching or non-matching list expression.

*(ro)[]
A:admin@node-2# show port | match '1/1/[3-7]'
1/1/3         Up    No   Ghost   1514 1514    - accs null xcme
1/1/4         Up    No   Ghost   1514 1514    - accs null xcme
1/1/5         Up    No   Ghost   1514 1514    - accs null xcme
1/1/6         Down  No   Ghost   8704 8704    - netw null xcme
1/1/7         Down  No   Ghost   8704 8704    - netw null xcme
*(ro)[]
A:admin@node-2# show port | match '1/1/[^3-7]'
1/1/1         Down  No   Ghost   8704 8704    - netw null xcme
1/1/2         Up    No   Ghost   1514 1514    - accs null xcme
1/1/8         Down  No   Ghost   8704 8704    - netw null xcme
1/1/9         Down  No   Ghost   8704 8704    - netw null xcme
1/1/10        Down  No   Ghost   8704 8704    - netw null xcme
1/1/11        Down  No   Ghost   8704 8704    - netw null xcme
1/1/12        Down  No   Ghost   8704 8704    - netw null xcme

The alternation operator (|) can be used with or without a bracket expression to match against two or more alternative expressions.

*(ro)[]
A:admin@node-2# show port | match '1/1/[2-5|7-9]'
1/1/2         Up    No   Ghost   1514 1514    - accs null xcme
1/1/3         Up    No   Ghost   1514 1514    - accs null xcme
1/1/4         Up    No   Ghost   1514 1514    - accs null xcme
1/1/5         Up    No   Ghost   1514 1514    - accs null xcme
1/1/7         Down  No   Ghost   8704 8704    - netw null xcme
1/1/8         Down  No   Ghost   8704 8704    - netw null xcme
1/1/9         Down  No   Ghost   8704 8704    - netw null xcme

Without a bracket expression, an exact match is attempted against two or more alternative expressions.

*(ro)[]
A:admin@node-2# info | match 'mda|fp'
        mda 1 {
            mda-type m12-1gb-xp-sfp
        mda 2 {
            mda-type m10-1gb-sfp-b
        fp 1 {

MD-CLI REs match on the output format of an element, as shown in the configuration. For example, if the value of an element is shown in hexadecimal in info output, a decimal RE will not match the value. In the following example, the Ethertype is entered in decimal format, but is displayed in hexadecimal. Matching on the decimal format does not find a match.

*(ex)[configure port 1/1/1 ethernet]
A:admin@node-2# dot1q-etype ?
 dot1q-etype <number>
 
 <number> - <0x600..0xffff>
 
 Configure the ethertype used for dot1q encapsulation on the Ethernet port.
 
 
*(ex)[configure port 1/1/1 ethernet]
A:admin@node-2# dot1q-etype 65535
 
*(ex)[configure port 1/1/1 ethernet]
A:admin@node-2# info
    dot1q-etype 0xffff
 
*(ex)[configure port 1/1/1 ethernet]
A:admin@node-2# top
 
*(ex)[configure]
A:admin@node-2# info | match 65535
 
*(ex)[configure]
A:admin@node-2# info | match 0xffff
            dot1q-etype 0xffff
 
*(ex)[configure]
A:admin@node-2#

MD-CLI REs are not implicitly anchored. The ^ or $ anchoring special characters can be used, as in the following example.

*(ex)[configure router "Base" bgp]
A:admin@node-2# info
    group "external" {
    }
    group "internal" {
    }
    neighbor 192.168.10.1 {
        group "external"
        keepalive 30
        peer-as 100
    }
    neighbor 192.168.10.2 {
        group "external"
        peer-as 100
        family {
            ipv4 true
        }
    }

This example uses the ^ anchor character to match on “group” preceded by four spaces at the beginning of the line.

*(ex)[configure router "Base" bgp]
A:admin@node-2# info | match '^    group' pre-lines 1
    group "external" {
    }
    group "internal" {

This example uses the ^ anchor character to match on “group” preceded by eight spaces at the beginning of the line.

*(ex)[configure router "Base" bgp]
A:admin@node-2# info | match '^        group' pre-lines 1
    neighbor 192.168.10.1 {
        group "external"
    neighbor 192.168.10.2 {
        group "external"
*(ex)[configure router "Base" bgp]
A:admin@node-2#

In the following configuration example using the compare command, the | match option filters out those commands to be deleted (configuration statements beginning with the minus sign (-)) and those to be added (configuration statements beginning with the plus sign (+)).

*(gl)[configure log accounting-policy 5]
A:admin@node-2# /compare
+   admin-state enable
-   collection-interval 105
+   collection-interval 75
-   include-system-info true
+   include-system-info false
 
*(gl)[configure log accounting-policy 5]
A:admin@node-2# /compare | match '^-'
-   collection-interval 105
-   include-system-info true

The backslash (\) is used to match the literal “+” character that denotes additions to the configuration seen in the compare command.

*(gl)[configure log accounting-policy 5]
A:admin@node-2# /compare | match '^\+'
+   admin-state enable
+   collection-interval 75
+   include-system-info false

A character class expression is expressed as a character class name enclosed within bracket colon (“[:” and “:]”) delimiters. Table 7 defines the character class expressions.

Table 7:  Character Class Expressions  

Character Class

Characters matched (delimited by ‘ single quotation marks’)

Description

[:alnum:]

‘ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz 0123456789’

Alphanumeric characters

[:alpha:]

‘ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz’

Alphabetic characters

[:blank:]

‘ \t’

Space and Tab

[:cntrl:]

‘\007\b\t\n\v\f\r\1\2\3\4\5\6\16\17\20 \21\22\23\24\25\26\27\30 \31\32\33\34\35\36\37\177’

Control characters

[:digit:]

‘0123456789’

Digits

[:graph:]

‘ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz 0123456789 !\"#$%&'()*+,-./:;<=>?@[\\]^_`{|}~’

Visible characters

[:lower:]

‘abcdefghijklmnopqrstuvwxyz’

Lowercase letters

[:print:]

‘ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz 0123456789!\"#$%&'()*+,-./:;<=>?@[\\]^_`{|}~ ’

Visible characters and the Space character

[:punct:]

‘!\"#$%&'()*+,-./:;<=>?@[\\]^_`{|}~’

Punctuation characters

[:space:]

‘\t\n\v\f\r ‘

Whitespace (blank) characters

[:upper:]

‘ABCDEFGHIJKLMNOPQRSTUVWXYZ’

Uppercase letters

[:xdigit:]

‘0123456789ABCDEFabcdef’

Hexadecimal digits

Character class expressions must be enclosed within brackets. The expression ‘[[:digit:]]’ is treated as an RE containing the character class “digit”, while ‘[:digit:]’ is treated as an RE matching “:”, “d”, “i”, “g”, or “t”.

Collating symbols and equivalence classes are not supported in MD-CLI REs.

1.3.11.2. Using | count

The | count option displays the line count of the output.

(ro)[configure qos]
A:admin@node-2# tree flat detail | match wrr-policy
hsmda-wrr-policy <string>
hsmda-wrr-policy <string> apply-groups <reference>
hsmda-wrr-policy <string> class-agg-weight <number>
hsmda-wrr-policy <string> description <string>
hsmda-wrr-policy <string> include-queues <keyword>
hsmda-wrr-policy <string> schedule-using-class <number>
network-queue <string> egress-hsmda wrr-policy <reference>
queue-group-templates egress queue-group <string> hsmda-queues wrr-policy <reference>
sap-egress <string> hsmda-queues wrr-policy <reference>
 
(ro)[configure qos]
A:admin@node-2# tree flat detail | match wrr-policy | count
Count: 9 lines
 
(ro)[configure qos]
A:admin@node-2#
Note:

Error messages are not processed by output modifiers. They are always displayed and are not affected by the count or match modifiers.

1.3.11.3. Using the | no-more Option

The | no-more option displays the output with pagination disabled. This option is similar to the environment more false setting, where the entire output text is printed without page interruptions.

1.3.12. Navigating Contexts in the MD-CLI

1.3.12.1. Entering Contexts

Configuring a container navigates into the context. In the following example, the first container is aaa, and the next is diameter. All containers are marked with a “+”.

(ex)[configure]
A:admin@node-2#?
 aaa                  + Configuration statements for authentication,
                        authorization and accounting
 bfd                  + The Bidirectional Forwarding Detection protocol
 bmp                  + Configure BGP Monitoring Protocol parameters.
 card                 + The list of physical cards in chassis slots.
 cflowd               + Configure Cflowd.
 chassis              + Physical Chassis
 connection-profile   + Connection Profile Configurations.
 connection-profile-  + Connection Profile Configurations.
  vlan
...
 
(ex)[configure]
A:admin@node-2# aaa
 
(ex)[configure aaa]
A:admin@node-2#?
 acct-on-off-group    + Configure a RADIUS accounting on off group
 diameter             + Diameter Base protocol
 diameter-peer-policy + Configure a Diameter peer policy
 isa-radius-policy    + ISA RADIUS policy
 l2tp-accounting-     + Configure an L2TP accounting policy
  policy
 radius-coa-port      - Configure radius CoA port
 radius-script-policy + Configure Python scripts to modify RADIUS messages
 radius-server-policy + Configure a RADIUS server policy
 route-downloader     + Configure a route-downloader
 wpp                  + Web portal protocol parameters
 
(ex)[configure aaa]
A:admin@node-2# diameter

Alternatively, the same context can be entered on one line:

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

Configuring a leaf element maintains the present working context if there is no explicit opening brace. Entering an explicit opening brace navigates into the specified context.

(ex)[]
A:admin@node-2# configure card 1 fp 2
 
*(ex)[configure card 1 fp 2]
A:admin@node-2# hi-bw-mcast-src default-paths-only false
 
*(ex)[configure card 1 fp 2]
A:admin@node-2# hi-bw-mcast-src { group 23
 
*(ex)[configure card 1 fp 2 hi-bw-mcast-src]
A:admin@node-2#

Configuring a container navigates into the context.

(ex)[configure]
A:admin@node-2# card 1 fp 2
 
*(ex)[configure card 1 fp 2]
A:admin@node-2# egress
 
*(ex)[configure card 1 fp 2 egress]
A:admin@node-2# wred-queue-control
 
*(ex)[configure card 1 fp 2 egress wred-queue-control]
A:admin@node-2#

Configuring an empty container or a list where the only children are keys does not navigate into the context. These elements are displayed with aggregated braces with a space ({ }) on the same line. It is possible to enter the element name with an opening brace; however, no options are available in this context.

For example, configuring the list element sdp-include with a key of “ref_group_name” does not change the existing context.

*(ex)[configure service pw-template "tt"]
A:admin@node-1# sdp-include ref_group_name
 
*(ex)[configure service pw-template "tt"]
A:admin@node-1# info
    sdp-include "ref_group_name" { }
 
*(ex)[configure service pw-template "tt"]
A:admin@node-1#

1.3.12.2. Exiting Contexts

The back and top commands are used to navigate contexts, but it is also possible to use closing braces to navigate.

The behavior of an explicit closing brace depends on the contents of the current command line. If the command line contains an explicit opening brace, the closing brace exits to the parent context of the opening brace.

In the following example with an opening brace on the command line, the closing brace exits VPRN 1, and then enters the context of VPRN 2.

(ex)[]
A:admin@node-2# configure service vprn 1 { interface "intf1" description "vprn-if" } vprn 2
 
*(ex)[configure service vprn "2"]
A:admin@node-2#

In the following example without an opening brace on the command line, the first closing brace exits interface “int1”, and the second closing brace exits VPRN 1 and enters the VPRN 2 context.

*(ex)[configure service]
A:admin@node-2# vprn 1 interface "int1" description vprn-if } } vprn 2
 
*(ex)[configure service vprn "2"]
A:admin@node-2#

1.3.13. Executing Commands with a File

The exec command executes commands from a file as if the user typed or pasted the input into the MD-CLI without command completion. The syntax can be seen as follows:

*(gl)[configure]
A:admin@node-2# exec ?
 
 [url] <string>
 <string> - <0..255 characters>
 
 The location of the file to be executed.
 
*(gl)[configure]
A:admin@node-2# exec my-url-file-name ?
 exec <url>
 [url]                - The location of the file to be executed.
 
 echo                 - Displays the commands on screen as they are being
                        executed.

The exec command:

  1. errors if it detects an interactive input
  2. terminates in the CLI engine in which it completes execution as follows:
    1. if there are no commands that switch CLI engines, the CLI engine is always the one in which exec started
    2. if there are commands that switch CLI engines, exec ends in the last CLI engine that was entered
    3. //exec returns to the engine in which it was started
  3. terminates execution and displays an error message if an error occurs, leaving the session in the same context as when the error occurred

The system executes the file as follows:

  1. disables pagination while the command is running
  2. disables command completion while the command is running
  3. suppresses the commands in the file from the command history

1.3.13.1. Using Commands that Switch Engines in an Executable File

When using commands that switch between CLI engines within an executable file, the following commands are recommended:

  1. use /!classic-cli to switch explicitly to the classic CLI engine and /!md-cli to switch explicitly to the MD-CLI engine, instead of // to toggle between engines
  2. use exit all to get to a known starting point: the operational root of the classic CLI or the MD-CLI engine
  3. include edit-config if the script needs to change the candidate configuration in the MD-CLI engine. Use quit-config after changes are committed in the script.
    Note:

    1. An executable with edit-config may fail if other users have locked the configuration.
    2. Issuing the quit-config command with changes in the candidate configuration while the session is in exclusive configuration mode fails the executable because of the “discard changes” prompt.

1.3.14. Displaying Information in the MD-CLI

1.3.14.1. Using the info Command

The info command shows the configuration for the present context. The command can only be executed while in a configuration mode. By default, all configured parameters in the candidate configuration datastore are displayed.

— info [[from] (candidate | running)]
— converted
— detail
— flat
— full-context
— inheritance

Table 8 describes the info command options.

Table 8:  Info Command Options  

Option

Description

[from] (candidate | running)

Specify the source datastore (default is from candidate)

converted

Include converted configuration values from third party modules

detail

Include default and unconfigured values in the output

flat

Show the hierarchy on each line starting from the present working context

full-context

Show the full hierarchy on each line

inheritance

Include configuration inherited from configuration groups

Note:

The flat and full-context options are mutually exclusive. Valid option combinations (in any order) are:

  1. converted detail
  2. flat detail
  3. full-context detail

The order of the configuration output is as follows:

  1. keys are displayed on the same line as the command element
  2. apply-groups is displayed, if applicable
  3. admin-state is displayed, if applicable
  4. description is displayed, if applicable
  5. other top-level elements are displayed in alphabetical order

The configuration output displays all elements that are configured, even if an element is set to the system default state or value.

In the following example, chassis has two key leafs (chassis-class (router) and chassis-number (9)). The double hash (##) indicates an unconfigured element or a dynamic default. Refer to section 1.4.6 for more information.

*(ex)[configure]
A:admin@node-2# info detail | match chassis post-lines 20
    chassis router chassis-number 9 {
        admin-state disable
     ## description
        mac-address 00:00:00:00:00:00
     ## sat-type
     ## software-repository
        sync-e false
     ## power-supply
     ## port-map
    }

The following displays configuration information for configure log accounting-policy 5:

*(ex)[configure log accounting-policy 5]
A:admin@node-2# info
    description "For aa-admit-deny statistics"
    collection-interval 69
    include-system-info true
    record aa-admit-deny

The detail option displays all data for the context, including default configurations.

*(ex)[configure log accounting-policy 5]
A:admin@node-2# info detail
    admin-state disable
    description "For aa-admit-deny statistics"
    collection-interval 69
    default false
    include-system-info true
    record aa-admit-deny
    custom-record {
        significant-change 0
        aa-specific {
            sub-attributes {
                app-profile false
                app-service-options false
            }
            sub-counters {
                long-duration-flow-count false
                medium-duration-flow-count false
                short-duration-flow-count false
                total-flow-duration false
                total-flows-completed-count false
            }
            from-sub-counters {
                flows-active-count false
                flows-admitted-count false
Press Q to quit, Enter to print next line or any other key to print next page.

The flat option displays the context of every element in the present working context on a single line. Braces ensure that the context stays in the present working context for copy and paste purposes.

*(ex)[configure log accounting-policy 5]
A:admin@node-2# info flat detail
    admin-state disable
    description "For aa-admit-deny statistics"
    collection-interval 69
    default false
    include-system-info true
    record aa-admit-deny
    custom-record significant-change 0
    custom-record aa-specific sub-attributes app-profile false
    custom-record aa-specific sub-attributes app-service-options false
    custom-record aa-specific sub-counters long-duration-flow-count false
    custom-record aa-specific sub-counters medium-duration-flow-count false
    custom-record aa-specific sub-counters short-duration-flow-count false
    custom-record aa-specific sub-counters total-flow-duration false
    custom-record aa-specific sub-counters total-flows-completed-count false
    custom-record aa-specific from-sub-counters flows-active-count false
    custom-record aa-specific from-sub-counters flows-admitted-count false
    custom-record aa-specific from-sub-counters flows-denied-count false
    custom-record aa-specific from-sub-counters forwarding-class false
    custom-record aa-specific from-sub-counters max-throughput-octet-count false
    custom-record aa-specific from-sub-counters max-throughput-packet-count false
    custom-record aa-specific from-sub-counters max-throughput-timestamp false
    custom-record aa-specific from-sub-counters octets-admitted-count false
    custom-record aa-specific from-sub-counters octets-denied-count false
    custom-record aa-specific from-sub-counters packets-admitted-count false
    custom-record aa-specific from-sub-counters packets-denied-count false
    custom-record aa-specific to-sub-counters flows-active-count false
    custom-record aa-specific to-sub-counters flows-admitted-count false
    custom-record aa-specific to-sub-counters flows-denied-count false
   ...
    <snip>

The full-context option displays the full context of every element from the present working context on a single line.

*(ex)[configure log accounting-policy 5]
A:admin@node-2# info full-context
    /configure log accounting-policy 5 description "For aa-admit-deny statistics"
    /configure log accounting-policy 5 collection-interval 69
    /configure log accounting-policy 5 include-system-info true
    /configure log accounting-policy 5 record aa-admit-deny
*(ex)[configure log accounting-policy 5]
A:admin@node-2# info full-context detail
    /configure log accounting-policy 5 admin-state disable
    /configure log accounting-policy 5 description "For aa-admit-deny statistics"
    /configure log accounting-policy 5 collection-interval 69
    /configure log accounting-policy 5 default false
    /configure log accounting-policy 5 include-system-info true
    /configure log accounting-policy 5 record aa-admit-deny
    /configure log accounting-policy 5 custom-record significant-change 0
    /configure log accounting-policy 5 custom-record aa-specific sub-attributes app-profile false
    /configure log accounting-policy 5 custom-record aa-specific sub-attributes app-service-options false
    /configure log accounting-policy 5 custom-record aa-specific sub-counters long-duration-flow-count false
    /configure log accounting-policy 5 custom-record aa-specific sub-counters medium-duration-flow-count false
    /configure log accounting-policy 5 custom-record aa-specific sub-counters short-duration-flow-count false
    /configure log accounting-policy 5 custom-record aa-specific sub-counters total-flow-duration false
    /configure log accounting-policy 5 custom-record aa-specific sub-counters total-flows-completed-count false
    /configure log accounting-policy 5 custom-record aa-specific from-sub-counte
rs flows-active-count false
    /configure log accounting-policy 5 custom-record aa-specific from-sub-counters flows-admitted-count false
    /configure log accounting-policy 5 custom-record aa-specific from-sub-counters flows-denied-count false
    /configure log accounting-policy 5 custom-record aa-specific from-sub-counters forwarding-class false
    /configure log accounting-policy 5 custom-record aa-specific from-sub-counters max-throughput-octet-count false
    /configure log accounting-policy 5 custom-record aa-specific from-sub-counters max-throughput-packet-count false
    /configure log accounting-policy 5 custom-record aa-specific from-sub-counters max-throughput-timestamp false
    /configure log accounting-policy 5 custom-record aa-specific from-sub-counters octets-admitted-count false
    /configure log accounting-policy 5 custom-record aa-specific from-sub-counters octets-denied-count false
    /configure log accounting-policy 5 custom-record aa-specific from-sub-counters packets-admitted-count false
    /configure log accounting-policy 5 custom-record aa-specific from-sub-counters packets-denied-count false
    /configure log accounting-policy 5 custom-record aa-specific to-sub-counters flows-active-count false
    /configure log accounting-policy 5 custom-record aa-specific to-sub-counters flows-admitted-count false
    /configure log accounting-policy 5 custom-record aa-specific to-sub-counters flows-denied-count false
   ...
    <snip>

1.3.14.1.1. Displaying Lists

The info command always displays all keys of the list on the same line. The first key of a list is unnamed in the MD-CLI, however, there are exceptions where the key is named and must be entered. (Refer to the online help for the correct syntax of the command, or the MD-CLI Command Reference Guide.) All other keys are named. For example, the collector list has two keys, ip-address and port. The name of the first key, ip-address, does not appear in the info display. The name of the second key and any subsequent keys are always displayed.

*(ex)[configure cflowd]
A:admin@node-2# info
    collector 10.10.20.30 port 7 {
    }
    collector 10.10.30.40 port 8 {
    }
 
*(ex)[configure cflowd]
A:admin@node-2#

1.3.14.2. Using the show Command

The classic CLI show commands can be used in the MD-CLI as well as in the classic CLI, in the following ways:

  1. use /show or show (while in the operational root []) in the MD-CLI engine
  2. use show in the classic CLI engine
  3. use // in the MD-CLI engine to switch to the classic CLI engine, then use show in the classic CLI engine
  4. use //show in the MD-CLI engine to execute /show in the classic CLI engine and switch back to the MD-CLI

1.3.14.2.1. Classic CLI Command Availability

Classic CLI commands that are accessible in the MD-CLI show outputs of the same information and provide the same functionality in the MD-CLI as they do in the classic CLI. No additional outputs or enhancements are included in the MD-CLI.

Note:

Follow the classic CLI context when using the show command. For example, route policy information is displayed using the show router policy command in both the MD-CLI and classic CLI engines, even though this information is configured in the configure policy-options context in the MD-CLI and in the configure router policy-options context in the classic CLI.

1.3.14.2.1.1. Classic CLI show commands not available in the MD-CLI

The following classic CLI show commands are currently blocked in the MD-CLI:

  1. show alias
  2. show bof
  3. show config
  4. show debug
  5. show system candidate
  6. show system rollback

1.3.14.2.2. Using the show Command in the MD-CLI Engine

The show command in the MD-CLI is applicable only in the operational root []. The /show command can be used from the root or any configuration context.

(ex)[]
A:admin@node-2# show port port-id 1/1/1 description
 
===============================================================================
Port Descriptions on Slot 1
===============================================================================
Port Id        Description
-------------------------------------------------------------------------------
1/1/1          10-Gig Ethernet
===============================================================================
 
(ex)[]
A:admin@node-2# configure router
 
(ex)[configure router "Base"]
A:admin@node-2# show port port-id 1/1/1 description
                ^^^^
MINOR: MGMT_CORE #2201: Unknown element - 'show'
 
(ex)[configure router "Base"]
A:admin@node-2# /show port port-id 1/1/1 description
===============================================================================
Port Descriptions on Slot 1
===============================================================================
Port Id        Description
-------------------------------------------------------------------------------
1/1/1          10-Gig Ethernet
===============================================================================

1.3.14.3. Using Output Modifiers

Output modifiers (match, count, and no-more) can also be used with the show command. See Using Output Modifiers.

1.3.15. MD-CLI Admin Tree

The following tree shows the available commands in the administrative branch in the MD-CLI. The admin commands are available only in the operational mode of the MD-CLI, or can be executed with /admin from a configuration branch.

— admin
— disconnect
— session-id session-id
— reboot
[card] (active | standby | upgrade)
— now
— redundancy
— force-switchover
— now
— save
[file-url] string
— show
— configuration

Table 9 describes the available commands in the MD-CLI admin tree.

Table 9:   Admin Tree Commands 

Admin command

Description

disconnect session-id session-id

Disconnect a user from a session, identified by a session identifier. The session identifiers can be obtained from the show system management-interface datastore-locks detail command. See section 1.4.13.

reboot [card] (active | standby | upgrade) [now]

Reboot the active or standby CPM, or force an upgrade of the system boot ROMs. The now option forces a reboot immediately without an interactive confirmation.

redundancy force-switchover [now]

Force a switchover to the standby CPM. The primary CPM reloads its software images and becomes the secondary CPM. The now option forces the switchover immediately.

save [[file-url] string]

Save the running configuration to a configuration file. If a filename is not specified, the location is derived from bof.cfg.

Note: Classic CLI admin save is blocked when the management interface configuration mode is model-driven.

show configuration

Show the current running configuration

1.4. Configuring in the MD-CLI

1.4.1. Operational and Configuration MD-CLI Session Modes

There are two modes in the MD-CLI:

  1. operational — user can run all commands except configuration commands
  2. configuration — user can run all commands when in global or exclusive configuration mode, or view configuration data in read-only configuration mode

In both session modes, a candidate configuration exists, but the user only has access to the candidate configuration when configuration mode is entered.

The type of configuration mode is defined by the type of access to the candidate configuration, and must be specified when entering the explicit configuration workflow. Three configuration modes are currently defined:

  1. global
  2. exclusive
  3. read-only

1.4.1.1. Global Candidate Configuration Mode

In global configuration mode, the candidate configuration is shared among all configuration management interfaces. Consider the following when using global configuration mode:

  1. multiple users can enter global configuration mode simultaneously
  2. configuration changes that are made by one user are visible to all other users
  3. when a user commits the candidate configuration, all changes from all users are committed to the running configuration

1.4.1.2. Exclusive Candidate Configuration Mode

In exclusive configuration mode, the candidate configuration is reserved for a single configuration management interface, with the following characteristics:

  1. only one user can enter exclusive configuration mode at a time
  2. configuration changes can only be entered by the user in exclusive configuration mode, although changes from other users are visible in read-only configuration mode
  3. only the user in exclusive configuration mode can commit the configuration changes
Note:

Nokia recommends using exclusive configuration mode to prevent potential conflicts between multiple users making configuration changes to the candidate configuration at the same time.

1.4.1.3. Read-Only Candidate Configuration Mode

In read-only configuration mode, the candidate configuration can be viewed using a configuration management interface. In addition to all commands available in operational mode, read-only configuration mode has the following functions and limitations:

  1. multiple users can enter read-only configuration mode simultaneously
  2. a user can enter read-only configuration mode while other users have entered global or exclusive configuration mode
  3. all configuration changes in the candidate configuration are visible
  4. changes in the candidate configuration cannot be committed

1.4.2. Entering and Exiting a Configuration Mode in the MD-CLI

When a CLI session starts using the MD-CLI, it is in operational mode. To enter one of the available configuration modes, enter edit-config with one of the access types:

edit-config (exclusive | global | read-only)

To exit a configuration mode, enter the quit-config command.

If the session leaves global configuration mode, any uncommitted configuration changes exist are kept in the candidate configuration.

*(gl)[]
A:admin@node-2# quit-config
INFO: CLI #2056: Exiting global configuration mode
INFO: CLI #2057: Uncommitted changes are kept in the candidate configuration
[]
A:admin@node-2#

If the quit-config command is issued in exclusive configuration mode and uncommitted changes exist in the candidate configuration, the user is prompted to discard the changes. If the user enters “n”, the quit-config command is aborted and the session remains in exclusive configuration mode.

*(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] n
INFO: CLI #2065: Exit exclusive configuration mode aborted
*(ex)[]
A:admin@node-2#

If the candidate configuration contains uncommitted changes from a previous MD-CLI session in global configuration mode, it is not possible to enter exclusive configuration mode until the uncommitted changes have been committed or discarded.

[]
A:admin@node-2# edit-config exclusive
MINOR: MGMT_CORE #2052: Exclusive access to datastore not available - uncommitted changes present in candidate configuration
[]
A:admin@node-2#

The quit-config command must be executed in the operational root within the configuration mode. The exit all command (or Ctrl-z) exits to the operational root level and the MD-CLI session leaves the configuration mode.

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

1.4.2.1. Transitioning Between Configuration Modes

When an MD-CLI session is in one of the configuration modes (exclusive, global, or read-only), it is permitted, in certain situations, to transition to another configuration mode without issuing the quit-config command and re-entering configuration mode with the edit-config command.

From read-only configuration mode, it is possible to transition directly to either exclusive or global configuration mode. It is also possible to transition to read-only configuration mode from either exclusive or global configuration mode. However, direct transitions between exclusive and global configuration modes are not supported.

[]
A:admin@node-2# edit-config exclusive
INFO: CLI #2060: Entering exclusive configuration mode
WARNING: CLI #2061: Uncommitted changes are discarded on 'quit-config'
 
(ex)[]
A:admin@node-2# edit-config read-only
INFO: CLI #2064: Exiting exclusive configuration mode
INFO: CLI #2066: Entering read-only configuration mode
 
(ro)[]
A:admin@node-2# edit-config global
INFO: CLI #2067: Exiting read-only configuration mode
INFO: CLI #2054: Entering global configuration mode
 
(gl)[]
A:admin@node-2# edit-config exclusive
MINOR: CLI #2004: Unsupported operation - switch from 'global' to 'exclusive'
 
(gl)[]
A:admin@node-2# edit-config read-only
INFO: CLI #2056: Exiting global configuration mode
INFO: CLI #2066: Entering read-only configuration mode
 
(ro)[]
A:admin@node-2# edit-config exclusive
INFO: CLI #2067: Exiting read-only configuration mode
INFO: CLI #2060: Entering exclusive configuration mode
WARNING: CLI #2061: Uncommitted changes are discarded on 'quit-config'
 
(ex)[]
A:admin@node-2#

The edit-config command can be issued from any working context in configuration mode.

(ex)[]
A:admin@node-2# configure router
 
(ex)[configure router "Base"]
A:admin@node-2# edit-config read-only
INFO: CLI #2064: Exiting exclusive configuration mode
INFO: CLI #2066: Entering read-only configuration mode
 
(ro)[configure router "Base"]
A:admin@node-2# edit-config exclusive
INFO: CLI #2067: Exiting read-only configuration mode
INFO: CLI #2060: Entering exclusive configuration mode
WARNING: CLI #2061: Uncommitted changes are discarded on 'quit-config'

1.4.3. Transactional Method Overview

For configuring router information, there is a transactional (two-stage) configuration method, where changes are kept in the candidate configuration datastore. Changes are not immediately effective; they need to be activated by issuing the commit command. For other operations besides the router configuration, such as configuring the environment, the changes are immediate.

The behavior of the MD-CLI configuration method differs from the classic CLI, where changes in the classic model are applied immediately. Changes to the router configuration in the classic CLI are immediately activated in the running configuration, and must be made in the correct order or the configuration fails. The transactional behavior of the MD-CLI allows multiple configuration changes to be made, and the correct ordering of the changes is applied by the system when the configuration is activated.

In a transactional method, configuration is a two-step process in which configuration changes are made in a datastore called the candidate configuration datastore. When the configuration is committed, the changes are copied to the running configuration datastore and activated. In the classic CLI model, configuration changes are made in the running configuration and each change is activated immediately.

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

Figure 1:  Flow of Configuration Changes  

1.4.3.1. Configuration Workflow

The configuration workflow provides a clear beginning and end of configuration commands, achieved using the edit-config and quit-config commands. Refer to Entering and Exiting a Configuration Mode in the MD-CLI for more information about these commands.

The candidate configuration datastore is created and allows the user to make configuration changes to the running configuration datastore when the changes are committed.

1.4.4. The MD-CLI Tree Structure

The MD-CLI tree contains the following elements from the Nokia YANG models.

  1. container — an element that contains other elements. In the following example, load-balancing and dns are containers.
        load-balancing {
            lsr-load-balancing lbl-only
            system-ip-load-balancing true
        }
        dns {
            address-pref ipv6-first
        }
  2. leaf — an element that does not contain any other elements and has a data type (for example, string or integer). A leaf could also be defined with the empty data type where the leaf takes no parameter value. The bold elements in the following example are leafs.
        load-balancing {
            lsr-load-balancing lbl-only
            system-ip-load-balancing true
        }
        dns {
            address-pref ipv6-first
        }
  3. list entry — an element similar to a container with multiple instances where each list entry is identified by the values of its keys (for example, interface “access-2”)
        interface "access-2" {
            description "This is a text description for access-2"
            ipv4 {
                qos-route-lookup destination
            }
            ipv6 {
            }
        }
        interface "access-3" {
            ipv4 {
                primary {
                    address 138.120.44.45
                    prefix-length 28
                }
            }
        }
  4. key — a unique identifier for a list entry (for example, “access-2” and “access-3”)
        interface "access-2" {
            description "This is a text description for access-2"
            ipv4 {
                qos-route-lookup destination
            }
            ipv6 {
            }
        }
        interface "access-3" {
            ipv4 {
                primary {
                    address 138.120.44.45
                    prefix-length 28
                }
            }
        }
  5. leaf-list — an element that contains a sequence of values of a particular data type (for example, “policy” is a leaf-list in the following example)
        policy ["policy-a" "policy-b" "policy-c"]
  6. list — a sequence of list entries. In the preceding example, the entire set of interfaces is a list.
        interface "access-2" {
            description "This is a text description for access-2"
            ipv4 {
                qos-route-lookup destination
            }
            ipv6 {
            }
        }
        interface "access-3" {
            ipv4 {
                primary {
                    address 138.120.44.45
                    prefix-length 28
                }
            }
        }
  7. leaf-list entry — one of the values of a leaf-list. For example, “policy-a”, “policy-b”, and “policy-c” are leaf-list entries in the following example.
        policy ["policy-a" "policy-b" "policy-c"]

The following terms are also used:

  1. keyword — an element with a name defined by SR OS; for example, enumerated values, leaf names, and container names)
  2. variable parameter — an element with a name defined by the user; for example, descriptions, names, integer or string leaf values)
  3. immutable element — an element that can only be configured in the transaction in which the parent element is created. It cannot be modified while the parent element exists.

In the following example, admin-state (leaf name), enable (enumerated value), and connect-retry (leaf name) are keywords, and “800” is a variable parameter.

*(ex)[configure router "Base" bgp]
A:admin@node-2# info
    admin-state enable
    connect-retry 800

Managing the router configuration using the MD-CLI involves accessing and configuring the appropriate elements (containers, lists, leafs, and leaf-lists).

The MD-CLI tree shows the commands and parameters (also known as elements) that are available, shown in a hierarchical structure as in Figure 2. Refer to the MD-CLI Command Reference Guide for more information.

Figure 2:  MD-CLI Configuration Tree Example 

1.4.5. Adding Configuration Statements

1.4.5.1. Default Values for Key Leafs

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

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

  1. default values cannot be used in a reference
  2. multiple keys in a list can have default values
  3. the first, last, or any key in a list may have a default value
  4. if the first key has a default value, the other keys must be named keys
  5. 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.
  6. 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#

1.4.5.2. Entering Integer Values

Integer values can be entered in any of the following formats:

  1. decimal
    Enter an integer (whole number) without spaces; for example, 123456.
  2. binary
    Enter 0b followed by the binary value without spaces; for example, 0b1111000100100000. Negative values are not accepted.
  3. 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#

In this example, the dot1q-etype parameter is a hexadecimal output value. A decimal value can be entered, but the value is displayed in hexadecimal format.

(ex)[configure port 1/1/1]
A:admin@node-2# ethernet dot1q-etype ?
 dot1q-etype <number>
 
 <number> - <0x600..0xffff>
 
 Configure the ethertype used for dot1q encapsulation on the Ethernet port.
 
(ex)[configure port 1/1/1]
A:admin@node-2# ethernet dot1q-etype 2000
 
*(ex)[configure port 1/1/1]
A:admin@node-2# info
    description "1-Gig/10-Gig Ethernet"
    ethernet {
        autonegotiate false
        dot1q-etype 0x7d0
        mode hybrid
        speed 1000
    }
Note:

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

In this example of a command with a union of data types, the rate-limit command can have an integer value representing the rate limit (for periodic RADIUS Interim-Update messages), or it can be defined with the unlimited enumerated value. If a numerical value is entered for rate-limit, it must be entered as a decimal number.

*(gl)[configure aaa isa-radius-policy "isa-str" accounting nat-periodic-update]
A:admin@node-2# rate-limit
 rate-limit <number or keyword>
 
 <number or keyword> - (<1..100000>|         - packets per second
                        unlimited)
 
 Rate limit for periodic RADIUS Interim-Update messages
 
*(gl)[configure aaa isa-radius-policy "isa-str" accounting nat-periodic-update]
A:admin@node-2# rate-limit 0b0010
                           ^^^^^^
MINOR: MGMT_CORE #2301: Invalid element value - rate-limit expected number or keyword: '(<1..100000>|unlimited)' (packets per second)
 
*(gl)[configure aaa isa-radius-policy "isa-str" accounting nat-periodic-update]
A:admin@node-2# rate-limit 2
 
*(gl)[configure aaa isa-radius-policy "isa-str" accounting nat-periodic-update]
A:admin@node-2# info
    rate-limit 2
 
*(gl)[configure aaa isa-radius-policy "isa-str" accounting nat-periodic-update]
A:admin@node-2#

1.4.5.3. Configuring Lists

A list is a sequence of list entries, and all keys of a list are entered on the same line as the list command. In general, the first key of a list is unnamed in the MD-CLI. All other keys are named. The name of the first key is shown in square brackets in ? help. Entering the name of the first key is optional when it is shown in brackets. In the following example, ip-address is the first key and port is the second key. Entering ip-address in the MD-CLI is optional; entering port and any subsequent key names is mandatory.

*(ex)[configure cflowd]
A:admin@node-2#
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>)
 
 Specifies the IP address of a remote Cflowd collector host to receive the
 exported Cflowd data.
 
*(ex)[configure cflowd]
A:admin@node-2# collector 10.20.30.40 ?
 port <number>
 
 <number> - <1..65535>
 
 Specifies the UDP port number on the remote Cflowd collector host to receive
 the exported Cflowd data.
 

The IP address and port number can be entered in one of the following ways:

*(ex)[configure cflowd]
A:admin@node-2# collector ip-address 10.10.20.30 port 7
 
*(ex)[configure cflowd]
A:admin@node-2# collector 10.10.20.30 port 7

There are some exceptions where the first key of a list is named. In these cases, the key name must be entered. In the following example, the key name index must be entered.

A:admin@node-2# peer ?
 index <number>
 
 <number> - <1..5>
 Index of this peer within the Node.
 
*(ex)[configure aaa diameter node "orig-host-name"]
A:admin@node-2# peer 5
                     ^
MINOR: MGMT_CORE #2201: Unknown element - expected key index but was 5
 
*(ex)[configure aaa diameter node "orig-host-name"]
A:admin@node-2# peer index 5
 
*(ex)[configure aaa diameter node "orig-host-name" peer index 5]
A:admin@node-2#

Auto-completion does not select or complete the name of the first key if it is optional. In the following example for configure aaa diameter, the key name for node (origin-host) is optional as indicated by the square brackets, and is not auto-completed when Tab is entered.

(ex)[configure aaa diameter]
A:admin@node-2# node ?
 [origin-host] <string>
 
 <string> - <1..80 characters>
 
 Origin-host name.
 
(ex)[configure aaa diameter]
A:admin@node-2# node //Press Tab
 <origin-host>

If the name of the first key is optional and is not entered as part of the command, the key name can be used as the actual value of the key if it is enclosed in quotation marks.

(ex)[configure aaa diameter]
A:admin@node-2# node "origin-host"
 
*(ex)[configure aaa diameter node "origin-host"]
A:admin@node-2# pwc
Present Working Context:
  configure
  aaa
  diameter
  node "origin-host"
 
*(ex)[configure aaa diameter node "origin-host"]
A:admin@node-2#

If the optional key name is entered, it can be specified as the actual value of the key with or without the quotation marks.

(ex)[configure aaa diameter]
A:admin@node-2# node origin-host origin-host
 
*(ex)[configure aaa diameter node "origin-host"]
A:admin@node-2# pwc
Present Working Context:
  configure
  aaa
  diameter
  node "origin-host"
 
*(ex)[configure aaa diameter node "origin-host"]
A:admin@node-2#

1.4.5.3.1. Special Handling for Lists with all Key Leafs

For lists in which the leafs are all keys (“key-only lists”), the creation of a single entry returns the user to the same context; that is, the MD-CLI session does not enter the context of the list member. This allows the user to enter multiple list items without the need to exit after each item. For example, prefix is a list with a single leaf that is the key. After each prefix entry, the session maintains the same context and other prefix entries can be added without applying the back or exit command.

*(ex)[configure filter match-list ip-prefix-list "my-prefix-list"]
A:admin@node-2# prefix 138.120.10.0/28
 
*(ex)[configure filter match-list ip-prefix-list "my-prefix-list"]
A:admin@node-2# prefix 138.120.20.0/28
 
*(ex)[configure filter match-list ip-prefix-list "my-prefix-list"]
A:admin@node-2# prefix 138.120.30.0/28
 
*(ex)[configure filter match-list ip-prefix-list "my-prefix-list"]
A:admin@node-2# info
    prefix 138.120.10.0/28 { }
    prefix 138.120.20.0/28 { }
    prefix 138.120.30.0/28 { }
 
*(ex)[configure filter match-list ip-prefix-list "my-prefix-list"]
A:admin@node-2#

1.4.5.4. Configuring Leaf-Lists

A leaf-list is an element that contains a sequence of values of a particular data type. Specifying a leaf-list entry in the MD-CLI is additive. New entries are added to existing entries and previous entries are not removed. If a duplicate entry is specified, the order remains. To minimize the number of CLI warnings, no message is displayed.

Single or multiple leaf-list entries can be added in a single command line with the use of brackets. For leaf-lists ordered by the system, the leaf-list entries are automatically reordered, as shown in the following example.

*(ex)[configure ipsec ike-policy 5]
A:admin@node-2# ike-transform 99
 
*(ex)[configure ipsec ike-policy 5]
A:admin@node-2# ike-transform [77 11 55]
 
*(ex)[configure ipsec ike-policy 5]
A:admin@node-2# info
    ike-transform [11 55 77 99]
 
*(ex)[configure ipsec ike-policy 5]
A:admin@node-2# ike-transform [88 22 11]
 
*(ex)[configure ipsec ike-policy 5]
A:admin@node-2# info
    ike-transform [11 22 55 77 88 99]
 
*(ex)[configure ipsec ike-policy 5]
A:admin@node-2# ike-transform [33]
 
*(ex)[configure ipsec ike-policy 5]
A:admin@node-2# info
    ike-transform [11 22 33 55 77 88 99]

For leaf-lists ordered by the user, new entries are appended to the end of the leaf-list.

*(ex)[configure policy-options policy-statement "plcy_str" entry 29]
A:admin@node-2# from prefix-list [ plcy5 plcy1 ]
 
*(ex)[configure policy-options policy-statement "plcy_str" entry 29]
A:admin@node-2# info
    from {
        prefix-list ["plcy5" "plcy1"]
    }
 
*(ex)[configure policy-options policy-statement "plcy_str" entry 29]
A:admin@node-2# from prefix-list plcy3
 
*(ex)[configure policy-options policy-statement "plcy_str" entry 29]
A:admin@node-2# info
    from {
        prefix-list ["plcy5" "plcy1" "plcy3"]
    }
 
*(ex)[configure policy-options policy-statement "plcy_str" entry 29]
A:admin@node-2# from prefix-list plcy1
 
*(ex)[configure policy-options policy-statement "plcy_str" entry 29]
A:admin@node-2# info
    from {
        prefix-list ["plcy5" "plcy1" "plcy3"]
    }
 
*(ex)[configure policy-options policy-statement "plcy_str" entry 29]
A:admin@node-2#

To reorder an ordered-by-user leaf-list, the leaf-list can be deleted and recreated using the desired order. Alternatively, the tilde (~) character can be used to replace a leaf-list, effectively deleting and recreating the leaf-list in one step.

(ex)[]
A:admin@node-6# configure router isis 5
 
*(ex)[configure router "Base" isis 5]
A:admin@node-6# export-policy [test5 test3 test2]
 
*(ex)[configure router "Base" isis 5]
A:admin@node-6# info
    export-policy ["test5" "test3" "test2"]
 
*(ex)[configure router "Base" isis 5]
A:admin@node-6# ~ export-policy [test1 test2 test3 test5]
 
*(ex)[configure router "Base" isis 5]
A:admin@node-6# info
    export-policy ["test1" "test2" "test3" "test5"]
 
*(ex)[configure router "Base" isis 5]
A:admin@node-6#

1.4.5.5. Configuring Leafs with Units

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

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:

  1. memory sizes, for example, bytes
  2. rates, for example, bps
  3. durations, for example, seconds
  4. dates, for example, FRI 11 MAY 2018 15:15:35 UTC

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

  1. as a value without a unit — the value is interpreted as the defined base unit. Decimal, binary, and hexadecimal numbers are supported. For example, connection-timer has a base unit of seconds. Entering connection-timer 5, without specifying a unit, configures the timer to 5 seconds.
    *(ex)[configure aaa diameter node "node-str"]
    A:admin@node-2# connection-timer
     connection-timer <number>
     
     <number> - <1..1000> - seconds
     
     The value of the connection-timer that determines how frequent connection will
     be attempted towards a peer without an active transport connection.
     
    *(ex)[configure aaa diameter node "node-str"]
    A:admin@node-2# connection-timer 5
     
    *(ex)[configure aaa diameter node "node-str"]
    A:admin@node-2# info
        connection-timer 5
  2. as unique value-unit tuples — the units are separated by a space in any order, and the same unit cannot be used more than once. The value is interpreted as the specified unit and can only be entered as a decimal number. For example, there are many acceptable formats to enter 187 seconds for connection-timer, including any of the following:
    *(ex)[configure aaa diameter node "node-str"]
    A:admin@node-2# connection-timer 3 minutes 7 seconds
     
    *(ex)[configure aaa diameter node "node-str"]
    A:admin@node-2# connection-timer 187
     
    *(ex)[configure aaa diameter node "node-str"]
    A:admin@node-2# connection-timer 1800 deciseconds 700 centiseconds
     
    *(ex)[configure aaa diameter node "node-str"]
    A:admin@node-2# connection-timer 180000 milliseconds 70 deciseconds
    The configured value is displayed as a positive integer in the defined base unit. Because the unit for connection-timer is defined as seconds, the value in info is displayed in seconds, regardless of the format in which it was entered.
    *(ex)[configure aaa diameter node "node-str"]
    A:admin@node-2# info
        connection-timer 187

The input value is calculated based on the input of all input tuples and validated after Enter is pressed. For example, entering 200 minutes for connection-timer results in an error display, as 12000 seconds is not in the element range.

*(gl)[configure aaa diameter node "node-str"]
A:admin@node-2# connection-timer 200 minutes //Press Enter
MINOR: MGMT_CORE #2301: Invalid element value - 12000 is not in range 1..1000
 
*(gl)[configure aaa diameter node "node-str"]
A:admin@node-2#

Entering a value followed by Space and Tab displays valid units for the value, as in the following example. For a value of 200 for connection-timer, the system displays valid unit possibilities, listed in alphabetical order.

*(gl)[configure aaa diameter node "node-str"]
A:admin@node-2# connection-timer 200 //Press Tab
 centiseconds         deciseconds          seconds
...

If a unit is already present in the input, it is suppressed for any further input.

*(gl)[configure aaa diameter node "node-str"]
A:admin@node-2# connection-timer 200 //Press Tab
 centiseconds         deciseconds          seconds
 
 description          ipv4-source-address  ipv6-source-address
 origin-realm         peer                 python-policy
 router
 
 delete
 
*(gl)[configure aaa diameter node "node-str"]
A:admin@node-2# connection-timer 200 centiseconds 200 //Press Tab
 deciseconds  seconds
 
*(gl)[configure aaa diameter node "node-str"]
A:admin@node-2# connection-timer 200 centiseconds 200

The unit names can be singular or plural, depending on the numerical value entered. For a numerical value of 1, the unit names displayed are their singular form.

*[]
A:admin@node-2# commit confirmed timeout 1
 day         hour        minute      week
 
 ...
 
*[]
A:admin@node-2# commit confirmed timeout 2
 days        hours       minutes     weeks
 
 ...
 
*[]
A:admin@node-2#

Auto-completion is supported for valid units entered after a value.

Table 8, Table 10, and Table 11 list units that have a conversion factor that allows a leaf with a specific base unit to be defined in a dynamic unit. The valid unit keywords for each unit name are also provided.

Table 10 shows the valid inputs for memory sizes based on the dynamic unit.

Table 10:  Dynamic Units for Memory Sizes  

Unit Name

Valid MD-CLI Input

terabytes

  1. terabytes
  2. terabyte
  3. tbytes
  4. tbyte

gigabytes

  1. gigabytes
  2. gigabyte
  3. gbytes
  4. gbyte

megabytes

  1. megabytes
  2. megabyte
  3. mbytes
  4. mbyte

kilobytes

  1. kilobytes
  2. kilobytes
  3. kbytes
  4. kbyte

bytes

  1. bytes
  2. byte

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

Table 11:  Dynamic Units for Rates  

Unit Name

Valid MD-CLI Input

terabps (terabits per second)

  1. terabps
  2. tbps

gigabps (gigabits per second

  1. gigabps
  2. gbps

megabps (megabits per second)

  1. megabps
  2. mbps

kilobps (kilobits per second)

  1. kilobps
  2. kbps

bps (bits per second)

  1. bps

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

Table 12:  Dynamic Units for Duration  

Unit Name

Valid MD-CLI Input

weeks

  1. weeks
  2. week
  3. wks
  4. wk

days

  1. days
  2. day

hours

  1. hours
  2. hour
  3. hrs
  4. hr

minutes

  1. minutes
  2. minute
  3. mins
  4. min

seconds

  1. seconds
  2. second
  3. secs
  4. sec

deciseconds

  1. deciseconds
  2. decisecond
  3. dsecs
  4. dsec

centiseconds

  1. centiseconds
  2. centisecond
  3. csecs
  4. csec

milliseconds

  1. milliseconds
  2. millisecond
  3. msecs
  4. msec

microseconds

  1. microseconds
  2. microsecond
  3. usecs
  4. usec

nanoseconds

  1. nanoseconds
  2. nanosecond
  3. nsecs
  4. nsec

picoseconds

  1. picoseconds
  2. picosecond
  3. psecs
  4. psec

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

Table 13:  Dynamic Units for Dates  

Time Format

Valid MD-CLI Input

“yyyy-mm-dd hh:mm[:ss] [TZ]”

For example: “2018-06-01 13:12:59 EDT”

yyyy is RFC 3339 date-fullyear

mm is RFC 3339 date-month

dd is RFC 3339 date-mday

hh is RFC 3339 time-hour

mm is RFC 3339 time-minute, requires preceding zeros

ss is RFC 3339 time-second, requires preceding zeros (optional)

TZ is the time-zone name (optional)

This format must be enclosed in double quotation marks.

“[DAY] dd MON yyyy hh:mm[:ss] [TZ]”

For example: “FRI 11 MAY 2018 13:21:11 EDT”

DAY is the name of the day of the week (SUN, MON, TUE, WED, THU, FR, SAT),(optional)

dd is RFC 3339 date-mday

MON is the name of the month (JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, DEC)

yyyy is RFC 3339 date-fullyear

hh is RFC 3339 time-hour

mm is RFC 3339 time-minute, requires preceding zeros

ss is RFC 3339 time-second, requires preceding zeros (optional)

TZ is the time-zone name (optional)

This format must be enclosed in double quotation marks.

yyyy-mm-ddThh:mm:ss[.fr][(Z|(+|-)hh:mm)]

For example: 2018-05-11T13:21:11-0400

or

2018-05-11T17:21:11Z

This format follows ISO 8601, and can be enclosed in double quotation marks.

1.4.5.6. Flexible Input for MAC and IPv6 Addresses

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

This example shows the hexadecimal digits entered in both uppercase and lowercase.

*(gl)[configure aaa diameter node "ns"]
A:admin@node-2# ipv6-source-address 2001:0Db8:aAa3:0000:0000:8a2E:3710:7335
 
*(gl)[configure aaa diameter node "ns"]
A:admin@node-2# info
    ipv6-source-address 2001:db8:aaa3::8a2e:3710:7335
 
*(gl)[configure aaa diameter node "ns"]
A:admin@node-2#

For MAC addresses, the dash (-) separator can also be used in place of the colon (:).

*(gl)[configure groups group "g" qos sap-ingress "str" mac-criteria entry "es" match  dst-mac]
A:admin@node-2# address aa-BB-cc-DD-eE-Ff
 
*(gl)[configure groups group "g" qos sap-ingress "str" mac-criteria entry "es" match  dst-mac]
A:admin@node-2# info
    address aa:bb:cc:dd:ee:ff
 
*(gl)[configure groups group "g" qos sap-ingress "str" mac-criteria entry "es" match  dst-mac]
A:admin@node-2#

Flexible input is also available for other formatted MAC addresses, such as using dot notation:

*(ex)[configure filter mac-filter "str" entry 33 match]
A:admin@node-2# dst-mac address aaBB.ccDD.eEFf
 
*(ex)[configure filter mac-filter "str" entry 33 match]
A:admin@node-2# info
    dst-mac {
        address aa:bb:cc:dd:ee:ff
    }
 
*(ex)[configure filter mac-filter "str" entry 33 match]
A:admin@node-2#

1.4.6. Deleting Configuration Statements

The delete command removes explicit configuration and returns the element configuration to the system default state or value. If there is no defined default for an element, the element returns to an unconfigured state.

The delete command can be used to delete any configuration element, such as:

  1. leafs
  2. containers
  3. lists
  4. leaf-lists

If an element has sub-elements (for example, a container with more containers and leafs), all of the sub-elements are also deleted as part of the parent deletion.

Note:

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

1.4.6.1. Deleting Leafs

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

*(gl)[configure router "Base" bgp]
A:admin@node-2# info
    admin-state disable
    description "BGP description"
    connect-retry 65535
 
*(gl)[configure router "Base" bgp]
A:admin@node-2# delete admin-state
 
*(gl)[configure router "Base" bgp]
A:admin@node-2# delete description
 
*(gl)[configure router "Base" bgp]
A:admin@node-2# delete connect-retry
 
*(gl)[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>

1.4.6.2. Deleting Containers

To remove a container, the delete command is specified before the container name. The following examples show the deletion of the node container from two different contexts.

This example removes the container from context configure aaa diameter:

*(gl)[configure aaa diameter]
A:admin@node-2# info
    node "node-str" {
        description "Diameter node node-str"
        connection-timer 999
        peer index 5 {
            watchdog-timer 555
        }
    }
 
*(gl)[configure aaa diameter]
A:admin@node-2# delete node node-str
 
(gl)[configure aaa diameter]
A:admin@node-2# info detail
 ## node
 
(gl)[configure aaa diameter]
A:admin@node-2#

This example removes the container from context configure aaa:

*(gl)[configure aaa diameter]
A:admin@node-2# info
    node "node-str" {
        description "Diameter node node-str"
        connection-timer 888
        peer index 5 {
            watchdog-timer 345
        }
    }
 
*(gl)[configure aaa diameter]
A:admin@node-2# back
 
*(gl)[configure aaa]
A:admin@node-2# diameter delete node “node-str”
 
(gl)[configure aaa]
A:admin@node-2# info
 
(gl)[configure aaa]
A:admin@node-2# info detail
    radius-coa-port 3799
    wpp {
     ## portal-group
    }
 ## acct-on-off-group
 ## radius-script-policy
 ## radius-server-policy
 ## route-downloader
 ## l2tp-accounting-policy
    diameter {
     ## node
    }
 ## diameter-peer-policy
 ## isa-radius-policy
 
(gl)[configure aaa]
A:admin@node-2#

In both of the preceding examples above, the node container is returned to an unconfigured state, as indicated by the ##.

In the following example, the timers element is a container, which contains sub-elements that are also containers; the lsa-generate and spf-wait elements. The placement of the delete command determines whether the timers element (and all of its sub-elements) are deleted, or one of the sub-elements.

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

To delete the lsa-generate element and its parameters, the delete command is specified before the lsa-generate element. The info command shows that the spf-wait parameters are still configured.

*(ex)[configure router "Base" ospf 0]
A:admin@node-2# timers delete lsa-generate
 
*(ex)[configure router "Base" ospf 0]
A:admin@node-2# info
    timers {
        spf-wait {
            spf-max-wait 2000
            spf-initial-wait 50
            spf-second-wait 100
        }
    }
    area 0.0.0.0 {
    }

If the delete command is placed before the timers element, all elements within the timers element are also deleted.

*(ex)[configure router "Base" ospf 0]
A:admin@node-2# info
    timers {
        lsa-generate {
            max-lsa-wait 8000
            lsa-initial-wait 10
            lsa-second-wait 1000
        }
        spf-wait {
            spf-max-wait 2000
            spf-initial-wait 50
            spf-second-wait 100
        }
    }
    area 0.0.0.0 {
    }
 
*(ex)[configure router "Base" ospf 0]
A:admin@node-2# delete timers
 
(ex)[configure router "Base" ospf 0]
A:admin@node-2# info
    area 0.0.0.0 {
    }

1.4.6.3. Deleting List Entries and Lists

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

*(ex)[configure service]
A:admin@node-2# info | match pw-template
    pw-template "pw-1" {
    pw-template "pw-3" {
    pw-template "pw-5" {
    pw-template "pw-8" {
 
*(ex)[configure service]
A:admin@node-2# delete pw-template “pw-3”
 
*(ex)[configure service]
A:admin@node-2# info | match pw-template
    pw-template "pw-1" {
    pw-template "pw-5" {
    pw-template "pw-8" {
 
*(ex)[configure service]
A:admin@node-2#

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

*(ex)[configure service]
A:admin@node-2# info | match pw-template
    pw-template "pw-1" {
    pw-template "pw-5" {
    pw-template "pw-8" {
 
*(ex)[configure service]
A:admin@node-2# delete pw-template *
 
*(ex)[configure service]
A:admin@node-2# info | match pw-template
 
*(ex)[configure service]
A:admin@node-2#

If the list is a multi-key list, a combination of specific members and wildcards (*) can be used. In the following example, mep is a multikey list, where the keys are md-admin-name, ma-admin-name, and mep-id.

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

The following delete operation deletes all lists with mep-id of 5, regardless of the md-admin-name or ma-admin-name.

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

The following delete operation removes all lists where ma-admin-name is “ref3” and mep-id is 5.

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

The following delete operation removes all lists where md-admin-name is “ref1”.

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

1.4.6.3.1. Deleting Leaf-List Entries and Leaf-Lists

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

*(ex)[configure system security user-params local-user user "test" console]
A:admin@node-2# info
    member ["profile-a" "profile-b" "profile-x"]
 
*(ex)[configure system security user-params local-user user "test" console]
A:admin@node-2# delete member “profile-a”
 
*(ex)[configure system security user-params local-user user "test" console]
A:admin@node-2# info
    member ["profile-b" "profile-x"]
 
*(ex)[configure system security user-params local-user user "test" console]
A:admin@node-2#

Multiple leaf-list entries can be deleted in a single command with the use of brackets. The entries do not need to be in any specific order.

*(ex)[configure system security user-params local-user user "test" console]
A:admin@node-2# info
    member ["profile-a" "profile-b" "profile-f" "profile-x" "profile-c"]
 
*(ex)[configure system security user-params local-user user "test" console]
A:admin@node-2# delete member [“profile-c” “profile-f”]
 
*(ex)[configure system security user-params local-user user "test" console]
A:admin@node-2# info
    member ["profile-a" "profile-b" "profile-x"]
 
*(ex)[configure system security user-params local-user user "test" console]
A:admin@node-2#

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

*(ex)[configure system security user-params local-user user "test" console]
A:admin@node-2# info
    member ["profile-b" "profile-x"]
 
*(ex)[configure system security user-params local-user user "test" console]
A:admin@node-2# delete member *
 
*(ex)[configure system security user-params local-user user "test" console]
A:admin@node-2# info
 
*(ex)[configure system security user-params local-user user "test" console]
A:admin@node-2#

The wildcard can optionally be enclosed in brackets.

*(ex)[configure system security user-params local-user user "test" console]
A:admin@node-2# delete member [*]

Deleting all members of a leaf-list sets the list to the unconfigured state (as indicated in the info detail display by the “##”).

*(ex)[configure system security user-params local-user user "test" console]
A:admin@node-2# delete member *
 
*(ex)[configure system security user-params local-user user "test" console]
A:admin@node-2# info detail | match member
 ## member
 
*(ex)[configure system security user-params local-user user "test" console]
A:admin@node-2# 

1.4.7. Copying Configuration Statements

The output from the info commands can be copied and pasted and used as a direct input to another MD-CLI session, or loaded from a file.

The following example shows the output from the info command, displaying the following configuration for the profile of the user “guest1”.

*(ex)[configure system security aaa local-profiles profile "guest1"]
A:admin@node-2# info
    default-action permit-all
    entry 10 {
        action deny
        match "configure system security"
    }
    entry 20 {
        action deny
        match "configure li"
    }
    entry 30 {
        action deny
        match "show li"
    }
    entry 40 {
        action deny
        match "tools"
    }

The output can be copied and pasted to configure an identical profile for another user; for example, “guest2”. The working context must be at the same hierarchy level, as the info command output is context-sensitive.

Enter the context for configuring the profile for guest2:

(ex)[]
A:admin@node-2# configure system security aaa local-profiles profile guest2
 
*(ex)[configure system security aaa local-profiles profile "guest2"]
A:admin@node-2#

Copy the info command output and paste each line into the command line:

*(ex)[configure system security aaa local-profiles profile "guest2"]
A:admin@node-2#     default-action permit-all
 
*(ex)[configure system security aaa local-profiles profile "guest2"]
A:admin@node-2#     entry 10 {
 
*(ex)[configure system security aaa local-profiles profile "guest2" entry 10]
A:admin@node-2#         action deny
 
*(ex)[configure system security aaa local-profiles profile "guest2" entry 10]
A:admin@node-2#         match "configure system security"
 
*(ex)[configure system security aaa local-profiles profile "guest2" entry 10]
A:admin@node-2#     }
 
*(ex)[configure system security aaa local-profiles profile "guest2"]
A:admin@node-2#     entry 20 {
 
*(ex)[configure system security aaa local-profiles profile "guest2" entry 20]
A:admin@node-2#         action deny
 
*(ex)[configure system security aaa local-profiles profile "guest2" entry 20]
A:admin@node-2#         match "configure li"
 
*(ex)[configure system security aaa local-profiles profile "guest2" entry 20]
A:admin@node-2#     }
 
*(ex)[configure system security aaa local-profiles profile "guest2"]
A:admin@node-2#     entry 30 {
 
*(ex)[configure system security aaa local-profiles profile "guest2" entry 30]
A:admin@node-2#         action deny
 
*(ex)[configure system security aaa local-profiles profile "guest2" entry 30]
A:admin@node-2#         match "show li"
 
*(ex)[configure system security aaa local-profiles profile "guest2" entry 30]
A:admin@node-2#     }
 
*(ex)[configure system security aaa local-profiles profile "guest2"]
A:admin@node-2#     entry 40 {
 
*(ex)[configure system security aaa local-profiles profile "guest2" entry 40]
A:admin@node-2#         action deny
 
*(ex)[configure system security aaa local-profiles profile "guest2" entry 40]
A:admin@node-2#         match "tools"
 
*(ex)[configure system security aaa local-profiles profile "guest2" entry 40]
A:admin@node-2#     }
 
*(ex)[configure system security aaa local-profiles profile "guest2"]
A:admin@node-2#

The info command displays the configuration changes for profile “guest2”, which are identical to the configuration for profile “guest1”.

*(ex)[configure system security aaa local-profiles profile "guest2"]
A:admin@node-2# info
    default-action permit-all
    entry 10 {
        action deny
        match "configure system security"
    }
    entry 20 {
        action deny
        match "configure li"
    }
    entry 30 {
        action deny
        match "show li"
    }
    entry 40 {
        action deny
        match "tools"
    }
 
*(ex)[configure system security aaa local-profiles profile "guest2"]
A:admin@node-2#

Similarly, the info flat command output can be copied and pasted for the user profile for “guest3”; for example:

*(ex)[configure system security aaa local-profiles profile "guest2"]
A:admin@node-2# info flat
    default-action permit-all
    entry 10 action deny
    entry 10 match "configure system security"
    entry 20 action deny
    entry 20 match "configure li"
    entry 30 action deny
    entry 30 match "show li"
    entry 40 action deny
    entry 40 match "tools"
*(ex)[configure system security aaa local-profiles profile "guest2"]
A:admin@node-2#
*(ex)[configure system security aaa local-profiles profile "guest1"]
A:admin@node-2# /configure system security aaa local-profiles profile "guest3"
 
*(ex)[configure system security aaa local-profiles profile "guest3"]
A:admin@node-2#  default-action permit-all
 
*(ex)[configure system security aaa local-profiles profile "guest3"]
A:admin@node-2#     entry 10 action deny
 
*(ex)[configure system security aaa local-profiles profile "guest3"]
A:admin@node-2#     entry 10 match "configure system security"
 
*(ex)[configure system security aaa local-profiles profile "guest3"]
A:admin@node-2#     entry 20 action deny
 
*(ex)[configure system security aaa local-profiles profile "guest3"]
A:admin@node-2#     entry 20 match "configure li"
 
*(ex)[configure system security aaa local-profiles profile "guest3"]
A:admin@node-2#     entry 30 action deny
 
*(ex)[configure system security aaa local-profiles profile "guest3"]
A:admin@node-2#     entry 30 match "show li"
 
*(ex)[configure system security aaa local-profiles profile "guest3"]
A:admin@node-2#     entry 40 action deny
 
*(ex)[configure system security aaa local-profiles profile "guest3"]
A:admin@node-2#     entry 40 match "tools"
 
*(ex)[configure system security aaa local-profiles profile "guest3"]
A:admin@node-2# info
    default-action permit-all
    entry 10 {
        action deny
        match "configure system security"
    }
    entry 20 {
        action deny
        match "configure li"
    }
    entry 30 {
        action deny
        match "show li"
    }
    entry 40 {
        action deny
        match "tools"
    }
 
*(ex)[configure system security aaa local-profiles profile "guest3"]
A:admin@node-2#

The output from the info full-context command contains the full configuration path for the configuration statements. This output can be used to reconfigure the same user profile on another router, or to rebuild the user profile if it was deleted or discarded. The following example begins with a “guest1” user profile, which is subsequently deleted and re-added using the output from the info full-context command.

The following output shows the “guest1” user profile:

*(ex)[configure system security aaa local-profiles profile "guest1"]
A:admin@node-2# info full-context
    /configure system security aaa local-profiles profile "guest1" default-action  permit-all
    /configure system security aaa local-profiles profile "guest1" entry 10 action deny
    /configure system security aaa local-profiles profile "guest1" entry 10 match "configure system security"
    /configure system security aaa local-profiles profile "guest1" entry 20 action deny
    /configure system security aaa local-profiles profile "guest1" entry 20 match "configure li"
    /configure system security aaa local-profiles profile "guest1" entry 30 action deny
    /configure system security aaa local-profiles profile "guest1" entry 30 match "show li"
    /configure system security aaa local-profiles profile "guest1" entry 40 action deny
    /configure system security aaa local-profiles profile "guest1" entry 40 match "tools"
 
*(ex)[configure system security aaa local-profiles profile "guest1"]
A:admin@node-2#

The “guest1” user profile is deleted, and the info full-context command after the delete shows no matches for profile “guest1”:

*(ex)[configure system security aaa local-profiles profile "guest1"]
A:admin@node-2# back
 
*(ex)[configure system security aaa local-profiles]
A:admin@node-2# delete profile “guest1”
 
*(ex)[configure system security aaa local-profiles]
A:admin@node-2# info full-context | match guest1
 
*(ex)[configure system security aaa local-profiles]
A:admin@node-2# 

In the next step, the original full-context output for “guest1” is copied and pasted. Since the output contains the full configuration path, the statements can be pasted from any configuration context.

*(ex)[configure system security aaa local-profiles]
A:admin@node-2# top
 
*(ex)[configure]
A:admin@node-2#  /configure system security aaa local-profiles profile "guest1" default-action permit-all
 
(ex)[configure]
A:admin@node-2#     /configure system security aaa local-profiles profile "guest1" entry 10 { }
 
*(ex)[configure system security aaa local-profiles profile "guest1"]
A:admin@node-2#     /configure system security aaa local-profiles profile "guest1" entry 10 action deny
 
*(ex)[configure system security aaa local-profiles profile "guest1"]
A:admin@node-2#     /configure system security aaa local-profiles profile "guest1" entry 10 match "configure system security"
 
*(ex)[configure system security aaa local-profiles profile "guest1"]
A:admin@node-2#     /configure system security aaa local-profiles profile "guest1" entry 20 { }
 
*(ex)[configure system security aaa local-profiles profile "guest1"]
A:admin@node-2#     /configure system security aaa local-profiles profile "guest1" entry 20 action deny
 
*(ex)[configure system security aaa local-profiles profile "guest1"]
A:admin@node-2#     /configure system security aaa local-profiles profile "guest1" entry 20 match "configure li"
 
*(ex)[configure system security aaa local-profiles profile "guest1"]
A:admin@node-2#     /configure system security aaa local-profiles profile "guest1" entry 30 { }
 
*(ex)[configure system security aaa local-profiles profile "guest1"]
A:admin@node-2#     /configure system security aaa local-profiles profile "guest1" entry 30 action deny
 
*(ex)[configure system security aaa local-profiles profile "guest1"]
A:admin@node-2#     /configure system security aaa local-profiles profile "guest1" entry 30 match "show li"
 
*(ex)[configure system security aaa local-profiles profile "guest1"]
A:admin@node-2#     /configure system security aaa local-profiles profile "guest1" entry 40 { }
 
*(ex)[configure system security aaa local-profiles profile "guest1"]
A:admin@node-2#     /configure system security aaa local-profiles profile "guest1" entry 40 action deny
 
*(ex)[configure system security aaa local-profiles profile "guest1"]
A:admin@node-2#     /configure system security aaa local-profiles profile "guest1" entry 40 match "tools"
 
*(ex)[configure system security aaa local-profiles profile "guest1"]
A:admin@node-2#
 
*(ex)[configure system security aaa local-profiles profile "guest1"]
A:admin@node-2# info
    default-action permit-all
    entry 10 {
        action deny
        match "configure system security"
    }
    entry 20 {
        action deny
        match "configure li"
    }
    entry 30 {
        action deny
        match "show li"
    }
    entry 40 {
        action deny
        match "tools"
    }
 
*(ex)[configure system security aaa local-profiles profile "guest1"]
A:admin@node-2#

The displayed output from the compare command can also be used to copy and paste statements in the MD-CLI. See section 1.4.8.1 for information about using the compare command.

1.4.8. Committing a Configuration

1.4.8.1. Viewing the Uncommitted Configuration Changes

The compare command in the MD-CLI compares configurations and displays the difference in one output. The command can only be executed from within the configuration context.

— compare [[from] (candidate | running)] [[to] (candidate | running)]
— flat
— full-context
— lines number
— summary

Table 14 provides a description of the compare command options.

Table 14:  Compare Command Options  

Option

Description

[from] (candidate | running)

Specify the reference datastore to compare (default is from running)

[to] (candidate | running)

Specify the datastore to compare against (default is to candidate)

flat

Show the context starting from the present working context

full-context

Show the context starting at the branch root

lines number

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

summary

Suppress specific differences and display a summarized comparison

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

  1. - (minus) — element is only in the first (from) configuration, displayed first
  2. + (plus) — element is only in the second (to) configuration, displayed second
  3. (space) — element is unchanged
  4. ~ (tilde) — new value of the element that changed (only used in the summary option)
  5. {...} — deleted elements compressed to its highest container (only used in the summary option)
*(ex)[configure]
A:admin@node-2# compare
    log {
+       accounting-policy 5 {
+           description "For aa-admit-deny statistics"
+           collection-interval 69
+           include-system-info true
+           record aa-admit-deny
+       }
+       accounting-policy 8 {
+       }
    }
 

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

 
*(ex)[configure]
A:admin@node-2# compare to running
 
*(ex)[configure]
A:admin@node-2# compare to candidate
    log {
+       accounting-policy 5 {
+           description "For aa-admit-deny statistics"
+           collection-interval 69
+           include-system-info true
+           record aa-admit-deny
+       }
+       accounting-policy 8 {
+       }
    }
 
*(ex)[configure]
A:admin@node-2# compare from running to candidate
    log {
+       accounting-policy 5 {
+           description "For aa-admit-deny statistics"
+           collection-interval 69
+           include-system-info true
+           record aa-admit-deny
+       }
+       accounting-policy 8 {
+       }
    }

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

*(ex)[configure]
A:admin@node-2# compare flat
+   log { accounting-policy 5 }
+   log accounting-policy 5 description "For aa-admit-deny statistics"
+   log accounting-policy 5 collection-interval 69
+   log accounting-policy 5 include-system-info true
+   log accounting-policy 5 record aa-admit-deny
+   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 aa-admit-deny statistics"
+   /configure log accounting-policy 5 collection-interval 69
+   /configure log accounting-policy 5 include-system-info true
+   /configure log accounting-policy 5 record aa-admit-deny
+   /configure log { accounting-policy 8 }
 
*(ex)[configure]
A:admin@node-2#

The following example shows the difference between the compare and compare summary commands. The compare command shows the deletion and addition of configuration changes, each on its own line, and the compare summary command shows the configuration change summarized on one line with a ~ character.

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

1.4.8.1.1. Using the compare Outputs to Copy and Paste

In the following example, the compare command shows the timers that have been modified. After the commit command has been issued to add these to the running configuration, the lsa-generate container is deleted. The following displays the output for the compare command.

*(ex)[configure router "Base" ospf 0 timers]
A:admin@node-2# compare
+   lsa-generate {
+       max-lsa-wait 500000
+       lsa-initial-wait 100000
+       lsa-second-wait 200000
+   }
+   spf-wait {
+       spf-max-wait 120000
+       spf-initial-wait 50000
+       spf-second-wait 60000
+   }

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

*(ex)[configure router "Base" ospf 0 timers]
A:admin@node-2# compare from candidate to running full-context
-   /configure router "Base" ospf 0 timers lsa-generate max-lsa-wait 500000
-   /configure router "Base" ospf 0 timers lsa-generate lsa-initial-wait 100000
-   /configure router "Base" ospf 0 timers lsa-generate lsa-second-wait 200000
-   /configure router "Base" ospf 0 timers spf-wait spf-max-wait 120000
-   /configure router "Base" ospf 0 timers spf-wait spf-initial-wait 50000
-   /configure router "Base" ospf 0 timers spf-wait spf-second-wait 60000
 
*(ex)[configure router "Base" ospf 0 timers]
A:admin@node-2# validate
 
*(ex)[configure router "Base" ospf 0 timers]
A:admin@node-2# commit

In the next step, the lsa-generate parameters are deleted, using a copy and paste of the first three configuration statements:

(ex)[configure]
A:admin@node-2# -   /configure router "Base" ospf 0 timers lsa-generate max-lsa-wait 500000
 
*(ex)[configure]
A:admin@node-2# -   /configure router "Base" ospf 0 timers lsa-generate lsa-initial-wait 100000
 
*(ex)[configure]
A:admin@node-2# -   /configure router "Base" ospf 0 timers lsa-generate lsa-second-wait 200000

The compare summary command shows that the deleted lsa-generate parameters are compressed to its highest container, shown with an ellipsis in braces ({}).

*(ex)[configure]
A:admin@node-2# compare summary
    router "Base" {
        ospf 0 {
            timers {
-               lsa-generate { ... }
            }
        }
    }

If the timers container is deleted, which holds both the lsa-generate and spf-wait containers, the compare summary command now shows the timers container as the highest deleted container:

*(ex)[configure router "Base" ospf 0]
A:admin@node-2# delete timers
*(ex)[configure router "Base" ospf 0]
A:admin@node-2# compare
-   timers {
-       lsa-generate {
-           max-lsa-wait 500000
-           lsa-initial-wait 100000
-           lsa-second-wait 200000
-       }
-       spf-wait {
-           spf-max-wait 120000
-           spf-initial-wait 50000
-           spf-second-wait 60000
-       }
-   }
 
*(ex)[configure router "Base" ospf 0]
A:admin@node-2# compare summary
-   timers { ... }
 
*(ex)[configure router "Base" ospf 0]
A:admin@node-2#

1.4.8.2. Discarding Configuration Changes

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

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

*(ro)[configure]
A:admin@node-2# compare
    log {
+       accounting-policy 5 {
+           description "For aa-admit-deny statistics"
+           collection-interval 69
+           include-system-info true
+           record aa-admit-deny
+       }
+       accounting-policy 8 {
+       }
    }
 
*(ro)[configure]
A:admin@node-2# discard
MINOR: CLI #2069: Operation not allowed - currently in read-only mode
 
*(ro)[configure]
A:admin@node-2# exit
 
*(ro)[]
A:admin@node-2# quit-config
INFO: CLI #2067: Exiting read-only configuration mode
 
[]
A:admin@node-2# edit-config global
INFO: CLI #2054: Entering global configuration mode
INFO: CLI #2055: Uncommitted changes are present in the candidate configuration
 
*(gl)[]
A:admin@node-2# compare
    log {
+       accounting-policy 5 {
+           description "For aa-admit-deny statistics"
+           collection-interval 69
+           include-system-info true
+           record aa-admit-deny
+       }
+       accounting-policy 8 {
+       }
    }
 
*(gl)[]
A:admin@node-2# configure log
 
*(gl)[configure log]
A:admin@node-2# discard
MINOR: MGMT_CORE #2203: Invalid element - 'discard' not allowed in 'log'
 
*(gl)[configure log]
A:admin@node-2# discard /configure
 
(gl)[configure log]
A:admin@node-2# /compare
 
(gl)[configure log]
A:admin@node-2#

Uncommitted changes from a global configuration mode session are kept in the candidate configuration when the quit-config command is executed. However, when executing a quit-config command from exclusive configuration mode, uncommitted changes are discarded, and a confirmation message is displayed:

*(ex)[]
A:admin@node-2# quit-config
INFO: CLI #2063: Uncommitted changes are present in the candidate configuration. Exiting exclusive configuration mode will discard those changes.
 
Discard uncommitted changes? [y,n] y
WARNING: CLI #2062: Exiting exclusive configuration mode - uncommitted changes are discarded
INFO: CLI #2064: Exiting exclusive configuration mode

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

1.4.8.3. Validating the Candidate Configuration

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

*(ro)[]
A:admin@node-2# compare
    log {
+       accounting-policy 7 {
+           description "seven"
+           collection-interval 77
+       }
    }
 
*(ro)[]
A:admin@node-2# validate
 
*(ro)[]
*(ex)[]
A:admin@node-2# compare
+   eth-cfm {
+       domain "mdn" {
+           association "man" {
+               ccm-interval 10ms
+           }
+       }
+   }
 
*(ex)[]
A:admin@node-2# validate
MINOR: MGMT_CORE #236: configure eth-cfm domain "mdn" level - Missing mandatory fields
MINOR: ETH_CFM #12: configure eth-cfm domain "mdn" format - Inconsistent Value error - One of dns, mac, name or format must be provided
 
*(ex)[]
A:admin@node-2#

The commit command also runs validation on the configuration. Therefore, it is not necessary to execute the validate command as a separate step when committing the candidate configuration.

1.4.8.4. Committing the Candidate Configuration

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

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

When a commit operation is initiated, a validation is first performed on the candidate configuration.

With a successful validation, the changes are copied to the running configuration, which becomes the current, operational router configuration. The candidate configuration is reset to its initial state.

If the commit operation fails, an automatic rollback occurs, which returns the running state to the state before the commit was applied. An automatic rollback does not use a rollback checkpoint file, so is not dependent on persistency to be enabled. Instead, a list of changes is kept in memory until the automatic rollback is completed. The uncommitted changes remain in the candidate configuration.

1.4.8.4.1. Issuing a Commit Operation from Global or Exclusive Configuration Mode

Multiple users can make candidate changes in global configuration mode. All changes from all users are visible in the candidate configuration. A commit operation issued by one user activates all changes made by all users.

No indication is given to other users when a commit operation is issued by a user.

Exiting global configuration mode before committing the changes leaves the changes in the candidate configuration.

Only one user can obtain an exclusive lock and enter exclusive configuration mode at a time. Making changes to the candidate configuration and committing these changes can only be done via the session that is in exclusive configuration mode.

All uncommitted changes are discarded on exiting exclusive configuration mode. If uncommitted changes are present in the candidate configuration, a session cannot enter exclusive configuration mode, but it is possible to enter global configuration mode if no exclusive lock has already been obtained by another session.

1.4.8.4.2. Using the commit confirmed Command

Executing the commit command with no options performs the operation immediately. the confirmed option can be used to activate configuration changes without making them persistent, to give the user time to verify that the configuration is working as intended. By default, the commit confirmed command executes the commit operation with an automatic rollback of 10 minutes. Within this time, an explicit confirmation (commit confirmed accept) must be issued for the changes to become persistent. Other configuration commands issued during this time interval are blocked. All prompt displays a countdown at the end of the display,

*(gl)[configure log accounting-policy 5]
A:admin@node-2# commit confirmed
 
INFO: CLI #2090: Commit confirmed - automatic rollback in 9 minutes 59 seconds
(gl)[configure log accounting-policy 5]
A:admin@node-2#
 
INFO: CLI #2090: Commit confirmed - automatic rollback in 9 minutes 47 seconds
(gl)[configure log accounting-policy 5]
A:admin@node-2# pwc
Present Working Context:
  configure
  log
  accounting-policy 5
 
INFO: CLI #2090: Commit confirmed - automatic rollback in 9 minutes 45 seconds
(gl)[configure log accounting-policy 5]
A:admin@node-2# back
 
INFO: CLI #2090: Commit confirmed - automatic rollback in 9 minutes 41 seconds
(gl)[configure log]
A:admin@node-2# accounting-policy 9
MINOR: MGMT_CORE #2604: Commit confirmed in progress - changes to the candidate configuration are not allowed
 
INFO: CLI #2090: Commit confirmed - automatic rollback in 9 minutes 38 seconds
(gl)[configure log]
A:admin@node-2#
 
INFO: CLI #2090: Commit confirmed - automatic rollback in 8 minutes 44 seconds
(gl)[configure log]
A:admin@node-2#

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

*(gl)[configure log accounting-policy 5]
A:admin@node-2# /compare
-   collection-interval 55
+   collection-interval 88
 
*(gl)[configure log accounting-policy 5]
A:admin@node-2# commit confirmed
MAJOR: LOG #1051: configure log accounting-policy 5 collection-interval - Invalid accounting policy interval - Must be in increments of 5 minutes for AA records
 
*(gl)[configure log accounting-policy 5]
A:admin@node-2#

The timeout option for the commit confirmed operation can override the default value of 10 minutes. While a commit confirmed timer is running, a subsequent commit confirmed or commit confirmed operation with a timeout option restarts the timer.

*(gl)[configure log accounting-policy 5]
A:admin@node-2# commit confirmed
 
INFO: CLI #2090: Commit confirmed - automatic rollback in 10 minutes
(gl)[configure log accounting-policy 5]
A:admin@node-2# commit confirmed 33
 
INFO: CLI #2090: Commit confirmed - automatic rollback in 33 minutes
(gl)[configure log accounting-policy 5]
A:admin@node-2#

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

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

1.4.8.4.2.1. Non-persistent Operation

The commit confirmed and commit confirmed accept or commit confirmed cancel commands must be executed from the same MD-CLI user session. Commit commands executed from another (global) session while the commit confirmed timer is running generate an error.

While the commit confirmed timer is running, the user can exit and re-enter global or exclusive mode within the same session. The commit confirmed timer keeps running, and can be seen from all sessions running in an MD-CLI engine.

If a logout is attempted from the session that issued the commit confirmed command, a user prompt displays to confirm the logout and automatic rollback.

*(gl)[]
A:admin@node-2# commit confirmed
 
INFO: CLI #2090: Commit confirmed - automatic rollback in 10 minutes
(gl)[]
A:admin@test-node#
 
INFO: CLI #2090: Commit confirmed - automatic rollback in 9 minutes 59 seconds
(gl)[]
A:admin@test-node#
 
INFO: CLI #2090: Commit confirmed - automatic rollback in 9 minutes 58 seconds
(gl)[]
A:admin@test-node#
 
INFO: CLI #2090: Commit confirmed - automatic rollback in 9 minutes 57 seconds
(gl)[]
A:admin@test-node# logout
INFO: CLI #2095: The commit confirmed in progress - a logout will cancel the commit confirmed and immediatelly start automatic rollback
 
Cancel commit confirmed and rollback immediately? [y,n]

1.4.8.4.2.2. Persistent Identifier

A persistence identifier can be specified with the initial commit confirmed command. A commit confirmed accept or cancel command can then be executed from the same or a different MD-CLI user session, NETCONF, or gRPC session, from where the commit confirmed persist-id command was initiated. The persistence identifier must then be included with the subsequent commit confirmed commands. The persistence identifier is a user-defined string of up to 255 characters or an empty string (“”).

*(ex)[configure]
A:admin@node-2# commit confirmed persist-id my-commit
 
INFO: CLI #2090: Commit confirmed - automatic rollback in 10 minutes
(ex)[configure]
A:admin@node-2# commit confirmed cancel
MINOR: MGMT_CORE #2603: Confirmed commit was started using a different persist token
 
INFO: CLI #2090: Commit confirmed - automatic rollback in 9 minutes 41 seconds
(ex)[configure]
A:admin@node-2# commit confirmed accept
MINOR: MGMT_CORE #2603: Confirmed commit was started using a different persist token
 
INFO: CLI #2090: Commit confirmed - automatic rollback in 9 minutes 32 seconds
(ex)[configure]
A:admin@node-2# commit confirmed cancel persist-id my-commit
 
*(ex)[configure]
A:admin@node-2# 

1.4.9. Saving Changes

The MD-CLI asterisk prompt (*) is the uncommitted changes indicator that indicates the presence of changes in the candidate configuration datastore since the last commit. The configuration becomes persistent when it is saved to a local or remote location.

Explicit persistence is achieved by issuing the admin save command after candidate changes have been committed. The command has the following syntax:

admin save [file-url] file-name

where file-name is a character string specifying the location where the configuration is to be saved.

The MD-CLI has an implicit persistency option linked to the commit command: the auto-config-save command in configure system management-interface cli md-cli. When candidate configuration changes are successfully committed, the configuration is automatically saved if auto-config-save is set to true.

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

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

1.4.10. Rolling Back a Configuration from a Checkpoint File

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

A rollback checkpoint is created automatically after every successful commit when automatic save is enabled via the MD-CLI auto-config-save command.

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

A rollback checkpoint is also created if an operator issues the admin save command, regardless of the MD-CLI auto-config save setting.

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

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

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

(ro)[configure system management-interface configuration-save]
A:admin@node-2# info detail
    configuration-backups 5
 
(ro)[configure system management-interface configuration-save]
A:admin@node-2# configuration-backups ?
 
 configuration-backups <number>
 
 <number> - <1..200>
 
 Maximum number of backup revisions maintained for a configuration file
 
 This value also applies to the number of revisions maintained for the BOF file
 and debug save files.

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

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

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

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

The rollback command is available in global or exclusive configuration mode and can only be executed from the root of the configuration branch.

When the auto-config-save parameter is set to true, the rollback command (without an index) is the equivalent of executing the discard command for the current candidate configuration changes.

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

In Figure 3, the auto-config-save parameter is set to true. With a successful commit, a rollback checkpoint is created.

Figure 3:  Successful Commit with auto-config-save true 

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

Figure 4:  Successful commit with auto-config-save false 

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

Figure 5:  Failed commit 

1.4.11. Loading a Configuration File

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

The syntax of the load command is as follows:

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

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

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

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

  1. MD-CLI commands such as commit, delete, or tools
  2. navigation commands such as exit, back, or top

See Executing Commands with a File to perform such actions from a file.

If the loaded file encounters errors, parsing terminates at the first error. Statements before the error are loaded into the candidate configuration. Configuration statements in the loaded file are also subject to AAA command authorization. An authorization check failure also terminates the execution of further statements in the file.

1.4.11.1. Using info Outputs in Load Files

The output from the info full-context or info commands can be copied and pasted into a load file. Both the full-replace and merge options support this type of content.

The following shows the output from the info full-context command. This output can be copied and pasted into a file; for example, cf1:\bgp.cfg.

*(ex)[configure router "Base" bgp]
A:admin@node-2# info full-context
    /configure router "Base" bgp neighbor 192.168.89.8 { }
    /configure router "Base" bgp neighbor 192.168.89.8 { prefix-limit ipv4 }
    /configure router "Base" bgp neighbor 192.168.89.8 prefix-limit ipv4 prefix-limit 1000
    /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

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

(ro)[]
A:admin@node-2# //file type cf1:\bgp.cfg
INFO: CLI #2051: Switching to the classic CLI engine
A:node-2# /file type cf1:\bgp.cfg
File: bgp.cfg
-------------------------------------------------------------------------------
    /configure router "Base" bgp group "external" { }
    /configure router "Base" bgp neighbor 192.168.89.8 { }
    /configure router "Base" bgp neighbor 192.168.89.8 group "external"
    /configure router "Base" bgp neighbor 192.168.89.8 { prefix-limit ipv4 }
    /configure router "Base" bgp neighbor 192.168.89.8 prefix-limit ipv4 prefix-limit 1000
    /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:node-2#

The load merge command can be used to merge the contents of the file into the candidate configuration. The following example shows no current candidate configuration changes for BGP before the command is executed. The compare command shows the candidate configuration changes after the file is merged.

(ex)[configure router "Base" bgp]
A:admin@node-2# info
 
(ex)[configure router "Base" bgp]
A:admin@node-2#
 
(ex)[configure]
A:admin@node-2# load merge cf1:\bgp.cfg
Executed 7 lines in 0.0 seconds from file cf1:\bgp.cfg
 
*(ex)[configure]
A:admin@node-2# compare
    router "Base" {
+       bgp {
+           group "external" {
+           }
+           neighbor 192.168.89.8 {
+               group "external"
+               prefix-limit ipv4 {
+                   prefix-limit 1000
+                   log-only true
+                   threshold 80
+               }
+           }
+       }
    }

The output from the info flat command can be copied into a file; for example, cf1:\bgp2.cfg:

*(ex)[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 prefix-limit 1000
    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#

An additional context line is added to specify the context /configure router “Base” bgp, as shown in the file display:

(ro)[]
A:admin@node-2# //file type cf1:\bgp2.cfg
INFO: CLI #2051: Switching to the classic CLI engine
A:node-2# /file type cf1:\bgp2.cfg
File: bgp2.cfg
-------------------------------------------------------------------------------
/configure router bgp
    group "external" { }
    neighbor 192.168.89.8 { }
    neighbor 192.168.89.8 group "external"
    neighbor 192.168.89.8 { prefix-limit ipv4 }
    neighbor 192.168.89.8 prefix-limit ipv4 prefix-limit 1000
    neighbor 192.168.89.8 prefix-limit ipv4 log-only true
    neighbor 192.168.89.8 prefix-limit ipv4 threshold 80
 
 
===============================================================================
A:node-1#

The file is merged and the compare command shows the resulting candidate configuration changes.

(ex)[configure router "Base" bgp]
A:admin@node-1# info
 
(ex)[configure router "Base" bgp]
A:admin@node-1# top
 
(ex)[configure]
A:admin@node-1# load merge cf1:\bgp2.cfg
Executed 9 lines in 0.0 seconds from file cf1:\bgp2.cfg
 
*(ex)[configure]
A:admin@node-1# compare
    router "Base" {
        bgp {
+           group "external" {
+           }
+           neighbor 192.168.89.8 {
+               group "external"
+               prefix-limit ipv4 {
+                   prefix-limit 1000
+                   log-only true
+                   threshold 80
+               }
+           }
        }
    }
 
*(ex)[configure]
A:admin@node-1#

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

*(ex)[configure router "Base" bgp]
A:admin@node-2# info
    neighbor 192.168.89.8 {
        prefix-limit ipv4 {
            prefix-limit 1000
            log-only true
            threshold 80
        }
    }

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

/configure router "Base" bgp
    neighbor 192.168.89.8 {
        prefix-limit ipv4 {
            prefix-limit 1000
            log-only true
            threshold 80
        }
    }

1.4.12. Using Configuration Groups

The SR OS MD-CLI supports the creation of configuration templates called configuration groups, which can be applied at different branches in the configuration, where the configuration elements are inherited. This is shown in Figure 6.

Figure 6:  Configuration Groups 

The advantage of using configuration groups is that similar configurations can be grouped in a template that is applied at multiple branches in the configuration tree. Subsequent configuration updates are only required in one location. Using groups, configurations can be organized in a logical fashion, such as regional (East vs West) or functional (core-facing vs access-facing parameters). The result is a more compact configuration that is easier to maintain and that reduces the number of configuration and operational errors.

The following guidelines apply when creating configuration groups:

  1. configuration groups can only be used in the MD-CLI
  2. the management interface configuration mode must be set to model-driven
  3. Nokia recommends a maximum of 64 configuration groups
  4. configuration groups are supported for the following configuration branches:
    1. configure router router-instance isis isis-instance
    2. configure qos
    3. configure card iom-card-slot mda mda-slot network ingress
    4. configure port port ethernet network
    5. configure router router-instance interface interface-name qos

1.4.12.1. Creating Configuration Groups

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

(ex)[configure]
A:admin@pe1# 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@pe1# 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.

1.4.12.1.1. Exact Match

With an exact match, configuration elements can only be inherited by the list entry that matches the specified key value. When no list entry is matched, a new list entry is created with the specified key value.

In the following example, interface “int-pe1-pe2” is an exact match. When the group is applied and IS-IS interface “int-pe1-pe2” exists in IS-IS instance 0, the interface-type leaf is inherited. If the IS-IS interface does not exist, it is created with the interface-type set to point-to-point.

(ex)[configure]
A:admin@pe1# info
    groups {
        group "isis-backbone" {
            router "Base" {
                isis "0" {
                    interface "int-pe1-pe2" {
                        interface-type point-to-point
                    }
                }
            }
        }
    }

1.4.12.1.2. Regular Expression Match

With a regular expression match, configuration elements can be inherited by all list entries for which the key value matches the regular expression. A list entry cannot be created with a regular expression match.

In the following example, interface “<.*>” is a regular expression match that matches any interface name. When the group is applied, all configured IS-IS interfaces in IS-IS instance 0 inherit the interface-type leaf.

(ex)[configure]
A:admin@pe1# info
    groups {
        group "isis-backbone" {
            router "Base" {
                isis "0" {
                    interface "<.*>" {
                        interface-type point-to-point
                    }
                }
            }
        }
    }

1.4.12.1.2.1. Regular Expression Match Format

A regular expression match is specified as a string with the regular expression enclosed in angle brackets: “<regex-match>”.

The regular expression match is implicitly anchored: a ^ (match-starting position) is added at the beginning of the regular expression and a $ (match-ending position) is added at the end.

The regular expression is a subset of the Extended Regular Expression (ERE) notation as described in section  1.3.11.1.1.

For example:

  1. interface “<int-.*>” — matches all interfaces that start with “int-”
  2. interface “<.*>” — matches all interfaces
  3. interface “<.*pe[1-3].*>” — matches all interfaces that have “pe1”, “pe2”, or “pe3” in their name

With regular expressions, it is possible to create conflicting matches: two regular expression matches, or a regular expression match and an exact match, that both match on the same list entry. These conflicting matches are not supported and result in a validation error.

In the following example, both interface “<int-.*>” and “int-pe1-pe2” match interface “int-pe1-pe2”, so result in a conflict at validation:

(ex)[configure]
A:admin@pe1# info
    groups {
        group "isis-backbone" {
            router "Base" {
                isis "0" {
                    interface "<int-.*>" {
                        interface-type broadcast
                    }
                    interface "int-pe1-pe2" {
                        interface-type point-to-point
                    }
                }
            }
        }
    }
 
(ex)[configure]
A:admin@pe1# validate
MINOR: MGMT_CORE #2901: configure router "Base" isis 0 interface "int-pe1-pe2" - Configuration group inheritance failed - conflicting match criteria within group "isis-backbone" : interface "<int-.*>", interface "int-pe1-pe2"

1.4.12.2. Applying Configuration Groups

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

(ex)[configure router "Base" isis 0]
A:admin@pe1# 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@pe1# 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@pe1# 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:

  1. configuration groups cannot be nested; therefore, apply-groups statements cannot be part of a configuration group
  2. configuration groups that are not applied in the configuration do not functionally change the configuration
  3. configuration groups and apply-groups statements are part of the running configuration and are saved in the MD-CLI configuration file

1.4.12.3. Inheritance Rules

Local configuration elements have precedence over configuration group inheritance.

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

(ex)[configure]
A:admin@pe1# 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@pe1# 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:

  1. configuration elements in the first listed group have the highest precedence
  2. configuration elements in the last listed group have the lowest precedence

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

(ex)[configure]
A:admin@pe1# 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@pe1# 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 explained earlier, the level-capability configuration element from group “isis-1” has lower precedence than the local configured value. The wide-metric-only configuration element from group “isis-3” is not inherited because the group is applied at the interface branch and only configuration elements at that level or lower can be inherited.

(ex)[configure]
A:admin@pe1# 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@pe1# 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
                }
            }
        }
    }
Note:

Inheritance rules for a leaf-list are the same as for a single leaf.

It is not possible to add values to an existing leaf-list through configuration group inheritance.

1.4.12.4. Displaying the Expanded Configuration

After configuring and applying configuration groups, the expanded configuration should be reviewed before commit. The expanded configuration at a configuration branch can be displayed with the info inheritance command. By default, this command displays the expanded candidate configuration. To display the expanded running configuration, use info running inheritance.

All statements that are inherited from a configuration group are tagged with a system comment.

(ex)[configure router "Base" isis 0 interface "int-pe1-pe2"]
A:admin@pe1# 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@pe1# info inheritance | match '^[ ]*##' invert-match
    interface-type point-to-point
    level 2 {
        metric 20
    }
Note:

Conflicting matches are detected at validation. The info inheritance command may display an inherited configuration element that is part of a conflicting match criteria.

1.4.12.5. Authentication, Authorization, and Accounting (AAA) in Configuration Groups

User profiles can restrict the configuration branches that a user can change. When configuration groups are used, these user profiles should be enhanced to restrict the creation or inheritance of configuration elements in these branches.

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

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

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

(ro)[configure system security aaa local-profiles profile "restricted-admin"]
A:admin@pe1# info
<snip>
    entry 200 {
        action deny
        match "configure qos sap-egress"
    }

Using configuration groups, user admin2 can still create or change sap-egress QoS policies:

(ex)[configure groups]
A:admin2@pe1# info
    group "qos-1" {
        qos {
            sap-egress "high-bw" {
                queue "1" {
                    rate {
                        pir 200000
                    }
                }
            }
        }
    }
 
(ex)[configure qos]
A:admin2@pe1# info
    apply-groups ["qos-1"]
 
<snip>

The result of the inheritance is not visible to user admin2 because the info command is also subject to the user profile rules.

(ex)[configure qos]
A:admin2@pe1# info inheritance
    apply-groups ["qos-1"]
    md-auto-id {
        qos-policy-id-range {
            start 1000
            end 2000
        }
    }

The admin user who has full privileges can see the inherited configuration, which includes the sap-egress policy created by user admin2.

(ro)[configure qos]
A:admin@pe1# info inheritance
    apply-groups ["qos-1"]
    md-auto-id {
        qos-policy-id-range {
            start 1000
            end 2000
        }
    }
    ## 'sap-egress "high-bw"' inherited from group "qos-1"
    sap-egress "high-bw" {
        ## 'queue 1' inherited from group "qos-1"
        queue 1 {
            ## 'rate' inherited from group "qos-1"
            rate {
                ## 'pir' inherited from group "qos-1"
                pir 200000
            }
        }
    }
 

To prevent user admin2 from creating sap-egress QoS policies using configuration groups, the AAA profile of the user can be enhanced. For example, an entry can be added in the local user profile:

(ro)[configure system security aaa local-profiles profile "restricted-admin"]
A:admin@pe1# info
<snip>
    entry 200 {
        action deny
        match "configure qos sap-egress"
    }
    entry 210 {
        action deny
        match "configure groups group qos sap-egress"
    }

This configuration removes the privileges for user admin2 to create sap-egress QoS policies using configuration groups:

(ex)[configure groups group "qos-1" qos]
A:admin2@pe1# sap-egress high-bw
MINOR: MGMT_CORE #2020: Permission denied - unauthorized use of 'sap-egress'
 

1.4.12.6. Configuration Group Example

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

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

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

(ex)[configure]
A:admin@pe1# 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@pe1# 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@pe1# 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
    }

1.4.13. Viewing the Status of the Local Datastores

An MD-CLI session in exclusive configuration mode acquires an explicit lock for both the global candidate and running configuration datastores. This is achieved by executing the edit-config exclusive command. An explicit lock can also be obtained via NETCONF or gRPC sessions. Refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide for more information.

To view the lock status of the datastores, the following show command is available:

show system management-interface datastore-locks [detail]

The detail option displays information about any model-driven interface session that impacts the datastore locks. MD-CLI read-only sessions, for example, do not impact the datastore locks.

[]
A:admin@node-2# show system management-interface datastore-locks detail
===============================================================================
Session ID  Region                 Datastore                     Lock State
  Username                         From
  Session Type                     Session Mode
-------------------------------------------------------------------------------
10          configure              candidate,running             Locked
  admin                            192.168.1.2
  MD-CLI                           Exclusive
===============================================================================
 
[]
A:admin@node-2#

1.4.13.1. Unlocking a Locked Datastore

A datastore lock that has been acquired by any model-driven session can be administratively removed by using the following admin command:

admin disconnect session-id session-id

For example, to disconnect the MD-CLI session indicated in the preceding show command output, issue the admin command as follows:

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

Disconnecting an MD-CLI session (or any model-driven session, including NETCONF and gRPC) that acquired a datastore lock has the following results:

  1. any uncommitted changes in the candidate configuration datastore are discarded
  2. the session is terminated
  3. the explicit lock is released

1.5. Troubleshooting

1.5.1. Debug commands

The debug command is not natively supported in the MD-CLI. The command can be executed from the classic CLI. The // command can be used to switch to the classic CLI engine from the MD-CLI engine. Both debug and /debug are supported in the classic CLI.

[]
A:admin@node-2# //
INFO: CLI #2051: Switching to the classic CLI engine
A:node-2# debug router bgp packets
A:node-2#
A:node-2# /debug router bgp packets
A:node-2#

1.5.2. Logging Debug Events in the MD-CLI

The following MD-CLI commands can be used to log debug events to an active CLI session.

— configure
— log
— log-id [id] number
— source
— debug boolean
— destination
— cli
— max-entries number

The following example shows the configuration for debug events to be stored in destination CLI log identifier 7. The log entries wrap at 50 entries (the configured value of max-entries).

(ex)[configure log]
A:admin@node-2# log-id 7
 
*(ex)[configure log log-id 7]
A:admin@node-2# source debug
 
*(ex)[configure log log-id 7]
A:admin@node-2# destination cli max-entries 50
 
*(ex)[configure log log-id 7]
A:admin@node-2# info
    source {
        debug true
    }
    destination {
        cli {
            max-entries 50
        }
    }

After the commit command has been issued to include the log in the running configuration, the following tools command can be executed in the CLI session that will be used to display outputs of the debug events. Refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide for more information about the tools command.

(ex)[tools perform log]
A:admin@node-2# subscribe-to log-id 7
 
(ex)[]
A:admin@node-2#

The events can be displayed using the /show log command and cleared using the /clear log command.

[]
A:admin@node-2# show log log-id log-id 7
===============================================================================
Event Log 7
===============================================================================
Description : (Not Specified)
Log contents  [size=50   next event=2  (not wrapped)]
 
<snip>
 
[]
A:admin@node-2# clear log log-id 7
 
[]
A:admin@node-2#

To terminate the output of the logs to the CLI session, use the unsubscribe-from command as shown.

(ex)[]
A:admin@node-2# tools perform log unsubscribe-from log-id 7
 
(ex)[]
A:admin@node-2#

1.6. MD-CLI Advanced Tips and Features

1.6.1. Discarding Changes in Specific Contexts

The discard command can be used only from the top level of the configuration branch. From any working context (including the configure context), the discard /configure command can be used.

*(ex)[configure router "Base" ospf 0 timers spf-wait]
A:admin@node-2# discard
MINOR: MGMT_CORE #2203: Invalid element - 'discard' not allowed in 'spf-wait'
 
*(ex)[configure router "Base" ospf 0 timers spf-wait]
A:admin@node-2# discard /configure
 
(ex)[configure router "Base" ospf 0 timers spf-wait]
A:admin@node-2#

However, the discard /configure command removes all configuration statements from the candidate configuration datastore. To discard changes from a specific context, the output from the compare command can be used to copy and paste configuration statements from within a working context.

By default, the compare command uses the running configuration datastore as the base reference. Therefore, any new configuration in the candidate configuration datastore is displayed with a preceding plus (+) sign. When the compare command uses the candidate configuration datastore as the base reference, the compare output displays any new configuration in the candidate configuration datastore with a preceding minus (-) sign, indicating that these configuration elements are not present in the running configuration datastore. These configuration statements preceded with a minus (-) sign can be used to discard configurations from the specific context from which the compare command was issued.

In the following configuration example, the lsa-generate timers are modified.

(ex)[configure router "Base" ospf 0 timers lsa-generate]
A:admin@node-2# info detail
    max-lsa-wait 5000
    lsa-initial-wait 5000
    lsa-second-wait 5000
 
(ex)[configure router "Base" ospf 0 timers lsa-generate]
A:admin@node-2# lsa-initial-wait 1000
 
*(ex)[configure router "Base" ospf 0 timers lsa-generate]
A:admin@node-2# lsa-second-wait 2000
 
*(ex)[configure router "Base" ospf 0 timers lsa-generate]
A:admin@node-2# max-lsa-wait 3000
*(ex)[configure router "Base" ospf 0 timers lsa-generate]
A:admin@node-2# info
    max-lsa-wait 3000
    lsa-initial-wait 1000
    lsa-second-wait 2000

By default, the compare command shows the new configuration using the running configuration datastore as the reference:

*(ex)[configure router "Base" ospf 0 timers lsa-generate]
A:admin@node-2# compare
+   max-lsa-wait 3000
+   lsa-initial-wait 1000
+   lsa-second-wait 2000

The following shows the compare command output when the command is executed with the candidate configuration datastore as the reference.

*(ex)[configure router "Base" ospf 0 timers lsa-generate]
A:admin@node-2# compare from candidate to running
-   max-lsa-wait 3000
-   lsa-initial-wait 1000
-   lsa-second-wait 2000

To discard the max-lsa-wait and lsa-initial-wait timer changes, the first two lines from the compare command output can be copied and pasted while in the specified context. The info detail command shows that the timer changes have reverted to their default values.

*(ex)[configure router "Base" ospf 0 timers lsa-generate]
A:admin@node-2# -   max-lsa-wait 3000
 
*(ex)[configure router "Base" ospf 0 timers lsa-generate]
A:admin@node-2# -   lsa-initial-wait 1000
 
*(ex)[configure router "Base" ospf 0 timers lsa-generate]
A:admin@node-2#
 
*(ex)[configure router "Base" ospf 0 timers lsa-generate]
A:admin@node-2# info detail
    max-lsa-wait 5000
    lsa-initial-wait 5000
    lsa-second-wait 2000
 
*(ex)[configure router "Base" ospf 0 timers lsa-generate]
A:admin@node-2#