Scenario Based Southbound Netconf/CLI Device Simulator

This simulator is a more advance version of the netsim that is used to simulate NSO Southbound Netconf/CLI device communications. The goal is to benifit the troubleshooting process for device dependent issue or construct pre-production test cases that require actual southbound devices to send specific communication sequence. By setting the expected substring in the reply and construct reply message back to the NSO, this simulator can simulate the actual device communication makes up the gaps that Netsim currently cannot be done.

Usage

Generate Key

Generate the SSH key before starting up the server

make key_gen

Define Payload

In the payload folder container the payload required to sent under different scenario. The payload now support both CLI and Netconf XML format. The information that required to populate the config below can be extracted from NED Trace with "trace raw" enabled.

• The reply sequence is defined in the payload.json. Inside payload.json, one can find "prepare" and "handler". "prepare" is only needed for CLI device for initial prompt right after connect the SSH connection. For example

Press any key to continue (Q to quit)
Username:
Password:

Inside "prepare" the sequence looks like the example below

   "prepare":
        {
            "reply_payload": ["example/alu-sr-cli/prep.cli","example/alu-sr-cli/prep_username.cli"],
            "spliter": "\n\n"
        },

• The usage of the "prepare" is as below
  • "reply_payload" - The payload that will be used to send back to the device. The payload is defined as XML in ./payload. For Netconf device, payload is defined as .xml. If CLI device is used, one can use .cli format of the file in ./payload to contain the reply from the CLI.
  • "spliter" - ending string. Can be "\n]]>]]>" or "\n##" based on RFC-6242. For CLI devices, leave this settings as empty - "".

While "handler" is for communication after initial prompt. "handler" is required for both CLI and Netconf devices. Inside, "handler" each reply sequence looks something like below

"hello":{
            "recv_signature": "<hello xmlns",
            "reply_payload": "example/juniper-junos/hello.xml",
            "spliter": "\n]]>]]>"
        }, 

• The usage of the Payload is as below

  • "hello" - name of the sequence
  • "recv_signature" - when the substring in "recv_signature" is included in the message from the device, current reply sequence is activated. For Netconf, we recommend to use the signature that can define what kind of message is it. For CLI, we recommend to use the actual command that was sent from NSO.
  • "reply_payload" - The payload that will be used to send back to the device. The payload is defined as XML in ./payload. For Netconf device, payload is defined as .xml. If CLI device is used, one can use .cli format of the file in ./payload to contain the reply from the CLI.
  • "spliter" - ending string. Can be "\n]]>]]>" or "\n##" based on RFC-6242. For CLI devices, leave this settings as empty - "". The current version of payload.json that is under the root folder shows a example of simulating both netconf and CLI devices.

• Modify the payload in the payload folder. This folder container message you would like to send when specific message is received and correalte to "reply_payload" in payload.json. By default, this folder is full of XML file that designed to interact with Juniper devices via Netconf. For CLI devices, change the content to .cli format and modify the payload.json as mentioned above.

payload$ tree -L 1
.
├── close.xml
├── commit.xml
├── discard_changes.xml
├── edit_config.xml
├── get.xml
├── get_config.xml
├── get_software_information.xml
├── hello.xml
├── lock.xml
└── request_package_add.xml

0 directories, 10 files

Inside "payload/example" folder shows the payload example to interact Junos with Netconf(.xml) and ALU with CLI(.cli). For CLI device, the payload must using CRLF as line break between the config with LF as line break behind the prompt(for example, cisco@cisco# ). Because LF simulate a enter after each command while CRLF is used as linebreak of the output between the lines.

Adjust Settings

Modify config.json and define how would you like the simulator to run.

{
    "settings": {
        "host":"0.0.0.0",
        "port":12022,
        "username":"admin",
        "password":"cisco123",
        "host_key": "./key/server_host.key"
    }
 }  

• "host" - Simulator assigned IP address.
• "port" - Assigned Port
• "username"/"password" - credential for the simulated device
• "host_key" - which key to used as SSH host key of the simulated device. Only RSA is supported at moment.

Start up the server

Startup the server with

make start

The simulator will wait at the following stage until the remote client side send in any specfic messages.

$ make start
python ssh_server.py
Host key generated: ./key/server_host.key
[*] SSH server listening on 0.0.0.0:12022
[*] Login with username='admin', password='admin'

Construct Test Cases with Lux

Lux (LUcid eXpect scripting) is a test automation framework with Expect style execution of commands.One can use Lux to easily construct Network Test Cases under various of scenarios.

Clone/copy the simulator beside your Lux test cases. For example as netconf_sim. Than add the following chapter in the lux to interact with NSO southbound

[shell mock_device]
    !cd netconf_sim;python ssh_server.py
    ???Login with

during cleanup. Do the following to exit the simulator

[shell mock_device]
    ~${_CTRL_C_}

Copyright and License Notice

Copyright (c) 2026 Cisco and/or its affiliates.

This software is licensed to you under the terms of the Cisco Sample
Code License, Version 1.1 (the "License"). You may obtain a copy of the
License at

               https://developer.cisco.com/docs/licenses

All use of the material herein must be in accordance with the terms of
the License. All rights not expressly granted by the License are
reserved. Unless required by applicable law or agreed to separately in
writing, software distributed under the License is distributed on an "AS
IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express
or implied.