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:

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

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

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.

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.

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

1.3.3.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.3.2. Customizing the Session Prompt

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

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.

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

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.

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

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

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

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

1.3.4.1. Indicators in the Online Help

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

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.

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

1.3.7.2. Using the Detail Option

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

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

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

1.3.11.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.12.1. Using | match Options

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

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.

1.3.12.2. Using | count

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

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.12.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.4. Using the File Redirect Option

The > option can be used to redirect output to a local or remote file. The > redirect must be specified at the end of a command and cannot be combined with other redirects.

1.3.13.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 “+”.

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

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.

Configuring a container navigates into the context.

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.

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

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.

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

Table 10 describes the info command options.

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

The order of the configuration output is as follows:

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.5 for more information.

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

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

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.

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

1.3.15.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.3.15.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.15.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.15.3. Using Output Modifiers

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

1.4.1.1. MD-CLI Session Modes

There are two modes in the MD-CLI:

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

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

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

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

1.4.1.2. Transactional Configuration Method

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

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

Figure 1:  Flow of Configuration Changes  

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

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

1.4.1.3. Implicit and Explicit Configuration Workflows

The MD-CLI supports two configuration workflows:

Table 12 compares the implicit and explicit configuration workflows.

1.4.2.1. Multiple Simultaneous Candidate Configurations

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

This section describes:

Figure 2 shows multiple candidate configurations.

Figure 2:  Multiple Candidate Configurations 

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

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

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

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

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

Furthermore, when simultaneous configuration sessions access different candidate configurations:

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

Figure 3:  Simultaneous Configuration Sessions 

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

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

Figure 4:  Simultaneous Configuration Sessions - Baseline Out-of-Date 

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

Figure 5:  Simultaneous Configuration Sessions - Update 

Conflicts can occur when merging changes are committed by more than one configuration session working on the same part of a configuration. A merge conflict occurs when a configuration element is added, deleted, or modified in the candidate configuration and the same configuration element is also added, deleted, or modified in the running configuration after the baseline snapshot was taken. With the update command, the router resolves each merge conflict and installs the result in the candidate configuration, as shown in Figure 6.

Figure 6:  Simultaneous Configuration Sessions - Merge Conflict 

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

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

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

1.4.2.2. Private Configuration Mode

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

A private configuration session has the following characteristics:

For simultaneous configuration sessions:

Datastore interactions include the following characteristics:

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

Note: CLI #2075 is shown only when applicable. To display the current active configuration sessions in the router, use the command show system management-interface configuration-sessions.

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

1.4.2.3. Exclusive Configuration Mode

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

An exclusive configuration session has the following characteristics:

For simultaneous configuration sessions:

Datastore interactions include the following characteristics:

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

Note: MGMT_CORE #2052 and CLI #2075 are shown only when applicable. To display the current active configuration sessions in the router, use the command show system management-interface configuration-sessions.

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

1.4.2.4. Global Configuration Mode

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

A global configuration session has the following characteristics:

For simultaneous configuration sessions:

Datastore interactions include the following characteristics:

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

Note: CLI #2055 and CLI #2075 are shown only when applicable. To display the current active configuration sessions in the router, use the command show system management-interface configuration-sessions.

When leaving global configuration mode, the following messages are displayed.

Note: CLI #2057 is shown only when applicable.

1.4.2.5. Read-Only Configuration Mode

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

A read-only configuration session has the following characteristics:

For simultaneous configuration sessions:

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

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

1.4.2.6. Transitioning Between Candidate Configuration Modes

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

Transitions from and to private configuration mode are not allowed.

Figure 7 summarizes the configuration mode transitions and transitions to operational mode.

Figure 7:  Configuration and Operational Mode Transitions 

Transitioning from exclusive to global or read-only configuration mode causes the candidate changes to be discarded.

Switching from global or read-only to exclusive configuration mode is allowed when no other global or exclusive configuration session is active. Uncommitted changes in the global candidate configuration are kept.

In the following example, the admin disconnect command is used to disconnect another active configuration session before the current session can switch to exclusive configuration.

1.4.2.7. Exclusive Private Configuration Session

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

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

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

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

1.4.4.1. Default Values for Key Leafs

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

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

1.4.4.2. Entering Integer Values

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

Integer values are displayed in decimal format, unless a different output format is specified internally by the system.

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

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.

1.4.4.3. Configuring Lists

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

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

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.

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.

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.

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

1.4.4.4. Configuring Leaf-Lists

A leaf-list is an element that contains a sequence of values of a particular data type. Specifying a leaf-list entry in the MD-CLI is additive. New entries are added to existing entries and previous entries are not removed. If a duplicate entry is specified, the order remains. 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.

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

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.

1.4.4.5. Configuring Leafs with Units

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

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:

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

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 timer results in an error display, as 12000 seconds is not in the element range.

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 timer, the system displays valid unit possibilities, listed in alphabetical order.

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

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.

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

Table 14, Table 15, and Table 16 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 14 shows the valid inputs for memory sizes based on the dynamic unit.

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

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

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

1.4.4.6. Flexible Input for MAC and IPv6 Addresses

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

This example shows the hexadecimal digits in an IPv6 address entered in both uppercase and lowercase. IPv6 addresses are displayed in lowercase hexadecimal digits using zero compression, according to RFC 5952, A Recommendation for IPv6 Address Text Representation.

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

Flexible input is also available for MAC addresses using dot (.) notation:

1.4.4.7. Input Translation

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

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

1.4.5.1. Deleting Leafs

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

1.4.5.2. Deleting Containers

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

This example removes the container from context configure aaa diameter:

This example removes the container from context configure aaa:

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.

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.

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

1.4.5.3. Deleting List Entries and Lists

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

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

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.

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

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

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

1.4.7.1. Viewing the Uncommitted Configuration Changes

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

Table 18 provides a description of the compare command options.

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

Note: The +/-/~ output from the compare command can be copied and pasted, or loaded from a file. Refer to section 1.4.7.1.1 for an example.

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

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

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.

When the compare command is executed with url, rollback, or startup for the from or to configuration source option, a temporary private configuration session is used, referred to as a scratchpad session. A scratchpad session requires a resource from a pool of eight available private configuration sessions. Scratchpad sessions are usually short-lived, however, it is possible that a session could consume a private configuration resource for a longer time. The show system management-interface configuration-sessions command displays the active private configuration sessions as well as the active scratchpad sessions.

A CLI warning is generated when the pool of private configuration sessions is exhausted.

1.4.7.2. Discarding Configuration Changes

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

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.

Uncommitted changes from a global configuration session are kept in the candidate configuration when leaving configuration mode. Uncommitted changes from an exclusive or private configuration session are discarded when leaving configuration mode and a confirmation message is displayed:

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.7.3. Validating the Candidate Configuration

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

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.7.4. Updating the Candidate Configuration

As described in Multiple Simultaneous Candidate Configurations, a candidate configuration uses two datastores:

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

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

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

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

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

The following is an example of a merge conflict reported in an update:

The first line lists the candidate configuration change that caused the merge conflict, in this case, adding an interface IPv4 address.

The second line describes the merge conflict and starts with a double hash (##) followed by the description:

An update is automatically started when the candidate configuration is committed. The commit is canceled when merge conflicts are detected to give the administrator the opportunity to resolve the conflicts before committing again. The update, in this case, is not executed, the candidate configuration is unchanged, and the baseline datastore is not updated.

The update check command performs a dry-run update of the candidate configuration. Merge conflicts are reported the same way as for the update command, but the update is not executed. The update check command must be executed at the configuration root (/configure) or it can be executed in any configure branch descendant as update check /configure.

1.4.7.5. Committing the Candidate Configuration

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

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

The update is executed and the commit operation proceeds when no merge conflict is detected. See Updating the Candidate Configuration for the update process.

A validation is subsequently performed on the candidate configuration.

With a successful validation, the changes are copied to the running configuration, which becomes the current, operational router configuration. The candidate configuration is reset to its initial state; an empty candidate datastore and an up-to-date baseline.

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

1.4.7.5.1. Using the commit confirmed Command

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

While the commit confirmed timer is running, the remaining time before an automatic rollback is shown before each prompt of all active MD-CLI sessions.

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

A:admin@node-2# commit confirmed

 

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

(gl)[configure log accounting-policy 5]

A:admin@node-2#

 

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

(gl)[configure log accounting-policy 5]

A:admin@node-2# pwc

Present Working Context:

  configure

  log

  accounting-policy 5

 

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

(gl)[configure log accounting-policy 5]

A:admin@node-2# back

 

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

(gl)[configure log]

A:admin@node-2# accounting-policy 9

MINOR: MGMT_CORE #2604: Commit confirmed in progress - changes to the candidate  configuration are not allowed

 

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

(gl)[configure log]

A:admin@node-2#

 

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

(gl)[configure log]

A:admin@node-2#

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

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

A:admin@node-1# collection-interval 3

 

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

A:admin@node-1# commit confirmed

MINOR: LOG #12: configure log accounting-policy 5 collection-interval - Inconsistent Value error - Minimum value is 5 minutes for this record type.

 

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

A:admin@node-1#

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. If the configuration session from which the commit confirmed was initiated is still active, the candidate configuration maintains all uncommitted configuration changes.

1.4.7.5.1.1. Non-persistent Operation

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

Leaving the configuration mode or logging out from the MD-CLI session cancels the ongoing commit confirmed and starts an automatic rollback. The user must acknowledge the request to exit configuration mode or logout.

*(gl)[]

A:admin@node-2# commit confirmed

INFO: CLI #2090: Commit confirmed - automatic rollback in 10 minutes

(gl)[]

A:admin@test-node# exit all

 

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

(gl)[]

A:admin@test-node# quit-config

INFO: CLI #2095: Commit confirmed in progress - exiting configuration mode will  cancel the commit confirmed and start configuration rollback

 

Cancel commit confirmed and rollback immediately? [y,n] n

INFO: CLI #2076: Exit global configuration mode canceled

 

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

(gl)[]

A:admin@test-node# logout

INFO: CLI #2095: Commit confirmed in progress - logout will cancel the commit  confirmed and start configuration rollback

 

Cancel commit confirmed and rollback immediately? [y,n] y

WARNING: CLI #2077: Exiting global configuration mode - commit confirmed canceled

INFO: CLI #2057: Uncommitted changes are kept in the candidate configuration

1.4.7.5.1.2. Persistent Identifier

Note: In private configuration mode, commit confirmed with a persistent identifier cannot be used. Instead, use the non-persistent commit confirmed command.

A persistence identifier can be specified with the initial commit confirmed command. A commit confirmed accept or cancel command can then be executed from the same or a different MD-CLI configuration 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: Commit confirmed - persist-id expected

 

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

(ex)[configure]

A:admin@node-2# commit confirmed accept

MINOR: MGMT_CORE #2603: Commit confirmed - persist-id expected

 

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

(ex)[configure]

A:admin@node-2# commit confirmed cancel persist-id my-commit

 

*(ex)[configure]

A:admin@node-2#

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

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

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.

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

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

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

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.

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

1.4.11.1. Creating Configuration Groups

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

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

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

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

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.

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

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

1.4.11.3. Inheritance Rules

Local configuration elements have precedence over configuration group inheritance.

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

The resulting expanded configuration after inheritance is shown as follows:

Up to eight configuration groups can be applied to a configuration branch. The configuration order determines the inheritance 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.

The resulting expanded configuration after inheritance is shown as follows:

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.