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.

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:

4.1.3. Implicit and Explicit Configuration Workflows

The MD-CLI supports two configuration workflows:

Table 15 compares the implicit and explicit configuration workflows.

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 

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

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.

Note: Private configuration mode should not be used in the MD-CLI when the router is also configured using NETCONF or gRPC for the following reasons: private candidate configurations are not visible over NETCONF or gRPC an equivalent function of the MD-CLI update command to manage an out-of-date baseline is not available in NETCONF or gRPC

4.2.3. Exclusive Configuration Mode

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

An exclusive configuration session has the following characteristics:

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.

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.

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.

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.

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:

4.2.8. Restricting Configuration Mode Sessions

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

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

In this example, the user pr-user has profile admin-private. Entries 3 and 4 in the local profile effectively deny users in the admin-private profile from entering the exclusive configuration mode in the MD-CLI.

The following additional entries to the profile deny users from entering the global configuration mode in the MD-CLI.

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:

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 the following example of a command with a union of data types, the pir command can have an integer value or it can be defined with the max enumerated value. If a numerical value is entered for pir, it must be entered as a decimal number.

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, the key name for ma-admin-name 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.

4.4.4. Configuring Leaf-Lists

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

Single or multiple leaf-list entries can be added in a single command line with the use of brackets ([]).

4.4.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 900 (deciseconds) for transmit-interval results in an error display, as 990 deciseconds 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 900 for transmit-interval, 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 17, Table 18, and Table 19 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 17 shows the valid inputs for memory sizes based on the dynamic unit.

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

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

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

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:

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.

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.

4.5.2. Deleting Containers

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

This example removes the instance from context configure service vprn:

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

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

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

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.

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

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

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.

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.

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.

4.7.5. Committing the Candidate Configuration

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

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

When a commit operation is initiated while the baseline is out-of-date, the router first attempts to update the candidate configuration. 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.

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-2# collection-interval 3

 

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

A:admin@node-2# commit confirmed

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

 

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

A:admin@node-2#

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

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

A:admin@node-2# commit confirmed

 

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

(ex)[configure log accounting-policy 5]

A:admin@node-2# commit confirmed 33

 

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

(ex)[configure log accounting-policy 5]

A:admin@node-2#

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

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

4.7.5.1.1. Non-persistent Operation

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

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

*(ex)[]

A:admin@node-2# commit confirmed

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

(ex)[]

A:admin@test-node# exit all

 

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

(ex)[]

A:admin@test-node# quit-config

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

 

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

INFO: CLI #2076: Exit global configuration mode canceled

 

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

(ex)[]

A:admin@test-node# logout

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

 

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

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

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

4.7.5.1.2. Persistent Identifier

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

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

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, cf3:\testbgp.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 also be copied into a file.

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

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.

4.11.1.2. Regular Expression Match

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

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

(ex)[configure]

A:admin@pe1# info

    groups {

        group "isis-backbone" {

            router "Base" {

                isis "0" {

                    interface "<.*>" {

                        interface-type point-to-point

                    }

                }

            }

        }

    }

4.11.1.2.1. Regular Expression Match Format

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

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

The regular expression is a subset of the Extended Regular Expression (ERE) notation as described in section 3.12.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

Note: A regular expression match on an encrypted leaf is restricted to a match all: “<.*>”. Any other string enclosed in angle brackets (“<string>”) is accepted as an exact match for the encrypted leaf and displayed as a hashed value in the configuration.

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

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.

The resulting expanded configuration after inheritance is shown as follows:

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

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

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

Use the regular expression pattern match info inheritance | match '^[ ]*##' invert-match to suppress the system comments in the output of info inheritance.

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.

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

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

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

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

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

The same entry prohibits configuration group inheritance for user admin2.

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

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

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

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

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

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

The resulting expanded configuration after inheritance is shown as follows:

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

4.11.7. Caveats

The following caveats apply to configuration groups.

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

4.12.1. Unlocking a Locked Datastore

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

admin disconnect session-id session-id

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

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