Nokia NRS II: IP network automation

The exam tests model-driven management of SR OS: how configuration and state are exposed through YANG, and how operators automate with NETCONF, gNMI, SNMP and Python instead of the CLI. Expect questions on datastores, transactions, telemetry and Nokia NSP.

Core rules

• MD-CLI is model-driven; its commands mirror the YANG tree and can be emitted as JSON or set-format commands.
• NETCONF uses SSH transport, XML encoding, and datastores: running, candidate, startup. Changes go to candidate, are validated, then committed.
• confirmed-commit rolls back automatically if not confirmed within the timeout.
• gNMI provides Get, Set and Subscribe over gRPC; Subscribe streams telemetry (operational state) rather than polling.
• SNMP remains for fault/performance polling and traps but is not a configuration model.
• NSP provides orchestration, templates and intent-based workflows across the network.

Worked example

An operator pushes a new interface with NETCONF: <edit-config> targets the candidate datastore with the interface container, then <validate> and <commit>. If the change should auto-revert, the commit carries confirmed and a timeout; the operator sends <commit> again to confirm. The same change via gNMI Set uses paths such as /configure/router/interface[name=to-pe2].

Traps

• Editing the running datastore directly, bypassing validation and rollback.
• Assuming gNMI Set is transactional in the same way as a NETCONF candidate commit; behavior depends on implementation and should be verified.
• Forgetting that YANG paths are case- and key-sensitive: interface[name=...].
• Using SNMP sets for configuration on modern SR OS instead of model-driven interfaces.
• Ignoring telemetry sample interval and subscription mode (once, poll, stream).