Nokia SR Linux CLI Basics: Modes, Commit and Verification - 夜莺博客

Nokia SR Linux CLI Basics: Modes, Commit and Verification

Nokia's SR Linux borrows the best habit of Junos — a candidate configuration you commit explicitly — and adds a model-driven CLI that understands the YANG schema underneath it. For anyone arriving from IOS or EOS the first hour is disorienting; after that, the CLI is one of the most predictable in the industry because it refuses to accept configuration that the data model does not define.

The two modes you live in

A:srl1# enter candidate
A:srl1# set / interface ethernet-1/1 admin-state enable
A:srl1# set / interface ethernet-1/1 subinterface 0 ipv4 address 10.0.0.1/30
A:srl1# commit now
A:srl1# exit all

enter candidate opens the candidate datastore. Nothing you type affects traffic until commit now. commit stay commits and remains in the candidate, and discard stay throws the candidate away — the fastest way to back out of a bad idea.

Reading configuration and state

A:srl1# info                                 # candidate diff
A:srl1# info / interface ethernet-1/1
A:srl1# info from state / interface ethernet-1/1
A:srl1# show version
A:srl1# show interface brief
A:srl1# show network-instance default protocols bgp neighbor

The distinction between info (configuration) and info from state / show (operational state) is the single most useful concept in the CLI. When someone reports "the config is there but nothing works", reading the state tree at the same path shows which of the two is lying.

The path syntax is the schema

A:srl1# tree / interface ethernet-1/1
A:srl1# tree / network-instance default protocols bgp
A:srl1# set / network-instance default protocols bgp
     admin-state enable
     autonomous-system 65001

Because paths map directly onto YANG modules, tree doubles as documentation: it enumerates exactly what may be configured at that node. This is why SR Linux rejects a typo instead of silently creating a meaningless leaf the way a flat CLI would.

Output formats and automation

A:srl1# show interface brief | as json
A:srl1# show network-instance default route-table | as table
A:srl1# info | as yaml

Every command can emit JSON, which means the same CLI an engineer uses interactively is the data source a script consumes — no screen-scraping and no TextFSM templates. Combined with gNMI, that makes SR Linux unusually friendly to intent-driven and telemetry-based workflows.

Where it differs from what you know

  • No configure terminal and no automatic save: configuration lives in a datastore that is committed and then persisted to the startup configuration.
  • Interfaces are named ethernet-1/1 with subinterface children — an L3 address belongs on a subinterface, not on the port.
  • Network instances replace the global routing table; everything routing-related is scoped to a network instance.

Related reading: Geneve vs VXLAN encapsulation, SuzieQ network observability, SDN controllers: ONOS vs OpenDaylight.

原文链接:https://documentation.nokia.com/srlinux/24-7/books/system-mgmt/general-operational-commands.html