Committing a Configuration

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

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

 compare [[from] <string>] [[to] <string>] [[cli-path] <path>]

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

    Source configuration from which to compare

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

    Configuration to compare against source configuration

 [cli-path] <path>
 <path>  - <absolute or relative from pwc>

    Absolute path or relative path from pwc

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

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

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

• + (plus) — element is only in the second (to) configuration, displayed second

• (space) — element is unchanged

• ~ (tilde) — new value of the element that changed (only used in the summary option)

• {...} — deleted elements compressed to its highest container (only used in the summary option)

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

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

*(ex)[/configure]
A:admin@node-2# compare to running

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

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

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

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

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

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

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

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

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

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

An error is displayed when the discard operation is attempted from read-only configuration mode.

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

*(ro)[/configure]
A:admin@node-2# discard
MINOR: CLI #2069: Operation not allowed - currently in read-only mode

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

*(ex)[/]
A:admin@node-2# quit-config
INFO: CLI #2063: Uncommitted changes are present in the candidate configuration.    
Exiting exclusive configuration mode will discard those changes.

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

The discard command accepts a path parameter on the input line to discard candidate changes starting from the specified path. If a path is not specified, the command discards candidate changes from the present working context.

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

 discard [[cli-path] <path>]

 [cli-path] <path>
 <path>  - <absolute or relative from pwc>

    Absolute path or relative path from pwc

In the following example, from the configure system context, the configure router ‟Base” bgp candidate changes can be discarded by specifying the absolute path.

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

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

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

From the configure system context, issuing the discard command without a path parameter removes candidate changes starting from the configure system context (the present working context).

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

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

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

Changes made by a session that obtained an explicit lock can be discarded 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.

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

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

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

*(ro)[/]

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

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

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

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

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

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

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

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

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

• when a manual update is performed

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

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

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

  • after a router reboot

  • after a successful commit

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

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

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

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

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

• the candidate configuration changes are merged in the new baseline:

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

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

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

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

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

+   /configure router "Base" interface "int-1" ipv4 primary address 10.2.3.4
##  address - exists with different value: address 10.1.2.3 - change updated: replace existing value

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

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

• A merge conflict is detected for the configuration element address.

• The address already exists in the running configuration, but has a different value.

• The candidate configuration change as shown on the first line is updated; instead of adding an interface address, the interface address is replaced.

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

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

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

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

 commit

 confirmed             + Require explicit confirmation for changes to apply[ex:/configure]

[ex:/configure]
A:admin@node-2# commit confirmed ?

 confirmed

 [timeout] <number>
 <number>  - <1..65535>  - minutes
 Default   - 10

    Commit expiration timeout interval

 persist-id            - Persistent confirmed commit ID

 Choice: confirmed-choice
 accept               :- Confirm an ongoing confirmed commit
 cancel               :- Cancel an ongoing confirmed commit issued and roll back
 [timeout]            :- Commit expiration timeout interval

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

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

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

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

A validation is subsequently performed on the candidate configuration.

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

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