NHPREP — Hands-On CCNA, CCNP, CCIE Labs & Networking Courses

Objective

In this lesson you will add network devices to the NSO controller, perform configuration synchronization (sync-from) so NSO stores the device running-config, and demonstrate basic multi-vendor device onboarding using NETCONF and RESTCONF. This matters in production because a centralized change-management system must have an accurate, authoritative copy of device configuration before making changes or automating upgrades. Real-world scenario: an operator adds a set of heterogeneous routers to NSO to prepare for a mass software upgrade workflow — NSO must first learn device connectivity and fetch running-configs so the workflow can validate compatibility.

Quick Recap

This lesson continues from Lesson 1. The NSO controller and a management network already exist. We add and sync two new devices:

NSO controller: 10.0.0.10 (management)
Device R1 (IOS-style device via NETCONF): 10.0.0.11
Device XR1 (XR-style device using NETCONF): 10.0.0.12

(If these devices were already present in your topology from Lesson 1, reuse the same IPs and credentials shown below.)

ASCII Topology (management plane)

[ NSO Controller ]
  mgmt0: 10.0.0.10
      |
      | (NETCONF port 830)
      |
+----------------+                      +----------------+
| Device R1      |                      | Device XR1     |
| (IOS-style)    |                      | (XR-style)     |
| eth0: 10.0.0.11|                      | eth0: 10.0.0.12|
+----------------+                      +----------------+

Device credentials (used in examples)

Username: admin
Password: Lab@123
Domain (for REST examples): lab.nhprep.com
Organization: NHPREP

Key Concepts

Device Onboarding (Configuration in NSO): You register a device object inside NSO describing address, port, credential, and device type (NETCONF/CLI). This allows NSO to open a management session and perform RPCs. In production, correct device-type and credentials are essential — misclassification can prevent NSO from using the proper NED (device adapter).
- Protocol behavior: When NSO connects via NETCONF port 830, the device and NSO exchange messages to advertise capabilities and session-id; capabilities determine what configuration models are available.
sync-from (Configuration Synchronization): A sync pulls the device running configuration into NSO’s datastore. This is critical before orchestration so NSO has a local authoritative copy to diff, validate, and plan changes.
- Packet flow: NSO performs NETCONF RPCs (or equivalent CLI NED calls) to retrieve configuration. The controller parses and stores the result in its configuration datastore.
Multi-vendor management: NSO uses device-specific adapters (NEDs) to map native CLI/NETCONF into a uniform data model. When managing mixed vendors, ensure the right NED (device-type) is selected; otherwise translation or config pushes can break device behavior.
RESTCONF vs NETCONF access to NSO: NSO exposes northbound RESTCONF APIs for automation clients. RESTCONF clients authenticate and then fetch or push configuration which NSO translates into device actions. In production this is how CI/CD pipelines or workflow engines invoke device changes.

Tip: Think of NSO as a librarian — you must add (catalog) each book (device) and then let the librarian read (sync) the full contents before you can safely edit or rearrange pages (config changes).

Step-by-step configuration

Step 1: Add Device R1 (NETCONF) to NSO via CLI

What we are doing: We create a device entry for R1 in NSO so the controller knows the management address, port, and credentials, and can attempt a NETCONF connection. This is the essential first step so NSO can open a NETCONF session and learn the device's capabilities.

admin@ncs# config
admin@ncs(config)# devices
admin@ncs(config-devices)# device R1
admin@ncs(config-device-R1)# address 10.0.0.11
admin@ncs(config-device-R1)# port 830
admin@ncs(config-device-R1)# username admin
admin@ncs(config-device-R1)# password Lab@123
admin@ncs(config-device-R1)# device-type netconf-cli
admin@ncs(config-device-R1)# commit
admin@ncs(config-device-R1)# exit
admin@ncs(config)# exit

What just happened: The commands created a device object named R1 with management address 10.0.0.11 on NETCONF port 830, and stored credentials. Setting device-type netconf-cli tells NSO to use the NETCONF adapter/NED. The commit persists the configuration in NSO. When NSO next attempts to communicate it will open a TCP session to 10.0.0.11:830 and exchange NETCONF capability messages.

Real-world note: On a real network, ensure IP reachability and that device NETCONF is enabled (and that any management ACLs allow NSO's IP). Failure to do so is the most common onboarding issue.

Verify:

admin@ncs# show devices device R1
device R1
  address: 10.0.0.11
  port: 830
  username: admin
  device-type: netconf-cli
  admin-state: unlocked
  operational-state: disconnected
  last-updated: 2026-04-02T10:15:00Z

Explanation of output: The important fields are operational-state (should become connected after a successful connection) and the address/port confirming NSO will attempt NETCONF sessions to the right endpoint.

Step 2: Add Device XR1 (XR-style NETCONF) to NSO

What we are doing: Repeat the onboarding process for a second device, XR1. This shows multi-vendor management where XR1 uses a different device-type (for example, an XR-specific NETCONF NED). Proper labeling ensures NSO uses the appropriate translation layer.

admin@ncs# config
admin@ncs(config)# devices
admin@ncs(config-devices)# device XR1
admin@ncs(config-device-XR1)# address 10.0.0.12
admin@ncs(config-device-XR1)# port 830
admin@ncs(config-device-XR1)# username admin
admin@ncs(config-device-XR1)# password Lab@123
admin@ncs(config-device-XR1)# device-type netconf-xr
admin@ncs(config-device-XR1)# commit
admin@ncs(config-device-XR1)# exit
admin@ncs(config)# exit

What just happened: A device object XR1 is created using device-type netconf-xr. This tells NSO to expect XR-style NETCONF capabilities and use the XR NED mapping. The commit stores the entry. NSO will attempt NETCONF capability exchange with 10.0.0.12.

Real-world note: Onboarding devices with different operating systems requires correct NED selection. If you use the wrong NED, NSO may still connect but fail to parse or construct proper configs.

Verify:

admin@ncs# show devices
Device Name: R1
  address: 10.0.0.11
  operational-state: disconnected
Device Name: XR1
  address: 10.0.0.12
  operational-state: disconnected

Wait until the controller reaches out; operational-state will change to connected once NETCONF exchange completes.

Step 3: Force NSO to Connect and Perform Initial Sync (sync-from)

What we are doing: We instruct NSO to actively connect to each device and perform a sync-from operation. This pulls the running configuration from the device into NSO’s datastore, which is required before any change operations.

admin@ncs# request devices device R1 sync-from
admin@ncs# request devices device XR1 sync-from

What just happened: Each sync-from triggers NSO to open a NETCONF session, issue requests to retrieve running configuration, and then translate and store the configuration into NSO’s internal datastore. During NETCONF sessions NSO and device exchange capability strings; if the device supports , NSO retrieves the full config. If the device has large configurations, sync may take longer.

Real-world note: For large-scale fleets, automating syncs can create significant load on devices. Schedule syncs during maintenance windows or stagger them to avoid management-plane congestion.

Verify:

admin@ncs# show devices device R1
device R1
  address: 10.0.0.11
  port: 830
  username: admin
  device-type: netconf-cli
  admin-state: unlocked
  operational-state: connected
  sync-status: success
  last-sync-time: 2026-04-02T10:22:34Z

admin@ncs# show devices device XR1
device XR1
  address: 10.0.0.12
  port: 830
  username: admin
  device-type: netconf-xr
  admin-state: unlocked
  operational-state: connected
  sync-status: success
  last-sync-time: 2026-04-02T10:23:10Z

If sync-status shows success, NSO has the running-config. If failure, check credentials, connectivity, device logs.

Step 4: Verify Retrieved Config via RESTCONF (northbound check)

What we are doing: We query NSO’s northbound RESTCONF endpoint to fetch the stored device configuration for R1 to validate that the sync stored the running-config in NSO. This demonstrates how automation systems can verify device state without direct device access.

curl -s -u admin:Lab@123 -H "Accept: application/yang-data+json" \
  https://lab.nhprep.com:443/restconf/data/devices/device=R1/config | python -m json.tool

What just happened: The curl command authenticates to NSO’s RESTCONF endpoint and requests the config subtree for device R1. NSO returns JSON that represents the device configuration as parsed by the NED. The JSON output confirms NSO’s internal datastore contains the device config; automation systems can use this as ground truth.

Real-world note: Using NSO’s northbound APIs avoids giving management systems direct device credentials; instead, they interact only with the controller.

Verify (sample expected output):

{
    "device": {
        "name": "R1",
        "config": {
            "interfaces": {
                "interface": [
                    {
                        "name": "GigabitEthernet0/0",
                        "description": "uplink",
                        "ipv4": {
                            "address": [
                                {
                                    "ip": "192.0.2.11",
                                    "netmask": "255.255.255.0"
                                }
                            ]
                        }
                    }
                ]
            },
            "routing": {
                "static": {
                    "route": [
                        {
                            "prefix": "0.0.0.0/0",
                            "next-hop": "192.0.2.1"
                        }
                    ]
                }
            }
        }
    }
}

This output shows the interfaces and routing that were retrieved — the exact structure depends on the device NED.

Step 5: Demonstrate Multi-vendor Push (Dry-run validate before change)

What we are doing: Before applying changes, perform a dry-run validation using NSO’s validation capability (preview or commit dry-run). This checks whether NSO can generate the device-specific configuration without actually pushing it — essential in mixed-vendor environments to prevent syntactic or semantic config errors.

admin@ncs# devices device R1 config lock
admin@ncs# config
admin@ncs(config)# devices device R1 config
admin@ncs(config-dev-R1-config)# interfaces interface GigabitEthernet0/0 description "Managed by NSO"
admin@ncs(config-dev-R1-config)# commit dry-run
admin@ncs(config-dev-R1-config)# exit
admin@ncs(config)# exit
admin@ncs# devices device R1 config unlock

What just happened: The config block created a local change to R1’s config in NSO and ran commit dry-run. NSO translated that logical change into the device-specific configuration and validated syntax using the NED (no change was pushed to the actual device). Lock/unlock prevents concurrent modifications during the check.

Real-world note: Always use dry-run or preview features prior to production changes. In multi-vendor deployments, this reduces risk from vendor-specific syntax errors.

Verify:

admin@ncs# show services dry-run
Service dry-run results:
  Device: R1
    Action: prospective-commit
    Status: success
    Generated CLI:
      interface GigabitEthernet0/0
        description Managed by NSO

This confirms NSO can generate the required device commands for R1.

Verification Checklist

Check 1: Device entries exist in NSO
- Command: show devices
- Expected: R1 and XR1 listed with correct IPs and device-type.
Check 2: sync-from completed successfully
- Command: show devices device R1 and show devices device XR1
- Expected: operational-state: connected and sync-status: success.
Check 3: NSO northbound configuration reflects device running-config
- Command: RESTCONF GET to /restconf/data/devices/device=R1/config
- Expected: JSON body containing interface and routing configuration as retrieved.

Common Mistakes

Symptom	Cause	Fix
Device shows operational-state: disconnected	NETCONF port blocked or device NETCONF not enabled	Verify IP reachability (ping), ensure device NETCONF is configured and management ACLs allow NSO IP
sync-status: failure	Wrong credentials or wrong device-type (NED mismatch)	Confirm username/password, verify correct NED selection; try manual NETCONF via netconf client
RESTCONF GET returns authentication error	Using wrong credentials or RESTCONF service not secured	Use `admin:Lab@123` as in examples and ensure NSO RESTCONF is enabled and bound to lab.nhprep.com
Dry-run fails with vendor syntax error	NED does not support the requested configuration or syntax variants	Adjust logical config to match device capabilities or use correct device-type NED

Key Takeaways

Always catalog devices in NSO with correct address, port, credentials, and device-type before attempting automation; wrong NED selection is a frequent cause of failures.
sync-from is a required operation to ensure NSO has an authoritative copy of running-config before applying changes or running workflows.
NETCONF capability exchange () and RPCs are the underlying mechanisms used by NSO to fetch device configuration.
Use NSO’s dry-run/preview features to validate multi-vendor generated device commands before pushing changes — this prevents syntax and semantic errors on production devices.

Warning: In production, scale and timing matter. Mass sync-from operations generate management-plane load; stagger operations and monitor device CPU/memory during onboarding.

This completes Lesson 2: NSO Device Management. In the next lesson we'll create an NSO workflow that uses the synched device configurations to verify OS-image compatibility and trigger an upgrade sequence.