NISH client

The NISH client provides an MD-CLI interface to multiple SR OS nodes. The NISH client uses the model-driven networking capabilities built into SR OS to identify the software version and obtain the MD-CLI schema for each SR OS node. This allows the NISH MD-CLI to generate the correct CLI tree that can be navigated within each SR OS node context. It also ensures that each node context is specific to its own software version.

The NISH client also allows the operator to issue Linux commands on the local machine, without leaving the MD-CLI shell. This capability provides increased productivity during extended management activities.

When launched, the NISH client provides an extensible MD-CLI interface. After the trademark, legal, and disclaimer information, NISH displays the following.

Starting nish application...
admin's password:
Connecting to test1 port 57400
!!! Creating unsecure connection !!!
 
Reading MD-CLI service capabilities...
 
Reading MD-CLI service event context...
[==============================================================================]
 
Reading MD-CLI service schemas...
[==============================================================================]
 
[]
A:admin@test1# ?
 
 admin                 + Enter the admin context
 configure             + Enter the configuration context
 environment           + Enter the environment configuration context
 file                  + Enter the file management context for file operations
 li                    + Enter the lawful intercept context
 password              - Change password command
 state                 + Show state information
 
 Global commands:
 back                  - Move back one or more levels
 delete                - Delete an element from the candidate datastore
 edit-config           - Enter a candidate configuration mode
 enable                - Enable administrative mode
 exec                  - Execute commands from a file
 exit                  - Return to the previous working context or to the → 
operational root
 history               - Show the most recently entered commands
 logout                - Exit the CLI session
 oam                   - Enter the oam context
 ping                  - Ping an IP address or DNS name
 pwc                   - Show the present working context
 ssh                   - Execute ssh command
 telnet                - Telnet to IP address or DNS name
 top                   - Move to the top level of the context
 traceroute            - Trace route to a destination
 tree                  - Show the command tree under the present working context

[]
A:admin@test1#

Beginning in Release 21.5.R1, the NISH client supports up to two prior SR OS major releases. This backwards compatibility is effective from SR OS Release 20.10.R1. As a hypothetical example, the NISH client instance with a version number 23.5.R1 supports SR OS Release 21.2.R1 and later.

The NISH client ensures that the SR OS version of the device that it connects to conforms to the supported release interval. If the SR OS version is outside the supported range, the client fails to connect and provides an error message.

Navigating in the NISH client MD-CLI interface is similar to navigating in the MD-CLI interface directly attached to a node. The NISH MD-CLI provides a YANG model-aware tree structure generated by the SR OS. Users can navigate the tree structure using the tree, back, top, and exit commands, enter a branch by typing the branch name into the CLI, and enter a list by typing the list name and key.

See the 7450 ESS, 7750 SR, 7950 XRS, and VSR MD-CLI User Guide, for more information about navigating in MD-CLI.

Context-sensitive help and auto-completion are supported within the NISH MD-CLI.

The Linux man pages provide usage assistance for NISH; see Accessing the Linux man pages for more information about how to access Linux man pages.

Unlike operating directly in MD-CLI, the NISH MD-CLI provides a hybrid shell that allows users to execute Linux commands directly on the local workstation, without leaving the MD-CLI shell. This provides a flexible working environment for managing multiple nodes.

The following example shows output of a configure system setup, with execution of both Linux and MD-CLI commands.

(pr)[configure system]
A:admin@test1# ls -la
total 96
dr-xr-x---.  7 root root  4096 Jun 11 13:06 .
dr-xr-xr-x. 18 root root   261 Apr 15 13:21 ..
-rw-------.  1 root root  1860 Apr 15 12:00 anaconda-ks.cfg
-rw-------   1 root root 21113 Jun 11 13:06 .bash_history
-rw-r--r--.  1 root root    18 May 11  2019 .bash_logout
-rw-r--r--.  1 root root   176 May 11  2019 .bash_profile
-rw-r--r--   1 root root   290 May 11 18:24 .bashrc
drwx------   4 root root    32 May 22 12:30 .cache
drwx------   3 root root    18 Apr 15 15:44 .config
-rw-r--r--   1 root root     0 May 22 11:04 config
-rw-r--r--.  1 root root   100 May 11  2019 .cshrc
drwxr-xr-x   2 root root    25 May  6 17:23 .docker
-rw-r--r--   1 root root    62 May  6 13:06 .gitconfig
-rw-------   1 root root    97 Jun  1 14:58 .lesshst
lrwxrwxrwx   1 root root    23 Apr 15 13:28 misc_vol -> /media/gluster/misc_vol
-rw-------   1 root root     0 Jun  4 12:16 .python_history
-rw-r--r--   1 root root 30123 May  6 16:14 screenlog.0
drwx------   2 root root    57 May  6 13:26 .ssh
-rw-r--r--.  1 root root   129 May 11  2019 .tcshrc
-rw-------   1 root root   533 Apr 15 14:50 .viminfo

(pr)[configure system]
A:admin@test1# cat .bashrc
# .bashrc

# User specific aliases and functions
alias rm='rm -i'
alias cp='cp -i'
alias mv='mv -i'

# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc

fi

If a command exists in both the MD-CLI and the Linux shell, the MD-CLI command takes precedence. This is shown in the following output example, which uses the time command.

(pr)[configure system]
A:admin@test1# time echo ‟hello world”
                    ^^^^
MINOR: MGMT_CORE #2201: Unknown element - 'echo'
(pr)[configure system]
A:admin@test1# time 
(pr)[configure system time]
A:admin@test1# time echo ‟hello world” 
"hello world"
0.00user 0.00system 0:00.00elapsed 93%CPU (0avgtext+0avgdata 1944maxresident)k
0inputs+0outputs (0major+84minor)pagefaults 0swaps

(pr)[configure system time]
A:admin@test1#

The NISH MD-CLI provides the ability to see and edit individual router configurations using the transactional configuration modes available in MD-CLI (private, exclusive, global, and read-only).

The following example shows this ability.

[]
A:admin@test1# edit-config private
INFO: CLI #2070: Entering private configuration mode
INFO: CLI #2061: Uncommitted changes are discarded on configuration mode exit

(pr)[]
A:admin@test1# configure system

(pr)[configure system]
A:admin@test1# name example

*(pr)[configure system]
A:admin@test1# compare
-   name "test1"
+   name "example"

*(pr)[configure system]
A:admin@test1# commit

(pr)[configure system]
A:admin@example#

The NISH MD-CLI provides the ability to obtain the operational state of the SR OS node, using the info command within the state tree, as shown in the following example.

[]
A:admin@example# /state

[state]
A:admin@example# system

[state system]
A:admin@example# info | match oper-name
    oper-name "example"

The NISH installation process performs the following activities:

• installs the NISH client into /usr/bin/nish

• installs the End User License Agreement (EULA) in /usr/share/licenses/nish/EULA

• installs an example connections file in /etc/nish/connections

• installs an example local schema file in /etc/nish/local-schema

• installs the global NISH run commands (rc) file into /etc/nish/nishrc

• installs the Linux man pages for the nish command

See Connections file, Local schema file, and NISH rc files, respectively, for more information about connections, local schema files, NISH rc files, and the features they support.

See Installing the NISH client for the procedure to install the NISH client.

The exclusive candidate configuration mode is the only supported candidate configuration mode for NISH client multinode operation.

To access the exclusive candidate configuration mode, use the explicit edit-config exclusive command or the implicit configure exclusive command.

When the operator tries to access the exclusive candidate configuration mode within a multinode context, the NISH client attempts the following actions:

1. connects to each SR OS node prompting for authentication credentials, if required

2. obtains an exclusive lock on all the nodes

A warning is displayed for every node for which the NISH client cannot obtain an exclusive lock. The operator can optionally continue the configuration activities with the remaining nodes or exit from configuration mode.

A list of the nodes for which the NISH client has successfully obtained an exclusive candidate configuration lock is stored in memory, and the MD-CLI configuration commands are executed against this set of nodes.

When the operator is presented with the exclusive configuration mode, the prompt changes. When the operator leaves the exclusive configuration mode, all candidate configurations on all nodes are discarded.

The NISH client can perform the info operation on multiple SR OS nodes that share a specific device-label grouping.

If the output is identical on all the SR OS nodes in the device-label group, the info operation displays a single copy of the output.

If any of the output differs, the NISH client displays the SR OS node output with a banner separating the output of each node.

The NISH client can execute many SR OS operations on multiple SR OS nodes that share a specific device-label group.

The NISH client obtains details of the MD-CLI schema from each node in the device-label group and builds a combined schema. The generated combined schema includes all the fields that are common between the SR OS devices, along with the most restrictive set of validation rules. The NISH client then uses this combined schema for functions such as configuration, info, and compare, that are performed for the device-label group.

The NISH client can perform a compare operation on multiple SR OS nodes that share a specific device-label group. The multinode compare operation uses the combined schema; see Multinode combined schemas for more information.

If the output is identical on all the SR OS nodes in the device-label group, the compare operation displays a single copy of the output. If any of the node outputs differ, they are displayed separately with a banner between the output of each node.

The NISH client can interactively configure multiple SR OS nodes that share a specific device-label group. Interactive configuration of multiple SR OS nodes uses the combined schema. This means that only configuration options that can be applied to all nodes in the group are available to the operator. Context-sensitive help and auto-completion are supported using the combined schema. See Multinode combined schemas for more information.

When you configure multinode interactive mode, the NISH client immediately places entries into the exclusively locked candidate configuration of every SR OS node in the group. Exiting the interactive configuration mode of a device-label group releases the exclusive lock on all devices that are part of the group. In-progress configuration changes that are stored in the candidate configuration but not committed are lost.

Only one device-label group at a time can hold the configuration lock. If the operator attempts to obtain a configuration lock from another device-label group, the system issues a prompt to release the previous lock. When the system releases the lock, all uncommitted configuration changes are discarded.

The NISH client provides the ability to provision a template-based configuration on multiple SR OS nodes with a specific device-label grouping. This operation is completed using the MD-CLI load command.

When using the load command within NISH for multinode configuration, the merge and full-replace options are supported. The referenced configuration file supplied to the load command must be accessible from each individual SR OS node within the addressed set of nodes, unless it is prefixed with the URL prefix nish://. When nish:// is used, the relative or absolute path or filename that follows nish:// is treated as local to the NISH client.

The following table describes examples of the supported file URL options that can be used to reference the configuration template file when using the load merge and load full-replace commands for multinode configuration from the NISH client. In the examples, a configuration file called myconfig.cfg is referenced.

The NISH client supports rollback of configuration changes on multiple nodes at the same time, using the rollback command. Issuing the rollback command from a multinode context in the NISH client causes every node in the group to attempt to roll back to the specified checkpoint. If all the nodes successfully roll back to the specified checkpoint, the operation completes successfully. If any node in the group cannot roll back, the command fails and none of the nodes roll back.

Committing configuration changes in a multinode environment from the NISH client is an atomic operation. This means that at the end of a commit operation for a specified set of nodes, every node successfully commits the configuration or all the nodes return to their configuration state before the commit.

To commit a configuration change in a multinode group, every node in the group must have automatic saving of configuration changes enabled in the MD-CLI. This is enabled by configuring the auto-config-save command in the configure system management-interface cli md-cli context on each device and committing this configuration change. The multinode commit process driven from the NISH client uses standard MD-CLI features to achieve the atomic commit. The two phases in the multinode commit operation are as follows:

1. conditional commit and validation phase (commit confirmed command)

2. confirmation phase (commit confirmed accept command)

At each stage, the nodes are processed in turn to ensure they are all in the expected state before the next stage.