5.3 Model-Driven CLI (MD-CLI) and Datastore Management

Configuration as a transaction

The Model-Driven Command Line Interface (MD-CLI) uses SR OS data models and a candidate configuration. The current Nokia IP Networks and Services Fundamentals course uses MD-CLI for its exercises. Learn its workflow directly rather than translating Classic commands word by word.

The running configuration governs the active device. A candidate holds proposed edits. Editing a candidate does not activate the proposed interface, route, or service. A successful commit applies accepted changes to running configuration. Persistence is another concern: a restart loads the saved configuration selected by boot settings.

A BOF is not the entire running service configuration. Likewise, an enabled configuration leaf does not prove an interface is operationally Up.

Enter and inspect a candidate

MD-CLI supports private, exclusive, and global configuration modes. A private workspace separates an operator's edits from another private candidate, but concurrent changes can still require reconciliation at commit. Exclusive mode obtains the configuration lock used by its workflow. Global mode shares a candidate, so an operator must understand whose edits are present before committing.

An implicit private workflow can begin with:

configure private
/configure system name "R1-lab"
compare
validate
commit

This changes an illustrative system name. It is a command example, not evidence that a router was configured during this review. compare shows differences against the relevant baseline/running configuration. validate checks candidate constraints; commit activates a valid transaction. discard abandons pending changes according to the selected workflow. Use help to check scope before discarding shared work.

Validation cannot know whether a chosen IP address belongs to the intended customer or whether a remote peer has matching configuration. A schema-valid change can still be operationally wrong.

Read the prompt correctly

The MD-CLI prompt normally spans two lines. The context line identifies configuration mode and location; the following line identifies the user and router. In an implicit workflow, a context can resemble [pr:/configure router "Base"].

The mode indicators are pr for private, ex for exclusive, gl for global, and ro for read-only. A leading * indicates uncommitted candidate changes. An exclamation mark ! indicates an out-of-date baseline. It is not the exclusive-lock symbol: ex identifies exclusive mode.

If another session changes running configuration, a candidate's baseline may become stale. Inspect differences and use the documented update/reconciliation workflow. Do not clear a warning by blindly discarding changes or assuming exclusive mode solves an already-stale comparison.

Configure a Layer 3 interface

A physical port and a named IP interface are different objects. The port provides connectivity; the IP interface supplies Layer 3 addressing and binds to a port or LAG. A system interface is a logical endpoint normally assigned a unique /32 IPv4 address in this course's examples.

The following MD-CLI fragment assumes supported hardware and an already enabled network port 1/1/1. Enter configuration mode first.

/configure router "Base" interface "system" ipv4 primary address 10.10.10.1
/configure router "Base" interface "system" ipv4 primary prefix-length 32
/configure router "Base" interface "to-R2" port 1/1/1
/configure router "Base" interface "to-R2" ipv4 primary address 192.0.2.1
/configure router "Base" interface "to-R2" ipv4 primary prefix-length 30
/configure router "Base" interface "to-R2" admin-state enable
compare
validate
commit

The address and prefix length are separate modeled leaves. Do not append Classic address 192.0.2.1/30 syntax to this MD-CLI path. The peer can use 192.0.2.2/30; 192.0.2.0 is the subnet and 192.0.2.3 is its conventional broadcast address.

After commit, inspect /show router interface, /show router route-table, and /show router arp. The local connected prefix should appear when the interface is operational. A missing ARP response is a separate issue from candidate validation. An operational interface still needs correct routing and a working return path to reach remote destinations.

Activation, saving, and recovery

commit applies changes to running configuration. The auto-config-save setting can save automatically after a successful commit. When automatic saving is disabled, use /admin save to persist the committed running configuration to its startup location. Inspect the actual setting and BOF instead of assuming that every successful commit was saved.

A confirmed commit provides automatic rollback unless accepted within its configured window. It can help protect remote changes, but it does not replace a recovery path or prove the proposed routing policy is correct. A commit may legitimately flap an interface or restart a protocol whose configuration changed; transactional configuration is not a universal “hitless” guarantee.

Rollback checkpoints and loading an older configuration also require care. In MD-CLI, a rollback can load earlier configuration into the candidate for comparison and commit. Do not treat a Classic admin rollback revert example as an interchangeable MD-CLI candidate command.

For lab review, record four outcomes separately: the candidate validates, the commit succeeds, the intended operational state appears, and the intended startup configuration is saved. This prevents the common mistake of checking only the command's success message.

Primary references

Nokia MD-CLI prompt documentation and configuration editing and saving, checked October 20, 2026. Use the matching release reference for additional features.